微店AB實驗平臺架構演進

前言

隨着微店業務的蓬勃發展，各類業務系統紛紛上線，各種推薦、搜索調優算法應運而生。微店AB測試平臺Flood誕生於核心推薦和搜索系統，最初想解決的問題也很簡單，好比：哪一種搜索精排算法比較好、哪一種推薦策略帶來的業務轉化率更高。

在完成了最初的功能需求以後，咱們陷入了思考，在這個數聽說話的時代，咱們不少部門不少決策都是經過拍腦殼決定的，好比產品經理大手一揮，就隨意決定了購物車按鈕的顏色，究竟是黑色比紅色帶來的點擊率高仍是偏偏相反，亦又如咱們某業務同窗想改版某個展現算法，作法很粗暴，兩個版本各跑半個月，觀察是否能夠進行變動。在深刻了解了整個公司的AB情況以後，發現存在一些共性的情況：

一、每一個產品線獨立一套，或者壓根就沒有AB
二、獨立設計開發、維護
三、支持少許規則
四、實驗缺少嚴謹性
五、大多使用配置上線

上述情況，反應出當時微店AB存在的問題：資源浪費、人力佔用、缺少靈活性、結果置信度低、週期長等等。
針對上述廣泛存在的問題，咱們推薦團隊提出設計一套通用的AB測試平臺：Flood。Flood原意是洪流，咱們就是要控制滾滾而來的訪問洪流，讓其按照咱們設定的「軌道」去運行。

平臺架構演進

Flood總體架構大體分爲三個階段演進，第一個階段是作做爲搜索系統的內嵌模塊提供服務的，支持的功能也比較有限，總體架構以下圖（注：爲了突出說明初始版本的AB，全面簡化了搜索架構）：

第二個階段獨立出來一個通用的AB測試平臺，這個階段主要支持後端AB實驗，總體架構圖以下：

第三個階段着重支持規則引擎，規則引擎支持豐富的人羣定向選擇，好比：支持當前網絡環境是4G的浙江用戶看到某個功能，同時支持前端AB測試，總體架構圖以下：

流量切割模型

當時設計流量模型主要考慮了以下幾點：

一、同一個業務系包含多個實驗並向的進行，好比前端頁面須要改版，後端推薦策略須要同時在線AB測試等。
 二、流量能夠按照一些規則進行切割，業務組內能夠共享流量。

基於這兩個強需求，咱們參考了google的流量切割模型，見參考[1]。流量分域分層模型，在每一個流量域以內，流量是互不干擾的，在每一個流量域以內能夠分層，知足不一樣層次的AB實驗。
流量切割模型以下所示：

踩過的一些坑

一、流量切割的準確性和穩定性

在具體的實踐中，發現用來路由的用戶ID並非均勻分佈，直接分流會形成流量不許確。因此不能依賴分流id自身的分散度，最好將id進行打散操做，可是這樣會帶來後續統計的問題，須要提早設計好。不少場景下，對於相同的用戶id，在不切換流量的狀況下返回的結果應當一致，既可重入，不然會給用戶形成極大的疑惑。好比推薦算法每次一刷新返回的都是徹底不一樣的商品推薦。

二、實驗碰撞
在進行分層實驗時，常常會碰到以下問題：

實驗名	分桶1	分桶2
前端按鈕顏色AB	A1	A2
後端推薦策略AB	B1	B2

這時候剛好都採用的userId做爲分流依據，而且分桶流量各50%（簡化問題設置），而且分流邏輯一致，這時候即便經過數據發現A1>A2，B1>B2，其實實驗結果並不科學，只能說明A1->B1 > A2->B2。爲了解決這個問題，最好採用：f(userId, salt)再進行分流，這裏Flood平臺salt採用的就是appId。

三、流量擴張
假設有三個桶，初始流量爲：80%，20%，0%。簡化流量切割模型：id%100，這時候假設第三個桶須要擴張10%的流量，切換先後流量區間發生很大變化，以下表：

實驗名	桶1	桶2	桶3
切換前	0-79	80-99	無
切換後	0-69	70-89	90-99

切換以後實際上桶1，桶2和桶3覆蓋的用戶人羣都發生了變化，這裏最好的實踐是：桶2原有流量不變，桶3從基準桶1中切換10%流量過去。

展望

目前Flood雖然能夠知足幾乎全部的業務需求，可是還存在不少能夠改進的地方，後續咱們主要在實驗方法和數據統計上進行進一步的探索：

• 進行多變量實驗

• AA test

• 數據統計的科學性

參考[1] Overlapping Experiment Infrastructure: More, Better, Faster Experimentation