定義：ABtest本身其實是物理學的“控制變量法”，通過只改變一個因素來確定其變化對cr或者收益的影響。其本身具備統計意義，而且具備實際意義。試想一下如果沒有ABtest，那新項目上線后的收益如何排除季節因素、市場環境因素的影響，而且一個頁面上如果同時做多處改動，如何評判是哪個改動造成的收益或損失?這對一個理性思維的人是不可接受的。

簡單理解為將一群人分成兩類，通過展示新舊版version A/B來測試哪種版本效果好，差異是多少。

ABtest流程

• ABtest數據流：APP啟動時，公共框架會拉取所有線上abtest的試驗號和對應版本(所有BU)存入本地，當用戶進入機票頻道時候，在特定場景觸發本地實驗號調用。比如往返實驗，在用戶首頁點擊往返搜索時，開發會從本地文件中查詢160519_fld_round試驗號該用戶的對應版本，確定跳轉新/舊版頁面。在試驗號接收到調用時，同時觸發一個abtest的trace埋點o_abtest_expresult，該埋點會記錄clientcode,sid,pvid,試驗號及版本信息，最終經過ETL，BI會匯總一張AB實驗表，將上述信息匯總，便于后續做關聯計算。

• 分流計算：每個設備在剛啟動的時候會根據設備號+試驗號+隨機數組成一串N位數，對100取模的余數從0-99，假設ABCD四個版本流量 10:70:10:10的情況下，則余數0-9為A版、10-79為B版、80-89為C版、90-99為D版。A版為默認版，如果尾數異常(Null或溢出)，則走A版。
• 版本說明：如果僅有新舊兩個版本的情況下，一般會設置ABCD四個版本，其中ACD為舊版，B為新版。(如果有多個迭代新版，則從EFG開始)。

AA測試：CD版同為舊版，且流量各為B版一半，在流量隨機分配的情況，通過對比CD版的數據表現來驗證舊版的狀態是穩定的。

AB測試：在確保CD數據相對穩定的前提下，再對比B和ACD版本的數據，來對比新舊版的差異。

兜底版本A：BCD的剩余流量走A版，版本異常的情況下走A版

• 實驗正交性：

• 非正交實驗，如左圖展示，在舊版的基礎上再做區分，會因為樣本數量的問題而限制同時進行的實驗個數，而且無法評估兩個新版同時存在的影響。
• 正交試驗：右圖展示，不同實驗流量完全打散隨機分配，上一個實驗與下一個實驗理論上流量上沒有關聯，這樣可以在一個頁面同時進行多項實驗。

這里再提一個Magic Number = 7，雖然理論上單頁面上同時進行的正交試驗數量沒有上線，但是經過長期經驗積累，單頁面同時線上實驗不要超過7，否則會造成難以捉摸的幺蛾子異常。

• 埋點下線機制：

像ABtest里面的埋點觸發場景埋點還是由開發控制的，也還是會存在埋點不準確的情況，比如說往返的實驗，觸發場景是在首頁點擊往返搜索，理論上去程列表頁的UV應該是參與式樣的樣本數抑制。實際情況是，去程列表頁30W的UV，但ABT的報表顯示每天樣本為50W，經過sql驗算兩者交集為20W,就說明有10W人是在往返流程但并沒有參與實驗(數據經過脫敏處理，但不改變相對位置)。

所以基于這樣的幺蛾子，在ABT結束后，既要刪除代碼，又要實驗流量全開100%

• 流量調整100%目的：將歷史版本的客戶端舊版規避，需要操作100%流量。
• 下線代碼：保證appのsize不會過度冗余，同時因埋點場景的問題，有些時候雖然流量全切100%，但仍有部分流量走舊版(非常詭異)，所以將客戶端代碼下掉是非常必要。

其他說明：

• 在任何情況下，分析的基礎條件就是流量隨機分配，如果質疑這件事情，則整個abtest就失去意義.
• 實驗分流一般采用設備號clientcode,但是也可以根據uid來，但情況較少
• 對于實驗的顯著性指標P值一般使用較少且不易理解，就不做過多解釋(一年也沒怎么用這個指標)
• 分流調節機制，新版流量不要忽上忽下，特別是涉及到核心頁面的時候，否則可能會造成用戶看到的頁面反復變化，增加適應時間和學習成本以及影響用戶體驗。

分析數據

ABT的目的：

abtest是希望通過如何改進新版優于舊版，而不是通過abtest證明新版弱于舊版而下線實驗，所以需要有效地分析數據。

如何看圖表：

圖表反映時間趨勢，在abtest中表現為新舊版本兩條折線圖，且一般會出現交叉的情況，那我們就需要判斷這些交叉是有隨機性波動還是實驗的效果，我在實踐中總結簡單易用的一條原則是：“抓大放小”。

• 抓大放小(個別表現不影響整體趨勢)：當你遮住有限個點的時候，不影響整體的差異。比如下圖，當你遮住2-11和2-13兩天的數據時，會發現藍色B版優于紅色舊版。(當然遮住點的數量因人而異，一般不超過總量10%)

這張圖就很難用抓大放小的方式來判斷差異，無法證明是新版好還是舊版好，這時候需要分解這個指標來繼續分析。

機票的核心指標是轉化率CR(conversion rate)和收益(revenue)，通常他們之間的關系如下圖所示。

攜程機票前臺以scrum Team的形式迭代，每個team對于需求的評審是以roi(投入產出比，return on investment)來決定項目的優先級，而return可能是cr的提升，也可能是單票收入的提升。

對于上線實驗數據跟蹤，也是以當初roi的預期來進行判斷實驗效果，尤其在沒有達到預期的情況下，尋求解決方案。(這其中還有諸多限制條件，比如收益類項目，如果CR有明顯下降需要重點關注。)

分析思路

這個分解公示也代表分析的思路，無論對于收益類項目還是CR類項目，都會先看單UV收入和CR(一般情況下，abtest不會改變每個訂單的票量，這是基于整體訂單估算的平均值，我們暫且認為TA是常量)，當這兩項都保持正向增長的情況下，那可以直接開大流量繼續驗證直至項目完美收官(這種案例比較少)。更多的情況是，對于重大項目，即使結果是積極正向的實驗，我們也會大概了解下改進點發生在哪個頁面或者哪個產品，做到心中有數;

而當發生問題的時候，我們都會對CR和單票收入做分解：

• CR下降的情況，看主流程每個頁面的CR，是哪個頁面下降，從頁面的來源去向和點擊來看，是否有明顯的異常，一般來講，對業務足夠熟悉的PM在這一步可以結合業務和這些數據大概會有一些預判，是哪些因素可能造成的影響，之后再請教bi專業人員或者自己拉sql來驗證數據，從而進行改進。
• 利潤下降的原因，繼續分解指標，可以分產品、航司、利潤構成等指標來分解，找到新舊版的gap，然后結合業務場景做一些預判，進行找數據來支持這個想法，繼續迭代新版。

之前的狀態是PM對于AB實驗的數據有一大坨報表，但是并不知道如何使用，也不知道怎么看報表，不知道怎么分解指標，但其實對于整體進行了解之后，具備簡單的分析能力，關鍵是有業務背景知識的情況下，這樣的幾個公式的八股文的分析可以解決80%的問題，對于實在無法定位的問題，可以找bi尋求幫助。

總結

ABtest其實核心在于如何定位問題解決問題，但是限于身份不能通過數據來進行舉例說明。但其實分析思路應該是一致，比如機票場景下指標分解的核心公式來解決80%的問題，在每個行業應該都會有這樣的公式，可以根據特定業務背景自己總結運用。

PM如能夠掌握這些基本的指標分析、能夠看懂圖表、這里面就能夠自助解決80%的問題，這樣的abtest效率其實已經是非常高的。

【本文為51CTO專欄作者“李寧”的原創稿件，轉載請通過51CTO聯系作者獲取授權】

戳這里，看該作者更多好文