阿裡妹導讀：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 來助力業務發展了。
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 的統計學本質就是做假設檢驗。
當然在開始假設檢驗前，我們要先驗證一下，我們的資料本身是正确的。
然後我們就要根據實驗的資料看：
- 實驗顯著性是否滿足要求？
- 實驗的結論是否證明了假設對資料的提升？
- 實驗是否帶來了漏鬥中其他資料變差？
關于實驗的顯著性，這裡我們還會用到一個 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 的能力要融入到其他平台的成本還是非常高的。
我想這些也是我們接下來一步步需要解決的問題。
原文釋出時間：2020-01-09
作者：喬福
本文來自阿裡雲合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。