編輯導語：AB測試這項技術最早被應用於美國的互聯網市場，進入國內市場也不過6、7年時間。2000年左右，以谷歌為首的互聯網企業開始採用AB測試的方法，運用數據幫助企業做決策管理，降低試錯成本，促進業務增長。2010年以後，AB測試開始出現產品化的趨勢，併成為企業決策的一項重要工具。
今天和大家分享一下關於AB測試的基礎知識。
一、AB測試是什麼互聯網行業變化很快，很多產品的迭代速度都是按周甚至是按天來的。無論是產品的優化方向，還是決策的制定，都需要有數據來説話。
目前，大部分產品迭代的方式，是直接將某版本發佈給全部用户。一旦遇到線上BUG或者數據效果不好，就不得不緊急修復或者功能優化，有時甚至需要回滾到前一版本。
這對用户體驗、項目進度影響是很大的，如何能解決這個問題呢？
AB測試能很好的避免這個問題。所謂AB測試，就是在正式發版上線前，將用户流量對應分成幾組，讓用户分別看到不同的方案設計，根據幾組用户的真實數據反饋，進行數據效果的校驗。
如果新版本數據呈現沒問題，再考慮將新版本向全量放開，從而可以有效減少線上全用户發生事故的概率，提升用户體驗。簡單理解，其實就是初中學的對照試驗。一組是對照組，一組是實驗組。
哪些場景比較適合進行AB測試呢？
二、AB測試的應用場景AB測試通常用在以下幾個場景：
1. UI的優化這是比較常見的場景。
不像功能的設計，存在着很多邏輯上的思路，經常還是可以確定哪種方案好，哪種方案不好。UI的優化，往往是很“藝術”層面的。往往看到真實數據前，誰也難以説明哪種設計能帶來更好的數據效果。如下圖：
上圖就是一個顏色的變化，這種情況下比較適合通過AB測試完成最終方案的確定。
2. 文案變化這個其實和UI層面的優化很類似。同一個按鈕，叫【現在申請】還是【立刻申請】呢？
如何決策，還是交給AB測試吧~
3. 頁面佈局頁面佈局，主要指的是同頁面中的不同元素的排列方式。
算法優化，應該也是AB測試的一個重要場景。
上線前的算法，基本都是基於歷史數據進行算法模型的訓練、搭建。在本地模型效果再好，上線後也不一定有良好的表現。只有線上才是檢驗算法效果的決定性標準。
但誰也不能確保上線後的效果吧？那這時先用小流量做一些AB測試，是非常不錯及通用的選擇。
三、流量分配AB測試的基礎概念也講了一些，其中很重要的一個概念就是用户流量分組。實際落地時，是按照一定的規則，讓用户隨機訪問某個版本，那具體該如何進行流量的分配呢？
關於流量分配，主要的要點有兩個：同層互斥分配和分層流量正交。
1. 同層互斥分配每個分層都擁有全部流量。在同一個分層中，多個試驗共用100%的流量，試驗之間流量互斥。例如在同一分層中，試驗1佔用了40%流量，則試驗2最多隻可使用60%流量，以此類推。
有以下示意圖：
當同時運行多個試驗時，如果希望試驗結果儘可能精確，需要確保試驗之間互不干擾，則建議將試驗建立在同一分層，同一個用户只會進入該分層中的一個試驗。
分層意為複用用户流量，如果驗1和試驗2使用不同的分層，則試驗1和試驗2均可分配最多100%的流量。在此情況下，同一個用户將會同時進入試驗1和試驗2。
當兩個試驗處於不同層時，需要確保試驗內容互不相關，否則將會干擾試驗數據。
目前平台中的每個實驗，獨立為一個實驗層，一份流量穿越每層實驗時，都會隨機打散再重組，保證每層流量數量相同。
舉個例子：假設我現在有2個實驗，實驗A（實驗組標記為版本A1，對照組標記為版本A2）分佈於實驗層1，取用該層100%的流量；實驗B（實驗組標記為B1，對照組標記為B2）分佈於實驗層2，也取用該層100%的流量（要注意，實驗層1和實驗層2實際上是同一批用户，實驗層2只是複用了實驗層1的流量）。
如果把A1組的流量分成2半，一份放進B1組，一份放進B2組；再把A2組的流量也分成2半，一份放進B1組，一份放進B2組。那麼兩個實驗對於流量的調用就會如下圖所示。此時實驗A和實驗B之間，就形成了流量“正交”。
關於AB測試，今天就先分享這些。下篇文章將分享一下行業中AB測試系統的調研，看看各大廠商是如何將AB測試產品化的。
本文由 @冬至 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。