一AB平臺簡介

AB實驗平臺這幾年在互聯網公司得到了越來越廣泛的應用，采用AB實驗來評估產品和技術迭代效果也成為主流的業務新功能效果評估方式，數據驅動的文化在這幾年得到了不少公司的廣泛的認同，通過數據和指標來說明產品效果也得到了越來越多的公司的認可和應用。

AB實驗在其中就是一種很常見的產品效果數據評估工具，在各大公司的產品迭代過程中也得到了越來越廣泛的應用。

二1.0 時代 從無到有

在AB實驗剛開始的時候，需要解決的問題很簡單：

通過某種用戶流量分組方式，將不同的用戶劃分到不同的流量組，在不同的流量組通過控制變量的方式應用不同的產品策略，隨后觀察兩個組的產品效果差別。

這種非常樸素的實驗思路就是最基本的AB實驗的分流，需要注意的是在過程中需要保證控制變量和穩定的流量比例。

一個基本AB實驗實例

一個基本的AB實驗需要有以下要素：

實驗目標和實驗假設

實驗目標決定到達到什么樣的效果實驗才算成功，舉個例子，我希望付款率提升5%，這就是目標，其中的實驗指標是付款率，做實驗之前一定要有實驗目標，沒有實驗目標沒辦法確定實驗是否成功，實驗目標包含指標和變化幅度兩個要素。

實驗假設是猜想通過控制哪些因素來達到實驗目標，比如我們假設付款按鈕的顏色會影響用戶的付款意愿進而影響付款率，那這里的實驗假設就是付款按鈕顏色會影響用戶付款意愿。

實驗對象（實驗對象是可以用來應用策略的用戶或者請求或者其他對象）

實驗對象并不是僅僅指用戶，用戶的每一次請求也可以單獨做實驗，甚至每一次用戶請求的每一個曝光位置都可以看做一個實驗流量，這個對象取決于具體的業務。

對照組和實驗組（AB實驗的核心要求是控制變量做效果對照，所以至少有一個或多個對照組策略和實驗組策略）

對照組：一般是沒有任何策略的組，代表了現在的實驗效果。

實驗組：一般是應用了新策略的組，代表了新策略的實驗效果。

統計功效：在進行實驗組和對照組的流量分配的時候要注意，因為我們的AB實驗是從整體用戶中取一部分進行實驗，然后采用統計學方式進行效果評估，所以無論是實驗組還是對照組樣本量要滿足最基本的統計功效，后續的實驗才有意義，而統計功效無法在實驗之后計算，需要我們在實驗進行之前就做充足的調研。

算法的AB1.0主要功能

通過控制變量的方式進行AB分流實驗，并通過離線的模擬分流規則提供用戶實驗分組信息，使得數據分析可以計算實驗的指標報表。

打通基本的工程實驗鏈路，可以讓算法通過實驗配置自主的控制實驗流量和實驗策略。

1.0AB實驗的策略生效流程

在早期的實驗過程有以下鏈路：

通過配置中心配置約定好的AB實驗配置信息，線上的服務通過配置中心的變更信息，實時變更實驗配置，從下次分流開始應用新的分流策略，同時記錄實驗日志。

報表計算方式，將實驗配置信息同步到ODPS，第二天用前一天的實驗配置對昨天的用戶進行重新分流計算，獲得昨天的用戶實驗分流信息（之所以這樣是因為實驗變更是以天為單位，離線計算可以比較方面的支撐后續的實驗分析）。

算法和普通業務的AB分流由于業務特性原因有較多的需求不同的地方，針對兩者區別我們也進行了一些特殊的算法實驗優化設計。具體如下：

早期的AB實驗設計解決了基本的實驗分流問題也提供了一套配套的實驗指標和實驗置信度計算方案，支撐了早期的簡單業務可以通過AB實驗的方式比較科學的觀測算法模型效果。

三2.0 時代 從有到全，支持復雜業務功能

新的業務需求

隨著公司業務發展和各個系統迭代優化，用戶對于基礎的AB實驗系統開始衍生出了一些新的，更細化更復雜的業務需求，用戶也希望AB系統可以幫助支撐更高效的實驗迭代。

流量饑渴，更豐富的流量需求：在1.0版本的AB實驗中已經解決了基本的實驗分流和配置的問題，但是由于一個場景中總用戶流量有限，可能會有多種業務實驗同時進行，實際實驗運行時需要在同時運行的實驗數量和每個實驗的流量大小之間做一個取舍，業務高速發展時期經常會有用戶希望提高同時運行的實驗數量，同時保證每個實驗有充足的流量，于是我們擴展了原來的實驗流量分流模型設計，采用分層分域的正交的業務實驗劃分方式來支撐上述的流量需求。

更實時更準確的實驗報表：在早期的實驗中通過第二天的配置重算的方式得到前一天的用戶實驗分組數據，這種方法可以支撐非常巨大的用戶和實驗數量，但是時效性上比較難以保證。隨著業務快速迭代，算法的實時實驗效果監控的需求也逐漸增加，離線的實驗報表計算反饋需要等到至少1天后才能觀測，實驗反饋周期太長。于是我們調整了實驗分流和報表的計算鏈路，采用實時實驗日志埋點通過flink等實時計算平臺實時計算實驗效果，這種做法可以實時捕捉實驗流量的變化情況，對于驗證實驗分流效果有較大的效率提升。

復雜實驗形式：聯合實，多集群實驗， 指定用戶實驗需求：隨著算法工程鏈路的規范化，業務鏈路中的一些業務層之間開始進行聯合調優實驗，催生出了多參數跨層聯合實驗的需求，需要在分層實驗的基礎上支持聯合參數的生效機制，這在一般的分層實驗設計中是很難支撐的。隨著工程鏈路穩定性項目的進展，大部分業務同時都具有多個不同集群，此時又需要AB系統也可以針對不同集群提供同場景不同實驗配置的功能支撐。還有隨著精細化運營的展開，越來越多的實驗只針對更精準的特定用戶群才能生效，這給原來的實驗分流和實驗分析都帶來了不小的需求和挑戰。

更強大更通用的分流模型

為了滿足更豐富的流量分配需求，我們設計了一套比較靈活通用的實驗分流模型， 這套模型經過多個公司的業務驗證，可以確保在未來較長的一段時間內，充分支撐我們所有業務的個各種AB實驗分流需求。同時根據我們自己的業務發展需求，也支持了條件層，自定義分流機制等為更復雜業務設計的一些分流機制。

多層正交的實驗流量模型

上述的分流模型將一個場景流量分為層和域兩種嵌套結構，通過層來隔離不同業務配置，通過域來隔離不同用戶群。用戶在該模型進行分流的過程采用從外到內，從上到下的逐步命中，每一次進入一個業務層都會觸發一次選桶邏輯，命中桶以后，讀取桶上的配置，如果桶內還有層配置繼續依次命中層，觸發內部的選桶邏輯。

該模型可以支持如下主要特點：

分層分域，互相嵌套的流量設計，支持業務域分層的正交流量，每一層都是一個單獨的業務，解決流量饑渴問題，同時支持自由的流量域劃分，流量域和流量層可以互相嵌套，實現極其靈活的流量劃分方式。

每一個流量層采用hash模板+流量槽，層內實驗通過圈槽的形式決定實驗在該層的流量比例，允許算法用戶自定義實驗分流的規則，支持根據用戶的用戶特征信息進行分流，同時支持靈活的跨層流量對齊機制。這種方式可以實現極為靈活的分流方式，支持各種對象和分流方式（比如用戶分流，請求分流，設備分流，作者分流，按地區分流等）。

支持白名單，允許用戶繞開分流機制，指定用戶的固定實驗鏈路，用于在線上進行特殊用戶的實驗驗證。

支持條件層，允許符合某種條件的用戶單獨進行特定實驗，比如只針對新用戶進行的實驗。

從該模型上線以來，2年多的時間內已經完美支撐了算法300多個場景的AB流量分配需求，經過了充分的業務驗證，從分流層面解決了許多有特殊需求的分流業務遇到的問題。

具體層中的分流規則如下：

每一個流量層根據層中的分流配置信息和用戶信息計算命中的流量槽，然后根據流量槽命中圈選了流量槽的實驗，實驗通過擁有的流量槽數量決定實驗流量比例。

標準的實驗工程鏈路

通過AB實驗的后臺改造，我們重新思考并調整了整個實驗鏈路的工程設計，在新的工程設計中，相對于上一個版本主要有以下幾個方面需要改進：

采用實驗分流日志而不是離線的實驗配置來計算用戶的實驗分組信息。

實驗日志可以捕獲每一個時刻的用戶的實驗分流情況，可以較為敏感的捕捉到實驗變更的情況。

實驗日志可觀測性強，用戶配置完實驗以后可以立刻通過日志觀測實驗的命中情況。

可以在日志中附加更多的實驗環境相關信息，做更豐富的實驗分析，可以簡化離線的實驗分組計算邏輯。

線上應用增加實驗信息的具體埋點信息， 埋點分為兩部分:

一部分透傳給客戶端，其中包含用戶命中的實驗信息，稱之為ACM埋點，客戶端在用戶進行點擊曝光等操作時上報信息中回傳服務端下發的ACM字段，這樣我們可以通過神策上報的行為日志，清楚的知道每個實驗曝光幾次，被點擊幾次,可以及時得到實驗的線上表現，這部分行為日志還可以幫助我們實時的計算實驗策略效果報表。

另一部分作為應用的后臺日志記錄，記錄了每一次請求中用戶命中的實驗相關信息，用于計算實驗分組信息。

設計了AB實驗的后臺操作管理界面，不用再通過手動修改配置中心的配置來進行實驗配置。并將實驗發布，實驗修改，實驗配置回滾等功能做成具體的按鈕功能，極大地提高了用戶的實驗操作使用體驗。

拆分了實驗參數和代碼執行鏈路，抽象出了AB參數和代碼鏈路運行方案兩種概念，將AB變成一個弱依賴，降低實驗參數配置錯誤對線上業務的影響。

Ps: 為什么要同時采用兩種實驗信息反饋鏈路，原因是第一種ACM上報的用戶實驗信息依賴于用戶上報,如果用戶遇到應用crash或者延遲上報，或者網絡情況突然不好，我們沒辦法獲得未上報的這部分信息，第二種很明顯，沒辦法知道發放下來的帶有實驗信息的內容的后續反饋情況。兩種鏈路都沒辦法完全的覆蓋全部用戶，只有互相配合才能完整的覆蓋全量用戶，至于為什么采用離線日志來做實驗報表，ACM來做實時報表純粹是工程效率方面的考慮。

ACM通用埋點標準

為了解決實驗的實時效果觀測問題， 我們需要想辦法將后臺的實驗命中標識信息傳遞給客戶端。考慮到其他業務場景也會有類似的埋點需求，為了埋點通用性考慮，我們規劃了一個算法的埋點標準，主要想簡化算法埋點流程和對算法的埋點信息進行統一的治理。

ACM埋點主要是通過算法與客戶端約定一個固定的埋點內容字段ACM，后端算法在開發時候，通過提供的SDK工具，將需要埋點的信息和內容通過SDK采用特定的規范形成一串可識別的字符串內容，客戶端同學對ACM這個約定好的字段進行事件（曝光，點擊等）上報，后端就可以根據上報的用戶行為日志通過實時計算工具快速的獲得某個實驗的后續用戶反饋信息。

ACM埋點規范例子：

版本.業務域.內容資源類型.資源位.實驗.自定義值

版本：標記本條ACM的遵循的規范版本，不同版本具有不同的解析規則，方便udf解析。

業務域：業務系統代稱，盡量簡短，比如 搜索srh。

內容資源類型：內容類型或資源，比如 user_10098, cspu_1020,spu_771等。

資源位：廣告位，榜單位。

實驗：資源本次采用的AB實驗策略，多個實驗用-隔開。

自定義值：

允許應用方進行擴展的字段，比如 chan_latest-pos_3 代表channel為latest，pos為3。

特殊要求：自定義字段中不能出現 ".","-","_"等字段，其他部分無此要求。

埋點示例：

acm: 1.srh.spu_1009.sh.kka3b.10089-1929-100.channel_hot-position_2
acm: 2.srh.spu:1009.sh.kka3b.10089;1929;100.channel:hot;position:2

埋點場景：

request維度，覆蓋所有搜索和推薦場景

埋點動作：

request維度

下面是一個帶有acm信息的后端返回示例：

{
    "code": 200,
    "data": {
        "total": 3730,
        "start": 0,
        "hits": 10,
        "searchId": "161113175619737242413163",
        "searchTime": 0.024447,
        "items":[
            {
                "spuId":"xxx",
                "acm": "1.ms.prd-10092.v1ss.exp-1.kka.12",
            }
        ],
        "facet":[],
        "cache": false
    },
    "requestId": "f2ca7c08693acd54",
    "cost": 0,
    "time": 1611131759
}

實時的實驗指標監控

實時實驗指標的計算流程

后臺服務日志實驗分流信息需要透傳給客戶端；

客戶端用戶行為及時上報；

行為日志被flink等實時計算平臺及時處理；

制定明確且可計算的實時指標規范。

有了上面四個基礎流程，就可以計算實時的實驗反饋指標，但是要注意實時的指標計算往往只能反映一段時間的實驗趨勢變化，在部分復雜指標上很難實現精確的實驗指標計算，所以一般用來觀察實驗指標變化趨勢，不作為最終決策依據。

實時數據處理鏈路

打通了數據鏈路并且在用戶的行為日志中包含了ACM埋點以后，算法就可以基于行為日志，通過flink等工具實時算計算用戶的各種指標信息。

具體的監控鏈路流程如下圖綠色鏈路所示：

具體實時實驗監控效果

最終可以達到秒級的實驗效果反饋，極大的加快了算法對實驗策略的反饋效率，具體效果如下圖，用戶可以自己選擇關注的實驗信息對比不同實驗在同一時間區間內的指標變化情況。可以非常迅速的得到線上的新實驗的效果反饋信息，極大地縮短了算法對實驗指標的策略調整反饋周期。

四3.0 時代 從全到優，提升用戶體驗和實驗效率

2.0 時代主要是從各種機制和功能方面盡量滿足業務需要，業務功能滿足以后，我們進行了業務與擴展，將算法的推薦業務場景也囊括進來，推薦業務接入以后，雖然在基本功能上也可以滿足需求，但是推薦和搜索的業務特點還是有點不同，于是我們針對實驗平臺的實驗操作用戶體驗和穩定性方面進行了較多的優化。

實驗操作易用性的建設

業務場景鋪開以后，使用的業務團隊和人員也變得更為復雜，于是我們在針對特定場景的使用和業務人員使用習慣方面做了不少的功能改進和優化。根據我們收集的算法人員的參數配置，白名單配置，流量調整等功能使用痛點，我們進行了針對性的優化。

實驗參數的易用性工具

實驗參數配置是AB實驗的最主要的功能，為了優化用戶體驗在實驗參數使用方面的體驗，我們收集了一些常見的用戶在使用參數配置時候經常遇到的問題，并針對性做了功能和體驗的優化。

場景1：隨著業務發展，算法配置的業務層越來越多，由于約定的參數規范是同一層的可配置實驗參數應該一致，同一個實驗參數配置也應該出現在同一層，但是隨著層數增多和部分參數使用不規范，估算某個實驗參數的實際生效流量就變得很困難（參數有后覆蓋前面的規則）。有可能出現你給a實驗配置了 10%流量的 recallSize = 20 但是后續該參數被別人的同名參數覆蓋導致實際參數生效流量不符合預期的情況。

參數流量著色分析：使用參數流量的著色分析可以清楚的知道某個實驗參數都在哪些實驗中有配置，這些實驗如果同屬于一個業務層則無流量覆蓋，如果有些實驗不屬于同一個業務層，有可能出現參數覆蓋的情況。流量著色就是通過程序，一鍵計算某個參數最終的流量結果分布情況，可以方便的看到某個參數最終的線上真實流量比例。

包含某參數配置的所有實驗查詢：

某參數的實際生效流量分布：

場景2：實驗參數越來越復雜，同一個參數往往有多個不同的版本需要同時觀測實驗的效果，這種時候可能由于時間久遠或者實驗變更頻繁，或者參數過多，很多時候在進行實驗觀測和調整的時候需要確認實驗中的參數配置信息，特地為這些需要對比參數的場景制作了便捷的實驗參數對比的功能。

實驗參數對比：可以比較清晰的對比同一個實驗參數在同一層其他實驗中分別是什么值，可以大幅度提高實驗流量調整期間需要進行的實驗信息核對工作效率。

實驗布局的操作和展示優化

為了滿足靈活的實驗流量劃分，我們設計了一套通用的實驗流量模型，但是該流量模型的可視化方面一直是一個不小的難題，最基本的我們希望能直觀的展示層與層，層與桶（用戶域）之間的布局結構和用戶流量的命中順序關系。

我們進行了一些更能直觀體現實驗布局的探索，目前我們采用一個標準的樹狀結構來表示個實驗分流模型。實驗模型中的業務層和用戶桶我們都會用圖標進行區分，由于層桶結構可以嵌套多次，我們通過將結構關系進行拆分，將桶頁面主視圖和層頁面主視圖進行了分別設計。

層頁面主視圖：可以便捷的觀察到當前層內的不同流量桶和子桶內的其他子業務層，主要是用于尋找自己的業務層位于某一個用戶桶內，觀察某些桶的流量比例和參數等。子業務層內的流量桶信息不予顯示。

桶頁面主視圖：桶頁面的主視圖可以同時觀察到該桶內的各個子業務層和業務層內部的子實驗桶信息，可以用來直觀的對照具體的實驗命中鏈路從上往下核對實驗命中路徑。

界面顯示如下（測試數據）：

通過將層桶結構進行主要的功能拆分，可以在復雜場景的視圖布局清晰度和易用性上達到一個比較好的平衡。

實驗信息的完善

算法的實驗在進行實驗分析報表的時候往往需要對比多個指標綜合觀察實驗效果，之前都是算法人員跟分析人工對齊某個實驗什么時候開始什么時候結束，需要觀察哪些指標等信息。為了方便后續自動化的進行實驗效果分析，我們完善了實驗的實驗時長，核心指標，輔助指標等功能，方便用戶進行實驗的分析信息管理，后續通過自動化功能依賴這種信息可以實現實驗報表指標流程的自動化計算。

服務穩定性的改進

動態白名單功能優化

白名單操作是一個使用頻次較高的AB實驗操作功能， 實驗參數配置好以后往往需要通過白名單來小范圍的驗證策略效果。但是早期的白名單設計時候考慮到白名單會影響用戶的分流，所以白名單信息和實驗布局配置信息一起被用戶感知，這也導致每一次的白名單變更都需要重新發布實驗配置，給線上的配置穩定性造成了威脅。

解決方案：

基于白名單的設計和生效流程，我們嘗試通過流程和配置格式改進優化，使得白名單的配置可以實時生效同時又不影響原來的實驗配置，如下圖所示：

動態白名單功能改動相當于將白名單的配置信息獨立出來，在白名單有修改的時候獨立加載，同時不觸發配置信息本身的更新。但是考慮到兼容性問題，我們每次配置信息改動也會額外觸發白名單的重新更新，描述配置更新相當于一次全量更新，配置和白名單都會更新。白名單更新相當于實時只更新新增的白名單信息。

并發操作Ark發布實驗的優化

由于AB實驗的配置下發方式是通過Ark配置中心提供的配置通知功能實現的，目前后臺操作Ark進行配置發布的時候是通過http接口進行了，使用接口同時操作同一個Ark配置集的時候，大量操作容易產生并發，并發問題會導致Ark操作直接失敗，這種情況極大地阻礙了實驗配置發布過程的流暢性。

解決的辦法有如下方案：

經過仔細評估和方案選擇，我們決定方案2,3,4同步進行，最終完全解決了實驗操作時候的并發問題。

實驗效果分析的探索和優化

在過去2年的AB實驗的實踐和改進過程中，我們也十分注重實驗效果方面的分析和問題歸因，根據遇到的實際實驗分析問題和情況，總結了一部分常見的實驗分析相關經驗文檔，其中涉及實驗流程標準化，實驗指標選取，實驗指標的統計功效分析，實驗指標的p值和置信度分析，以及常見的實驗中遇到的問題等。

常見的實驗分析問題

我們總結了一些實驗效果分析中常見的問題和可能的原因，可以幫助排查AB實驗中遇到的常見問題。具體如下表：

實驗中的辛普森悖論

辛普森悖論（英語：Simpson's paradox），是概率和統計中的一種現象，其中趨勢出現在幾組數據中，但當這些組被合并后趨勢消失或反轉。這個結果在社會科學和醫學科學統計中經常遇到，當頻率數據被不恰當地給出因果解釋時尤其成問題。當干擾變量和因果關系在統計建模中得到適當處理時，這個悖論就可以得到解決。辛普森悖論已被用來說明統計誤用可能產生的誤導性結果。

落實到我們的AB實驗中就是如果一個實驗A在一個較長的實驗周期內每天指標都高于實驗B，實驗A的整體周期指標未必高于實驗B。

本圖想說明一個問題，如果一個實驗周期跨很多天，每天觀測實驗效果的情況下，如果某個實驗組用戶數量（或者某個指標）長期每天穩定高于另一個實驗組，不能說明分流不均勻。

第一天 因為剛剛重新分流，所以所有用戶對實驗來說都是新用戶，a組 505萬，b組 495萬 ，1%的正常誤差。

第二天 因為老用戶要保持分流一致，組內用戶=新用戶+次留老用戶， 新用戶會重新分組，老用戶沿用之前的分組，此時有兩種情況：

情況1 （合理） 老用戶按原來的分流， 新用戶分流誤差 1%。

情況2 （不合理） 老用戶按原來的分流，新用戶必須要保證誤差 2%，才能逆轉第二天的分組誤差情況，但是此種情況下第二天的新老用戶比例會嚴重不均勻，同時沒辦法保持分流策略的一致性，理論上不可能實現。

五未來的改進方向

未來我們會希望借助數倉部門的AB平臺的指標計算和可視化通用能力，希望可以逐步增強AB平臺的數據可視化能力，在實驗分流情況的可視化分析，實驗的用戶特征的分布可視化分析，實驗的指標變化原因排查等方面與分析同學一起合作，提升AB實驗的指標報表問題分析效率。

在AB實驗平臺本身的實驗信息操作和性能，穩定性方面我們也有一些新的想法，希望將來可以打通開發環境，測試環境，生產環境，實現一個界面可以跨環境操作，降低算法同學使用不同環境AB需要在不同系統切換的問題，同時在將來還希望借助sidecard的形式增強AB實驗的分流能力和分流穩定性，兼顧分流性能和分流平臺功能迭代效率。

審核編輯：湯梓紅