一、什么是A/B test

A/B-test，本質(zhì)就是對照實(shí)驗(yàn)。為同一個(gè)目標(biāo)和假設(shè)，設(shè)計(jì)A、B兩個(gè)方案。從一波用戶中，隨機(jī)分為A、B兩組，A組用A方案，B組用B方案。上線后，驗(yàn)收兩組實(shí)驗(yàn)的數(shù)據(jù)情況，從而判斷哪一組的效果更優(yōu)。

A/B-test在國內(nèi)互聯(lián)網(wǎng)中的應(yīng)用越來越普及，成為互聯(lián)網(wǎng)進(jìn)入精細(xì)化迭代和運(yùn)營的核心方法論。

二、沒有平臺化的A/B-test 如何進(jìn)行實(shí)踐？

個(gè)人所在創(chuàng)業(yè)公司，在業(yè)務(wù)早期，沒有平臺化的時(shí)候，就開始粗暴地進(jìn)行A/B-test。以一個(gè)簡單case為例，闡述一個(gè)實(shí)驗(yàn)過程。

Step1. 確定實(shí)驗(yàn)內(nèi)容

基于同一個(gè)目標(biāo)，策劃了①、②、③、④組實(shí)驗(yàn)內(nèi)容。

Step2.放量策略

4組實(shí)驗(yàn)，分為9個(gè)實(shí)驗(yàn)組和1個(gè)實(shí)驗(yàn)組，針對某日注冊的新用戶，進(jìn)行尾號0-9的分割，進(jìn)行分流，由服務(wù)器控制版本下發(fā)。

Step3.上線收集數(shù)據(jù)

建立一張用戶-實(shí)驗(yàn)組別的維度表，根據(jù)埋點(diǎn)日志 join 維度表，手動(dòng)跑sql查詢關(guān)于用戶行為、次日留存、7日留存的數(shù)據(jù)。

Step4.根據(jù)結(jié)果判斷next step

根據(jù)實(shí)驗(yàn)結(jié)果，判斷相關(guān)的實(shí)驗(yàn)線下 或者 開放全量。比較難的問題是，如果測試的產(chǎn)品功能差異較大，如何進(jìn)行版本兼容是個(gè)比較大的問題。

此外，客戶端版本直接的管理，是根據(jù)各個(gè)獨(dú)立版本進(jìn)行服務(wù)器控制。沒有進(jìn)行用戶版本記錄和版本回滾，后續(xù)版本變多，可能會存在管理混亂的風(fēng)險(xiǎn)。

三、暴露的問題和平臺產(chǎn)品解法

2.1 放量策略

現(xiàn)在使用的策略是這樣的

對當(dāng)日新增注冊的用戶，進(jìn)行尾號0-9的分割，直接分配給10個(gè)實(shí)驗(yàn)組

當(dāng)問到為什么這樣的時(shí)候

UserID 是自增 ID，跟用戶注冊順序有關(guān)，可以保證測試的隨機(jī)性。

A/B-test的放量策略，一個(gè)重要原則就是隨機(jī)無偏，不然會存在誤差。

這樣的實(shí)驗(yàn)做法，確實(shí)可以滿足單個(gè)實(shí)驗(yàn)中的隨機(jī)性。但如果考慮到長期繁雜的、交叉的、連續(xù)的實(shí)驗(yàn)，會出現(xiàn)問題：

第一，這種策略只能進(jìn)行單層實(shí)驗(yàn)，對實(shí)驗(yàn)的流量分配的靈活變動(dòng)非常不友好。

中途想要對某些實(shí)驗(yàn)擴(kuò)容，對某些實(shí)驗(yàn)縮容都不可實(shí)現(xiàn)

其次，這種策略在長期會造成實(shí)驗(yàn)組間用戶行為有偏。

剛開始因?yàn)槠潆S機(jī)性，實(shí)驗(yàn)組間的用戶行為差異很小。但第一次實(shí)驗(yàn)過后，某個(gè)尾號（某個(gè)實(shí)驗(yàn)組）就會產(chǎn)生行為差異，這種差異如果直接和某個(gè)尾號關(guān)聯(lián)，可能直接會對后續(xù)的實(shí)驗(yàn)產(chǎn)生影響

那該如何設(shè)計(jì)用戶分桶，才能滿足A/B-test 的需求呢？

目前業(yè)內(nèi)，對于A/B-test的流量策略，基本是基于google的論文Overlapping Experiment Infrastructure: More, Better, Faster Experimentation

總結(jié)來說，就是存在一個(gè)域和層的概念。不同域之間互斥，同一個(gè)域的不同層正交

具體來說，根據(jù)實(shí)驗(yàn)類型，從修改的系統(tǒng)參數(shù)到觀察的產(chǎn)品指標(biāo)上的相關(guān)性，將流量分成可重疊的多個(gè)Layer。例如 UI 層、推薦算法層、廣告算法層。各個(gè)層之間的實(shí)驗(yàn)結(jié)果和觀測指標(biāo)獨(dú)立，不存在相互影響的可能。

流量分層后，針對每個(gè)層中的流量，選用不同的隨機(jī)算法，保證流量在不同層是重新打亂隨機(jī)分發(fā)的。

用戶分流，一般以用戶維度分流，這樣可以保證單一用戶每次進(jìn)來看到的是相同實(shí)驗(yàn)，不會造成體驗(yàn)上的不一致：

實(shí)驗(yàn)的 Hash 因子有用戶唯一標(biāo)示（通常是cookie，UID，手機(jī)號等）、策略ID、Layer ID，根據(jù)具體需求，可以選擇多個(gè)因子組合后 Hash。

HashID=Hash(用戶標(biāo)示，策略 ID，Layer ID)%100+1

每個(gè)用戶會分配唯一的 HashID，同時(shí)會落在[1，100]的范圍內(nèi)，讓用戶隨機(jī)均勻散落在這個(gè)范圍內(nèi)。配置實(shí)驗(yàn)時(shí)，根據(jù)實(shí)際需求，為各個(gè)版本均勻切分流量。譬如A版本劃分20%的流量，則 HashID 從 1-20 的用戶被劃分到 A 版本。

2.2 數(shù)據(jù)收集

現(xiàn)在在數(shù)據(jù)收集上，使用的方法是

用戶和實(shí)驗(yàn)分組建立一張維度表，針對核心指標(biāo)，基于系統(tǒng)日志跟用戶-實(shí)驗(yàn)分組的維度表去 join

這種方式存在著明顯的缺點(diǎn)：，一方面需要手動(dòng)寫sql取數(shù)，join的復(fù)雜程度比較高，對于業(yè)務(wù)方（通常是產(chǎn)品或運(yùn)營）的要求太高。

另一方面，擴(kuò)展性比較差，目前只針對新注冊用戶做實(shí)驗(yàn)，一個(gè)用戶在生命周期內(nèi)，只有一個(gè)實(shí)驗(yàn)分組。當(dāng)后續(xù)實(shí)驗(yàn)拓展，用戶和實(shí)驗(yàn)分組間按精確到秒的時(shí)間來分配，join的復(fù)雜程度更高。

再有一方面，用戶中實(shí)驗(yàn)分組在產(chǎn)品上的生效往往不是實(shí)時(shí)的。尤其是在客戶端上，用戶正在用一個(gè)功能的時(shí)候，很難瞬間將該功能切換成另一種樣式，往往是在用戶在下一次重入初始化的時(shí)候才開啟實(shí)驗(yàn)樣式，否則很容易引起崩潰。

針對該問題，更友好的解法，是在日志上報(bào)時(shí)，都帶上分組信息參數(shù)。這樣雖然增加了一些冗余信息，但會使所有的關(guān)鍵數(shù)據(jù)記錄都帶上分組信息，作為篩選的參數(shù)更加便捷。

2.3 數(shù)據(jù)分析

在某個(gè)案例的實(shí)踐中，業(yè)務(wù)方獲得數(shù)據(jù)如下

一般的測試owner拿到數(shù)據(jù)后，直接算出各個(gè)實(shí)驗(yàn)組之間的轉(zhuǎn)化率差距，然后就做決策。

但這樣的做法，忽略了A/B-test的本質(zhì)，是一個(gè)抽樣實(shí)驗(yàn)，在統(tǒng)計(jì)學(xué)角度上，樣本代表全體始終存在著統(tǒng)計(jì)顯著性的問題。在一定程度內(nèi)的數(shù)據(jù)差別是正常波動(dòng)，并不能說明某個(gè)版本更優(yōu)。通常A/B-test會進(jìn)行顯著性檢驗(yàn)，計(jì)算P-value。

關(guān)于顯著性檢驗(yàn)的原理和方法，在之前的文章中介紹過了。

可以查看“一文解析：A/B-test里「顯著性檢驗(yàn)」的原理方法和實(shí)操案例”

2.4 版本回滾

客戶端版本直接的管理，是根據(jù)各個(gè)獨(dú)立版本進(jìn)行服務(wù)器控制。沒有進(jìn)行用戶版本記錄和版本回滾，一般的參數(shù)配置回滾都是單值的回滾，但是存在多個(gè)表的情況下沒有辦法這么簡單地去回滾，后續(xù)版本變多，可能會存在管理混亂的風(fēng)險(xiǎn)。

針對此問題，以美團(tuán)為例，設(shè)計(jì)一套回滾模型如下：

首先在配置發(fā)布時(shí)，會將所有修改的表名、列名、列類型、列新舊值、修改類型存入表中。

回滾時(shí)獲取上次發(fā)布的所有修改的表名、列名、列類型、列新舊值、修改類型，反向操作數(shù)據(jù)庫，達(dá)到回滾的目的。

回滾模型

四、總結(jié)

從A/B-test的功能模塊來看，大概有以下三個(gè)：用戶分流服務(wù)、A/B test 配置、數(shù)據(jù)統(tǒng)計(jì)、（版本回滾非必要）。實(shí)現(xiàn)流程圖如下：

針對此，平臺產(chǎn)品重點(diǎn)需要策劃的核心在于：

實(shí)驗(yàn)創(chuàng)建和人群分組管理

流量分配管理

實(shí)驗(yàn)綁定指標(biāo)和指標(biāo)上報(bào)邏輯

統(tǒng)計(jì)指標(biāo)和顯著性指標(biāo)

---

參考資料：

Overlapping Experiment Infrastructure: More, Better, Faster Experimentation

ABTest 平臺設(shè)計(jì) - 如何進(jìn)行流量分桶

ABTest 平臺設(shè)計(jì) - 實(shí)驗(yàn)開關(guān)和分組信息傳遞

ABTest 平臺設(shè)計(jì) - 灰度發(fā)布和早鳥用戶

ABTest 平臺設(shè)計(jì) - 流量分布問題

滬江ABTest測試平臺實(shí)踐

總結(jié)

以上是生活随笔為你收集整理的a*算法流程图_如何从0开始，搭建A/B test平台产品？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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