溫先輝：從技術(shù)視角看什么才是值得擁有的 A/B 測試

A/B 測試被更多人熟知的是持續(xù)觀察并對照按一定規(guī)則分成的 A、B 兩組測試樣本，基于數(shù)據(jù)反饋輔助優(yōu)化決策，其背后復雜的數(shù)學理論和試驗基礎(chǔ)設(shè)施卻往往被人忽視。

目前，國內(nèi)一線互聯(lián)網(wǎng)公司大多采用自研的方式建設(shè) A/B 測試平臺，而中小互聯(lián)網(wǎng)企業(yè)和傳統(tǒng)行業(yè)的企業(yè)則會選擇自采的方式建設(shè) A/B 測試平臺。在面對標準不一的多種 A/B 測試平臺時，企業(yè)該如何選擇？參照 Google 重疊試驗框架——更多、更好、更快地試驗，并結(jié)合神策 A/B 測試服務數(shù)十家客戶的實踐，我們從不同維度總結(jié)出評價 A/B 測試平臺的標準：

• 功能：支持豐富的試驗人群定向和指標管理配置，同時進行多個試驗的可擴展性、靈活性
• 性能：A/B 測試的性能越高，對實際業(yè)務造成的延遲越小，對 C 端客戶的體驗越好
• 穩(wěn)定：A/B 測試平臺要保證足夠高的 SLA，A/B 故障不應該影響正常業(yè)務運行
• 效率：降低試驗的實施和分析成本，通過標準化的試驗指標計算快速發(fā)現(xiàn)、終止不符合預期的試驗
• 易用：降低試驗的實施門檻，幫助沒有 A/B 測試基礎(chǔ)的小白快速上手、避免踩坑

基于上述評價標準，接下來我們將重點探討神策 A/B 測試在提升功能、性能這兩個維度的技術(shù)實踐。

一、功能：基于數(shù)據(jù)體系與模型算法的成功演繹

A/B 測試平臺功能維度的建設(shè)核心主要表現(xiàn)在兩方面：試驗人群定向和指標的支持依賴于底層的數(shù)據(jù)體系建設(shè)；同時進行多個試驗的可擴展性和靈活性取決于試驗模型和分流算法的設(shè)計方案。

1.數(shù)據(jù)體系

神策數(shù)據(jù)的 Event-User-Item（用戶-事件-實體）數(shù)據(jù)模型能夠?qū)τ脩粜袨閿?shù)據(jù)標準化抽象，從而支持豐富的用戶行為指標建設(shè)，為企業(yè)提供強大、便捷的分析能力。

A/B 測試構(gòu)建于神策數(shù)據(jù)體系之上，基于神策數(shù)據(jù)根基平臺和神策用戶畫像體系，神策系統(tǒng)支持的全部畫像標簽和分析指標可以更便捷地應用到 A/B 測試中；與此同時，A/B 測試產(chǎn)生的結(jié)果又會遵循神策標準數(shù)據(jù)模型回流到神策數(shù)據(jù)平臺中，如下圖所示：

采用上述架構(gòu)，能夠為神策 A/B 測試帶來強大的試驗人群定向和指標分析能力，所具備的獨特優(yōu)勢如下：

（1）支持公有 SaaS 化部署和私有 PaaS 化部署兩種方案，滿足多種場景的差異化需求，而用戶核心數(shù)據(jù)則私有存儲在客戶環(huán)境中，保障數(shù)據(jù)安全；

（2）既可以作為獨立產(chǎn)品支持客戶 A/B 測試的需求，也可以結(jié)合神策分析等明星產(chǎn)品為客戶實現(xiàn)數(shù)據(jù)分析感知、目標決策、線上測試驗證、試驗數(shù)據(jù)反饋打通的 SDAF 閉環(huán)；

（3）結(jié)合神策分析，A/B 測試的數(shù)據(jù)回流到平臺后，既能夠豐富用戶行為分析指標種類，又能夠提供用戶人群圈定功能，進一步增強試驗分析能力，不斷形成正向反饋。

這里值得提一下，已經(jīng)購買神策產(chǎn)品的客戶，可以將現(xiàn)有產(chǎn)品與神策 A/B 測試無縫對接，再也不用為多產(chǎn)品打通而苦惱。

2.模型算法

要具備同時進行多個試驗的可擴展性和靈活性，本質(zhì)是要解決在有限的流量（比如僅能滿足 2 個試驗的樣本量）前提下同時進行多個試驗無法保證隔離的矛盾。具體來說就是：流量在試驗之間互斥可以保證隔離性，但多個試驗同時運行所需要的流量規(guī)模最好同時滿足；讓流量同時經(jīng)過多個試驗，即正交，需要解決試驗效果出現(xiàn)互相干擾的問題。而試驗互斥和正交的背后則隱藏了一系列復雜的技術(shù)和業(yè)務問題。

（1）試驗互斥

怎么保障試驗有公平獲取到流量的機會？比如存量試驗消耗了全部流量導致新上線的試驗無法分配到流量而出現(xiàn)“流量饑餓”。

怎么保障試驗流量的分配使用是隨機且公平的？比如某個試驗消耗了全部男性用戶的流量，導致其他互斥的試驗流量全是女性用戶。

對于一個新增流量規(guī)模為 X（X<100%）的試驗，如何保證該試驗得到精確定義的流量規(guī)模？

（2）試驗正交

同時經(jīng)過兩個試驗之間的流量如何保證均勻打散，實現(xiàn)流量正交，從而保證試驗之間的影響是一致的，對試驗效果評估不會出現(xiàn)相互干擾。

天然存在相互干擾的試驗如何解決？比如同一個按鈕，試驗 1 設(shè)置背景為紅色，試驗 2 設(shè)置文字為紅色，同時命中這兩個試驗的用戶將會看到一個沒有文字全是紅色的按鈕。

除此之外，我們還需要保證每個試驗配置的靈活性，比如差異化的人群定向和試驗流量規(guī)模等。

解決上述問題的根本方法是構(gòu)建一套邏輯嚴謹且擴展靈活的試驗模型，加上能夠?qū)崿F(xiàn)嚴格正交的算法。以前人為鑒，筑后世基石，參照 Google 重疊試驗框架，結(jié)合業(yè)界優(yōu)秀的 A/B 測試平臺建設(shè)經(jīng)驗，我們推演出如下試驗模型：

在試驗域、試驗層和試驗的模型上，我們支持精確的流量定義、嚴格的流量分配歸屬和差異化的人群定向功能；既支持獨占域的試驗場景規(guī)劃，又支持對效果顯著的試驗進行全量發(fā)布；同時我們還保留了對如下復雜重疊試驗模型的擴展支持，也將會面向部分存在循環(huán)嵌套重疊試驗需求的客戶開放該功能。

基于上述試驗模型設(shè)計，我們可以充分保證同時進行多個試驗的可擴展性和靈活性，但仍有可能面臨一個很關(guān)鍵的問題——在多個試驗層重疊的場景下，如何保證試驗之間的流量是均勻打散，嚴格正交的？這里我們對 hash 因子和 hash 算法進行了大量的調(diào)研和驗證，最終得到了嚴格正交的流量分配結(jié)果，如下：

二、性能：基于鏈路拆分與治理降低 A/B 測試耗時

大多數(shù)客戶在使用 A/B 測試平臺之前都存在疑慮：A/B 測試的性能如何，會不會對 C 端客戶的響應增加延遲？解答這個問題的關(guān)鍵是要先搞清楚一次 A/B 測試的過程：

如上圖所示，1 次 A/B 測試請求的耗時主要包含 2 次公網(wǎng)傳輸耗時和 1 次分流服務處理耗時，而公網(wǎng)傳輸耗時是 App 使用過程中不可避免會存在的。所以降低 A/B 測試延遲的根本在于降低分流服務的處理耗時和規(guī)避試驗請求的公網(wǎng)傳輸耗時。

針對試驗分流服務，我們進行了多方面的探索和嘗試。

• 增加試驗結(jié)果分布式緩存和持久化存儲，降低存儲查詢/寫入次數(shù)，提升存儲讀寫效率
• 前置過濾試驗人群定向條件，提升試驗分流效率
• 整體服務和存儲支持快速水平橫向擴容，保證服務響應耗時保持在平穩(wěn)狀態(tài)
• 優(yōu)化試驗模型和抽象，簡化分流業(yè)務流程
• 拆分強弱依賴處理邏輯，部分弱依賴操作異步化

基于上述實踐，最終實現(xiàn)了整體分流服務單次平均處理耗時在 11-12ms。

接下來，通過對服務的重構(gòu)拆分，神策 A/B 測試試驗分流的單次平均處理耗時會降低到 8ms 以內(nèi)，TP90<10ms。

那么，對于占比超過 80% 的公網(wǎng)請求耗時該如何規(guī)避呢？我們可以簡單拆分為通過緩存 + 異步請求的通用場景和必須首次請求的特殊場景。

1.通用場景

在大多數(shù)場景中，C 端用戶的試驗分流結(jié)果是可以被預先獲取并存儲的，針對這類通用場景，我們在多個端的 SDK 集成了異步定時發(fā)起試驗請求 + 本地緩存的方案，如下圖所示：

通過本地緩存，在對 C 端客戶分流時我們就可以繞過一次實時的遠程試驗請求，直接在本地進行試驗分流。

2.特殊場景

在部分特殊場景中，試驗分流結(jié)果只能在首次加載時獲取，無法預先被加載，例如投放落地頁場景中用戶從流量平臺跳轉(zhuǎn)到 B 端平臺/App，因為用戶信息無法提前獲取到，導致在落地頁加載之前必須實時發(fā)起一次試驗請求。針對這部分特殊場景，可以考慮通過前文提到的私有化部署方案來規(guī)避。

通過私有化部署方案，將公網(wǎng)的試驗分流請求轉(zhuǎn)化為內(nèi)網(wǎng)請求（平均網(wǎng)絡延時低于 20ms），就規(guī)避了試驗請求過程中不穩(wěn)定的公網(wǎng)傳輸耗時。

作者：溫先輝 神策數(shù)據(jù)咨詢服務專家