在位元組，A/B 實驗是這么做的！

主要為大家介紹了為什么要做 A/B 測驗、火山引擎的 A/B 測驗系統架構及位元組跳動內部 A/B 測驗的最佳實踐，

為什么要做 A/B 測驗

首先我們看一個案例，

位元組跳動有一款中視頻產品叫西瓜視頻，最早它叫做頭條視頻，為了提升產品的品牌辨識度，團隊想給它起個更好的名字，經過一些內部調研和頭腦風暴，征集到了西瓜視頻、奇妙視頻、筷子視頻、陽光視頻 4 個名字，于是團隊就針對一共 5 個 APP 名稱進行了 A/B 實驗，

這個實驗中唯一改變的是應用市場里該產品的名稱和對應的 logo，實驗目的是為了驗證哪一個應用名稱能更好地提升“頭條視頻” APP 在應用商店的點擊率，最后西瓜視頻和奇妙視頻的點擊率位列前二，但差距不顯著，結合用戶調性等因素的綜合考量后，最終決定頭條視頻正式更名為西瓜視頻，

通過這個案例可以看到，A/B 測驗可以幫助業務做最終決策，結合案例的直觀感受，我們可以這樣來定義 A/B 測驗：在同一時間對目標受眾做科學抽樣、分組測驗以評估效果，

以上圖圖示為例，假設我們有 100 萬用戶要進行 A/B 測驗：

先選定目標受眾，比如一線城市的用戶，

A/B 測驗不可能對所有用戶都進行實驗，所以要進行科學抽樣，選擇小部分流量進行實驗，

抽樣之后需要對樣本進行分組，比如 A 組保持現狀，B 組的某一個因素有所改變，

分組之后在同一時間進行實驗，就可以看到改變變數后用戶行為的變化，

再根據對應實驗目標的指標，比如點擊率的高低，來評估實驗的結果，

以上就是我們對 A/B 測驗的定義，

目前，A/B 測驗已被 Google、Facebook、亞馬遜等大型互聯網公司廣泛采用；位元組跳動更是在 2012 年成立之初便開始使用 A/B 測驗，公司內部一直流傳一句話：一切皆可 A/B 測驗，

A/B 測驗在位元組跳動已是非常基礎的設施和文化，目前，位元組跳動日新增實驗 1500+，那我們為什么要做 A/B 測驗呢？主要有 3 點原因：

1. 風險控制：小流量實驗可以避免直接上線效果不好造成損失，其次，實驗迭代的程序中，決策都是有科學依據的，可以避免系統性的偏差，

2. 因果推斷：我們相信 A/B 實驗中的優化和改變最終能影響到線上資料以及用戶的行為，在這個前提下，A/B 測驗就是最好的因果推斷工具，

3. 復利效應：A/B 測驗是可以持續不斷進行的實驗，即使一次實驗提升的效果不大，但是長期下來復利效應的積累會產生很大的變化和回報，

A/B 測驗系統實作

了解了我們為什么要做 A/B 測驗，下面我們來看一下火山引擎的 A/B 測驗系統是如何實作的，

上圖是火山引擎 A/B 測驗系統的架構示意圖，整體架構分為幾層：

• 運行環境層：在最底層，服務可以運行在容器內，也可以運行在物理機上，

• 基礎設施層：會用到關系型資料庫和鍵值對，因為 A/B 測驗要處理很大的資料量，這一層也會使用離線和實時的大資料組件，

• 服務層：包括實驗所需的分流服務、元資訊服務、調度服務等，在 A/B 測驗中我們也需要標識用戶，因此這一層有設備服務，為了提供多種資料查詢，還有 OLAP 引擎，

• 業務層：包括實驗管理、指標管理、Feature 管理、評估報告等，

• 接入層：包括 CDN、網路防火墻、負載均衡，

• 應用層：提供管理后臺控制實驗、查看報告等，SDK 呼叫，

下面介紹幾個實驗流程的實作：

客戶端實驗引數傳遞及生效程序

客戶端實驗的流程如上圖所示：

• 業務方開發策略，確定實驗內容；

• 列舉策略中的映射關系并在客戶端實作映射關系；

• 創建并開啟實驗；

• 客戶端已經集成了火山引擎 A/B 測驗系統的 SDK，向 A/B 測驗系統請求分流服務，判斷用戶命中哪些實驗哪些版本，下發引數；

• 客戶端從 SDK 取到引數，進行相對應的流程完成實驗，

服務端實驗引數傳遞及生效程序

服務端的實驗和客戶端類似：

• 設計實驗；

• 服務端實驗的 SDK 是跟業務系統比如服務端集成在一起，客戶是從其他 C 端用戶直接請求業務的服務端，該服務端會在本地 SDK 做決策；

• 決策完之后將引數下發到下游，使策略生效；

統計分析實踐

在統計分析中，我們總結了一些有用的實踐經驗：

• 確定業務的指標體系：可以從宏觀/微觀、長期/短期、橫向/縱向三個角度建設指標體系，

• 分類檢驗：對指標進行置信度計算的時候，并不會每次都用同一套方法，而是針對不同的指標型別（包括轉化類、人均類、CTR 類等）進行不同的建模采用不同的方法，

• 統計修正：如果一個實驗開了多個組，可能犯了多重比較的錯誤，還有時開完實驗之后每天都會查看結果，這就犯了連續觀測的錯誤，所以在實踐中需要有一些統計修正的方法來修正行為，

• 基于葉貝斯體系的探索：區別于經典的假設檢驗，我們也在探索基于葉貝斯體系，如何評估實驗效果，降低面向用戶使用時候的理解門檻，在智能流量調優、模型超引數搜索等場景下有具體落地，

這里也跟大家分享一些 A/B 實驗設計背后的思考：

• 避免過度曝光：A/B 實驗中有一個很關鍵的點是決策哪些樣本應該進入實驗，如果所有打開應用的人都能命中實驗，實驗結果就不會很明顯，

• 進組和出組：假設我們對北京的用戶進行了實驗，有些人出差或者旅游離開北京之后還能命中實驗嗎？我們可以把這個決策留給實驗者，讓實驗者自己決定是進組還是出組，

• 和 Feature Flag 的珠聯璧合：實驗之前可以把能進行實驗的內容抽象成 Feature Flag，簡單理解成功能開關，實驗完成之后的上線或者重復實驗，也可用 Feature Flag 進行管理，

位元組跳動 A/B 測驗最佳實踐

在位元組跳動，A/B 測驗已經是一種企業文化，大家都認可其價值，達成共識才能一起探討，A/B 測驗跟其他環節是緊密相關的，

我們在收集和分析資料之后會得到一些洞察，基于這些洞察可以知道有些環節是比較薄弱的，可進行提升，然后就可以提出假設，設計 A/B 實驗，完成實驗之后評估效果，

有可能實驗沒有達到預期效果，可以對實驗進行迭代繼續收集資料，這樣就形成了以 A/B 測驗為核心的業務增長倍訓，

下面為大家介紹如何完整進行一次 A/B 實驗，

如何產生好的實驗想法

關于如何產生好的實驗想法，我們可以從定量分析和定性分析幾個角度來看，前面提到的構建完善的指標體系就是定量分析，這里不再贅述，在收集到指標資料以后，對于指標發生的異動進行現象分析，針對已存在問題（非異動），則可以進行新的產品策略或者運營策略迭代執行，

定性分析可以分為三個方面：

• 產品本身的價值主張是什么？比如一款打車 APP 的價值主張是通過共享經濟實作社會的效率提升，這個產品有沒有很好地體現價值主張？可以從這一方面產生一些實驗想法，

• 推動因素

相關性：同一個頁面中如果有不相關的功能，用戶大概率也不會點擊，這樣的設計就沒有效果，

清晰度：要表達的內容（比如命名）是否足夠清晰，

緊迫性：對于有時間周期的活動，可以設計一些事件營造緊迫感，

• 阻礙因素

注意力分散：避免在一個頁面放五花八門的資訊讓用戶找不到重點，

焦慮性：有的地方可能給了用戶很多選擇，也會造成選擇困難，不自覺地形成一種焦慮感，不如簡單一些只設計一個選擇，

如何建立一個有效的實驗假設

我們需要針對一個用戶群體做出改變，然后產生一定的影響，但是這個假設不是無腦定的，要有邏輯性是合理的，最終能通過指標來評估變化的影響，針對這幾個要素，我們總結出了設計 A/B 實驗的 PICOT 原則，即 Population、Intervention、Comparison、Outcome、Time，明確對什么樣的用戶做出了什么樣的改變，然后進行分組比較，最終需要設計衡量結果的指標，并決策實驗要進行多長時間，

A/B 測驗效果評估

• 看哪些資料

上圖是一份 A/B 測驗實驗報告，可以看到指標在實驗版本里是絕對值，還有變化值以及置信區間，置信區間是指假設策略全量上線，你有 95% 的把味訓看到真實的指標收益在 [,] 這個范圍內，

置信區間越窄且不包含 0，可信度就越高，

從「查看圖表」進入選擇差異值可以觀察累計 diff 趨勢圖，如果呈現置信區間逐漸變窄的現象，說明隨著樣本量越來越大，我們對評估結果的信心就越來越強，

指標變化是顯著的嗎

A/B 實驗的結果有以下幾種：

• 正向顯著：說明當前樣本容量條件下，實驗版本優于對照版本，實驗結果和假設一致；

• 負向顯著：說明當前樣本容量條件下，實驗版本不優于對照版本，實驗結果和假設不一致；

• 不顯著：

• 確實不顯著：可以參考 MDE 指標是否符合預期，如果符合，則說明結果確實不顯著，

• 其他原因導致的不顯著：比如樣本容量小，指標對應的用戶行為滲透率低，實驗時長較短等，在這些情況下，如果實驗效果不顯著，可以進一步優化實驗，比如增大樣本量，擴大流量、再觀察一段時間積累更多進組用戶等，

接下來我們可以再看兩個案例，

哪個首頁新 UI 版本更受歡迎

今日頭條 UI 整體風格偏大齡被詬病已久，不利于年輕和女性用戶泛化，歷史上幾次紅頭改灰頭實驗都對大盤資料顯著負向，因此團隊設計了 A/B 實驗，目標是在可接受的負向范圍內，改一版用戶評價更好的 UI，通過控制變數法，對以下變數分別開展數次 A/B 實驗：

• 頭部色值飽和度

• 字號

• 字重

• 上下間距

• 左右間距

• 底部 tab icon

• 結合用戶調研（結果顯示：年輕用戶和女性用戶對新 UI 更偏好）

綜合來看，效果最好的 UI 版本如圖 2 所示，全量上線，

新 UI 上線后，Stay duration 顯著負向從-0.38% 降至 -0.24%，圖文類時長顯著 +1.66%，搜索滲透顯著 +1.47%，高頻用戶（占 71%）已逐漸適應新 UI，

選擇更優的視頻上滑引導產品形態

某款短視頻在剛面世時，很多用戶都不知道上滑的玩法，因此就設計實驗驗證如何能更好地引導用戶上滑，實驗目標定為優化后提升新用戶留存，上滑操作滲透率提升 1%，錯誤操作滲透率下降 1%，定向受眾為新用戶，面向 10% 的線上流量進行為期 1 個月的實驗，

我們做了兩輪實驗，第一輪實驗結果并不符合預期，上滑操作滲透率下降 1% 且顯著，錯誤操作滲透率提升 1.5%，不符合預期，新用戶留存未見顯著上升，但在不符合預期的情況下，還是能做一些分析來發現原因，因此經過改進我們做了第二輪實驗，結果上滑操作滲透率上升 1.5% 且顯著，新用戶 7 日內留存提升 1%-1.8%，且指標結果呈顯著，符合預期，

上面的例子就說明了我們可以把 A/B 測驗當成一個理解用戶的工具，

展望

最后想跟大家一起展望一下 A/B 測驗行業未來的情況，

• 從行業前景來看：

認知率和普及率在高速提升：我們之前做過一個調研，發現 A/B 測驗在國內整體認知度較低，可能低到一個難以想象的數字，我們認為在未來 5-10 年內，A/B 測驗的認知度可能會有 50-100 倍的提升，這個市場還是一片藍海，

從 nice-to-have 到 must-have：現在很多人認為 A/B 測驗是一個錦上添花的工具，但在資料驅動越來越重要的今天，A/B 測驗是必須要掌握的工具，是企業開展業務程序中的剛需，否則在行業競爭中就會失去優勢，

• 破圈：
  我們也發現 A/B 測驗正在破圈，大家的印象中 A/B 測驗只有互聯網公司會用，但是我們在交流的程序中發現，很多傳統企業雖然沒有線上業務，但如果能解決資料收集的問題，A/B 測驗也能滿足傳統企業優化的訴求，

• 從技術趨勢上來看，有這樣幾個發展方向：

智能化：A/B 測驗目前還處在早期階段，一些實驗結論或實驗洞察對資料和用戶屬性的利用還不是很充分，如果 A/B 測驗能和統計方法、演算法模型相結合，很可能提高整個行業的水平，

場景化：很多場景還沒有開始使用 A/B 測驗，未來更多的行業場景能和 A/B 測驗相結合，讓 A/B 測驗更易用，

被集成：目前我們的 A/B 測驗平臺可以一站式管理實驗、查看報告，但是一些用戶的業務已經很成熟，希望 A/B 測驗能夠走入業務和系統，更順滑地使用，所以 A/B 測驗技術也需要提高自身被集成的能力，無縫地和各種業務、系統結合起來，

產品介紹

火山引擎A/B測驗

擺脫猜測，用科學的實驗衡量決策收益打造更好的產品，讓業務的每一步都通往增長，

關聯閱讀

相關文章：注意，你所做的 A/B 實驗，可能是錯的！

歡迎關注位元組跳動資料平臺同名公眾號

標籤：大數據

上一篇：Flink使用Pod Template將狀態快照(Checkpoint、Savepoint)存盤在NFS

下一篇：mac下進入mysql，提示command not found的解決方法（親測有效）