本文以一次性設計好A/B test功能架構為目的，對A/B test的使用場景與功能模塊進行了分析。

最近在考慮一個產品的小功能改進，目前我們的產品列表按照產品帶來的收益排序，如果用戶點擊了產品之后，那再點擊這個產品可能就無法帶來很大的收益，于是我們想到，那把用戶點過的產品放在產品列表底部怎么樣呢？

當然團隊內部也有不同的聲音，用戶點擊產品之后，可能由于網速、或者手滑，并沒有實際上注冊到第三方產品中去，那么放在產品列表底部可能會給用戶造成困惑，也失去了用戶第二次點擊的機會。

內部討論過后，我們認為這是個值得做的嘗試，但應該以A/B test的方式去實現。根據數據，來決定是否要全量覆蓋該功能。

A/B test的概念大家并不陌生，被廣泛應用于快速迭代的互聯網產品中。同時在以前的迭代過程中，我們也以其他方式進行過A/B test。

但是A/B test帶來的問題是，單個功能的A/B test是很容易做的，但與此帶來的數據統計拆分，每次都會帶來重復的工作量。因此比較節約的方式是，一次性設計好A/B test功能架構，支持未來的持續A/B test，降低單次測試帶來的邊際成本。

一、A/B test的使用場景

從技術上講，AB測試存在兩種場景：純頁面交互A/B和功能A/B。這兩種場景的區別僅在于是否需要向后端申請不同的服務。

二、功能模塊

A/B test功能模塊大概有以下三個：用戶分流服務、A/B test 配置、數據統計。整個流程如下：

用戶訪問后，根據用戶屬性，調取用戶分流服務，根據用戶分流服務返回結果調取相應 AB/TEST 配置。

前端業務側做數據埋點，在用戶訪問時，前端做數據上報。同時自動生成數據報表，處理原始數據后給出是否采信方案的結論。

2.1 用戶分流服務

用戶分流服務用于將訪問用戶分流進入對應客群。

這里我做設計的時候有一個部分很后悔，就是我曾經做了一個版本是將用戶分類展示不同產品列表的功能。本質上就是一種設定客群然后分流的服務，當時沒有考慮到后來這個功能有這樣的拓展，所以與產品列表與運營位配置耦合度很高。在做 A/B test 的分流服務時，只能獨立再做一套。

事實上不僅用戶分流服務是一個應該與各功能模塊解耦的部分，客群服務（包括用戶信息、用戶畫像建設）也應該解耦。這兩個服務結合起來可用于：為不同用戶做定制化展示、A/B test、黑白名單等功能應用。

2.1.1 分層分流

說回用戶分流服務來，大型系統會遇到一個問題，我們總是希望以小范圍的測試來驗證足夠多的的假設?？扇绻鄠€部門多實驗并行，實驗之間又相互互斥的話，流量會不足。這里我們產生一個“域”的概念，不同域之間互斥，同一個域的不同層正交，正如下圖所示（圖片引用，具體見文末參考文章，之后不再贅述）：

• 不同域之間共享100%流量，例如域1分流了30%，那域2就分流70%；
• 同一個域的不同層之間，會重復使用這個域中的流量，但不同層之間，每次進入流量會重新打散，保證互相不影響；
• 同一個層之間配置 A/B test 的實驗 A/B/N，共同分享這個域中的流量，不同實驗組之間相互互斥共享100%該域流量；

2.1.2 如何對用戶分流

用戶分流方式有三種，一般使用的是以用戶維度分流，這樣可以保證單一用戶每次進來看到的是相同實驗，不會造成體驗上的不一致：

1. 以用戶維度；
2. 以分類維度；
3. 完全隨機；

哈希因子：實驗的 Hash 因子有設備 ID、策略 ID、流量層 ID，根據具體需求，可以選擇其中的幾個因子組合后 Hash，。

HashID=Hash(設備 ID，策略 ID，流量層 ID)%100+1

這樣每個用戶會得到唯一的 HashID，同時會落在[1，100]的范圍內，讓用戶隨機均勻散落在這個范圍內。如果需要將流量控制的更精準，可以對1000甚至10000取余，這個根據實際情況靈活做選擇就好。

在配置實驗時，根據實際需求，為各個版本均勻切分流量。譬如A版本劃分10%的流量，則 HashID 從 0-10 的用戶被劃分到 A 版本，以此類推。

2.2 A/B test 設置

AB/TEST 設置用于配置實驗，做實驗的增刪查改，同時對線上的實驗做管理，及時上下線。

管理員在 AB/TEST 配置系統中，新建實驗，并設置分流規則。完成后實驗配置入庫，當用戶訪問產品時，根據分流規則調取 AB/TEST 實驗版本。

2.2.1 新建/編輯實驗

• step1：新建實驗
• step2：輸入實驗信息（實驗的基本信息、生效時間）等
• step3：選擇分流服務
• step4：選擇后端服務
• step4：選擇數據指標

2.2.2 管理實驗

管理實驗模塊主要用于上下架實驗。

2.3 數據統計

A/B test 最重要的一部分是統計和分析數據。在建立實驗時，同步選擇需要關注的數據指標。以實時或T+1的方式，展示數據報表。在新建實驗時，可以在現有的埋點指標中做選擇，選擇出用于分析實驗效果的關鍵漏斗指標，生成報表。在技術實現上，埋點的數據上報，需增加分流服務ID。

2.4 數據分析

在數據統計完成后，更重要的部分是我們如何根據數據報表來判斷各個版本的優劣。由于其他因素的擾動，譬如流量質量、級別等因素，同一個實驗的多個版本會有微小數據差別，在一定程度內的數據差別是正常波動，并不能說明某個版本更優。因此大部分的 A/B test 系統采用了 T 檢驗。

為什么要 T 檢驗或者其他檢驗呢，是因為 **樣本參數=總體參數+機會誤差+偏差**，現在我們手里有樣本，可以計算樣本參數，但是我們想知道的是總體參數，但是這個樣本參數能不能代表總體參數呢？T 檢驗在這里就是用來判斷是否是機會誤差這個因素造成，通俗點說就是樣本得到的參數值可不可能由于是抽取的時候的隨機造成的。

2.4.1 P 值（P value）

P 值檢驗用于驗證假設。在 A/B test 里，原先的版本可以稱它為H0（原假設），新的版本稱為H1（備擇假設），假設就是我們認為H1版本是優于H0的。若 P 值落在置信區間里，那我們的假設成立，若 P 值沒有落在置信區間，就認為 P 值推翻了我們的假設。

P 值越小，我們認為H1這個備擇假設越靠譜。P 值越大，H1越不靠譜。置信區間是我們自行定義的“靠譜區間”。

以上我們計算出了 T 值，通過查詢界值表，可以獲取到 P 值。

2.4.2 置信區間

剛才說置信區間是人工定義的，α值你可以定義為0.05、0.1，這個根據實際情況去做選擇，1-α就是置信區間，除此以外的就是拒絕域。

• 若 p ≤ α，那么拒絕原假設；
• 若 p > α，那么不能拒絕原假設。

推薦閱讀（即參考文獻）

1.【ABtest在OpenSearch上的設計與實現】

https://yq.aliyun.com/articles/672758?spm=a2c4e.11153940.0.0.74981c4aY0BCsg&type=2

https://help.aliyun.com/document_detail/89958.html

2.【推薦系統衡量：ABtest框架】

https://cloud.tencent.com/developer/article/1450557

3.【馬蜂窩ABTest多層分流系統的設計與實現】

https://my.oschina.net/u/4084220/blog/3053499?from=timeline&isappinstalled=0

4.【美圖 AB Test 實踐：Meepo系統】

https://my.oschina.net/leejun2005/blog/302500

5.【Netflix推薦系統模型的快速線上評估方法——Interleaving】

https://www.jianshu.com/p/40eb1b7d6932

6.【攜程機票的ABTest實踐】

https://zhuanlan.zhihu.com/p/25685006

7.【滬江ABTest測試平臺實踐】

https://www.itcodemonkey.com/article/5227.html

#專欄作家#

作者：張小四兒，微信公眾號：產品小怪獸

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議