01 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 產品做的。主要有幾個好處，首先平臺抽象算子，算子用來規范指標的技術。另外業務方在定義指標的時候只需要選擇事件、算子，剩下的都是平臺托管的，火山引擎目前就已經達到了這一階段。