編輯導語：增長黑客這一概念起源於美國互聯網行業，最早由 Sean Ellis 提出。近年來，增長黑客的概念傳到國內，其核心是驅動用户飛漲增長黑客，指的是創業型團隊在數據分析基礎上，利用產品或技術手段來獲取自發增長的運營手段。本文作者詳細的分析了增長黑客的AB-Testing系統應該如何設計，希望對你有所幫助。
數據驅動概念興起的同時，AB-test也同步出現在大家的視線中，各互聯網大廠率先引進了AB-test系統，希望通過循環的測試，上線最符合公司客羣的產品。
這一理念一出引發行業內各個公司的效仿，各種宣導紛至而來，那麼什麼是AB-test？什麼樣的公司能迅速構建出AB-test系統？我們今天來一起聊一下。
1. 什麼是AB-test？攜程的大佬們曾給出一個定義：AB試驗可以簡單的認為是傳入一個實驗號和用户分流ID到AB試驗分流器，分流器吐出分流版本A、B、C、D等，截取一部分應用流量，落地某一段時間的分流數據，進而分析各個版本的優劣，決定啓用新版本還是沿用老版本的過程。
這一定義大家能不能理解呢？我們用更通俗的語言做一下解讀：
首先：試驗的目的是為了決策新開發的兩個或兩個以上的版本該上線哪一個的問題——即當有較多的版本選擇時可以先測一把，讓數據告訴我們哪一個方案比較適合我們公司的客户。
大家有沒有遇到經驗失效的時候，就是我們按照自己的經驗設計出來的產品、活動，客户並不買賬，失效的原因有很多，其中一個比較常見的原因就是經驗失效，即我們培養起來的經驗往往是根據之前公司或者歷史數據形成的。
問題在於新公司/當下時間中客羣發生了變化，我們之前的經驗未必完全符合現在的客羣，這也就凸顯出了AB-test的價值，AB-test是根據本公司現在的客羣進行的對照試驗，可以直觀的表達出客户需要什麼樣的產品。
其次：試驗用到的一個重要組件是分流器，分流器有什麼用處呢？
顧名思義——分流用的，就是通過一定的規則將APP中隨時流動的數據分成多個版本，客户進入APP後會自動分配到各個版本中，各個版本對應開發的新舊版本，進行穩定測試。
分流器中常用的方法是對客户的session/cookie進行hash運算，然後將運算結果取模mod（即取餘運算，不清楚的看官可以百度一下）。通過取模後的值進行分流，分流的過程涉及正交、互斥試驗的設計，其中細節，我們下文中會詳細描述。
其三：就是試驗效果評估的過程，AB-test的兩個重點之一就是效果評估（另一個就是上面的分流器），如何評估一個試驗是否成功？試驗1的UV大於試驗2的UV是否就説明試驗1是好的？
這其中就涉及到了統計中的各種檢驗知識，我們會在下文原理部分詳細描述。
現在我們從簡到繁瞭解一下AB-test的試驗思路，假設一個客户來到我們的APP，其在AB-test中的數據訪問可以如下圖描述：
看圖聽故事如下：
- 一個客户進入到我們的APP時，會在客羣的部分做一次篩選，即試驗是否是有劃分客羣，如果有客羣劃分，則需要判斷新來的客户是否命中我們的試驗客羣；
- 第二步我們要判斷需要進行什麼類型的試驗，正交還是互斥？以及此次試驗需要切分多少流量，5%還是10%；
- 經過了客羣識別和流量切分後，我們的客户來到了試驗分組部分，系統採集客户訪問的cookie/session信息計算出唯一hash值，並對這一hash值做mod處理；
- mod處理之後的數據會被分到t個桶中的某一個，然後再根據一定的比例和算法將t個桶中的數據分成三組，即：A組、A組和B組，假設分流比例為：1/3，1/3，1/3；
- A-A組即為舊版本對照組，用來檢驗分流是否有效，如果A-A組不顯著，説明數據不受系統性因子影響，分流是有效的；A-B組即為新舊版本的對照組，其中B組為新版本；
- A-A-B組的數據比較即為試驗數據分析，分析人員藉此完成試驗的效果檢驗，確定試驗是否顯著。
看完上面這一串介紹，有沒有一種原來如此的感覺？
AB-test的基本流程可以是上圖的樣式，但是充其量只能作為一個簡圖，接下來我們一點點的抽絲剝繭，還原AB-test產品的真相：
2. 什麼是正交試驗？什麼是互斥試驗？正交試驗：每個獨立試驗為一層，為保證各層之間不相互影響，一份流量穿越每層試驗時，會再次隨機打散，且隨機效果離散，這一過程叫正交，這樣的試驗叫正交試驗。
正交試驗能最大化的保證各層試驗相互獨立，確保各個試驗不會相互影響。
我們用圖形來表示正交，如下圖：
X層的全部流量隨機打散，然後進入到Y層，看到的結果即為Y層的流量為X層流量重組之後的再分配，兩層之間相互獨立。
互斥試驗：即為在同一層中拆分流量，且不論如何拆分，不同的流量是不重疊的。
互斥試驗是在流量足夠的情況下進行的分流策略，各個試驗之間也不會相互影響。我們同樣用圖形來表示互斥，如下圖：
X層的流量會各自獨立的分到Y層，相互之間不受影響。
3. 如何計算最小樣本量？最小樣本量的計算，我們會在下文原理篇詳細講解～
4. 多個試驗同時發生時如何分層？前面我們講解了正交和互斥兩個原則，接下來我們介紹一下在正交和互斥的原則下該如何設計試驗分層？
正交、互斥兩種試驗的引用是為了能夠更充分、更高效的使用流量，實際試驗中往往是多組試驗同時存在，既有正交，又有互斥，如下圖：
上圖中的分組情況可以看出：域1和域2互斥拆分流量，域2中的流量串過1-1層、1-2層、1-3層，進入到2層和3層，1-1層、1-2層、1-3層是互斥的，1層、2層、3層是正交的，上層的流量大於等於下層。
從使用場景上看，1層、2層、3層可能分別為UI層、搜索結果層、廣告結果層，這幾個層級基本上沒有任何的業務關聯度，即使共用相同的流量，也不會對實際的業務造成影響。
但是如果不同層之間所進行的試驗相互關聯，就需要進行互斥試驗。
例如：1-1層是修改頁面按鈕上文字的顏色，1-2層是修改按鈕顏色，如果按鈕和文字顏色一致，估計按鈕就不可用了。試驗的基本原則是控制變量，即儘可能的保證每次試驗只有一個變量，不要讓一個變量的試驗動態影響另一個變量試驗，否則試驗就會失去公正性。
另外，如果我們覺得一個試驗可能會對新老客户產生完全不同的影響，那麼就應該對新客户和老客户分別展開定向試驗，觀察結論。
無論從層級上還是單層的分流上都被充分應用，流量的使用效率很高，但是，隨着試驗越來越多，對試驗的管理也會顯得越來越重要，往往後期會需要專門的人員進行管理。
5. Hash分流過程是啥樣的？分流的方式有很多種，筆者這次來和大家聊一下hash的算法如何實現分流效果。
AB-test又稱作是桶測試，為什麼叫桶測試呢？關鍵就在於分流的過程，我們先解釋一下桶和試驗組的關係：
假設試驗有12個人，我們對這12個人進行編號，編號方法可以使用cookie，也可以使用session，總之獲取到這12個人的唯一編碼。
當獲取到唯一編碼之後我們就可以開始分流了，我們對每個人的唯一編碼進行hash處理，常規使用MD5進行hash計算，這樣計算的好處在於MD5幾乎不會重複，分流效果較好。
計算好的hash值需要進行mod處理，圖中有6個桶，我們就用6進行mod處理， 12個人按照餘數分散到六個桶裏面，原則上12個人的分流是隨機的分散到各個桶裏面，很難保證每個桶裏的人數一致。
但是從統計學的角度上講，當數據量足夠大時，數據會均勻的分散到各個桶裏面。
桶分流完成後，我們需要處理的就是將這些桶平均分成兩組，原則是保證隨機性和平均分配，聰明如你，應該已經明白分流的原理了吧？
6. Hash分流是否能保證樣本在A-A-B三組中平衡分佈？三組數據的分流原則上需要儘可能平衡，即各個特徵都能均勻的分佈在三組試驗中，這樣才能符合AB-test控制變量的原則。
生化試驗中控制變量是一個較為簡單的問題，不管是脊蛙反射還是腸胃蠕動試驗；但是社會學中的試驗，控制變量卻異常複雜，因為面對大量人羣，很難通過隨機分配保證各個特徵的平衡，而且有些隱含變量很難被發現，也難以做到平衡。
這樣的問題稱在生化試驗中稱作是系統誤差，在互聯網AB-test中則會引發辛普森悖論。
生化試驗中往往通過重複試驗來避免，互聯網下的AB-test很難進行重複試驗，因為無法讓一個人即使用A版本，又使用B版本，串行試驗又會添加時間因素，所以只能採用其他的方式解決這個問題。
那麼，什麼是辛普森悖論呢？
我們用一個真實的醫學 AB 測試案例來説明這個問題，這是一個腎結石手術療法的 AB 測試結果：
看上去無論是對於大型結石還是小型結石，A療法都比B療法的療效好。但是總計而言，似乎B療法比A療法要好。
這個AB測試的結論是有巨大問題的，無論是從細分結果看，還是從總計結果看，都無法真正判斷哪個療法好。
那麼，問題出在哪裏呢？
這個AB測試的兩個實驗組的病歷選取有問題，都不具有足夠的代表性。
參與試驗的醫生人為的製造了兩個試驗組本身不相似，因為醫生似乎覺得病情較重的患者更適合A療法，病情較輕的患者更適合B療法。所以下意識的在隨機分配患者的時候，讓A組裏面大結石病歷要多，而B組裏面小結石病歷要多。
更重要的問題是：很有可能影響患者康復率的最重要因素並不是療法的選擇，而是病情的輕重！換句話説，A療法之所以看上去不如B療法，主要是因為A組病人裏重病患者多，並不是因為A組病人採用A療法。
所以，這一組不成功的AB測試，問題出在試驗流量分割的不科學，主要是因為流量分割忽略了一個重要的“隱藏因素”，也就是病情輕重。
正確的試驗實施方案裏，兩組試驗患者裏，重病患者（也就是AB-test中的特徵值）的比例應該保持一致。
我們再來聊一個互聯網領域的場景：我們對APP上一個按鈕進行了顏色調整，需要比較一下顏色調整前後用户UV點擊率是否提高？
經過一段時間的試驗，我們得到了兩組試驗的數據，為了説明辛普森悖論的問題，我們單獨抽離出了性別作為比較。
原因有二：一是性別在這次試驗中是重要特徵；二是這一特徵的數據不均衡，剛好出現了辛普森問題。計算出了兩組試驗的點擊率，如下：
數據中我們發現：單獨看這一試驗，無論是女性特徵和男性特徵，數據表現都是A組中較好。但是，總計卻是B組效果較好，其中的差異我想大家已經清楚了，性別特徵並沒有均衡的分佈在兩個試驗組中。
這個解決方法就是——定向試驗。
在進行試驗之前，先做一次試驗分析，確定對試驗影響較大的因素，然後通過分流的權重設置來均衡各個組之間的特徵差異，因素確認用到的方法較多，比如GBDT等等。
如下圖：
在進行試驗同時，可以實現各分組特徵中的監控。如果發現某一特徵在某一組中偏小，就增加這一特徵在這一組的分配權重，以保證特徵一致性。
但是這樣也存在特徵取捨的問題，具體就不展開來描述了，有興趣的小夥伴可以自行查詢一下。畢竟，能做到這一點的公司已經很不錯了。
分層試驗，交叉試驗，定向試驗是我們規避辛普森悖論的有力工具。
規避辛普森悖論，還要注意流量動態調整變化的時候新舊試驗參與者的數據問題，試驗組和對照組用户數量的差異問題，以及其他各種問題。
而優秀的增長黑客，不會去投機取巧“製造數據”，而是認真思考和試驗，用科學可信的數據來指導自己和企業的決策，通過無數次失敗的和成功的AB測試試驗，總結經驗教訓，變身能力超強的超級英雄。
二、AB-testing原理統計計算主要應用在效果評估領域。
客户經過分流之後在各個試驗組中產生數據，統計的作用即為查看對應組的樣本量是否達到最小樣本量，數據之間是否存在顯著性差異，以及進行差異大小的比較。
如下圖：
A-A-B三組數據觀察n天后，會產生3組數據，我們接下來的任務就是計算這三組數據的統計效果，進而確定哪個方案效果好。
1. 如何計算最小樣本量？最小樣本量是按照統計功效進行計算的，主要分兩類：絕對值類（例如：UV）和比率類（例如：點擊率）。
在試驗過程中，大部分場景是進行比率類指標的比較，單純的計算絕對值是沒有價值的；而且對於試驗效果來講，絕對值的比較可以轉化為比率的比較。
所以在計算過程中，我們統一成比率計算，以方便口徑統一和數值比較。
理論上，比率類最小樣本量計算：
例如：“XX提交”按鈕由紅色變為橙色，統計的指標是點擊UV轉化率UV_rate，測試時間是20200801～20200814，則計算“XX提交”按鈕的歷史月均值mean(UV_rate)為下面數據的均值avg(UV_rate)：
注：此處的計算需要對統計學中的統計功效有所瞭解，閲讀有阻力可以補充一下“統計功效”的計算方法。
流程圖介紹：最小樣本量的作用是確定試驗是否有效，後管配置好對應的客羣信息、開放流量佔比、提升率等信息後，後台需要進行“最小樣本量”的計算，並進行相關判斷，如下圖：
補充——統計功效：
確定好最小樣本量並實現分流、試驗上線之後，需要進行數據的有效天數需要進行相應計算：
試驗的有效天數即為試驗進行多少天能達到流量的最小樣本量。
當流量達到最小樣本量時，查看數據是否存在顯著性差異，如果不存在顯著性差異則繼續進行試驗，直到達到最大要求天數；如果試驗仍然沒有達到顯著性，則確定兩組試驗不顯著，即沒有明顯差異。
計算過程如圖：
如果到達試驗最小天數且試驗樣本量>=最小樣本量n_per，則觀察試驗是否有顯著性，如果A-A試驗沒有顯著性且A-B存在顯著性（B>A），則表示試驗成功，否則試驗失敗。
如果到達試驗最小天數且試驗樣本量<最小樣本量n_per，則繼續進行試驗；
3. 判斷試驗天數是否到達試驗最大天數（t天）：如果到達試驗最大天數且試驗樣本量>=最小樣本量n_per，則觀察顯著性；如果到達試驗最大天數且試驗樣本量<最小樣本量n_per，則終止試驗並標註試驗失敗。
邏輯流程圖為：
通過每天的數據計算可以做出如上判斷，進而確定試驗進行的有效天數並計算出顯著性水平。
三、AB-testing工程化經過上面的描述，我們可以通過下面的兩張圖來了解一下在工程方面，AB測試系統是什麼樣子的：
註釋：
- 根據需求設計好AB試驗之後，在AB測試系統配置好對應的策略；
- 將這一策略固化成文件，並推送到APP的AB系統SDK中；
- 客户每次訪問APP，先掃描AB系統SDK中的策略文件，根據策略文件給客户打標，分配對應的A、B版本；
- APP中根據策略呈現A、B版本的試驗內容，並監控客户的操作行為以及訂單行為；
- 這一行為被記錄並上報到大數據環境中；
- 天在大數據中進行顯著性計算和最小樣本量的處理，得到對應的顯著性結果。
我們再來看一個詳細的系統數據，如下圖：
目前為止，AB系統已經介紹完成了，AB的結構深不可測，其中也需要經常的更新和討論，歡迎大家關注溝通～
作者：野水晶體；個人公眾號：livandata
本文由 @野水晶體 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議