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 測試在穩定和效率維度的技術實踐分享！

???

【更多內容】

A/B 測試搞定超 60% 會員增長

A/B 測試業務場景實踐解讀

神策數據 A/B 測試五大亮點

總結

以上是生活随笔為你收集整理的神策数据：从技术视角看，如何更多、更好、更快地实施A/B试验的全部內容，希望文章能夠幫你解決所遇到的問題。

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