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

什么是 A/B Testing?

關于A/B 有很多層的定義，通俗來說，A/B 是一種工具，通過分隔 A 和 B 兩個版本，統計數據，進而看哪個版本的數據效果更好，對產品目標更有幫助。

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

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

我覺得這樣定義的好處是，A/B 不僅僅是一個工具，更多是一種與業務發展融合在一起的迭代思路，并且在 A/B 背后實際有著科學的統計學的依據支撐著，你也會更加關注每一個業務假設是否真的是有效的。

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

產品在什么階段適合 A/B Testing?

• 對于一個初創項目，產品剛剛孵化，這種時候不太適合做 A/B 測試，因為這個時候我們的目標相對是比較明確的，就是快速形成“原型”產品和大框架，把“產品生下來”，因此也基本上不會有太多摳細節的部分。
• 而當產品到了一定的階段，模式已經成型比較穩定，相對處于快速迭代的階段，就比較適合利用 A/B Testing 來助力業務發展了。

[[312319]] 

A/B Testing 的步驟

說 A/B Testing 的步驟之前，我想說，A/B Testing 實驗不是說你做了一次實驗拿到結果就再也不用做 A/B 了，它更多是一個不斷優化和理解產品以及用戶的過程。

因此，這里所說的 A/B Testing 的步驟不是指我們如何在平臺上面配置一次 A/B 實驗，而是更大范圍的，如何用 A/B Testing 優化產品的步驟。

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

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

1. 建立產品漏斗

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

2. 確定產品鏈路核心指標

在明確了產品的漏斗之后，我們需要明確要觀察產品鏈路中的哪些核心指標。

如果你的關注點僅僅是一個頁面，那你可能更多需要細看當前頁面的用戶指標;如果你關注的產品鏈路比較長，你應該關注整個鏈路上各個節點之間的指標。

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

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

3. 觀察指標，提出優化假設

接著我們的產品同學就可以根據指標分析當前的業務狀況，然后結合需要優化的數據指標，提出相對應的業務假設。這里開始，就有統計學知識入場了。

這里我們說假設實際上包含了兩種：

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

備擇假設(Alternative Hypothesis)，代表我們希望通過試驗結果驗證的假設。

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

假如說我們的場景是：優化頁面上面按鈕的點擊率，而我們的預計做法是加大按鈕的尺寸。

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

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

另外要注意的是，在假設檢驗中，原假設和備擇假設有且只有一個成立。

確定了假設，接下來我們就進入實驗的設計了。 

4. 設計A/B 實驗方案

實驗設計上，我們要明確一些信息：

• 我們要寫明，實驗目標是什么，包括上面說的假設。
• 在實驗分組上，我們要考慮如何劃分分組，是否要有 A/A 對照，要切多少流量來做實驗?
• 另外在投放上，我們的實驗要針對誰做?是否要投放在特定的地區?或是投放在特定的端?

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

5. 開發 A/B 實驗

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

6. 運行實驗

開發完成后，我們就要準備上線了，這時要設定實驗運行時的配置，例如：

我們主要需要設定：

• 指標的樣本量(反過來樣本量也決定了實驗的運行時長)。
• 實驗的顯著性水平(α)、統計功效(1-β),一般業界普遍設定 α 為 5%，β 為 10%~20%。

為什么要設置顯著性水平(α)、統計功效(1-β)?

這是因為，所有的實驗，在概率統計學上都是存在誤差的，而誤差會導致我們做出錯誤的判斷。

這里常見的錯誤判斷包括：

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

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

• 第一類的錯誤是指，加大按鈕的尺寸，按鈕點擊率實際沒有什么變化，但因為誤差，我們認為有變化。
• 第二類的錯誤是指，加大按鈕的尺寸，按鈕點擊率實際產生了變化，但因為誤差，我們認為沒有變化。

這里如果覺得繞，可以多感受幾遍。設置好這些，發布完代碼后，我們就可以發布實驗了。 

7. 實驗數據分析

我們前面說過: A/B Testing 的統計學本質就是做假設檢驗。

當然在開始假設檢驗前，我們要先驗證一下，我們的數據本身是正確的。

然后我們就要根據實驗的數據看：

1. 實驗顯著性是否滿足要求?
2. 實驗的結論是否證實了假設對數據的提升?
3. 實驗是否帶來了漏斗中其他數據變差?

關于實驗的顯著性，這里我們還會用到一個 z-test 計算 p 值的方式來進行校驗。

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

8. 實驗結論

最后，我們根據這次實驗的分析結果，總結實驗結論。

例如：這次實驗我們具體通過做了 xx 提升了 xx 指標，并且沒有對其他的指標產生影響，通過這次實驗的結論，我們推理出在 xx 場景下，適合使用 xx 方式來提升 xx 指標。

當然如果沒有達到預期的目標，我們就要調整策略提出更進一步的優化假設。

這 8 步，有時候我們也會縮減為一個 5 步的循環：

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

在電商業務中做 A/B Testing，我們面臨什么挑戰?

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

我個人覺得主要的挑戰就是：

A/B 測試直觀感覺成本高，業務有接受門檻。

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

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

另外 A/B 不是一次性的事情，而是一個長期迭代的過程，大家做 A/B 是要以“不斷優化”的心態來做，而不是“一次到位”。

從 A/B “平臺”的角度來說，要幫助業務解決這些挑戰，我們有很多的問題要解：

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

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

2.開發更加規范，我們需要從開發 sdk 上規范業務的定制 A/B 開發，提供開發。

3.開發效率提升：

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

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

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

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