攜程機票的ABTest實踐

攜程ABTest伴隨UBT(User Behavior Tracking System)系統一塊兒，兩年多的時間，從最初online寥寥幾個實驗，到如今單是機票BU每週就有數十個app/online/h5平臺同時線上運行。

在14年-16年James領導下的技術驅動的大攜程體系，對於項目上線的收益、年終KPI考覈、CEO獎項的評比都須要拿ABTest數聽說話（聽說James對數據特別敏感，曾經在2016年某hackathon決賽中，未上線前一team在臺上大談項目收益，James立即打斷說"大家的項目上AB了嗎？沒上的話不要講了"，該team被當場淘汰） 。

攜程市值不斷增加的背後，是無數個ABTest的支持，而攜程機票大部分的ABTest都放到前臺來配置，有幸在2016年經歷N多大項目的上線ABT過程，本文將以此爲背景來講明攜程機票對於ABTest的應用。（ABTest在攜程被簡稱爲ABT）

1、ABTest的定義

ABTest自己實際上是物理學的"控制變量法"，經過只改變一個因素來肯定其變化對CR(conversion rate)或者收益的影響。其自己具有統計意義，並且具有實際意義。

試想一下若是沒有ABTest，那新項目上線後的收益如何排除季節因素、市場環境因素的影響，並且一個頁面上若是同時作多處改動，如何評判是哪一個改動形成的收益或損失？這對一個理性思惟的人是不可接受的。

簡單理解爲將一羣人分紅兩類，經過展現新舊版version A/B來測試哪一種版本效果好，差別是多少。

2、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版。

AB版本：若是僅有新舊兩個版本的狀況下，通常會設置ABCD四個版本，（其中ACD爲舊版，B爲新版；若是有多個迭代新版，則從EFG開始）來進行AA測試和AB測試。

一、AA測試：CD版同爲舊版，且流量各爲B版一半，在流量隨機分配的狀況，經過對比CD版的數據表現來驗證舊版的狀態是穩定的。A版做爲舊版，也稱爲兜底版本，BCD的剩餘流量走A版，版本異常的狀況下走A版。

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

實驗正交性：

一、非正交實驗：如左圖展現，在舊版的基礎上再作區分，會由於樣本數量的問題而限制同時進行的實驗個數，並且沒法評估兩個新版同時存在的影響。

二、正交試驗：右圖展現，不一樣實驗流量徹底打散隨機分配，上一個實驗與下一個實驗理論上流量上沒有關聯，這樣能夠在一個頁面同時進行多項實驗。
這裏再提一個Magic Number = 7，雖然理論上單頁面上同時進行的正交試驗數量沒有上線，可是通過長期經驗積累，單頁面同時線上實驗不要超過7，不然會形成難以捉摸的幺蛾子異常。

埋點下線機制：

像ABTest裏面的埋點觸發場景埋點仍是由開發控制的，也仍是會存在埋點不許確的狀況，好比說往返的實驗，觸發場景是在首頁點擊往返搜索，理論上去程列表頁的UV應該是參與式樣的樣本數抑制。實際狀況是，去程列表頁30W的UV，但ABT的報表顯示天天樣本爲50W，通過SQL驗算二者交集爲20W,就說明有10W人是在往返流程但並無參與實驗（數據通過脫敏處理，但不改變相對位置）。

因此基於這樣的幺蛾子，在ABT結束後，既要刪除代碼，又要實驗流量全開100%

一、流量調整100%目的：將歷史版本的客戶端舊版規避，須要操做100%流量。

二、下線代碼：保證app的size不會過分冗餘，同時因埋點場景的問題，有些時候雖然流量全切100%，但仍有部分流量走舊版（很是詭異），因此將客戶端代碼下掉是很是必要。

其餘說明：

一、在任何狀況下，分析的基礎條件就是流量隨機分配，若是質疑這件事情，則整個ABTest就失去意義.

二、實驗分流通常採用設備號clientcode,可是也能夠根據uid來，但狀況較少

三、對於實驗的顯著性指標P值通常使用較少且不易理解，就不作過多解釋（一年也沒怎麼用這個指標）

四、分流調節機制，新版流量不要忽上忽下，特別是涉及到核心頁面的時候，不然可能會形成用戶看到的頁面反覆變化，增長適應時間和學習成本以及影響用戶體驗。

3、分析數據

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和單票收入作分解：

1、CR降低的狀況，看主流程每一個頁面的CR，是哪一個頁面降低，從頁面的來源去向和點擊來看，是否有明顯的異常，通常來說，對業務足夠熟悉的PM在這一步能夠結合業務和這些數據大概會有一些預判，是哪些因素可能形成的影響，以後再請教BI專業人員或者本身拉SQL來驗證數據，從而進行改進。

2、利潤降低的緣由，繼續分解指標，能夠分產品、航司、利潤構成等指標來分解，找到新舊版的gap，而後結合業務場景作一些預判，進行找數據來支持這個想法，繼續迭代新版。

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

4、總結

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

PM如可以掌握這些基本的指標分析、可以看懂圖表、這裏面就可以自助解決80%的問題，這樣的ABTest效率其實已是很是高的。