AB測試:基礎概念、應用場景及入門指南
?編輯導語:AB測試這項技術最早被應用于美國的互聯網市場,進入國內市場也不過6、7年時間。2000年左右,以谷歌為首的互聯網企業開始采用AB測試的方法,運用數據幫助企業做決策管理,降低試錯成本,促進業務增長。2010年以后,AB測試開始出現產品化的趨勢,并成為企業決策的一項重要工具。
今天和大家分享一下關于AB測試的基礎知識。
一、AB測試是什么
互聯網行業變化很快,很多產品的迭代速度都是按周甚至是按天來的。無論是產品的優化方向,還是決策的制定,都需要有數據來說話。
目前,大部分產品迭代的方式,是直接將某版本發布給全部用戶。一旦遇到線上BUG或者數據效果不好,就不得不緊急修復或者功能優化,有時甚至需要回滾到前一版本。
這對用戶體驗、項目進度影響是很大的,如何能解決這個問題呢?
AB測試能很好的避免這個問題。所謂AB測試,就是在正式發版上線前,將用戶流量對應分成幾組,讓用戶分別看到不同的方案設計,根據幾組用戶的真實數據反饋,進行數據效果的校驗。
如果新版本數據呈現沒問題,再考慮將新版本向全量放開,從而可以有效減少線上全用戶發生事故的概率,提升用戶體驗。簡單理解,其實就是初中學的對照試驗。一組是對照組,一組是實驗組。
哪些場景比較適合進行AB測試呢?
二、AB測試的應用場景
AB測試通常用在以下幾個場景:
1. UI的優化
這是比較常見的場景。
不像功能的設計,存在著很多邏輯上的思路,經常還是可以確定哪種方案好,哪種方案不好。UI的優化,往往是很“藝術”層面的。往往看到真實數據前,誰也難以說明哪種設計能帶來更好的數據效果。如下圖:
上圖就是一個顏色的變化,這種情況下比較適合通過AB測試完成最終方案的確定。
2. 文案變化
這個其實和UI層面的優化很類似。同一個按鈕,叫【現在申請】還是【立刻申請】呢?
如何決策,還是交給AB測試吧~
3. 頁面布局
頁面布局,主要指的是同頁面中的不同元素的排列方式。
4. 算法優化
算法優化,應該也是AB測試的一個重要場景。
上線前的算法,基本都是基于歷史數據進行算法模型的訓練、搭建。在本地模型效果再好,上線后也不一定有良好的表現。只有線上才是檢驗算法效果的決定性標準。
但誰也不能確保上線后的效果吧?那這時先用小流量做一些AB測試,是非常不錯及通用的選擇。
三、流量分配
AB測試的基礎概念也講了一些,其中很重要的一個概念就是用戶流量分組。實際落地時,是按照一定的規則,讓用戶隨機訪問某個版本,那具體該如何進行流量的分配呢?
關于流量分配,主要的要點有兩個:同層互斥分配和分層流量正交。
1. 同層互斥分配
每個分層都擁有全部流量。在同一個分層中,多個試驗共用100%的流量,試驗之間流量互斥。例如在同一分層中,試驗1占用了40%流量,則試驗2最多只可使用60%流量,以此類推。
有以下示意圖:
當同時運行多個試驗時,如果希望試驗結果盡可能精確,需要確保試驗之間互不干擾,則建議將試驗建立在同一分層,同一個用戶只會進入該分層中的一個試驗。
2. 分層流量正交
分層意為復用用戶流量,如果驗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協議。
公眾號跟過來的
剛轉型產品。幾個概念都非常受用,期待更新
感謝關注~歡迎關注同名gongzhonghao~!