文章發佈於公號【數智物語】 （ID：decision_engine），關注公號不錯過每一篇乾貨。
來源 | 中國統計網
2000年Google的工程師第一次將AB測試用於測試搜索結果頁展示多少搜索結果更合適，雖然那次的AB測試因為搜索結果加載速度的問題失敗了，但是這次的AB測試可以認為是Google的第一次AB測試。
從那以後AB測試被廣泛應用於互聯網公司的優化迭代, 每年數萬個AB實驗被Google、Amazon、eBay、阿里等主流互聯網公司應用於線上進行UI內容優化、算法優化、收益優化等方方面面。
01
AB測試的基本概念
1. 什麼是AB測試？
AB測試的概念來源於生物醫學的雙盲測試，雙盲測試中病人被隨機分成兩組，在不知情的情況下分別給予安慰劑和測試用藥，經過一段時間的實驗後再來比較這兩組病人的表現是否具有顯著的差異，從而決定測試用藥是否有效。
互聯網公司的AB測試也採用了類似的概念：將Web或App界面或流程的兩個或多個版本，在同一時間維度，分別讓兩個或多個屬性或組成成分相同（相似）的訪客群組訪問，收集各群組的用戶體驗數據和業務數據，最後分析評估出最好版本正式採用。
從對AB測試的定義中可以看出AB測試強調的是同一時間維度對相似屬性分組用戶的測試，時間的統一性有效的規避了因為時間、季節等因素帶來的影響，而屬性的相似性則使得地域、性別、年齡等等其他因素對效果統計的影響降至最低。
2. A/B測試的好處
1. 消除客戶體驗（UX）設計中不同意見的紛爭，根據實際效果確定最佳方案；
2. 通過對比試驗，找到問題的真正原因，提高產品設計和運營水平；
3. 建立數據驅動、持續不斷優化的閉環過程；
4. 通過A/B測試，降低新產品或新特性的發佈風險，為產品創新提供保障。
3. A/B測試的限制
1. 在App和Web開發階段，程序中添加用於製作A/B版本和採集數據的代碼由此引起的開發和QA的工作量很大，ROI（投資回報率）很低；
2. AB測試的場景受到限制，App和Web發佈後，無法再增加和更改AB測試場景；
3. 額外的A/B測試代碼，增加了App和Web後期維護成本。
02
AB測試的基本步驟
AB測試是一個反覆迭代優化的過程，它的基本步驟如下圖所示可以劃分為：
現狀分析並建立假設：分析業務數據，確定當前最關鍵的改進點，作出優化改進的假設，提出優化建議；
設定目標，制定方案：設置主要目標，用來衡量各優化版本的優劣；設置輔助目標，用來評估優化版本對其他方面的影響。
設計與開發：製作2個或多個優化版本的設計原型並完成技術實現：
分配流量：確定每個線上測試版本的分流比例，初始階段，優化方案的流量設置可以較小，根據情況逐漸增加流量。
採集並分析數據：收集實驗數據，進行有效性和效果判斷：統計顯著性達到95%或以上並且維持一段時間，實驗可以結束；如果在95%以下，則可能需要延長測試時間；如果很長時間統計顯著性不能達到95%甚至90%，則需要決定是否中止試驗。
根據試驗結果確定發佈新版本、調整分流比例繼續測試或者在試驗效果未達成的情況下繼續優化迭代方案重新開發上線試驗
03
影響AB測試結果準確性的因素
1. 樣本數量：流量樣本的數量不能過少
測試版本的流量如果太小又可能造成隨機結果的引入，試驗結果失去統計意義。
舉個例子：某電商網站對我的歷史訂單這個頁面進行改版的AB測試，測試的目標是提升用戶的復購，衡量的指標是經過這個頁面的單UV產生的GMV貢獻（單日GMV總數／單日進入UV）
假設這個頁面每天的UV在2000左右，而我們對新版本取的分流比例是2%，那麼一天就會有差不多40個UV進入試驗版本。如果試驗進行1周然後考察試驗結果，這是試驗的結果就很容易受到某些異常樣本的影響，譬如說某個土豪老王恰好分在了試驗組然後購買了一個高價值的東西，那麼老王的購買行為就可能帶偏整個測試組的統計結果。
但是需要強調的是，不能一昧追求大量的流量，流量過多，會增加試錯成本。AB測試是對線上生產環境的測試，而之所以進行AB測試通常是對測試中的改進版本所產生效果的好壞不能十分確定，所以測試版本的流量通常不宜過大。尤其對於那些影響範圍較大的改版（如主流程頁面的重大調整），影響用戶決策的新產品上線和其他具有風險性的功能上線通常採用先從小流量測試開始，然後逐步放大測試流量的方法。
所以，在試驗設計時需要預估進入試驗的樣本量，並根據觀察的數據及時進行調整。
2. 樣本質量：分流出的樣本是否有效
當測試結果顯示兩個版本沒有區別時，我們不能完全確定這樣的結果是因為方案本身的原因還是樣本質量的原因。例如，依舊是購物車復購的案例，假設樣本數量足夠多，但很不巧的是恰好實驗組裡大部分都是老王這樣的土豪，那麼結果依舊會產生偏差。這個時候我們還需要更進一步確定，實驗組裡究竟有沒有這樣的意外因素。
解決這個問題有個很好的方式：AA測試
將原始版本的流量中分出兩個和測試版本相同的流量也進入測試。
3. 測試的時間長短
測試的時間長短要根據進入的流量進行調整，不能太長或太短。
時間太短，沒有足夠的樣本進入測試版本，會出現樣本不足的情況，這時就需要通過拉長試驗時間的方式來累積足夠的樣本量進行比較。時間太長，就意味著線上系統需要同時維護多個可用的版本，長時間的AB測試無疑加大了系統的複雜性。
同時，在設定測試時間時還要考慮到用戶的行為週期和適應期。
①用戶的行為週期
對部分行業的產品來說，用戶的操作行為存在很大的週期性變化，例如電商用戶的購買行為有較強的周次規律，週末流量和購買量與工作日會有顯著差異，這時測試的週期應該能夠覆蓋一個完整的週期，也就是應該大於1周。
②用戶適應期
如果進行的是UI改版一類影響用戶體驗的測試，新版本上線後用戶通常需要有一個適應的過程，這時我們通常會在試驗開始時給用戶一個適應期讓用戶適應新的UI版本，然後再考察試驗的結果。適應期的長短通常以足量用戶流量參與試驗後的2到3天為宜。
4. 多個實驗並行的相互影響
在試驗版本的設計過程中還需要考慮線上進行多個試驗相互間的影響，譬如在電商的購買流程中我們同時對搜索算法【1】和商品詳情頁的UI【2】進行優化，這兩個變動貫穿在用戶的購物流程中，相互之間可能是有影響的，我們需要區分試驗中這兩種改動帶來的影響分別是怎樣的。
在這種情況下當然我們可以將用戶流量分成：
A：老的搜索算法【1A】和老的詳情頁UI【2A】
B：新的搜索算法【1B】和老的詳情頁UI【2A】
C：老的搜索算法【1A】和新的詳情頁UI【2B】
D：新的搜索算法【1B】和新的詳情頁UI【2B】
這樣分流的問題是對於流程中元素的改動，測試的版本是呈現指數上升的，在多個改動同時進行時就容易造成版本流量不足的情況。在這種情況下就需要引入試驗分層的概念，將實驗空間橫向和縱向進行劃分，縱向上流量可以進入獨佔實驗區域或者是並行實驗區域。
在獨佔實驗區域，只有一層，實驗可以獨享流量且不受其他實驗的干擾。在分層區域，不同的應用屬於不同layer，每個應用內部，又可以劃分為多層，層與層之間相互不影響。流量可以橫向經過多層，每一層可有多個實驗。流量在每一層都會被重新打散。
這樣多層次正交的實驗方式使多個併發實驗都可以保證具備一定流量的並行進行。
最後，在對用戶體驗有明顯影響的實驗中通常採用對用戶穩定的分流實現。即分到不同版本的用戶在多次登錄應用落入相同的實驗版本，這樣可以保證用戶體驗的一致性，保證用戶能夠在適應新版本的情況下有穩定的表現。
04
AB測試效果分析
關於AB實驗效果的分析通常分為兩個步驟：實驗有效性的判斷、實驗結果的比較。
1. 實驗有效性的判斷
①判斷實驗的分流是否已經到達所需要的最小樣本量，從而能夠以較大的概率拒絕兩類統計錯誤的發生。最小樣本量的判斷可以採用假設實驗目標指標符合正態分佈下，兩類錯誤發生概率的分位數的方式進行估算；
②判斷樣本有效性。採用AA測試，如果AA實驗的結果不存在顯著差異，那麼可以認為實驗結果是有效的，進而可以對新老版本的實驗結果進行進一步的判斷；
③判斷測試時間是否滿足了樣本需求，並考慮了適應期和行為週期；
④判斷是否收到並行實驗的影響。
2. 實驗結果的比較
在確認實驗有效後就可以對實驗的結果進行判斷了，通常通過比較新實驗版本和老版本是否存在顯著差異（前述的P值判斷），以及計算實驗結果指標的置信區間（通常選用指標的95%置信區間），從而判斷新版本是否相對老版本存在顯著提升或下降。
05
關於AB測試的一些誤區
最後，講一下關於AB測試的一些誤區，通過對這些誤區的理解希望能夠恰如其分的應用AB測試提升網站和產品的轉化等指標。
誤區1
AB測試運用成本過高，可以通過灰度發佈的方式來進行AB測試，進而避免同時維護不同版本的情況。
灰度發佈是應用發佈通常採用的方式，是指在黑與白之間，能夠平滑過渡的一種發佈方式。這種發佈方式讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B上面來。灰度發佈可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
這樣的方式的確可以起到分流的作用，但是這樣的分流是不穩定的，用戶的兩次訪問很有可能會被分到新老兩個版本上。同時，灰度發佈的分流單位通常是以服務器的流量為最小單位的，不能做到對測試流量的精確分配。
誤區2
用參加實驗的部分用戶的體驗質疑AB實驗結果的正確性。
經常碰到產品經理或是業務人員提出某些用戶在新版本的實驗中沒有轉化，而實際實驗數據體現新版本效果好於老版本的情況，從而質疑實驗的結果。AB實驗是基於統計的結果，是基於大樣本量的有效統計結果，實驗結果的好壞是針對參與實驗的大多數樣本而言的，個例不具備代表性。
誤區3
AB測試是優化Web應用的利器，應該在所有場合都應用AB測試進行優化。
AB測試從實驗的設計、實施和實驗結果的收集通常需要一個不短的階段，且進行AB實驗需要在線上維護多個不同的版本，所以不應該所有場景下都採用AB測試對Web應用進行優化迭代。對於那些明顯的bug修復，或者對於那些能夠明顯改善用戶體驗的功能，應該採用儘快上線並監控關鍵數據指標的方式。
誤區4
AB測試總是非常有效的解決方法。
通常AB測試的時間不會延續很長時間，對於一些長期效果很難做到有效的監測和對比。例如，某OTA對機票進行捆綁銷售產生的收益進行了為期一年的多版本AB測試，測試的目標是在用戶轉化率沒有顯著下降的情況下提升用戶客單價。
在實驗中，通過對價格非敏感用戶的個性化展示、默認勾選等方式的確客單價有了很顯著的提升，同時用戶的線上轉化率並沒有顯著變化甚至有了略微的提升。但是，這種捆綁銷售的方式從長遠來看可能對用戶是有傷害的，這種情況在低頻消費的場景下很難在實驗的結果上有所體現。而且，這種捆綁銷售的產品為媒體和公眾所詬病，這些都不是AB測試能夠體現的。
06
總結
AB測試不能解決所有的問題，但是仍然不失為衡量線上優化迭代的最有效方式之一。可衡量的實驗目標、有效的實驗分流、實驗結果的正確解讀是AB測試成功的關鍵。
化AB測試需要公司付出一定的資源成本，因此在小型公司，產品還以生存為首要目的的階段，並不是AB測試可以發揮的地方，但這並不代表我們不需要了解。作為一種知識儲備，即便是不會真正使用，但是它內在的思維邏輯依舊會對我們有很大的幫助。
星標我，每天多一點智慧
閱讀更多 數智物語 的文章
