從技術視角看，如何更多、更好、更快地實施 AB 試驗

A/B 測試被更多人熟知的是持續觀察並對照按一定規則分成的 A、B 兩組測試樣本，基於資料反饋輔助最佳化決策，其背後複雜的數學理論和試驗基礎設施卻往往被人忽視。

目前，國內一線網際網路公司大多采用自研的方式建設 A/B 測試平臺，而中小網際網路企業和傳統行業的企業則會選擇自採的方式建設 A/B 測試平臺。在面對標準不一的多種 A/B 測試平臺時，企業該如何選擇？參照 Google 重疊試驗框架——

更多、更好、更快地試驗

，並結合

神策 A/B 測試服務數十家客戶的實踐

，我們從不同維度總結出評價 A/B 測試平臺的標準：

功能：支援豐富的試驗人群定向和指標管理配置，同時進行多個試驗的可擴充套件性、靈活性

效能：A/B 測試的效能越高，對實際業務造成的延遲越小，對 C 端客戶的體驗越好

穩定：A/B 測試平臺要保證足夠高的 SLA，A/B 故障不應該影響正常業務執行

效率：降低試驗的實施和分析成本，透過標準化的試驗指標計算快速發現、終止不符合預期的試驗

易用：降低試驗的實施門檻，幫助沒有 A/B 測試基礎的小白快速上手、避免踩坑

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

一、功能：基於資料體系與模型演算法的成功演繹

A/B 測試平臺功能維度的建設核心主要表現在兩方面：試驗人群定向和指標的支援依賴於

底層的資料體系建設

；同時進行多個試驗的可擴充套件性和靈活性取決於

試驗模型和分流演算法的設計方案

。

1.資料體系

神策資料的

Event-User-Item（使用者-事件-實體）資料模型

能夠對使用者行為資料標準化抽象，從而支援豐富的使用者行為指標建設，為企業提供強大、便捷的分析能力。

A/B 測試構建於神策資料體系之上，基於神策資料根基平臺和神策使用者畫像體系，神策系統支援的全部畫像標籤和分析指標可以更便捷地應用到 A/B 測試中；與此同時，A/B 測試產生的結果又會遵循神策標準資料模型迴流到神策資料平臺中，如下圖所示：

採用上述架構，能夠為神策 A/B 測試帶來強大的

試驗人群定向和指標分析

能力，所具備的獨特優勢如下：

（1）支援公有 SaaS 化部署和私有 PaaS 化部署兩種方案，

滿足多種場景的差異化需求

，而使用者核心資料則私有儲存在客戶環境中，

保障資料安全

；

（2）既可以作為獨立產品支援客戶 A/B 測試的需求，也可以結合神策分析等明星產品為客戶實現

資料分析感知、目標決策、線上測試驗證、試驗資料反饋

打通的 SDAF 閉環；

（3）結合神策分析，A/B 測試的資料迴流到平臺後，既能夠

豐富使用者行為分析指標種類

，又能夠提供使用者人群圈定功能，進一步增強試驗分析能力，不斷形成正向反饋。

這裡值得提一下，已經購買神策產品的客戶，可以將現有產品與神策 A/B 測試無縫對接，再也不用為多產品打通而苦惱。

2.模型演算法

要具備同時進行多個試驗的可擴充套件性和靈活性，本質是要

解決

在有限的流量

（比如僅能滿足 2 個試驗的樣本量）

前提下同時進行多個試驗無法保證隔離的矛盾

。具體來說就是：流量在試驗之間互斥可以保證隔離性，但多個試驗同時執行所需要的流量規模最好同時滿足；讓流量同時經過多個試驗，即正交，需要解決試驗效果出現互相干擾的問題。而試驗互斥和正交的背後則隱藏了一系列複雜的技術和業務問題。

（1）試驗互斥

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

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

對於一個新增流量規模為 X（X<100%）的試驗，如何

保證該試驗得到精確定義的流量規模

？

（2）試驗正交

同時經過兩個試驗之間的流量如何保證均勻打散，實現流量正交，從而保證

試驗之間的影響是一致的

，對試驗效果評估不會出現相互干擾

。

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

除此之外，我們還需要保證每個試驗配置的靈活性，比如

差異化的人群定向和試驗流量規模

等。

解決上述問題的根本方法是

構建一套邏輯嚴謹且擴充套件靈活的試驗模型，加上能夠實現嚴格正交的演算法

。以前人為鑑，筑後世基石，參照 Google 重疊試驗框架，結合業界優秀的 A/B 測試平臺建設經驗，我們推演出如下試驗模型：

在試驗域、試驗層和試驗的模型上，我們支援精確的流量定義、嚴格的流量分配歸屬和差異化的人群定向功能；既支援獨佔域的試驗場景規劃，又支援對效果顯著的試驗進行全量釋出；同時我們還保留了對如下複雜重疊試驗模型的擴充套件支援，也將會面向部分存在迴圈巢狀重疊試驗需求的客戶開放該功能。

基於上述試驗模型設計，我們可以

充分保證同時進行多個試驗的可擴充套件性和靈活性

，但仍有可能面臨一個很關鍵的問題——在多個試驗層重疊的場景下，如何保證試驗之間的流量是均勻打散，嚴格正交的？這裡我們對 hash 因子和 hash 演算法進行了大量的調研和驗證，最終得到了

嚴格正交的流量分配結

果，如下：

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

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

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

降低分流服務的處理耗時

和

規避試驗請求的公網傳輸耗時

。

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

增加試驗結果分散式快取和持久化儲存，降低儲存查詢/寫入次數，提升儲存讀寫效率

前置過濾試驗人群定向條件，提升試驗分流效率

整體服務和儲存支援快速水平橫向擴容，保證服務響應耗時保持在平穩狀態

最佳化試驗模型和抽象，簡化分流業務流程

拆分強弱依賴處理邏輯，部分弱依賴操作非同步化

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

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

那麼，對於佔比超過 80% 的公網請求耗時該如何規避呢？我們可以簡單拆分為透過

快取 + 非同步請求

的通用場景

和

必須首次請求的特殊場景

。

1.通用場景

在大多數場景中，C 端使用者的試驗分流結果是可以被預先獲取並存儲的，針對這類通用場景，我們在多個端的 SDK 集成了非同步定時發起試驗請求 + 本地快取的方案，如下圖所示：

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

2.特殊場景

在部分特殊場景中，試驗分流結果只能在首次載入時獲取，無法預先被載入，例如投放落地頁場景中使用者從流量平臺跳轉到 B 端平臺/App，因為使用者資訊無法提前獲取到，導致在落地頁載入之前必須實時發起一次試驗請求。針對這部分特殊場景，可以考慮透過前文提到的私有化部署方案來規避。

透過私有化部署方案，將公網的試驗分流請求轉化為內網請求（平均網路延時低於 20ms），就規避了試驗請求過程中不穩定的公網傳輸耗時。

目前，神策資料 A/B 測試已經收穫不少客戶的好評反饋，接下來，我們也將持續輸出功能和易用性相關實踐，例如智慧化的試驗配置、分層、試驗問題檢測和試驗控制，幫助渴望踏入 A/B 測試大門的客戶直接上手，自動規避試驗陷阱，即便是不懂複雜理論的使用者，也能輕鬆完成 A/B 測試。

請期待更多關於 A/B 測試在

穩定和效率維度的技術實踐分享

！