AB 測試最佳實踐

AB 測試有用，也是產品經理和分析師的必備能力。不過要從中產出真正效果並不簡單。這裡探討分享下一些最佳實踐。（此貼的 AB 測試指的是經典的 frequentist 測試方法，不涉及序列測試或貝葉斯測試）

什麼時候開始做 AB 測試

產品用戶不多的時候，沒必要做。如果一共才幾百個用戶，應該做的是打電話給每個用戶收集反饋，了解他們的感受，喜歡什麼，討厭什麼。 每個產品具體情況不同，大致準則是公司開始僱傭專職分析人員時，就可以開始考慮做 AB 測試了，剛開始可以直接在產品代碼中 adhoc 實現或用第三方工具，無需自己研發一個獨立通用系統。

做哪些 AB 測試

如果一談到 AB 測試，滿腦子想的就是按鈕該紅色還是藍色，位置左邊還是右邊，文案該長還是短，那就跑偏了。同樣，如果一上來就考慮怎麼提高轉化率，怎麼增加點擊率，也是被帶到溝里去了。產品經理可能身上背了不少 KPI，壓力大，但一定要頂住壓力，不能為了短期指標，拚命做局部優化，「騙取「用戶完成一些動作，最後發覺方向性錯誤，之前嘗試出來的各種優化全部推倒重來。

AB 測試同其他工具一樣，為產品服務，還是要回到產品本身。問問自己，這個產品的核心價值是什麼，為什麼用戶要使用這個產品，怎樣讓用戶儘快體驗到這個核心價值。如果用戶已經很快能體驗到，那麼他們的感受和設想的是否一樣，用戶抱怨最多的地方是什麼，有哪些隱藏較深的可選內容，很多用戶都會點開去看，又有哪些交互中必經之路，用戶恨不得馬上離開。通過不斷使用產品，分析對比數據，或者直接採訪典型用戶，都是搞明白這些問題的較好方法，理解了現實和預期的差距，才能幫助 AB 測試找准實驗方向。

在定位差距後，總結需要測試的問題，提出假設並排優。比如搜索是用戶獲取 app 價值最重要的橋樑，但發現用戶一搜索就退出 app 了，是因為是搜索方式不夠直觀，有學習成本，還是演算法不夠好，搜索結果匹配度不高，或者是匹配度不錯，但展示區分度不夠等等。每個問題基本都能找到相對應的用戶群，按照影響的範圍，實現成本等因素做個大致估計，來決定做不做，先做後做。AB 測試是理解用戶，學習和改進的機會，對於有一定使用量的產品，一天不做 AB 測試就是浪費，但亂做 AB 測試，不按重要性來，隨便拍腦袋上一個也是很大機會成本。

怎麼衡量 AB 測試是否成功

決定了做哪些 AB 測試後，接下來才是考慮 KPI。首先要定義成功指標是什麼，這個要定義的非常具體。比如是營收，還是訂單數量，還是成單轉化率，這3個指標高度相關，但不是一回事，分別把用戶往不同的方向上牽引，想清楚哪個和產品目標一致性最強。

然後確定對於成功指標，最少想看到多少提升，3%，5%，還是20%，具體的量值取決於現有業務的情況，和對將來的預期，如果預期提升效果太小，會導致成本高（需要很大的樣本量），ROI 不太吸引人。這時就得想想是否真有必要做，還是其他測試更有意義。如果預期效果設定太大，除非有強有力的邏輯分析支持，否則也難以讓人信服去實施。

除了成功指標外，還要考慮其他會受影響的指標，對它們產生多少負面影響是可以接受的。這點非常重要，因為測試結束後，很可能面臨這樣的問題：營收上升了5%，但活躍用戶下降了5%，回滾測試還是全面上線？或者使用時長上升了5%，但購買用戶下降了5%，怎麼取捨？這個事先就要說清楚，根據公司最高目標和優先順序逆推，設定一個明確閾值，各團隊取得一致。負面影響超過這個閾值就放棄，不超過就可以繼續，避免事後各種扯皮浪費時間。

那是否要對每一個測試都監控一大堆指標呢

可以這麼做，但不推薦暴露給業務人員。AB 測試本身是基於概率的，通常 alpha 設定在5%左右，也就是說有5%的概率我們會犯第一類型錯誤（false positive, 或 FP），如果對一個測試，設立100個觀測指標（別以為很多，公司大了，有幾百個指標衡量各個方面很常見），最後實驗組和控制組即使沒任何區別 （比如 AA 測試），我們能看到至少一個指標是統計顯著的概率是1-0.95^100=99.4%，如果監控20個指標，看到統計顯著的概率也有1-0.95^20=64%。當然不少指標都有相關性，實際的概率會比這低很多。這裡主要是給大家一個概念，暴露太多指標，會導致由於隨機概率而出現統計顯著的情況變多，造成純業務人員不必要的困惑。

AB 測試應該運行多長時間

有了成功指標和預期的最小提升，就可以估算需要的樣本數量。alpha 一般取0.05，beta 取0.2，忘了係數意義的同學可以回去看下中學課本。如果要求更高的正確概率，可以進一步減小 alpha 和 beta。成功指標的方差則可以通過歷史估計。有了這些，就能得到所需要的樣本數量。

不過，把樣本數量簡單除一下每天流量來得出測試需要的運行時間並不可取。需要考慮以下因素：

如果是前端界面修改，新的體驗可能讓用戶感到新奇，花更多時間在上面。也有可能遭致資深用戶反感，不願改變操作習慣而離開。這些情緒會干擾測試結果，所以需要一段時間來緩衝，一般推薦至少1周，也就是測試上線後前1周的數據不納入最後判斷。

另外，每個業務都有自己的周期性和延遲性。周期比如一個付費訂閱項目可能是每天扣款，也可能是每周或每月扣款。而延遲指用戶進入實驗組後，可能要幾天甚至更長時間才會反饋到成功指標上，當 KPI 是付費轉化（需要一定考慮時間）而不是單純的點擊的話，這點就會比較明顯。

對於很多業務，一個普遍存在的周期就是周中和周末，用戶的使用情況在這兩段時間一般都不太相同，所以為了覆蓋完整周期，即使產品流量大到幾小時就能滿足樣本數量，也推薦至少運行測試2到3周。

都是按照用戶級別來抽樣的么

大部分都是。AB 測試有一個基本假設，就是每次抽樣都來自於獨立同一分布 （iid）。嚴格來說，這個假設在現實世界中從來不成立（事物是普遍聯繫的嘛=D），但至少要確保抽樣之間相關性不能太強，否則會嚴重扭曲測試結果，造成誤導。

很多用戶都會訪問同一個 app 或 web 多次，如果不按用戶，按訪問來抽樣，不同的訪問背後是同一個用戶在操作，那麼抽樣間就形成了強相關，得到的結果會無法使用。而且如果是 UX 測試，一個用戶第一次訪問能看見某個元素，第二次訪問可能看不見了，這體驗就太糟了。

值得一提的是，Airbnb 在做 AB 測試 時發現，如果測試涉及到未登錄用戶，那麼最好保持實驗組和控制組具有相同的用戶比例，也就是如果實驗組有5%的用戶，那麼控制也要選5%的用戶做對照。背後的原因是對於未登陸用戶，我們依靠瀏覽器 cookie 或者設備 id 來標識，一旦用戶使用多個瀏覽器，多個電腦，跨設備，就會具有多個標識，很可能被同時分配到了控制組和實驗組。我們認為這些標識都相互獨立，其實都指向一個用戶。如果這群用戶具有和其他單設備單瀏覽器用戶不同的特性（比如特別活躍），那麼就會引入偏差，扭曲結果。處理的方法就是給予控制和實驗組相同的比例，讓這群同時進入實驗和控制組的用戶可以被等比例的刪除。這個視頻中也提到如果一個用戶進入測試組，對其他的用戶產生了影響，那麼抽樣獨立性被破壞，此時用戶級別不適用，而應該在更粗顆粒度進行抽樣。

需要 AA 測試么

如果從來沒做過，建議測試，可以用來檢驗實驗漏斗，數據質量問題，或者抽樣是否符合獨立同一分布等等，如果沒有時間，可以做 AAB 測試，一邊進行實驗，一邊把控制組分流互相校驗。

什麼時候能觀察 AB 測試的結果了呢

這是一個主要誤區。AB 測試上線後，是不能去反覆查看 p 是否已經小於0.05，達到統計顯著了。且不說上面提到的產品周期性和延遲性因素，p 本身就是一個隨機變數，每觀測一次實際上就是對其進行一次抽樣，也就增大了統計顯著的概率，同時增加了 FP 的概率。那什麼時候能觀察結果呢？就是等到事先設定好的運行時間結束，然後看一次，決定是否統計顯著。

AB 測試開始後真的不能立即／重複觀察么

好吧，測試上線後忍著不看，這也不現實。畢竟我們需要知道測試開始後，是否會對產品造成重大不良影響，這樣可以及時回滾。或者如果測試實施中出了問題，也希望及早察覺修復，而不是等過了1個月才發現漏洞，浪費大把時間。

所以比較好的做法是，實驗上線後就要開始緊密觀察，但這時觀察不是看有沒有統計顯著（請暫時忽略 p 值），看的是實驗和控制組的指標讀數是否符合預期，有沒有出現完全無法解釋的情況。如果感覺奇怪，不要猶豫，排查下有否程序漏洞，如果對產品出現明顯負面影響，考慮立即回滾。

至於 p 值，還是要等到預定的測試時間完成後，才能採樣一次用來做判斷。

實驗組效果不錯準備全面上線，但長期效果會惡化么？

是有可能的。測試完成，實驗組的指標提升統計顯著，可真全面推廣上線了，過段時間發覺成功指標或者其他監測指標可能降低到原有水平甚至更低了。這對一些長期 KPI，比如 LTV，留存，年營收等要特別留意。應對的方法是保留一個全局對照組（比如5%的流量），全局對照組相對穩定，一個季度，甚至一年都不進入任何測試，長期處於「控制組」狀態，用來對比各個測試全面上線後的長遠影響，出現情況時就需要部分或者全面回滾相應測試。當然，這個全局對照組的比例不能太大，否則機會成本太高。

碰到欺詐流量扭曲實驗結果怎麼辦

比如機器人可能短期造成大量流量，無論相應 ID 被分配到實驗還是控制組，都會造成嚴重偏差，有些其他欺詐行為，像付費賬號共享給了幾千或者上萬用戶，也會產生類似效果。一個方法是限定成功指標的邊界，不再計算每個用戶點擊按鈕幾次，而是計算是否點擊過，把0到無窮大的區域映射到0和1兩個值，缺點是沒了權重，優點是克服了欺詐問題。

其他需要注意的地方

如果你有一個喜歡微管理，但又不太理解統計的業務夥伴，那預期一定要設好，主要就是：大部分 AB 測試都是以失敗告終的。

我們是在失敗中學習，失敗中摸索找到答案。否則也不叫實驗了。這個「大部分」可以理解成超過一半、或者四分之三的實驗最後都是正面影響沒有統計顯著，甚至是負面影響。這個溝通如果沒有提前做好，以後日子會很難過。

另外，不是所有的問題都能 AB 測試。AB 測試的基礎是統計，也就是需要大量獨立樣本來撫平隨機性，所以嘗試次數非常有限的問題就不用想了，比如戰略規劃。而對於能進行 AB 測試的問題，也不是都有機會。有時市場投放時間，融資需求，上市公司財報發布壓力等有更高優先順序。

而作為產品經理，需要明白以當前 AI 的水平，數據知情比數據驅動更實用些（見之前所寫），AB 測試提供了一個重要的方法和依據，但不能代替你做決定，其抽象簡化的數學模型在現實複雜的商業環境中會面臨很多挑戰。作為產品負責人，仍需要綜合各方面信息，下最終判斷，並為結果負責。總之，把它當成一個幫手，而不是產品經理的擋箭牌 =D

原文發表在：http://www.shanyuanming.com/2017/04/06/abtest-best-practice/