在位元組,A/B 實驗是這麼做的!

語言: CN / TW / HK

主要為大家介紹了為什麼要做 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 測試也能滿足傳統企業優化的訴求。

  • 從技術趨勢上來看,有這樣幾個發展方向:
  1. 智慧化:A/B 測試目前還處在早期階段,一些實驗結論或實驗洞察對資料和使用者屬性的利用還不是很充分。如果 A/B 測試能和統計方法、演算法模型相結合,很可能提高整個行業的水平。

  2. 場景化:很多場景還沒有開始使用 A/B 測試,未來更多的行業場景能和 A/B 測試相結合,讓 A/B 測試更易用。

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

產品介紹

火山引擎A/B測試:擺脫猜測,用科學的實驗衡量決策收益打造更好的產品,讓業務的每一步都通往增長。

關聯閱讀

相關文章:注意,你所做的 A/B 實驗,可能是錯的

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