電商領域A/B實驗平臺建設方法

分享嘉賓｜展博 內容&電商領域 資料產品經理

編輯整理｜段上雄 網易

出品社群｜DataFun

A/B 實驗應用

A/B 實驗應用作為論證的黃金方法，目前已經成為一個必然的選擇，但是實際上如何在企業內部去建設實驗平臺，還充滿了很多選擇。目前的實驗平臺，包括線上實驗的數量，已經成為衡量網際網路公司體量、業務量以及使用者量的一個隱藏指標。一些大廠的實驗平臺，同時線上實驗數量超過 10000，可能每個月新建的實驗數量都會大於 1000。

1. A/B 實驗是論證的黃金方法

上圖列出了一些資料分析方法，比如案例研究、觀察研究、類實驗、隨機控制實驗，以及統合分析，即結合隨機實驗和觀察研究去做一些強分析。

這幾層分析方法中存在一些通用的因素，首先，樣本是定向的樣本還是隨機的樣本。第二個是有沒有控制，比如最下面的案例研究是沒有控制的，它可能針對一個群體做分析，而 A/B 實驗天然會分成對照組和實驗組，是有控制的。最後一個就是實驗結論是否可以復現，是否科學。這三個因素的不同導致了整個分析方法可信度的差異。從下往上，可行度逐步提升。A/B 實驗是分析成本最低的一個方法，可以透過工程化的方法來提效，透過 A/B 產品化的方式來降低使用門檻。

A/B 實驗有三個主要的特點：

（1）第一個是先驗性，用事實說話，可以透過小流量低成本來得到一些結論；

（2）第二個是科學性，實驗分析時會用到假設檢驗的方法，相對來說是比較科學的；

（3）第三個是推斷性，透過隨機流量控制可以排除混雜因素的干擾，聚焦到我們的控制變數和實驗策略上。

2. 實驗平臺選擇

整個 A/B 平臺的建設，主要有兩個思路，第一個就是直接採購第三方平臺；另外一個就是自建平臺。

國內目前比較好的第三方產品，比如火山引擎，無論是產品 feature 還是整個應用情況都比較好，因為它是基於自己內部的最佳實踐。另外騰訊也開放了第三方平臺。熱雲、神策資料也提供了 SaaS 的實驗平臺。國外的廠商也比較多，像 VWO 實驗測試平臺、谷歌的 Optimize、以及 Optimizely 等等，都是一些比較有競爭力的產品。

第三方平臺通常適用於使用者體量比較小，資料跟分析的基建還相對比較薄弱的公司。透過第三方平臺的使用，提升公司內部資料以及分析的認知。

使用者行為分析和 A/B 實驗是緊密聯絡的，因為它們都是基於使用者的行為，讓使用者來告訴我們答案，包括底層的一些分析引擎、儲存引擎的等基建也都是可以複用的，這也是火山引擎的 A/B 測試和分析能力，和使用者行為分析能力都是緊密耦合在一起的原因。

對於公司自建平臺，國內主流的一些網際網路廠商也都有很好的實驗平臺，比如滴滴、美團、阿里、網易、新浪微博等，甚至有一些公司內部有多個實驗平臺。國外的微軟、谷歌也都有非常有特色的實驗平臺。這些公司也都是使用者體量比較大，實驗場景多，資料分析基礎比較強的公司。在自建實驗平臺的時候，如果公司業務體量大的話，不同的業務可能結合自身的需求都建過一些實驗平臺了，這時候還要推動平臺從 N 到 1 的建設。在新建平臺時，就要考慮業界的最佳實踐，同時還要考慮業務方的獨特訴求。這樣在公司內部推行實驗平臺的時候才能順暢，並且最終可能變成全公司通用的實驗平臺。

02

更多業務應用

接下來介紹更多業務應用。通常我們可以從實驗型別切入，比如產品類的實驗、服務端的實驗，演算法模型或者策略的實驗、運營類的實驗或者營銷類的實驗等等，這些都需要在實驗平臺中有比較好的支援。

1. 流量

在實驗中有三個要素，第一個就是流量，沒有流量也就不需要做實驗了，流量代表場景參與的使用者。可能不同的業務，不同的實驗型別，對整個流量的抽象是不同的。第二個是干預，也就是控制。第三個是分析，所使用的業務指標能夠體現出做實驗的目的。

上圖是谷歌重疊實驗框架的一個簡單示意圖，分成了 ABCD 4 種不同複雜度的框架，可以結合自己的業務實際情況來選擇，如果公司業務比較多，比如有電商、內容、遊戲和支付等，就需要 C 或者 D 這種形態才能夠比較好的滿足業務需求。

2. 聯合實驗

接下來講一下聯合實驗的幾種場景。

其中一種是貫通實驗，在同一個業務的上下游之間做實驗，比如業務的客戶端、前端、服務端、演算法測，整體要做一個順序的實驗。通常的做法是，在前端做實驗，透過傳參的方式來拉動後端去做響應，這是一種比較簡單的實驗方法。

第二種是聯合實驗，比如搜廣推場景，通常會分為召回、粗排、精排等環節。在做實驗的時候都會按實驗層來做實驗的控制。如果想做層與層之間的組合實驗，通常就叫聯合實驗，比如一個召回加排序的實驗，可能有些排序演算法針對某些召回佇列是有效的，就可以做這種組合實驗。如上圖中的例子，層 a 和層 b 都在獨立的做實驗，如果想做 a 和 b 的聯合實驗，就需要建立一個虛擬的聯合層，原有的層 a 和層 b 的流量都會縮水，這是對業務影響最小的一種實現方式。

第三種實驗是跨業務的聯合實驗，比如搜廣推場景下如果想用 1% 的使用者做免廣告測試，就是跨業務的聯合實驗。也可以透過類似於優先層，或者關聯實驗等方式來實現。

所以在實際的實驗型別設計和實驗方案設計的過程中，要靈活考慮不同的業務訴求。

3. 樣本獨立性

接下來介紹樣本獨立性。在 O2O 業務中，比如直播、短影片這種涉及到生產者和消費者雙邊市場的場景下，往往樣本的獨立性會受到一些影響，就不能很好地實現隨機控制。

對於涉及到雙邊甚至多邊的場景，比如買家、賣家以及騎手三方，如果很難滿足樣本獨立性，我們會透過類似版本翻轉實驗來做一些持續的觀測，也就是上個時間片用策略一，下個時間片用策略二，做足夠多的翻轉，然後再總體上來看策略一與策略二的優劣。比如運力排程策略，如果全域性有多個排程策略同時生效，排程就亂了，可以透過給每個排程策略分一個時間片讓其生效的方法來論證其優劣。

第二種是時間片輪轉實驗，在 O2O 場景中也比較常見，比如快遞或者外賣的 ETA（Estimated Time of Arrival）場景，我們可以透過時間片翻轉的方式來消除時間這種混雜因素的影響。因為在這種場景下，做 ETA 預估時，整個運力下所有的使用者之間是互相爭搶的，所以可以透過類似實驗片輪轉的方式來消除這種影響。當然也有雙邊控制這種實驗。因為在做實驗的時候會有很重的網路效應，比如分享這種沒有代價的溢位效應。還有一種情況是剛才講到的運力在乘客之間的擠佔效應，也會有一些影響。

針對不太敏感的場景，我們會做一些雙邊的控制，如果是一些有類似擠佔效應的強敏感場景，我們也會有類似於合成控制法等一些其他的方法來滿足樣本獨立性假設，避免樣本出現干擾，以至影響最後的實驗結論。上面這三種案例，本質都是確保分流的隨機性從而控制混雜因素對實驗結論的干擾。

03

更快系統整合

這一部分將介紹如何更好地做工程整合。在做系統功能提升的時，通常有 4 個議題：

（1）實驗配置怎麼分發？

（2）怎麼做分流的執行服務？

（3）實驗的引數怎麼與平臺和業務程式碼做整合？

（4）實驗日誌怎麼更好地支援分析師快速分析？

重點主要在後面兩部分，因為前兩部分的實驗平臺並沒有太多獨創的東西。關於配置，要麼平臺自建配置中心然後做分發；要麼依託公司的配置中心做分發。分流服務這塊其實沒有太多差異點，既然做實驗平臺，比如 API、SDK、UDF 這些能力都是要具備的，下面重點講一下引數整合和實驗日誌。

1.  實驗引數

對引數整合的理解分為幾個層面。

首先是引數如何控制。有三種控制方法，第一種是基於變體來控制，直接就是分組的名稱，這種控制法比較簡單，靈活性相對略差；第二種是基於引數來控制，引數有 key-value，比較適合於多選項的實驗控制，而且在後續也可以很好地做實驗引數的推全控制；第三種是基於配置的控制，所謂的配置是一系列引數的集合，往往基於配置來控制的時候在實驗平臺整合時會有一些優勢。因為某些業務方過往都已經有自己的實驗機制了，而且整個實驗配置也打包變成了一個配置。

如果是一個新平臺切入，比較好的對接方式是支援基於配置的方式來控制，這樣可以把一些打包的配置放到平臺上，然後分發給他，同時也可以去開發一些額外的特性，比如做一些衝突檢測，或是更好的工程適配等等。

第二個層面是引數的優先順序，比如實驗平臺的一個預設配置，再往上一個優先順序可能是普通實驗中的配置。如果想再增加優先順序，類似於在整個流量框架裡，還可以給某些層去賦一個更高的許可權，在這種層上的實驗引數可以有更高的許可權。

當然，隨著實驗越來越多，會發現好多 APP 包體會越來越大，在包體瘦身的過程中，做程式碼推全也是一個很好的手段，我們也會做一些檢測，讓 APP 的包體能夠有效地減小。

2.  實驗日誌

實驗日誌對分析師來說是非常重要的，我們提供了兩種實驗日誌。

一種是分流日誌，一般適用於服務端，因為服務端一般來說可以近似的理解為請求即觸發，服務端也不會做太多的大規模快取機制。

另外一種是觸發日誌，比較適合於客戶端，一般來說為了減少實驗平臺的互動會採用快取的機制，或者是我們很多實驗配置，希望 APP 啟動的時候就能夠生效，必須要做快取。所以在客戶端會有一些快取的機制，有快取以後，如果我們拿到實驗配置以後就上報的話，往往進組的樣本量就被誇大了，所以這時候我們會做一些觸發的控制。比如在做實驗配置的時候，配置一些埋點事件，埋點事件觸發以後，才認為這個事件被觸發了，這樣可以更精準的拿到實驗效果。

上圖是一個簡單的示意圖，涉及到不同實驗日誌型別是怎麼產生的，怎麼傳輸的，怎麼匯聚的，當然涉及到日誌的匯聚，包括後續的一個指標分析，大概我們就會有一個資料的管道，比如實驗日誌表，包括使用者行為表，包括逐層聚合後有更多業務資料產生的聚合表。一般來說聚合包括到分組粒度的聚合，到使用者粒度的聚合等等，支援後續不同情況的分析。

04

更好實驗分析

實驗分析的訴求是要保證實驗分析是可信的和科學的。為了保證分析是科學可信的，除了前面講的重疊流量框架，能夠保證整個流量是均勻與置信的以外，我們也會有適合於不同指標的各種檢驗方法。

1. 流量質檢

首先講一下實驗開始之前的 Pre AA 檢驗。不同流量平臺整個流量的感知是不一樣的，流量管理方式也不一樣。如果大家用過火山引擎，會發現它其實是一種弱感知的狀態。基於實驗的需求，你可以建立無限的流量層，而且這個層對你是隱藏的，但一般來說內部自建的話，我們會把層都抽象出來。因為抽象出來有一些好處，比如像前面講的聯合實驗那種場景，可能我們在搜廣推的召回排序的時候，要做組合實驗，如果沒有一個很強的層感知就會無從組合。業界有些公司將流量層叫做 World/Flight/Cell 等等，又或者簡單就叫作 layer。所以流量管理的強感知和弱感知，是未來大家要做實驗平臺迭代需要考慮的點。

對於 Pre AA 驗證，上圖中右側展示了我們實現的一個截圖。如果 Pre AA 流量是平的，按照統計理論，對它做重複取樣，應該發現 AA 之間的 diff 顯著程度，p_value 分佈應該符合均勻分佈。如果不平的話，就要懷疑整個分流是否是不均勻的。分流不均勻有兩種情況，一種是整個 layer 在做雜湊分流時，seed 是一個壞種子，這個種子不太好，這時就需要選一個新的種子來保證流量分流的均勻性；另一種是 seed 是好的，實驗層上也有一些實驗在跑了，在使用剩餘的流量做實驗的時候，又出現了 AA 不平，其實在做實驗的時候，會存在實驗的記憶效應，比如如果前期剛剛結束了一個實驗，這個實驗相對來說比較正向的組又分配到新實驗的某些組裡，它可能本身天然就是有偏的，這時候我們也可以做 Pre AA 的這種驗證，但是這種驗證其實已經不是在種子層面，而是 bucket 的層面，如果 DAU 能達到千萬，分桶一般會用千分桶，這時如果實驗桶是不均勻的，我們可以透過更隨機的 bucket 分配來有效縮減 AA diff。

這個功能往前再走一步，就變成所謂的流量自檢，我們平臺可以主動對一些重點的層、重點的業務去做一些流量質檢，這樣我們可以事先發現問題，甚至可以干預使用者去建立實驗，這樣就不需要使用者手動觸發在層、桶或者實驗粒度上的檢驗。

同時這樣也規避了一個弱勢，如果不是基於實時引擎來做 Pre AA 計算，是有時間開銷的，這樣使用者也不需要等，相當於前置計算中可以做到以空間換時間，前置做一些計算，能夠讓使用者使用流量的時候更放心。

2. 校驗方法

我們平臺目前有三種檢驗方法，第一種是在做分組樣本量均衡時的一個 SRM 檢驗，比如做了一個 50% VS 50% 的分組，如果分組之間進組的樣本量偏移比較大，那麼就認為整個分流是不均勻的，這時有可能和 Pre AA 是類似的情況，就很難拿到一個相對比較自信的結論，所以這個地方是 SRM 檢驗。通常來說，對於這種比率類的，我們可以透過卡方檢驗去做論證。

另外一種，我們在做實驗分析的時候，人均時長、人均 gmv、人均訂單也是經常要分析的指標，這時我們用了 Welch’s T 檢驗方法。

還有一種，像留存、使用者轉化率等轉化率指標，我們是用 Z 檢驗去做的。之所以用 Z 檢驗和 Welch’s T，是在於它們對資料集的要求會有一些差異， Z 檢驗可以用更低的成本去做，比如可以用基於主粒度的聚合表來做 Z 檢驗的分析，而像 Welch’s T 最好是要基於樣本粒度的表來做一些檢驗的計算。當然其實沒有必要去追求更多的檢驗方法，而是應該結合業務的需求來做。

上圖中右面是 Uber 實驗指標分析引擎的整個流程，它從資料輸入到資料離線處理，到資料分佈的判斷，包括針對不同的指標型別，會用到不同的檢驗方法或者計算方法。第一步是計算方差，後面才是應用檢驗方法進行顯著性分析。

3. 指標管理

最後一部分簡單分享一下關於指標管理的一些經驗。

整個指標體系會分為關鍵指標，業務的北極星指標，包括護欄指標，以及一些 OEC 指標。比如內容產業，判斷使用者時長更重要，還是生產者上傳更重要，還是廣告的收益更重要，往往這時候我們就需要引入 OEC 綜合評判指標來下結論。

另外，在指標設計的時候，我們需要考慮整個指標的靈敏性和魯棒性，所謂靈敏性是當前時間它足夠靈敏，能夠幫我們下結論。所謂的魯棒性就是做一些護欄指標或平臺指標，也考慮一些指標的計算成本。

指標管理的實現路徑有三種，也是三個不同的階段。

第一個階段是業務驅動。實驗平臺前期是搭框架，後期做功能，再後期實驗平臺就變成一個指標的管理平臺了。實驗平臺指標上十萬是非常正常的。在第一階段可能並沒有很多資源，更多的是做規範，有了規範以後，不同業務方依照規範把指標匯入進來，就可以用我們提供的實驗日誌和檢驗方法，並且我們實驗報告能夠幫他做決策分析。

第二階段是任務驅動。隨著一些長尾的業務接入，可能業務方沒有資料開發資源，這時我們可以去基於一些標準的模板來支援他們更快的接入。這個模板可能包括離線的模板和實時的模板，使用模板指定自己的事件、指標口徑等等，能夠快速的實現指標接入，包括實驗報告。

最後一個階段是基於事件驅動。這也是很多 SAAS 產品做的。主要有幾個好處，首先平臺抽象運算元，運算元用來規範指標的技術。另外業務方在定義指標的時候只需要選擇事件、運算元，剩下的都是平臺託管的，火山引擎目前就已經達到了這一階段。

05

Q1：前面提到的實驗科學相關的書籍叫什麼呢？

A1:《關鍵迭代-可信賴的線上對照實驗》，封面是一個河馬所以又稱河馬書，意指反資料驅動、實驗決策的 HIPPO 論。

Q2：客戶端首頁實驗，請求的時機可能是比較強的，等到分流的結果返回再渲染之後，可能會走一個兜底。這種情況下怎麼能保證分流的均勻？

A2：其實前面講到了客戶端實驗怎麼生效，可能是透過快取方式來落後一個冷啟或熱啟的週期來生效，但是我沒有講到怎麼保證分流的均勻。因為其實這一天中使用者的整個客戶端啟動，進組的節奏一定是有變化的，所以怎麼來保證實際進組的均勻性，這時候要引入一個版本的概念了，在實驗配置的時候會有一個版本概念，透過版本來做一個強一致的控制。因為不同的使用者使用 APP 的頻次是不一樣的，重度使用者可能一天開啟幾十次，一些相對非重度使用者可能兩三天才開啟，和它整個進組的節奏是沒有辦法完全保障的，因為這時候單單用日期來做控制已經不太科學了。比如一個相對低頻的使用者，他可能今天啟動了，但是他的實驗版本可能是一週之前的，這時候如果單純按日期來分析是不對的。

Q3：在流量管理的部分，強感知和弱感知的區別是什麼？

A3：強感知，一個比較形象的說法是你在實驗平臺中實實在在能看到一個個的層，這個層上跑了多少個實驗都是能看得到的。弱感知就是整個平臺只有實驗沒有層，你看到的是一個個的實驗，但是實際上這個實驗是在哪個流量層上，沒有刻意的去展示給你，當然在底層的工程框架一定是有一些設計的。

Q4：針對於總值類的指標，比如總播放的時長可能不服從正態分佈，應該用什麼檢驗？

A4：首先總時長不滿足我剛才講的人均指標以及轉化率指標框架，所以對應的檢驗方法就沒有辦法去做。但對於總播放時長以及 DAU 等，有一些公司的平臺使用 Bootstrap 等方法計算方差，然後緊接著也可以套 t 檢驗的公式來做這種置信度的分析。

Q5：在實驗指標波動的方向有沒有什麼建議？

A5：涉及到實驗指標波動，如果是判斷波動的顯著性，業界通用做法是先看是否統計顯著，然後再看是否業務顯著。在計算指標波動的時候還需要注意分析單元和分流單元的一致性， 通常我們實驗分流一般都會基於使用者來去做分流，因為體驗的一致性會得到保證。也會存在按照會話分流或者請求分流等等的情況，這時候做波動分析的時候可能也會有一些挑戰，你會發現其實整個方差的波動都會比較大需要進行一些消減，比如 DeltaMethod。

A6：對於想看的指標比較多的情況，有不同的解決辦法。首先從實驗目的上是否有足夠收斂的指標，當然實際一般來說都是妥協，可能我們這個實驗就是要觀察很多指標，這時候怎麼辦？剛才我講到的，比如說把指標收斂變成一個統一的綜合分指標來去做評判，也是一個手段。當然，如果很多指標也會涉及多重檢驗，要不要去做收斂，比如說是不是要求更強的置信度 p_value 等等。其實在目前我們的實驗平臺，我們提供一些選項，比如我們預設 p_value 是 0.05 幫使用者去做置信分析，但是使用者也可以去選擇 0.01 來做分析。我們來幫他做顯著性的判斷。所以我理解其實更多的還是結合業務的需求。