關于AB測試那些事兒

本文作者康偉華(點融黑幫),現任點融BI總監,曾就職于1號店、攜程、eBay等互聯網公司從事數據和開發工作,關注數據科學和系統架構。2000年Google的工程師第一次將AB測試用于測試搜索結果頁展示多少搜索結果更合適,雖然那次的AB測試因為搜索結果加載速度的問題失敗了,但是這次的AB測試可以認為是Google的第一次AB測試。從那以后AB測試被廣泛應用于互聯網公司的優化迭代, 每年數萬個AB實驗被Google、Amazon、eBay、阿里等主流互聯網公司應用于線上進行UI內容優化、算法優化、收益優化等方方面面。本文將從AB測試的原理、過程、AB測試結果的評測分析以及關于AB測試的一些誤區和大家好好聊一聊關于AB測試的那些事兒。?

 

什么是AB測試?

AB測試的概念來源于生物醫學的雙盲測試,雙盲測試中病人被隨機分成兩組,在不知情的情況下分別給予安慰劑和測試用藥,經過一段時間的實驗后再來比較這兩組病人的表現是否具有顯著的差異,從而決定測試用藥是否有效。互聯網公司的AB測試也采用了類似的概念:將Web或App界面或流程的兩個或多個版本,在同一時間維度,分別讓兩個或多個屬性或組成成分相同(相似)的訪客群組訪問,收集各群組的用戶體驗數據和業務數據,最后分析評估出最好版本正式采用。

 

AB測試的基本步驟

AB測試是一個反復迭代優化的過程,它的基本步驟如下圖所示可以劃分為:

1.設定項目目標即AB測試的目標

2.設計優化的迭代開發方案,完成新模塊的開發

3.確定實施的版本以及每個線上測試版本的分流比例

4.按照分流比例開放線上流量進行測試

5.收集實驗數據進行有效性和效果判斷

6.根據試驗結果確定發布新版本、調整分流比例繼續測試或者在試驗效果未達成的情況下繼續優化迭代方案重新開發上線試驗

 

從對AB測試的定義中可以看出AB測試強調的是同一時間維度對相似屬性分組用戶的測試,時間的統一性有效的規避了因為時間、季節等因素帶來的影響,而屬性的相似性則使得地域、性別、年齡等等其他因素對效果統計的影響降至最低。

 

%e5%be%ae%e4%bf%a1%e5%9b%be%e7%89%87_20170712153353

如何提供對用戶的有效分組以及如何判斷實驗中不同分組用戶屬性的相似性是AB測試需要解決的第一個問題。而在試驗過程中如何收集用戶的體驗和業務數據,如何對收集的數據進行分析并判斷不同版本間的優劣是AB測試需要解決的第二個問題,也是AB測試的目的所在。下面我們對AB測試中這兩個關鍵的問題進一步展開。

 

AB測試的設計

AB測試中分流的設計直接決定了測試結果是否有效。AB測試是對線上生產環境的測試,而之所以進行AB測試通常是對測試中的改進版本所產生效果的好壞不能十分確定,所以測試版本的流量通常不宜過大。尤其對于那些影響范圍較大的改版(如主流程頁面的重大調整),影響用戶決策的新產品上線和其他具有風險性的功能上線通常采用先從小流量測試開始,然后逐步放大測試流量的方法。但是,測試版本的流量如果太小又可能造成隨機結果的引入,試驗結果失去統計意義。舉個例子:某電商網站對我的歷史訂單這個頁面進行改版的AB測試,測試的目標是提升用戶的復購,衡量的指標是經過這個頁面的單UV產生的GMV貢獻(單日GMV總數/單日進入UV)。假設這個頁面每天的UV在2000左右,而我們對新版本取的分流比例是2%,那么一天就會有差不多40個UV進入試驗版本。如果試驗進行1周然后考察試驗結果,這是試驗的結果就很容易受到某些異常樣本的影響,譬如說某個土豪老王恰好分在了試驗組然后購買了一個高價值的東西,那么老王的購買行為就可能帶偏整個測試組的統計結果。

為了規避這種因為樣本量不足造成的試驗結果不可用,在AB測試設計時可以采用如下措施:

1.試驗設計時預估進入試驗的樣本量,做分流規劃時避免分配給測試集的樣本量過少。

2.除了進行AB測試外增加關于數據有效性考量的AA測試,將原始版本的流量中分出兩個和測試版本相同的流量也進入測試。例如:為測試一個新的功能,我們原本準備劃分90%流量給老版本,10%流量給新版本;這時我們可以分配70%流量給老版本A,同時生成兩個10%流量的老版本C和D進行AA測試,然后把剩余的10%流量給新版本B;在試驗過程中通過考察分配給老版本C和D的兩股流量是否存在顯著性差異,從而認定試驗分流是否有效。

 

%e5%be%ae%e4%bf%a1%e5%9b%be%e7%89%87_20170712153423

 

3.如果參與測試新版本已經分配了很大的流量比例,但是仍然存在樣本量不足的情況,這時就只能通過拉長試驗時間的方式來累積足夠的樣本量進行比較了

AB測試的設計過程中另一個重要的點就是AB測試延續的時長了,通常AB測試延續的時間不宜太長,因為AB測試是對線上的多個版本的測試,這也就意味著線上系統需要同時維護多個可用的版本,長時間的AB測試無疑加大了系統的復雜性。但是,另一方面如果試驗進行的時間太短可能會造成試驗樣本量不足的問題。同時,如果進行的是UI改版一類影響用戶體驗的測試,新版本上線后用戶通常需要有一個適應的過程,這時我們通常會在試驗開始時給用戶一個適應期讓用戶適應新的UI版本,然后再考察試驗的結果。適應期的長短通常以足量用戶流量參與試驗后的2到3天為宜。適應期過后的試驗時間長短除了需要考察樣本量的情況外,還需要參考用戶的行為周期,譬如說電商用戶的購買行為有較強的周次規律,周末流量和購買量與工作日會有顯著差異,這時測試的周期應該能夠覆蓋一個完整的周期,也就是應該大于1周。

在試驗版本的設計過程中還需要考慮線上進行多個試驗相互間的影響,譬如在電商的購買流程中我們同時對搜索算法和商品詳情頁的UI進行優化,這兩個變動貫穿在用戶的購物流程中,相互之間可能是有影響的,我們需要區分試驗中這兩種改動帶來的影響分別是怎樣的。在這種情況下當然我們可以將用戶流量分成:

A.老的搜索算法和老的詳情頁UI

B.新的搜索算法和老的詳情頁UI

C.老的搜索算法和新的詳情頁UI

D.新的搜索算法和新的詳情頁UI

這樣四個版本,然后進行測試。但是這樣分流的問題是對于流程中元素的改動,測試的版本是呈現指數上升的,在多個改動同時進行時就容易造成版本流量不足的情況。在這種情況下就需要引入試驗分層的概念,將實驗空間橫向和縱向進行劃分,縱向上流量可以進入獨占實驗區域或者是并行實驗區域。在獨占實驗區域,只有一層,實驗可以獨享流量且不受其他實驗的干擾。在分層區域,不同的應用屬于不同layer,每個應用內部,又可以劃分為多層,層與層之間相互不影響。流量可以橫向經過多層,每一層可有多個實驗。流量在每一層都會被重新打散。

 

%e5%be%ae%e4%bf%a1%e5%9b%be%e7%89%87_20170712153437

這樣多層次正交的實驗方式使多個并發實驗都可以保證具備一定流量的并行進行。

最后,在對用戶體驗有明顯影響的實驗中通常采用對用戶穩定的分流實現。即分到不同版本的用戶在多次登錄應用落入相同的實驗版本,這樣可以保證用戶體驗的一致性,保證用戶能夠在適應新版本的情況下有穩定的表現。通常會采用不同實驗選用不同的hash種子,對用戶的guid和上述分層實驗的實驗層次id的組合進行hash,然后根據hash值取余的方式進行分流。

 

AB測試效果分析 ??

關于AB實驗效果的分析通常分為兩個步驟:實驗有效性的判斷、實驗結果的比較。實驗有效性的判斷即判斷實驗的分流是否已經到達所需要的最小樣本量,從而能夠以較大的概率拒絕兩類統計錯誤的發生。最小樣本量的判斷可以采用假設實驗目標指標符合正態分布下,兩類錯誤發生概率的分位數的方式進行估算。或者更一般的可以采用AA測試,對兩個老版本的實驗結果計算P值,從而判斷其是否存在顯著差異。如果AA實驗的結果不存在顯著差異,那么可以認為實驗結果是有效的,進而可以對新老版本的實驗結果進行進一步的判斷。

在確認實驗有效后就可以對實驗的結果進行判斷了,通常通過比較新實驗版本和老版本是否存在顯著差異(前述的P值判斷),以及計算實驗結果指標的置信區間(通常選用指標的95%置信區間),從而判斷新版本是否相對老版本存在顯著提升或下降。

 

%e5%be%ae%e4%bf%a1%e5%9b%be%e7%89%87_20170712153451

 

 

關于AB測試的一些誤區

最后,講一下關于AB測試的一些誤區,通過對這些誤區的理解希望能夠恰如其分的應用AB測試提升網站和產品的轉化等指標。

誤區1: AB測試運用成本過高,可以通過灰度發布的方式來進行AB測試,進而避免同時維護不同版本的情況。

灰度發布是應用發布通常采用的方式,即對一個pool的部分服務器發布新版本的代碼,而其余的服務器采用老版本代碼,在確認應用正常的情況下逐步將新版本發布到pool的全部服務器。這樣的方式的確可以起到分流的作用,但是這樣的分流是不穩定的,用戶的兩次訪問很有可能會被分到新老兩個版本上。同時,灰度發布的分流單位通常是以服務器的流量為最小單位的,不能做到對測試流量的精確分配。

誤區2: 用參加實驗的部分用戶的體驗質疑AB實驗結果的正確性。

經常碰到產品經理或是業務人員提出某些用戶在新版本的實驗中沒有轉化,而實際實驗數據體現新版本效果好于老版本的情況,從而質疑實驗的結果。AB實驗是基于統計的結果,是基于大樣本量的有效統計結果,實驗結果的好壞是針對參與實驗的大多數樣本而言的,個例不具備代表性。

誤區3: AB測試是優化Web應用的利器,應該在所有場合都應用AB測試進行優化。

AB測試從實驗的設計、實施和實驗結果的收集通常需要一個不短的階段,且進行AB實驗需要在線上維護多個不同的版本,所以不應該所有場景下都采用AB測試對Web應用進行優化迭代。對于那些明顯的bug修復,或者對于那些能夠明顯改善用戶體驗的功能,應該采用盡快上線并監控關鍵數據指標的方式。此外,AB測試也不是silver bullet, 通常AB測試的時間不會延續很長時間,對于一些長期效果很難做到有效的監測和對比。例如,某OTA對機票進行捆綁銷售產生的收益進行了為期一年的多版本AB測試,測試的目標是在用戶轉化率沒有顯著下降的情況下提升用戶客單價。在實驗中,通過對價格非敏感用戶的個性化展示、默認勾選等方式的確客單價有了很顯著的提升,同時用戶的線上轉化率并沒有顯著變化甚至有了略微的提升。但是,這種捆綁銷售的方式從長遠來看可能對用戶是有傷害的,這種情況在低頻消費的場景下很難在實驗的結果上有所體現。而且,這種捆綁銷售的產品為媒體和公眾所詬病,這些都不是AB測試能夠體現的。

30987 Views
即刻實踐文章理論 A/B測試 灰度發布 產品優化 免費申請
Please wait...

訂閱我們

對于每位訂閱讀者,每兩周,吆喝科技會為您發送4篇精選文章,可能是最新的A/B測試實踐,也會是你所期待的增長干貨。
qq宠物捕鱼大师 做pvc管道生意赚钱不 排球直播频道朱婷 时时彩平投1:1盈利技巧 喜马拉雅咋赚钱 三公扑克牌手机游戏 捕鱼达人土豪金破解版 AG骰宝打流水方法 盖上大棚你就能赚钱了吗 上海时时查开奖结果查询结果 捕鱼来了