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

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

• 功能：支持豐富的試驗(yàn)人群定向和指標(biāo)管理配置，同時(shí)進(jìn)行多個(gè)試驗(yàn)的可擴(kuò)展性、靈活性

• 性能：A/B 測(cè)試的性能越高，對(duì)實(shí)際業(yè)務(wù)造成的延遲越小，對(duì) C 端客戶的體驗(yàn)越好

• 穩(wěn)定：A/B 測(cè)試平臺(tái)要保證足夠高的 SLA，A/B 故障不應(yīng)該影響正常業(yè)務(wù)運(yùn)行

• 效率：降低試驗(yàn)的實(shí)施和分析成本，通過標(biāo)準(zhǔn)化的試驗(yàn)指標(biāo)計(jì)算快速發(fā)現(xiàn)、終止不符合預(yù)期的試驗(yàn)

• 易用：降低試驗(yàn)的實(shí)施門檻，幫助沒有 A/B 測(cè)試基礎(chǔ)的小白快速上手、避免踩坑

基于上述評(píng)價(jià)標(biāo)準(zhǔn)，接下來我們將重點(diǎn)探討神策 A/B 測(cè)試在提升功能、性能這兩個(gè)維度的技術(shù)實(shí)踐。

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

A/B 測(cè)試平臺(tái)功能維度的建設(shè)核心主要表現(xiàn)在兩方面：試驗(yàn)人群定向和指標(biāo)的支持依賴于底層的數(shù)據(jù)體系建設(shè)；同時(shí)進(jìn)行多個(gè)試驗(yàn)的可擴(kuò)展性和靈活性取決于試驗(yàn)?zāi)Ｐ秃头至魉惴ǖ脑O(shè)計(jì)方案。

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

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

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

采用上述架構(gòu)，能夠?yàn)樯癫?A/B 測(cè)試帶來強(qiáng)大的試驗(yàn)人群定向和指標(biāo)分析能力，所具備的獨(dú)特優(yōu)勢(shì)如下：

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

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

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

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

2.模型算法

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

（1）試驗(yàn)互斥

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

怎么保障試驗(yàn)流量的分配使用是隨機(jī)且公平的？比如某個(gè)試驗(yàn)消耗了全部男性用戶的流量，導(dǎo)致其他互斥的試驗(yàn)流量全是女性用戶。

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

（2）試驗(yàn)正交

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

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

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

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

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

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

二、性能：基于鏈路拆分與治理降低 A/B 測(cè)試耗時(shí)

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

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

針對(duì)試驗(yàn)分流服務(wù)，我們進(jìn)行了多方面的探索和嘗試。

• 增加試驗(yàn)結(jié)果分布式緩存和持久化存儲(chǔ)，降低存儲(chǔ)查詢/寫入次數(shù)，提升存儲(chǔ)讀寫效率

• 前置過濾試驗(yàn)人群定向條件，提升試驗(yàn)分流效率

• 整體服務(wù)和存儲(chǔ)支持快速水平橫向擴(kuò)容，保證服務(wù)響應(yīng)耗時(shí)保持在平穩(wěn)狀態(tài)

• 優(yōu)化試驗(yàn)?zāi)Ｐ秃统橄?#xff0c;簡化分流業(yè)務(wù)流程

• 拆分強(qiáng)弱依賴處理邏輯，部分弱依賴操作異步化

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

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

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

1.通用場景

在大多數(shù)場景中，C 端用戶的試驗(yàn)分流結(jié)果是可以被預(yù)先獲取并存儲(chǔ)的，針對(duì)這類通用場景，我們?cè)诙鄠€(gè)端的 SDK 集成了異步定時(shí)發(fā)起試驗(yàn)請(qǐng)求 + 本地緩存的方案，如下圖所示：

通過本地緩存，在對(duì) C 端客戶分流時(shí)我們就可以繞過一次實(shí)時(shí)的遠(yuǎn)程試驗(yàn)請(qǐng)求，直接在本地進(jìn)行試驗(yàn)分流。

2.特殊場景

在部分特殊場景中，試驗(yàn)分流結(jié)果只能在首次加載時(shí)獲取，無法預(yù)先被加載，例如投放落地頁場景中用戶從流量平臺(tái)跳轉(zhuǎn)到 B 端平臺(tái)/App，因?yàn)橛脩粜畔o法提前獲取到，導(dǎo)致在落地頁加載之前必須實(shí)時(shí)發(fā)起一次試驗(yàn)請(qǐng)求。針對(duì)這部分特殊場景，可以考慮通過前文提到的私有化部署方案來規(guī)避。

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

目前，神策數(shù)據(jù) A/B 測(cè)試持續(xù)輸出功能和易用性相關(guān)實(shí)踐，例如智能化的試驗(yàn)配置、分層、試驗(yàn)問題檢測(cè)和試驗(yàn)控制，幫助渴望踏入 A/B 測(cè)試大門的客戶直接上手，自動(dòng)規(guī)避試驗(yàn)陷阱，即便是不懂復(fù)雜理論的用戶，也能輕松完成 A/B 測(cè)試。

請(qǐng)期待更多關(guān)于 A/B 測(cè)試在穩(wěn)定和效率維度的技術(shù)實(shí)踐分享！

???

【更多內(nèi)容】

A/B 測(cè)試搞定超 60% 會(huì)員增長

A/B 測(cè)試業(yè)務(wù)場景實(shí)踐解讀

神策數(shù)據(jù) A/B 測(cè)試五大亮點(diǎn)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。