手把手教你從0到1搭建AB測試系統（一）
本文對AB測試做了相關的整體介紹。什麼是A/B測試？為什麼要使用A/B測試？A/B測試的架構是什麼？
最近一段時間在負責公司內部AB測試系統從0到1的搭建，在實現中踩了很多坑，也做了很多競品分析瞭解國內外的競品通用做法。
藉此機會總結下這段時間的經驗並分享給大家，希望能讓看到這篇文章的人少走彎路。
之所以命名這個題目是因為我小學的時候曾學過一篇文章叫《手把手教你從0-1搭建傳奇私服》，一不小心就暴露了年齡哈哈哈，跟著教程確實搭建成功並且還有附近的人進入遊戲，可是當時自己的電腦作為伺服器的效能太差，運營一天就關閉了，傷感。
分析大多是從產品經理需要了解的寬度和深度來描述，具體的技術不會涉及很多。AB測試的系統裡面細講起來會比較複雜，這一系列文章的主要目的就是掰開了揉碎了結構化的把這點事說清楚。
閒話少敘，進入正題！
一、什麼是AB測試？
引用VWO對AB測試的解釋：
A/B testing (sometimes called split testing) is comparing two versions of a web page to see which one performs better. You compare two web pages by showing the two variants (let’s call them A and B) to similar visitors at the same time. The one that gives a better conversion rate, wins!
從圖中可以看出， AB測試是對比兩個或多個變體在同一地方好壞的方法，並且需要保證樣本的同時和同質。
同時性：兩個變體是同時投入使用的，而不是今天使用A變體，明天使用B變體，這樣會有其他因素影響。比如，對於電商網站來說今天沒有活動，而明天是雙十一，在這個條件下我們不能判斷變體B比變體A好。
同質性：兩個變體對應的使用群體需要保證儘量一致。比如，想想一個極端場景：變體A裡全是女性，變體B中全是男性，我們根本無法判斷出來究竟是方案影響了最終效果還是性別。
為什麼要使用AB測試？
先來看下最近挺火的一個概念：增長黑客。
俗話說：人挪活，樹挪死。網際網路想要成長也得挪一挪，我個人理解增長黑客的核心就是：變。
左邊PDCA戴明環，這個四部的迴圈一般用來提高產品品質和改善產品生產過程。
右邊是增長黑客環，是不是很像？
網際網路的好處就是能對資料能夠有更加深層次的挖掘和記錄，經過對整體資料的分析提出能夠達成自己的目標的解決方案，然後排期、測試，根據測試資料再進行分析依次迴圈，如下圖：
觀察力驚人的你一定還發現了增長黑客裡邊有個紅色星星是幹啥的？
增長黑客裡叫北極星指標，他的作用是：
- 重點抓取；
- 明確優先順序；
- 提高行動力；
北極星指標舉例：
詳細介紹北極星指標的文章可以看這篇： ofollow,noindex" target="_blank">如何選擇正確的資料指標？
上述說了這麼多概念，主要是為了讓大家對AB測試的背景有個基礎的認知，接下來重點說AB測試。
二、AB測試的架構
我會從四個方面：管理後臺、分流引擎、結構資料、對接方式來解構如果想要做一個AB測試系統需要準備哪些。
這篇文章的目的是為了讓大家有一個巨集觀的瞭解，詳細的功能性闡述會放在後續的文章中。
下面這張是巨集觀的腦圖：
1. 管理後臺
我們習慣定義每一個AB測試都屬於一個獨立的實驗，方便管理和檢視統計資料。
在管理後臺當中可以建立、管理實驗，還可以在實驗進行中、結束後檢視實驗資料。
舉例國外和國內分別做的比較好的AB測試平臺的實驗架構：
國外：Google 的 Optimize。Google的實驗架構一共有五層：
國內：吆喝科技。吆喝科技的實驗架構一共有四層：
為什麼有這麼多層？
其實真正看實驗的是最下面那兩層，實驗下面繫結不同的變體（或者叫版本）。
上面的層是為了更好的管理賬號，他們作為商業軟體需要更靈活的適合不同公司的情況，各位按需即可。
2. 分流引擎
AB測試一般又稱為桶測試，為啥叫桶測試呢？奧祕就在分流這塊！
先解釋一下變體和桶的關係：
為了方便計算，假設現在有12個人（Customer），我們給12個人進行編號，C1~C12；有6個桶（Bucket）我們編號為B1~B6。
每個使用者在訪問實驗時，會先進入到分流演算法中，由演算法來決定分到哪個桶裡面，都分完後最理想的是每個桶裡正好有2個人。（實際上基於大數定律原理，資料量越大分配的會越平均）
那麼現在，假設每個變體的流量是50%，變體A我們假定對應的是三個桶B1、B2、B3桶，變體B也是對應的是B4、B5、B6桶。
實際上有沒有發現，變體A選中的概率是50%，所以只要對應任意三個桶即可：
- 演算法：保證分每個桶分到的越隨機越平均越好。
- 節點：前端分流和後端分流
- 分流主體：Cookie、Session
國內的AB測試一般採取的是Cookie分流，Google採取的是Session分流。
3. 結構資料
- 埋點方式：主要是資料的採集和上報
目前市面上常用的埋點方式為：程式碼埋點、視覺化埋點、全埋點（或者無埋點）
- 資料倉庫：埋點資料的清洗、計算、儲存。
結構資料的準確性決定了，AB測試資料分析準確性，如果你所在的公司埋點沒有搞起來，並且無法保證資料的準確性，我勸你還是不要做AB測試浪費時間 [尷尬又不失禮貌的微笑]。
4. 對接方式：業務方接入到AB測試的方式
對接方式更偏技術，但是從產品的角度需要知道不同方式對AB測試競爭力的影響。
如果是商用的AB測試軟體SDK肯定是首選，因為你不可能每次都與業務方對接介面，並且SDK裡面是會包含埋點的。
如果只是內部使用，並且是初步搭建AB測試系統，最好還是選取介面的方式，方便快捷並且比較穩定。
5. 從訪問到產生實驗統計資料的流程
上面是拆分了不同的模組做了簡單的介紹，下面介紹一下使用者從訪問到產生實驗統計資料的整個流程。
1. 分流引擎：當用戶來到實驗時會通過分流引擎把流量一部分分到變體A，一部分分到變體B。
注：在分流引擎中會有一些模組拆分，這些會在後續的文章中詳細講解。
2. 變體展示：為了方便理解，假設我們本次實驗每個變體流量均為50%，則所有訪問本次實驗的將會有50%的概率看到變體A，有50%的概率看到變體B。
注：實驗對應的每個變體的流量是可以通過管理後臺進行配置的。
3. 埋點指標：業務端或者AB測試服務提供端採集預先定義好的“埋點指標”。埋點指標的意思是，能證明此是否達成了所設定的北極星指標的具體資料。
4. 資料整理：針對埋點指標進行清洗、計算。
5. 資料展示：對應到管理後臺中是實驗報告，是對本次實驗結果的集中展示。包括描述性統計分析和決策統計分析。
6. 變體編輯：對不同變體實際功能需求的開發。這個模組是發生整個實驗開始之前，需要定義好每個變體究竟是以什麼方式展示給參與實驗的使用者。
比如：變體A用紅色按鈕，變體B用綠色按鈕。
如果把所有的資訊全部都寫進一篇文章可能大家對這篇文章剩下的操作就只剩收藏了，加之平時寫文章的時間畢竟也比較有限，所以就把它拆分成了一個系列。
本次只是先將AB測試做整體介紹，後續再分開做某一模組的詳細介紹。大家可以在留言中給自己感興趣留言，疑問比較多或者更多人感興趣的地方會優先更新。
萬一此篇文章看的人很少也沒人回覆，只能按自己的節奏逐步更新，就全當總結歸納罷了。
水平有限，歡迎各位大神來砸場討論！謝謝！
本文由 @ 任秀明 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議