寫本文的主要目的在於希望能將理論和實際產品設計結合得更加緊密，幫助大家抓住設計的重點，對於比較深入的統計學原理不會過多涉及，僅用於輔助理解系統，如有深入學習興趣的讀者可自行研究。
不知不覺拖更了好久，後臺被催更了好幾次，前陣子比較忙，在給某四大銀做一個私有化的系統，再次實踐後又對相關系統有了新的認知，趁著熱乎這期就先來講講 A/B測試系統吧。
雖然目前已順利上線投產，但回想當初實在找了很多資料，包括書籍論文、相關產品使用資料，以及產品和開發者社區。資料雖然不少，但還是存在2 大問題，要麼過於理論化以至於難以實操落地，要麼就是過於靠近產品功能的介紹以至於對於產品背後的邏輯理解得不夠深刻，整體都不夠體系化（畢竟要深入和體系化講解篇幅是很長的，這事就交給我吧）。
因此筆者希望本文能對此有個補充，寫本文的主要目的在於希望能將理論和實際產品設計結合得更加緊密，幫助大家抓住設計的重點，對於比較深入的統計學原理不會過多涉及，僅用於輔助理解系統，如有深入學習興趣的讀者可自行研究。
當然，因為筆者現在做的是saas產品，所以在產品形態上是一個 saas系統模塊，讀完如覺得筆者理解不到位或偏頗之處，歡迎指教。
01 全文內容概要
說實在的，寫這麼一篇文肯定篇幅會比較長，所以對全文內容做個基本介紹還是比較有必要的。
對於網際網路人而言，A/B 測試應該耳熟能詳，即使沒用過絕大部分也聽過，但正常來說如果沒接觸過，很多人的理解可能仍停留在初中生物時學到的「對比實驗」。因此先介紹系統背後的基礎原理還是十分必要的，也能幫助大家更好地理解系統設計背後的目的所在，全文展開的節奏如下：
介紹 A/B 測試背後的統計學原理和試驗流程，拋出系統的定位，幫助大家理解系統設計的目標；結合對 3 大類涉及 A/B測試功能產品的調研，對背後不變的產品邏輯和系統架構進行抽象總結，幫助大家明確各個關鍵模塊及作用；在設計系統各個關鍵模塊時，需要重點考慮的地方，屬於落地實操部分，幫助大家看完後能知道應該具體該怎麼開始設計。
02 A/B測試背後的統計學原理
1. 基礎統計學概念
某度對於統計學的定義是：
統計學是通過搜索、整理、分析、描述數據等手段，以達到推斷所測對象的本質，甚至預測對象未來的一門綜合性科學。
聯繫到A/B測試，其實它就是通過先對部分用戶設置不同的方案，並進一步對不同方案的數據進行分析，從而去推測哪個方案在全量發布後效果是更優的，在這個過程中有必要介紹下幾個基礎的統計學概念。下面以一個 case 為例來說明，假設現在希望看下改變按鈕顏色能否提高落地頁中的按鈕點擊率，在這個試驗中涉及：
總體：落地頁的全部訪客，不僅包括試驗時訪問的那些，也包括後續訪問網頁的，綠色按鈕、紅色按鈕分別對應 2 個總體；樣本：在訪問時隨機分配了不同顏色按鈕的訪客，對應顏色的按鈕分別對應著一個樣本，這些樣本是總體經過抽樣產生的，通常在統計中只有樣本量足夠大，才能更好地確保實驗結論的有效性，所以 A/B測試系統會提供樣本量計算器，告訴用戶試驗應該達多少樣本量或運行多行時間才能得出相對有效的結論；抽樣：有多種抽樣方法，包括簡單隨機抽樣（有放回抽樣、無放回抽樣）、分群抽樣、分層抽樣，核心是要在隨機原則下從總體取出樣本，並且具有代表性（樣本能夠代表總體）；總體參數：描述總體特徵的參數，在示例中是按鈕點擊率統計量：樣本統計計算後得到的統計數值，在示例中是樣本的點擊率；參數評估：指用樣本統計量來估計總體參數，這裡我們通過對比試驗的2 個樣本間的數據，從而評估方案調整後針對全部用戶的效果。常有包括點估計和區間估計 2 種方式，一般我們使用的是後者。這也很好理解，當我們統計出樣本的點擊率是 20%，如果這時候說確定採用點擊率更高的按鈕顏色後，點擊率大概是20%，這便是點估計，顯然它的誤差是非常大的，所以我們在估計是會給出總體參數的一個概率範圍，即有多大的可能落在某個範圍，比如說有 90%的可能提升 10%~20%，顯然這樣的估計就會更加準確科學，通常我們稱之為「置信區間」，這個區間的計算有一定的方法，大部分 A/B測試系統都會給用戶提供這個參數以供參考。
2. 假設檢驗試驗
結合上文提到的落地頁按鈕點擊率試驗，假如現在通過一周的試驗，我們發現綠色按鈕比紅色按鈕的點擊率更高，但事實真的是這樣嗎？
不，其實我們提出的只是一個基於試驗樣本的「假設」，但我們其實更想知道的是「總體參數」，當所有按鈕都改為綠色後，最終針對所有用戶所統計到的結果也不一定就是我們在試驗中得出的結論。
所以，為了提升結論的可靠性，我們會基於對這個「假設」進行「檢驗」，看看這個「假設」在應用到「總體」時是否靠譜。
怎樣檢驗呢？
統計學提出了它的解決方案：小概率反證法，即統計學中認為小概率的事件很難發生，我們只需證明某個假設發生的概率小於某個值（通常取 0.05），這個值在統計學中稱為顯著性水平，如果概率小於這個顯著性水平，我們可判斷為這個試驗在統計上是顯著的，就可以有一定的把握認為這個假設不會發生，大部分 A/B測試系統都會給用戶提供這個參數以供參考。
通常情況下，在進行試驗時我們往往並不知道新提出的方案對於原方案而言是好是壞，所以我們常常假設「原方案（對照組）」和「新方案（控制組）」是沒有差異的，當我們證明這個假設小於顯著性水平時，就可以有一定把握可以說原方案與新方案是有差異的，結合樣本數據結果我們就可以獲得一個相對可行的試驗結論。
PS：上面介紹到的原理部分，為降低理解成本，沒有對統計學背後的一些更底層的數學原理進行說明，也沒有對假設檢驗中的基礎概念做解釋，比如原假設與備擇假設、棄真與取偽錯誤、單側與雙側檢驗等，有興趣的讀者可自行了解
小結
AB測試系統只是站在上述理論的基礎上進行了產品化，有了理論基礎，我們才能夠在系統中通過各個功能去確保試驗的有效性，簡單的對應關係：
抽樣：系統需提供科學的分流算法來確保試驗有效性；統計量：系統需要建設好基礎的數據埋點和數據統計能力，才能完成統計量的計算；假設：系統需提供試驗方案的編輯管理能力，讓用戶能夠創建不同的試驗方案，從而形成試驗假設；置信區間、統計顯著：系統在提供試驗樣本統計量數據外，還需基於試驗統計量類型，基於不同的檢驗計算方法去計算出統計指標，通常為置信區間以及試驗是否統計顯著。
03 系統核心業務流程
AB測試系統核心的業務流程當然是圍繞試驗的設計和分析進行的，同時筆者調研了業界多個 AB測試產品，各家產品在使用流程上也相差無幾。但不同的產品也提供了一定的方法來提升流程的效率，在設計時需要多考慮系統應該通過提供什麼樣的能力來支撐這個業務流程，以及怎樣才能夠幫助提升流程效率，幫助運營者更快更準確地得出結果。
業務流程圖
結合一個具體 case來說上述業務流程，還是採用上文的例子，現在是希望提升落地頁的按鈕點擊率。
確定改進點：按鈕樣式；設計不同方案：設計了綠色和紅色 兩套方案；確定衡量指標：按鈕點擊率；配置試驗：配置按鈕顏色為綠色、紅色共兩套落地頁；分析試驗數據：對比哪個方案的按鈕點擊率更高，是否統計上是顯著的；如果發現紅色按鈕比原來綠色按鈕的點擊率還差，則可決定中止試驗不繼續優化，或更改為其他顏色繼續試驗；如果發現紅色按鈕和設想一樣比原來綠色按鈕的點擊率更好，則可考慮將按鈕顏色徹底改為紅色。
04 系統目標
在設計系統時，我們通常會先定義系統目標並拆分階段重點，讀過 google 相關論文的讀者也會發現 google也結合自己的情況給出了系統的目標：
更多：google數據驅動的文化使其對試驗運行數量的要求比較高，要求系統能夠支持同時運行更多的實驗；更快：簡單便捷地創建試驗；更好：能夠去規避無效實驗的運行、、發現有效但不好的試驗、能夠提供標準的衡量維度確保對比是有效的。筆者在設計自家系統時則定義如下：
（1）要能確保試驗有效性
確保試驗有效運行：確保分流規則、統計指標計算規則是科學的；讓用戶確保試驗有效：引導用戶確保樣本量符合要求或提供樣本量計算工具、提供置信區間和統計顯著性指標輔助用戶進行判斷。（2）能支撐到更多有需要的試驗場景
讓試驗進行得更快速；能夠幫助用戶更快地得出結論（意味著不用耗費更多流量）：部分系統提供 MAB算法自動分配各個版本的流量，幫助用戶簡化分析的過程，並在得出優勝版本能夠自動全量應用。（3）更便捷快速地完成配置
指使用者能夠有較低的使用和學習成本，A/B測試本身需要比較專業的背景知識，在網際網路企業內部往往是增長團隊和產品經理等角色負責。但筆者所設計的系統面向傳統企業以及一些有IT部門的企業，企業內是否有配置專業的人員來實施，是否有對A/B測試比較了解的人都是問題。所以產品設計上一方面需要考慮易用性，另一方面也需要考慮讓交付同事能更好地理解以便引導客戶使用。
05 系統架構
結合筆者調研的結果，目前會涉及到AB測試系統的公司主要有以下幾類：
（1）AB測試服務saas軟體供應商
以saas 化形式提供AB測試能力，客戶基於簡單對接後即可基於平臺能力進行 AB測試，能夠有效降低企業自己的開發投入，企業體量沒達到一定規模時或相應的團隊建設沒到位的情況下往往可採取這種方案，這些供應商可能同時也會提供其他數據分析平臺等其他數據服務，針對的目前客戶以有網際網路相關業務、有 IT研發能力的企業為主。
（2）提供 AB測試能力的其他saas 平臺
比如營銷 saas 產品主要針對的營銷場景下的 ab 測試能力提供、用戶運營 saas產品主要針對消息推送場景下的 ab 測試能力提供。
（3）需自建 AB測試系統的企業
這類企業的公司體量基本都到了一定的規模，並且有專業的增長團隊。
在產品形態上，目前在不同類型產品上看到的總共有 3 種形態：
AB測試saas產品一般均以試驗管理的形式，在試驗報表中查看 AB測試相關數據；營銷 saas 產品則會與營銷流程編輯器結合，以流程組件的形式提供AB測試能力，在流程數據中查看 AB測試相關數據；垂直場景的用戶運營工具則是在以高級配置的方式提供AB測試能力，比如可在業務功能配置中通過額外的AB測試配置項完成配置，並在業務數據中可查看 AB測試的相關數據。但拋開具體的產品形態，由於系統背後的原理、業務流程和目標都相同的，所以經過抽象後的系統架構其實是差不多的，僅在一些細節方案上有差異。
系統架構圖
1. 業務層
這一層是AB測試的核心功能模塊，用於支持用戶創建 A/B 測試試驗。
1.1 樣本設置
用於設置進入試驗的客戶，主要涉及 2 點：
（1）樣本篩選
可篩選特定類型的客戶參與試驗，可與CRM、用戶畫像系統相結合，可針對某一特定人群進行試驗。
（2）樣本量設置
可設置客戶進入試驗的佔比或數量，樣本量對於試驗有效性有著重要影響，大部分系統都會提供一個樣本量計算公式，結合用戶設置的預期提升效果，告知用戶較合適的樣本量是多少、試驗應該進行多久，讓用戶確保試驗有足夠的流量（也看到一些產品會提供一些經驗值給到用戶，比如讓用戶確保樣本數量應該大於 1000）。
1.2 流量分配
主要作用是決定客戶命中哪個試驗、命中的是試驗的哪個版本，這塊跟試驗的管理結構有關係，分流模塊需要滿足以下要求：
（1）隨機均勻分流
分流規則是系統中比較核心的模塊，有幾個核心的點：
必須確保樣本一致性：確保分配到不同試驗方案的用戶樣本特徵是一致的，在統計上控制單一變量原則，即所謂「隨機均勻」；確保分流一致性：在分配到不同版本時應確保隨機均勻分布，並且確保分流一致性（即同一客戶多次進入同一 個試驗，訪問的試驗版本相同）。（2）分層分流
當需要同時進行多個試驗，且避免試驗間會互相干擾時，需要通過分域的形式把一些會互相干擾的試驗區隔開，用戶只能命中其中某個試驗，通過分層的形式把不會互相干擾的試驗區隔開，用戶可以同時命中不同層的試驗，通用的 A/B 測試工具都會支持用戶自定義層級規則和試驗所處層級。但也並非必需，需要結合自身系統場景看是否有並發多個試驗的場景，可查看下方分流模型示意：
分流模型圖（來源網絡，如有侵權請聯繫刪除）
分流指定版本：在試驗結束後，用戶可直接指定進入試驗的客戶進入哪個試驗版本，為了提升流程效率，大部分產品提供了自動幫助客戶選擇最優版本的能力，但大部分只能從單個指標維度進行評判；自動分流：基於MBA算法，可自動結合不同版本方案的試驗指標，自動調整流量分配規則，幫助快速選擇出可信賴的優化版本，可有效提升試驗的效率，目前有提供該能力的主要是一些比較專業的 ab 測試工具。1.3 試驗配置
（1）版本設置
可添加不同的試驗版本，與對照組版本進行對比，不同類型試驗版本設置會有所不同，同時設置方式也與具體的 A/B測試場景有關，比如：
大部分系統針對 UI層面的優化會提供可視化編輯模式，可讓運營人員直接在可視化界面完成不同方案的配置；針對廣告著陸頁場景，則會提供的是連結合併跳轉的模式，針對不同版本的廣告著陸頁提供不同的URL，用戶訪問時會隨機跳轉到某個版本的連結中；針對算法優化等後端優化場景，則提供接口給後端服務調用。這一塊也是需要具體考慮，需結合業務場景和自身平臺的情況考慮用戶配置版本的方式。
（2）流量設置
即設置分配給各個版本的流量，總和需為100%，需要支持在試驗中進行調整，方便使用者結合試驗情況靈活調整流量分配（一般會先給試驗版小流量試跑，然後再進一步加大流量）。
（3）指標設置
設置指標後可在數據統計中看到不同版本對應的指標數據，用於評估不同版本的效果：
主要目標與附加目標：評估方案好壞有時候顯然不可能只從一個維度去評估，並且即使新版本方案在核心指標上表現更好，也不排除在其他比較重要的指標維度上表現更弱，所以主要目標是指本次試驗重點要關注優化的指標，附加指標則是其他關聯的效果指標，可幫助我們進一步全面地評估方案；複合指標與自定義指標：可支持更多的業務場景；自定義指標：指用戶可以自定設定指標，可指定更多事件指標以及複合型指標，本期暫不考慮。（4）分層分域
本質上是為了解決流量在多個試驗的分配問題，考慮的是如何儘可能地分配流量確保每個試驗都有足夠的樣本，以及如何避免試驗之間互相干擾，這些層和域需要結合自身情況去做劃分，常見的可劃分為啟動層、UI層、算法層等。比如對於頁面中同一個區域進行試驗，如果現在在進行 2 個試驗，分別對文字顏色、文字背景做測試，假設不把這 2 個試驗分配在不同域，那可能出現文字顏色和文字背景都是同一顏色，會導致在前端完全不可見，進而影響試驗。
2. 數據統計層
這一層會展示試驗數據，包括試驗設定的各個指標數據以及統計數據，使命是幫助用戶更準確和快速地進行決策，選擇最優的方案，其中統計類指標主要提供 2 個指標：
一個是置信區間，通常採用的是置信度為 95%的區間，用於幫助用戶科學評估方案效果；另外一個是統計顯著性指標，用於告訴用戶當前統計得到的結論在統計學上是否是顯著有效的，提升決策科學性。當然，有時候會需要去細分到不同人群去看效果，可以進一步評估方案在不同人群中的效果是如何的，在產品上只需增加一個客戶篩選即可。
3. 數據接入層
這一層主要解決試驗指標統計的問題，與 AB測試系統的應用場景相關，要拓展系統使用場景，肯定是得垂直地從數據埋點、試驗設置都進行拓展，通過同步外部數據，可以大大拓寬使用場景，比如筆者設計的是營銷 saas 系統，如果能對接交易數據，場景可以進一步拓展為「驗證通過更低的優惠券折扣是否可促進交易轉化率」。
4. 服務接入層
當企業內部有多個客戶端、多個系統、多個場景需要對接 AB測試能力時，通過標準接口可快速完能力的部署，有助於可以提升系統的擴展開放性。
06 業務場景
當我們對系統要做的事情以及系統的整體邏輯有所理解後，就需要因地制宜結合自己負責系統的業務場景、客戶特點等因素設計產品的能力分布和形態。
當然，場景肯定是沒法遍歷完的，但可以記下一句話：「當你無法衡量它時，你就無法優化它」，結合上文對系統架構的介紹，我們知道A/B測試系統底層需依賴數據埋點這一基礎設施，當我們能埋的點，能統計到的數據越多，能調控的變量更多，系統能支撐的場景也就越豐富。
但筆者還是對常見的AB測試場景做個簡單總結，方便大家參考：
產品優化UI層面優化：比如調整頁面布局，調整文案等功能體驗優化算法層面：比如推薦規則優化、列表展示規制，提高內容點擊率營銷優化廣告落地頁：營銷文案優化，提升按鈕點擊率營銷活動流程、策略優化等等其中 AB測試saas 產品無可置疑肯定基本都可滿足上述場景，營銷saas產品中則會圍繞活動內容、消息觸達、權益策略、活動流程等營銷相關的場景做優化，垂直類場景僅支持自身產品場景的優化，比如「某策」能進行觸達與否是否影響最終轉化的 ab 測試。
07 落地細節注意
1. 分流模塊
分流算法的實現方法網絡上大把，推薦大家可以參考一下 google 的論文，具體實現上就是通過一致性哈希算法計算用戶 id 、層 id 後進行取模即可，這樣既可實現上文我們提到對於分流需要注意的關鍵點。但這裡需要注意的是要結合我們設計出的產品形態，與上文的產品架構進行對應，考慮需要加什麼因子加入哈希算法因子中。
當然，一些平臺為了確保樣本的一致性也提出了一種驗證性的方法，比如微博廣告系統提到的一個解決方案：
在廣告系統中，用戶是通過多維的畫像向量（a,b,c,…,n）來進行刻畫的，如果流量劃分是均勻的，意味著用戶的每一個畫像向量分量在該流量劃分條件下是均勻，更進一步，多個畫像向量分量的組合在該流量劃分條件下也是均勻的。通過進行用戶畫像向量單個分量和若干個畫像向量分量的組合的均勻性驗證，即可來反映該流量的劃分的均勻性。
2. 試驗指標模塊
這塊目前也比較成熟，在代碼上有一些已經封裝好的計算方法可直接供開發去調用，目前 adobe Target產品使用的是 t 檢驗的方式來計算置信區間和 P 值（p 值小於 0.05即證明本次試驗是統計顯著的），具體不成問題，問題主要在於公司內部目前是否一套比較完善的數據採集處理機制。
08 總結
結合全文，相信讀者對於 AB測試系統已經有了比較完整的認識，大的原理和邏輯基本不變，變的是大家需要結合自身業務場景、自身內部系統情況去因地制宜，尤其是要做好業務場景的梳理，即可從目前已經擁有的數據進行反推，也可從業務需求進行正推。
但是，需要提醒的是，至此我們也只是設計出了一個能用的系統而已。
AB測試的落地還需要依賴使用的組織和人，公司組織層面上是否有數據驅動的意識、執行人員層面是否具備做AB測試的專業知識、支持做AB測試的場景是否有足夠的價值吸引力、是否具備足夠的數據量來做 AB 測試，這些因素都會影響到最終系統的落地效果。
如果碰巧你做的是 saas 系統，面向的客戶可能是傳統企業或傳統銀行這類有研發能力但數據驅動意識不強的企業，更是由於考慮清楚上面提到的幾點，好好評估客戶是否有落地A/B測試的能力。
本文由 @Sen 原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自unsplash，基於CC0協議