在 2018 年，我相信 ABTest 這個名詞已經不用過多地解釋了。但我發現很多公司，尤其是初創企業，雖然能理解這件事是什么，卻不知道這件事該怎么做，以及該怎么做好。

這一系列文章，就是想講清楚在設計具體的 A/B 測試平臺這種基礎架構時，要考慮哪些問題，以及有哪些推薦的做法。

今天先談一談，如何進行用戶分桶？

我們都知道互聯網產品的 ABTest 主要是圍繞用戶進行的實驗，從統計意義上觀察用戶對不同的產品設計、交互體驗、業務流程的反饋，從而指導產品的改進方向。

那么很重要的一點就是，怎么圈定哪些用戶進行 A 實驗，哪些用戶進行 B 實驗。

在我工作過的一家公司，他們是這樣做的：“使用用戶的 UserID 對 1000 取模分成 1000 個桶，然后選擇不同的桶分配給 A 或者 B。”

我問研發人員為什么這么做？他們給的理由是：“UserID 是自增 ID，跟用戶注冊順序有關，有一定的隨機性?？梢员ＷC用戶隨機地分到 A 或者 B 中。”

A/B 的流量圈定的一個重要原則就是無偏，不然無法進行對比評估。上面的做法看起來倒也有一定的道理。（還常見的一種做法是，用手機尾號最后一位來進行分桶，優惠多少就看你手機尾號是否運氣好了 ^_^ ）

單單考慮孤立實驗，這樣做也無可厚非。但如果考慮到長期交叉、連續的實驗，這樣做有很大的問題。

首先，這種設計只能進行單層實驗，也就是說一份流量只能通過一個實驗。

如果實驗人員選擇了在任意一個桶中同時進行 X, Y 兩個實驗的話，那兩個實驗的結果就會相互干涉，導致最終結果不可信。例如：在尾號為 001 的桶里進行了兩個促銷活動“降價10%”和“滿100減10塊”的實驗，最終 001 桶的用戶訂單數比其它桶高，那到底是哪個促銷更有效果呢？

其次，這種設計在長期會造成桶間用戶行為有偏。

也許剛開始因為其隨機性，桶間用戶行為差異很小。但第一個實驗過后，桶間就開始有了行為差異——這也是 ABTest 的目標。N 個實驗過后，桶間行為的差異可能就變得非常大了。

比如你總是在 001 桶的用戶上實驗幅度較大的促銷活動，那么 001 桶的用戶留存就會顯著高于其它桶。那實驗人員為了讓實驗效果更好看，可能會偷偷地繼續選擇 001 桶進行實驗。

第三，這種設計的實驗效率太低。因為一份流量只能通過一個實驗，無法對流量進行充分的利用。

那該如何設計用戶分桶，才能滿足 ABTest 的需求呢？

目前業界應用最多的，是可重疊分層分桶方法。

具體來說，就是將流量分成可重疊的多個層。因為很多類實驗從修改的系統參數到觀察的產品指標都是不相關的，完全可以將實驗分成互相獨立的多個層。例如 UI 層、推薦算法層、廣告算法層，或者開屏、首頁、購物車、結算頁等。

單單分層還不夠，在每個層中需要使用不同的隨機分桶算法，保證流量在不同層中是正交的。也就是說，一個用戶在每個層中應該分到哪個桶里，是獨立不相關的。具體來說，在上一層 001 桶的所有用戶，理論上應該均勻地隨機分布在下一層的 1000 個桶中。

通過可重疊的分層分桶方法，一份流量通過 N 個層可以同時中 N 個實驗，而且實驗之間相互不干擾，能顯著提升流量利用率。

從實操上來說，我們通常采取下面的方法：

首先，確定 Layer，確定請求 Tag。例如從 UserID，DeviceID、CookieID、手機號 中選一個，支持匿名流量的，一般會選用 DeviceID 或者 IMSI 等作為請求 Tag。

然后，選一個你喜歡的 Hash 函數，盡量選個使用方便、隨機性更強的；

最后，通過 Hash(Layer, Tag) % 1000 確定每層分桶。如果 Hash 函數支持 seed，那么使用 Layer 作為 seed，否則作為 SALT，即將 "Layer+Tag" 作為輸入參數。

在完成分桶以后，還可以進行一定的流量篩選。例如來自北京和上海的用戶，可以允許分別進行不同的實驗。

可重疊分層分桶方法的系統性介紹，可以參見 Google 在 KDD 2010 發表的論文 《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》，感興趣的同學可以延伸閱讀一下。

但分層方法并不能讓所有人滿意，尤其是對并行實驗非常多的大公司來說。因為同一層可能有不同份額的其它小流量實驗在線上，新實驗能夠拿到的流量非常有限，需要等待同層其它實驗結束，會非常影響迭代效率。而新實驗未必一定會修改其它實驗的參數，或者影響其它實驗的效果。

所以一些公司也逐漸開始探索無分層，也可以稱為無限分層的方法。具體的做法是，每個實驗都可以看成獨立的層，只保證層間流量分桶的正交性，所有的實驗都可能存在重疊情況。

這樣做用戶就有大概率同時中同一類實驗，例如兩個實驗人員同時在實驗 UI 布局，實際上用戶只能看到一種布局（因為代碼分支有先后邏輯），那么實驗結果就不可信了。

由于系統上無法保證實驗間不沖突，那么只能從組織上來避免沖突，或者從數據上盡早觀察到沖突的存在來解決沖突。這對組織的管理能力和企業的數據能力提出了更高的要求。

下篇，我們聊一下實驗的開關和分組信息傳遞。

首發于本人原創個人博客：

ABTest 平臺設計 - 如何進行流量分桶?yangwenbo.com

總結

以上是生活随笔為你收集整理的平台如何限制ip流量_ABTest 平台设计 - 如何进行流量分桶的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。