在談AB測試之前，忍不住先說一說另外一個概念：Growth Hacking
這個詞目前為止仍沒有一個確切的中文翻譯，直譯過來就叫“增長黑客”。最早在2010年,由Qualaroo創始人兼首席執行官肖恩 埃利斯（Sean Ellis）提出這一概念,隨后安德魯 陳（Andrew Chen）在2012年4月發表一篇文章叫《Growth Hacker is the new VP Marketing》后引起業界廣泛關注與交流。在硅谷很多知名的初創企業如Facebook、Twitter、LinkedIn等等專門為Growth Hacking這個角色成立獨立的部門，全權負責用戶增長。
“Growth Hacking”拆分開來看，“Growth（增長）”指的便是產品增長這一核心目標，不僅包括用戶量的增加，更是囊括了產品各個聲明周期各個階段的核心指標（日活，月活，留存等等），增長的目標可以拆分為“AARRR”漏斗轉化模型，即：Acquisition（獲取用戶）、Activation（激發活躍）、Retenition（提高留存）、Revenue（增加收入）、Referral（傳播推薦）。之所以稱為漏斗是因為每個環節都將會有一些流失，而剩下的那部分用戶則在繼續使用中流向下一個環節，在層層深入中實現最終轉化。
從“用戶獲取”到“傳播推薦”在整個AARRR模型中，增長黑客在不斷的“指標分析--提出目標--頭腦風暴--AB測試”來提出產品優化策略，減少每個環節的損耗，提高轉化率，從而不斷的擴大自己用戶群體的數量和質量。
而“Hacking（黑客）”我們可以理解為用創造性思維分析解決AARRR模型中每個階段存在的問題。
關於“增長黑客”有興趣的同學可以關注范冰著的《增長黑客》一書。
現在回到我們的AB測試，A/B測試概念簡單概括就是，將用戶分為兩組，一組使用舊產品（或舊功能），一組使用新的。然后對比兩個用戶組，通過數據來分析，新的功能究竟是好是壞。沒錯，就跟小學的時候做的那些有控制組、實驗組的自然科學實驗一樣一樣的。
AB測試可以說是增長黑客分析和解決問題過程中最重要的武器。要實現產品優化，首先我們找到產品在AARRR模型中具體某個周期存在的問題，例如我們發現很多用戶來到了產品注冊頁面，卻沒有產生注冊的行為，那我們就可以得出一個簡單的結論：注冊頁面轉化效率比較低。之后提出我們的優化目標，即：提高注冊頁面的轉化率。然后發動產品經理進行頭腦風暴，提出優化方案。最后利用AB測試來驗證方案是否可行。總結一下可以概括為“發現問題 - 提出目標 - 建立假設（提出優化方案）- AB試驗 - 驗證假設”若假設成立則上線新方案，若不成立則繼續頭腦風暴提出新方案。
經過一番頭腦風暴提出產品改進方案后，接下來就需要用AB測試來驗證改進方案是否正確了，接下來我們來探討一下具體的AB測試解決方案。
架構設計
整個架構包括以下幾個部分：
- AB測試管理平台：產品經理在管理平台上創建、修改、關閉試驗，並查看試驗結果報表。
- 試驗配置數據庫：AB試驗管理平台后台數據庫，主要存儲AB試驗配置信息。
- 分流服務：執行具體的分流算法的Web服務，客戶端通過請求分流服務來獲取具體加載哪個版本。
- 集成方應用：集成了AB測試SDK的應用程序，真正的AB測試需求方，可以是Web、Android、IOS、Windows客戶端等。
- SDK：負責跟分流服務進行交互。
- 數據收集：收集應用程序打點數據。
- 數據分析：分析打點數據，通過一定的數據分析算法，得出能夠判斷版本優劣的報表數據。
AB測試管理平台
要開始AB試驗，產品經理首先在【AB測試管理平台】上創建AB試驗，填寫AB試驗的關鍵信息：
- 版本開關（集成方應用寫死在代碼里的，用於區分AB試驗的依據）
- 優化指標（數據統計時收集的關鍵指標）
- 分流比例（將百分之多少的用戶作為試驗用戶）
關於這三個屬性暫時不理解沒關系，稍后會再次介紹。
集成方應用
應用程序應為每個用戶都生成一個唯一標識（通常隨機生成一個uuid），用來區分用戶，這個標識不應隨着用戶重啟應用等行為而發生改變，我們姑且稱這個唯一標識叫puid。分流服務會根據“puid”運行分流算法。
Tips：Web端可以在頁面加載之前，運行一段JS代碼生成並存儲在cookie中最好一次生成永不過期，Android和IOS可以取設備號來作為puid。
當用戶訪問應用時，在頁面加載之前首先利用SDK訪問分流服務獲取版本信息，再根據不同版本信息加載不同的版本。
當用戶在使用過程中產生一些關鍵操作時，進行數據收集，發送相關統計數據到數據收集服務。
//全局唯一的puid，用戶終端的唯一標識 String puid; //從分流服務獲取到的版本信息 String versionInfo; //在頁面加載之前執行此操作 void onPageLoad() { //版本開關 Stirng versionSwitch="android_client_purchase_button_color_test"; //將用戶終端唯一標識，以及版本開關傳遞給分流服務，獲取分流版本 versionInfo = getVersionInfo(puid,versionSwitch);
if(versionInfo=="版本A") { //運行版本A的初始化代碼 } else if(versionInfo=="版本B") { //運行版本B的初始化代碼 } } //在用戶產生關鍵操作時打點統計數據 void onPurchase() { //將優化指標"purchase",版本信息，puid發送給數據收集服務 punchData("purchase",versionInfo,puid); }
觀察上面的代碼，假設我要做的AB試驗是在安卓端測試“購買按鈕的顏色對產品購買率的影響”。
我們首先設立一個版本開關叫做“android_client_purchase_button_color_test”，在創建在AB測試管理平台上創建AB實驗之前，產品經理和產品開發人員約定好版本開關的值，分流服務根據版本開關的值判斷請求來自於哪個AB實驗，以便讀取AB實驗配置。
在應用程序頁面加載之前，將“puid”和“版本開關”作為參數請求分流服務，分流服務根據“版本開關”判斷請求來自哪個AB試驗，並把“puid”作為參數運行分流算法，最終返回“版本信息”給客戶端。客戶端以分流服務返回的“版本信息”作為條件判斷該加載哪個版本。
在用戶產生購買行為時，將優化指標“purchase”，當前版本信息以及puid發送給數據收集服務。數據統計時通過計算在哪個版本上“purchase”這個指標被發送了多少次，以及用戶量等。
那么puid的作用是什么呢？puid代表着客戶終端的唯一性，代表着單個用戶，在版本開關固定的情況下，用同一個puid去請求分流服務，只會產生同一個版本信息，也就是說用戶第一次啟動應用時看到的是版本A，下次啟動看到的也是版本A，避免了“有時看到版本A，有時看到版本B”這種非常不好的用戶體驗。
SDK
上面架構設計圖中，在集成方應用里面通過SDK與分流服務進行交互，簡單的服務調用為何要專門一個SDK呢？
設想一下，當用戶基數非常大的時候，每次用戶打開頁面都去調用分流服務來獲取版本信息，這樣的操作將會給分流服務帶來非常大的壓力。但其實我們並不需要每次重新請求分流服務，只需將上一次的請求結果寫入緩存中，下一次打開應用時復制過來即可。 什么情況下需要重新請求分流服務？那就是當我們的AB試驗有所更改，比如分流比例的更改，最初用5%的用戶作為試驗用戶，后期為了進一步驗證實驗結果，需要將試驗用戶擴大到10%，也就是說有額外5%的用戶需要從版本A切換到版本B，那么就需要重新請求分流服務了。
解決方案是，設定一個請求過期時間，假設一個小時（設定為一天也沒有關系，通常一個AB試驗至少運行幾天，或幾周才能得出一個比較靠譜的結果），再次調用分流服務之前，先觀察一下緩存中有沒有之前的請求結果，若之前的請求結果有沒有過期，那么直接把上次的請求結果作為結果返回。
分流服務
分流服務的主要功能就是響應來自集成方應用的獲取版本信息的請求。並每隔5秒鍾同步一下最新的AB試驗信息。
分流服務的邏輯：
首先從用戶請求中讀取參數，然后對參數進行校驗，根據versionSwtich（版本開關）的值從本地緩存中讀取AB實驗配置，然后開始執行分流算法，首先判斷以下是否需要執行分流因子，若不需要則直接執行散列分流，若需要執行分流因子后再進行散列分流。
什么是分流因子？
有時候我們的AB實驗並不是面向所有的用戶展開，例如只對VIP用戶進行AB實驗，或者只在對上海的用戶做AB實驗，或者我們也可以只對上海和北京兩個城市的用戶做AB實驗，於是我們把會員、地域等等划分條件成為分流因子。當需要按照分流因子分流的時候我們先按照分流因子對流量進行歸類（需要客戶端請求分流服務的時候將地域、是否會員必要的信息通過cookie或session等傳遞給分流服務），然后再執行散列分流。
散列分流
“散列”就是將puid按照一個算法散列為0~100之間的小數，為了方便說明，我們暫時稱散列后的值為K。前面說過，產品經理創建AB實驗的時候，會填寫一個分流比例，這個分流比例就決定了具體給用戶分配哪個版本。假設拿50%的用戶作為實驗用戶，那當K值落到0~50之間時，就會為用戶分配版本A，當K值落到50~10之間時，就會為用戶分配版本B。再假設拿20%的用戶為實驗用戶，那么K值落在0~20之間時，為用戶分配原始版本A，20~40之間則為用戶分配版本B，另外60%的用戶將不參與結果統計，返回原始版本A。
數據統計分析
在數據分析中我們用到了兩個統計學的概念，即：“顯著性”和“置信區間”。篇幅有限，這里就只介紹個大概。
A/B 測試是一種對比試驗，而試驗就是從總體中抽取一些樣本進行數據統計，進而得出對總體參數的一個評估。
統計顯著性。在假設檢驗中，如果樣本數據拒絕原假設，我們說檢驗的結果是顯著的；反之，我們則說結果是不顯著的。
置信區間。置信水平代表了估計的可靠度，一般來說，我們使用 95% 的置信水平來進行區間估計。簡單地講，置信區間就是我們想要找到的這么一個均值區間范圍，此區間有 95% 的可能性包含真實的總體均值。
數據舉例
| 版本 |
用戶總量 |
總值 |
平均 |
變化[95%置信區間] |
變化顯著性 |
| 版本A |
42470 |
92990 |
2.19 |
|
|
| 版本B |
42674 |
108468 |
2.54 |
+16.09%[14.98%, 17.20%] |
顯著 |
觀察上面的表格
版本A一共有42470個用戶，產生的打點數據量是92990，平均每個用戶產生打點2.19次。
版本B一共有42670個用戶，產生的打點數據量是108468，平均每個用戶產生打點2.54次，比版本A提高了16.09%，我們有95%的概率相信，最差的情況下版本B比版本A好14.98%，最好的情況下版本B比版本A好17.20%，變化顯著性為顯著，代表版本B比版本A好這個命題是真的。
Tips: 除了上面提到的數據，在真實的事情情況中，還可以針對不用的版本分別統轉化率，回訪率，日活等等常用指標，觀察用戶活躍度、轉化率等等的變化情況。
AB測試結合灰度發布
在一輪實驗后我們發現版本B確實要比版本A更優秀，那么我們就可以在AB測試管理平台上結束這個實驗，並設置最終版本為版本B，分流服務接到這個通知后就會改變分流策略，所有的請求都將返回版本B，這樣就實現了一鍵發版。
AB測試的意義不只是驗證改版策略是否正確，結合灰度發布來說，每一次新版本的發布都首先經歷過小流量的 A/B 測試驗證，所以可以保證確定性的提升。每一版更新都比老版要更好一些，日積月累就會大幅度超過 “裸奔” 的競爭對手。