A/B 相信大家都或多或少做過，但是你對 A/B 測試的了解有多少，A/B 僅僅是分流嗎?怎么樣才是科學(xué)的 A/B 實(shí)驗(yàn)。下面阿里前端技術(shù)專家會結(jié)合最近的一些學(xué)習(xí)，系統(tǒng)性和通俗性地說一說 A/B Testing，希望對大家有所幫助。

什么是 A/B Testing?

關(guān)于A/B 有很多層的定義，通俗來說，A/B 是一種工具，通過分隔 A 和 B 兩個(gè)版本，統(tǒng)計(jì)數(shù)據(jù)，進(jìn)而看哪個(gè)版本的數(shù)據(jù)效果更好，對產(chǎn)品目標(biāo)更有幫助。

在這里我更多想從 A/B 本身的意義來說一下它的定義。

以我們的業(yè)務(wù)迭代為例，我們會定義產(chǎn)品的業(yè)務(wù)數(shù)據(jù)指標(biāo)(這些指標(biāo)通常是可以直接和間接反映我們的業(yè)務(wù)目標(biāo)的)，然后我們在業(yè)務(wù)迭代中不斷提出假設(shè)，期望通過做這些假設(shè)的改變來提升相對應(yīng)的業(yè)務(wù)指標(biāo)。而在這里 A/B 就是用來衡量我們提出的業(yè)務(wù)改進(jìn)假設(shè)是否有效的一種方法，從統(tǒng)計(jì)學(xué)意義上說是一類假設(shè)驗(yàn)證的方法。

我覺得這樣定義的好處是，A/B 不僅僅是一個(gè)工具，更多是一種與業(yè)務(wù)發(fā)展融合在一起的迭代思路，并且在 A/B 背后實(shí)際有著科學(xué)的統(tǒng)計(jì)學(xué)的依據(jù)支撐著，你也會更加關(guān)注每一個(gè)業(yè)務(wù)假設(shè)是否真的是有效的。

用戶增長中最忌諱的是盲目套用其他業(yè)務(wù)線的增長手段，而忽視了自己業(yè)務(wù)的分析和推導(dǎo)的過程，凡事是否正確，需要我們測一測才知道。

產(chǎn)品在什么階段適合 A/B Testing?

• 對于一個(gè)初創(chuàng)項(xiàng)目，產(chǎn)品剛剛孵化，這種時(shí)候不太適合做 A/B 測試，因?yàn)檫@個(gè)時(shí)候我們的目標(biāo)相對是比較明確的，就是快速形成“原型”產(chǎn)品和大框架，把“產(chǎn)品生下來”，因此也基本上不會有太多摳細(xì)節(jié)的部分。
• 而當(dāng)產(chǎn)品到了一定的階段，模式已經(jīng)成型比較穩(wěn)定，相對處于快速迭代的階段，就比較適合利用 A/B Testing 來助力業(yè)務(wù)發(fā)展了。

[[312319]] 

A/B Testing 的步驟

說 A/B Testing 的步驟之前，我想說，A/B Testing 實(shí)驗(yàn)不是說你做了一次實(shí)驗(yàn)?zāi)玫浇Y(jié)果就再也不用做 A/B 了，它更多是一個(gè)不斷優(yōu)化和理解產(chǎn)品以及用戶的過程。

因此，這里所說的 A/B Testing 的步驟不是指我們?nèi)绾卧谄脚_上面配置一次 A/B 實(shí)驗(yàn)，而是更大范圍的，如何用 A/B Testing 優(yōu)化產(chǎn)品的步驟。

總的來說，業(yè)界一般會給 A/B Testing 劃分為 8 個(gè)步驟。

這是我學(xué)習(xí)看到的 8 階段 A/B 劃分，可以看到我們技術(shù)同學(xué)最關(guān)注的創(chuàng)建 A/B 實(shí)驗(yàn)，實(shí)際上只是其中的第 4、5 步，而除此之前，我們還有很多工作要做，那么要科學(xué)做 A/B 我們究竟每一步應(yīng)該做些啥呢?我們來看一下。

1. 建立產(chǎn)品漏斗

這一步往往在我們的工作中會被忽略掉，我覺得，不管是業(yè)務(wù)還是技術(shù)同學(xué)，我們都有必要了解自己的產(chǎn)品鏈路以及用戶的漏斗，知道了用戶從哪里來，我們希望用戶去哪里，才能夠有準(zhǔn)備的做增長。例如用戶拉新的流程，它的漏斗大致可以是：

2. 確定產(chǎn)品鏈路核心指標(biāo)

在明確了產(chǎn)品的漏斗之后，我們需要明確要觀察產(chǎn)品鏈路中的哪些核心指標(biāo)。

如果你的關(guān)注點(diǎn)僅僅是一個(gè)頁面，那你可能更多需要細(xì)看當(dāng)前頁面的用戶指標(biāo);如果你關(guān)注的產(chǎn)品鏈路比較長，你應(yīng)該關(guān)注整個(gè)鏈路上各個(gè)節(jié)點(diǎn)之間的指標(biāo)。

以上面“用戶拉新”的例子來說，我們可能要關(guān)注每一個(gè)節(jié)點(diǎn)的用戶量(PV/UV)，還要看每一層的轉(zhuǎn)化率(例如: 點(diǎn)擊/曝光)等等。

確定了指標(biāo)之后，我們就需要把這些指標(biāo)納入長期的觀察中。 

3. 觀察指標(biāo)，提出優(yōu)化假設(shè)

接著我們的產(chǎn)品同學(xué)就可以根據(jù)指標(biāo)分析當(dāng)前的業(yè)務(wù)狀況，然后結(jié)合需要優(yōu)化的數(shù)據(jù)指標(biāo)，提出相對應(yīng)的業(yè)務(wù)假設(shè)。這里開始，就有統(tǒng)計(jì)學(xué)知識入場了。

這里我們說假設(shè)實(shí)際上包含了兩種：

原假設(shè)，又叫零假設(shè)、無假設(shè)(Null Hypothesis)，代表我們希望通過試驗(yàn)結(jié)果推翻的假設(shè)。

備擇假設(shè)(Alternative Hypothesis)，代表我們希望通過試驗(yàn)結(jié)果驗(yàn)證的假設(shè)。

可以看得出原假設(shè)是悲觀主義的。為啥要這么分一下，說實(shí)在我自己一開始也很懵逼。我們這里先提出這兩個(gè)概念(原假設(shè)、備擇假設(shè))，他們的作用在后面幾步會看到。

假如說我們的場景是：優(yōu)化頁面上面按鈕的點(diǎn)擊率，而我們的預(yù)計(jì)做法是加大按鈕的尺寸。

那么原假設(shè)的表述就是：加大按鈕的尺寸，按鈕點(diǎn)擊率不會有任何變化。

而備擇假設(shè)的表述則是：加大按鈕的尺寸，按鈕點(diǎn)擊率會有影響(我覺得影響包含提升和降低，不過大多數(shù)的講解中這個(gè)假設(shè)只會寫提升，我理解我們正常不會假設(shè)為數(shù)據(jù)降低，這點(diǎn)可以探討一下)。

另外要注意的是，在假設(shè)檢驗(yàn)中，原假設(shè)和備擇假設(shè)有且只有一個(gè)成立。

確定了假設(shè)，接下來我們就進(jìn)入實(shí)驗(yàn)的設(shè)計(jì)了。 

4. 設(shè)計(jì)A/B 實(shí)驗(yàn)方案

實(shí)驗(yàn)設(shè)計(jì)上，我們要明確一些信息：

• 我們要寫明，實(shí)驗(yàn)?zāi)繕?biāo)是什么，包括上面說的假設(shè)。
• 在實(shí)驗(yàn)分組上，我們要考慮如何劃分分組，是否要有 A/A 對照，要切多少流量來做實(shí)驗(yàn)?
• 另外在投放上，我們的實(shí)驗(yàn)要針對誰做?是否要投放在特定的地區(qū)?或是投放在特定的端?

另外，A/B 實(shí)驗(yàn)中最好每次只做一個(gè)“變量”的改變(雖然受限于時(shí)間你也可以同時(shí)做多個(gè)變量，例如經(jīng)典的奧巴馬參選的 A/B 版本海報(bào))，這樣對于后續(xù)的數(shù)據(jù)分析和拿明確的結(jié)論會比較有好處。

5. 開發(fā) A/B 實(shí)驗(yàn)

這一步，是我們最熟悉的階段，一般的項(xiàng)目需求評審都是從這里開始的，開發(fā)同學(xué)會借助 Runtime SDK 編寫 UI 邏輯、分桶邏輯等，這里先不贅述里面的細(xì)節(jié)。

6. 運(yùn)行實(shí)驗(yàn)

開發(fā)完成后，我們就要準(zhǔn)備上線了，這時(shí)要設(shè)定實(shí)驗(yàn)運(yùn)行時(shí)的配置，例如：

我們主要需要設(shè)定：

• 指標(biāo)的樣本量(反過來樣本量也決定了實(shí)驗(yàn)的運(yùn)行時(shí)長)。
• 實(shí)驗(yàn)的顯著性水平(α)、統(tǒng)計(jì)功效(1-β),一般業(yè)界普遍設(shè)定 α 為 5%，β 為 10%~20%。

為什么要設(shè)置顯著性水平(α)、統(tǒng)計(jì)功效(1-β)?

這是因?yàn)?，所有的?shí)驗(yàn)，在概率統(tǒng)計(jì)學(xué)上都是存在誤差的，而誤差會導(dǎo)致我們做出錯(cuò)誤的判斷。

這里常見的錯(cuò)誤判斷包括：

• 第 I 類錯(cuò)誤(棄真錯(cuò)誤)：原假設(shè)為真時(shí)拒絕原假設(shè);第 I 類錯(cuò)誤的概率記為 α(alpha)，對應(yīng)就是顯著性水平值。
• 第 II 類錯(cuò)誤(取偽錯(cuò)誤)：原假設(shè)為假時(shí)未拒絕原假設(shè)。第 II 類錯(cuò)誤的概率記為 β(Beta)，取反后(1-β)對應(yīng)就是統(tǒng)計(jì)功效值。

再白話一些，以上面的例子來說：

• 第一類的錯(cuò)誤是指，加大按鈕的尺寸，按鈕點(diǎn)擊率實(shí)際沒有什么變化，但因?yàn)檎`差，我們認(rèn)為有變化。
• 第二類的錯(cuò)誤是指，加大按鈕的尺寸，按鈕點(diǎn)擊率實(shí)際產(chǎn)生了變化，但因?yàn)檎`差，我們認(rèn)為沒有變化。

這里如果覺得繞，可以多感受幾遍。設(shè)置好這些，發(fā)布完代碼后，我們就可以發(fā)布實(shí)驗(yàn)了。 

7. 實(shí)驗(yàn)數(shù)據(jù)分析

我們前面說過: A/B Testing 的統(tǒng)計(jì)學(xué)本質(zhì)就是做假設(shè)檢驗(yàn)。

當(dāng)然在開始假設(shè)檢驗(yàn)前，我們要先驗(yàn)證一下，我們的數(shù)據(jù)本身是正確的。

然后我們就要根據(jù)實(shí)驗(yàn)的數(shù)據(jù)看：

1. 實(shí)驗(yàn)顯著性是否滿足要求?
2. 實(shí)驗(yàn)的結(jié)論是否證實(shí)了假設(shè)對數(shù)據(jù)的提升?
3. 實(shí)驗(yàn)是否帶來了漏斗中其他數(shù)據(jù)變差?

關(guān)于實(shí)驗(yàn)的顯著性，這里我們還會用到一個(gè) z-test 計(jì)算 p 值的方式來進(jìn)行校驗(yàn)。

p 值表示，我們觀察實(shí)驗(yàn)樣本有多大的概率是產(chǎn)生于隨機(jī)過程的，p 值越小，我們越有信心認(rèn)為原假設(shè)是不成立的，如果 p 值小于顯著性水平(α)，則我們可以認(rèn)為原假設(shè)是不成立的。

8. 實(shí)驗(yàn)結(jié)論

最后，我們根據(jù)這次實(shí)驗(yàn)的分析結(jié)果，總結(jié)實(shí)驗(yàn)結(jié)論。

例如：這次實(shí)驗(yàn)我們具體通過做了 xx 提升了 xx 指標(biāo)，并且沒有對其他的指標(biāo)產(chǎn)生影響，通過這次實(shí)驗(yàn)的結(jié)論，我們推理出在 xx 場景下，適合使用 xx 方式來提升 xx 指標(biāo)。

當(dāng)然如果沒有達(dá)到預(yù)期的目標(biāo)，我們就要調(diào)整策略提出更進(jìn)一步的優(yōu)化假設(shè)。

這 8 步，有時(shí)候我們也會縮減為一個(gè) 5 步的循環(huán)：

總的來說，所做的事情是差不多的。

在電商業(yè)務(wù)中做 A/B Testing，我們面臨什么挑戰(zhàn)?

說了這些，我們再來看看目前在電商中做 A/B 測試，我們都面臨什么樣的挑戰(zhàn)?

我個(gè)人覺得主要的挑戰(zhàn)就是：

A/B 測試直觀感覺成本高，業(yè)務(wù)有接受門檻。

電商業(yè)務(wù)都講究跑得快，這點(diǎn)我也和不少同學(xué)聊過，其實(shí)大家對于接受做 A/B 測試這件事情，感覺不是這么的 buy-in，原因還是直觀感覺成本高，開發(fā)得開發(fā)兩(n)個(gè)版本，耽誤了上線時(shí)間。不過講道理來說，我們不僅僅要追求“跑得快”，還得“方向?qū)?rdquo;。

相信前面說了這么多，我們可以看到結(jié)合 A/B Testing 來做業(yè)務(wù)，是一個(gè)比較科學(xué)的過程，有 A/B Testing 我們在業(yè)務(wù)過程中會更加注重假設(shè)求證、數(shù)據(jù)推導(dǎo)以及驗(yàn)證，同時(shí) A/B 上線相比“一把梭上功能”也可以降低迭代帶來的業(yè)務(wù)風(fēng)險(xiǎn)，甚至結(jié)合 A/B 你可以發(fā)掘業(yè)務(wù)中存在的問題，更加了解你的用戶的行為，此外通過 A/B 獲得的業(yè)務(wù)的增長經(jīng)驗(yàn)可以沉淀下來通用化。

另外 A/B 不是一次性的事情，而是一個(gè)長期迭代的過程，大家做 A/B 是要以“不斷優(yōu)化”的心態(tài)來做，而不是“一次到位”。

從 A/B “平臺”的角度來說，要幫助業(yè)務(wù)解決這些挑戰(zhàn)，我們有很多的問題要解：

解決A/B 成本高的問題(這里我們從幾個(gè)角度來解決)：

1.平臺的操作效率(是否簡單易用)，平臺工具是否通俗易懂(A/B 那么多統(tǒng)計(jì)學(xué)的概念的理解成本能否被我們平臺側(cè)抹平)。

2.開發(fā)更加規(guī)范，我們需要從開發(fā) sdk 上規(guī)范業(yè)務(wù)的定制 A/B 開發(fā)，提供開發(fā)。

3.開發(fā)效率提升：

• 從工程側(cè)，我們可以利用代碼腳手架、代碼生成等方式來提升效率。
• 從平臺功能上來說，我們可以提供 UI Editor 等之類的工具，把一些“靜態(tài)配置”類的部分開放給運(yùn)營和產(chǎn)品，允許他們做改動(dòng)來做 A/B 實(shí)驗(yàn)，減少開發(fā)人員自己的投入。

4.A/B 的能力需要融入到其他的流程、平臺、系統(tǒng)里面。

未來運(yùn)營在使用其他平臺的時(shí)候，不會感覺 A/B 配置是一個(gè)割裂的部分，當(dāng)然這里的方案也是需要我們好好思考的，現(xiàn)在 A/B 的能力要融入到其他平臺的成本還是非常高的。

我想這些也是我們接下來一步步需要解決的問題。