以上圖圖示為例，假設我們有100萬用戶要進行 A/B 測試：
● 先選定目標受眾，比如一線城市的用戶。
● A/B 測試不可能對所有用戶都進行實驗，所以要進行科學抽樣，選擇小部分流量進行實驗。
● 抽樣之后需要對樣本進行分組，比如 A 組保持現(xiàn)狀，B 組的某一個因素有所改變。
● 分組之后在同一時間進行實驗，就可以看到改變變量后用戶行為的變化。
● 再根據(jù)對應實驗目標的指標，比如點擊率的高低，來評估實驗的結果。
以上就是我們對 A/B 測試的定義。目前，A/B 測試已被 Google、Facebook、亞馬遜等大型互聯(lián)網公司廣泛采用；字節(jié)跳動更是在2012年成立之初便開始使用 A/B 測試，公司內部一直流傳一句話：一切皆可 A/B 測試。A/B 測試在字節(jié)跳動已是非?；A的設施和文化，目前，字節(jié)跳動累計已有80W+ 的 A/B 實驗，日新增實驗1500+，同時運行試驗1W+，服務500+ 業(yè)務線。
那我們?yōu)槭裁匆?A/B 測試呢？我總結有3點原因：
● 風險控制：小流量實驗可以避免直接上線效果不好造成損失。其次，實驗迭代的過程中，決策都是有科學依據(jù)的，可以避免系統(tǒng)性的偏差。
● 因果推斷：我們相信 A/B 實驗中的優(yōu)化和改變最終能影響到線上數(shù)據(jù)以及用戶的行為。在這個前提下，A/B 測試就是最好的因果推斷工具。
● 復利效應：A/B 測試是可以持續(xù)不斷進行的實驗，即使一次實驗提升的效果不大，但是長期下來復利效應的積累會產生很大的變化和回報。
A/B 測試系統(tǒng)實現(xiàn)
了解了我們?yōu)槭裁匆?A/B 測試，下面我們來看一下火山引擎的 A/B 測試系統(tǒng)是如何實現(xiàn)的。
上圖是火山引擎 A/B 測試系統(tǒng)的架構示意圖，整體架構分為幾層：
● 運行環(huán)境層：在最底層，服務可以運行在容器內，也可以運行在物理機上。
● 基礎設施層：會用到關系型數(shù)據(jù)庫和鍵值對。因為 A/B 測試要處理很大的數(shù)據(jù)量，這一層也會使用離線和實時的大數(shù)據(jù)組件。
● 服務層：包括實驗所需的分流服務、元信息服務、調度服務等。在 A/B 測試中我們也需要標識用戶，因此這一層有設備服務。為了提供多種數(shù)據(jù)查詢，還有 OLAP 引擎。
● 業(yè)務層：包括實驗管理、指標管理、Feature 管理、評估報告等。
● 接入層：包括 CDN、網絡防火墻、負載均衡。
● 應用層：提供管理后臺控制實驗、查看報告等，SDK 調用。
●下面介紹幾個實驗流程的實現(xiàn)。
客戶端實驗參數(shù)傳遞及生效過程
客戶端實驗的流程如上圖所示：
● 業(yè)務方開發(fā)策略，確定實驗內容；
● 枚舉策略中的映射關系并在客戶端實現(xiàn)映射關系；
● 創(chuàng)建并開啟實驗；
● 客戶端已經集成了火山引擎 A/B 測試系統(tǒng)的 SDK，向 A/B 測試系統(tǒng)請求分流服務，判斷用戶命中哪些實驗哪些版本，下發(fā)參數(shù)；
● 客戶端從 SDK 取到參數(shù)，進行相對應的流程完成實驗。
服務端實驗參數(shù)傳遞及生效過程
服務端的實驗和客戶端類似：
● 設計實驗；
● 服務端實驗的 SDK 是跟業(yè)務系統(tǒng)比如服務端集成在一起?？蛻羰菑钠渌?C 端用戶直接請求業(yè)務的服務端，該服務端會在本地 SDK 做決策；
● 決策完之后將參數(shù)下發(fā)到下游，使策略生效。
統(tǒng)計分析實踐
● 在統(tǒng)計分析中，我們總結了一些有用的實踐經驗：
● 確定業(yè)務的指標體系：可以從宏觀/微觀、長期/短期、橫向/縱向三個角度建設指標體系。
● 分類檢驗：對指標進行置信度計算的時候，并不會每次都用同一套方法，而是針對不同的指標類型（包括轉化類、人均類、CTR 類等）進行不同的建模采用不同的方法。
● 統(tǒng)計修正：如果一個實驗開了多個組，可能犯了多重比較的錯誤。還有時開完實驗之后每天都會查看結果，這就犯了連續(xù)觀測的錯誤。所以在實踐中需要有一些統(tǒng)計修正的方法來修正行為。
● 基于葉貝斯體系的探索：區(qū)別于經典的假設檢驗，我們也在探索基于葉貝斯體系，如何評估實驗效果，降低面向用戶使用時候的理解門檻。在智能流量調優(yōu)、模型超參數(shù)搜索等場景下有具體落地。
● 這里也跟大家分享一些 A/B 實驗設計背后的思考：
● 避免過度曝光：A/B 實驗中有一個很關鍵的點是決策哪些樣本應該進入實驗。如果所有打開應用的人都能命中實驗，實驗結果就不會很明顯。
● 進組和出組：假設我們對北京的用戶進行了實驗，有些人出差或者旅游離開北京之后還能命中實驗嗎？我們可以把這個決策留給實驗者，讓實驗者自己決定是進組還是出組。
● 和 Feature Flag 的珠聯(lián)璧合：實驗之前可以把能進行實驗的內容抽象成 Feature Flag，簡單理解成功能開關。實驗完成之后的上線或者重復實驗，也可用 Feature Flag 進行管理。
字節(jié)跳動 A/B 測試最佳實踐
在字節(jié)跳動，A/B 測試已經是一種企業(yè)文化，大家都認可其價值，達成共識才能一起探討。A/B 測試跟其他環(huán)節(jié)是緊密相關的。我們在收集和分析數(shù)據(jù)之后會得到一些洞察，基于這些洞察可以知道有些環(huán)節(jié)是比較薄弱的，可進行提升，然后就可以提出假設，設計 A/B 實驗，完成實驗之后評估效果。有可能實驗沒有達到預期效果，可以對實驗進行迭代繼續(xù)收集數(shù)據(jù)，這樣就形成了以 A/B 測試為核心的業(yè)務增長閉環(huán)。
下面為大家介紹如何完整進行一次 A/B 實驗。
如何產生好的實驗想法
關于如何產生好的實驗想法，我們可以從定量分析和定性分析幾個角度來看。前面提到的構建完善的指標體系就是定量分析，這里不再贅述。在收集到指標數(shù)據(jù)以后，對于指標發(fā)生的異動進行現(xiàn)象分析，針對已存在問題（非異動），則可以進行新的產品策略或者運營策略迭代執(zhí)行。
定性分析可以分為三個方面：
● 產品本身的價值主張是什么？比如一款打車 APP 的價值主張是通過共享經濟實現(xiàn)社會的效率提升，這個產品有沒有很好地體現(xiàn)價值主張？可以從這一方面產生一些實驗想法。
● 推動因素
相關性：同一個頁面中如果有不相關的功能，用戶大概率也不會點擊，這樣的設計就沒有效果。
清晰度：要表達的內容（比如命名）是否足夠清晰。
緊迫性：對于有時間周期的活動，可以設計一些事件營造緊迫感。
● 阻礙因素：
注意力分散：避免在一個頁面放五花八門的信息讓用戶找不到重點。
焦慮性：有的地方可能給了用戶很多選擇，也會造成選擇困難，不自覺地形成一種焦慮感，不如簡單一些只設計一個選擇。
如何建立一個有效的實驗假設
我們需要針對一個用戶群體做出改變，然后產生一定的影響。但是這個假設不是無腦定的，要有邏輯性是合理的，最終能通過指標來評估變化的影響。針對這幾個要素，我們總結出了設計 A/B 實驗的 PICOT 原則，即 Population、Intervention、Comparison、Outcome、Time，明確對什么樣的用戶做出了什么樣的改變，然后進行分組比較，最終需要設計衡量結果的指標，并決策實驗要進行多長時間。
A/B 測試效果評估
看哪些數(shù)據(jù)
上圖是一份 A/B 測試實驗報告，可以看到指標在實驗版本里是絕對值，還有變化值以及置信區(qū)間。置信區(qū)間是指假設策略全量上線，你有95% 的把握會看到真實的指標收益在 [,] 這個范圍內。置信區(qū)間越窄且不包含0，可信度就越高。從「查看圖表」進入選擇差異值可以觀察累計 diff 趨勢圖，如果呈現(xiàn)置信區(qū)間逐漸變窄的現(xiàn)象，說明隨著樣本量越來越大，我們對評估結果的信心就越來越強。
指標變化是顯著的嗎
A/B 實驗的結果有以下幾種：
● 正向顯著：說明當前樣本容量條件下，實驗版本優(yōu)于對照版本，實驗結果和假設一致；
● 負向顯著：說明當前樣本容量條件下，實驗版本不優(yōu)于對照版本，實驗結果和假設不一致；
● 不顯著：
確實不顯著：可以參考 MDE 指標是否符合預期，如果符合，則說明結果確實不顯著。
其他原因導致的不顯著：比如樣本容量小，指標對應的用戶行為滲透率低，實驗時長較短等。在這些情況下，如果實驗效果不顯著，可以進一步優(yōu)化實驗，比如增大樣本量，擴大流量、再觀察一段時間積累更多進組用戶等。
接下來我們可以再看兩個案例。
哪個首頁新 UI 版本更受歡迎
今日頭條 UI 整體風格偏大齡被詬病已久，不利于年輕和女性用戶泛化，歷史上幾次紅頭改灰頭實驗都對大盤數(shù)據(jù)顯著負向。因此團隊設計了 A/B 實驗，目標是在可接受的負向范圍內，改一版用戶評價更好的 UI。通過控制變量法，對以下變量分別開展數(shù)次 A/B 實驗：
● 頭部色值飽和度
● 字號
● 字重
● 上下間距
● 左右間距
● 底部 tab icon
● 結合用戶調研（結果顯示：年輕用戶和女性用戶對新 UI 更偏好）
綜合來看，效果最好的 UI 版本如圖2所示，全量上線。
新 UI 上線后，Stay duration 顯著負向從-0.38% 降至 -0.24%，圖文類時長顯著 +1.66%，搜索滲透顯著 +1.47%，高頻用戶（占71%）已逐漸適應新 UI。
選擇更優(yōu)的視頻上滑引導產品形態(tài)
某款短視頻在剛面世時，很多用戶都不知道上滑的玩法，因此就設計實驗驗證如何能更好地引導用戶上滑。實驗目標定為優(yōu)化后提升新用戶留存，上滑操作滲透率提升1%，錯誤操作滲透率下降1%。定向受眾為新用戶，面向10% 的線上流量進行為期1個月的實驗。
我們做了兩輪實驗，第一輪實驗結果并不符合預期，上滑操作滲透率下降1% 且顯著，錯誤操作滲透率提升1.5%，不符合預期。新用戶留存未見顯著上升。但在不符合預期的情況下，還是能做一些分析來發(fā)現(xiàn)原因。因此經過改進我們做了第二輪實驗，結果上滑操作滲透率上升1.5% 且顯著，新用戶7日內留存提升1%-1.8%，且指標結果呈顯著，符合預期。
上面的例子就說明了我們可以把 A/B 測試當成一個理解用戶的工具。
展望
● 最后想跟大家一起展望一下 A/B 測試行業(yè)未來的情況。從行業(yè)前景來看：
● 認知率和普及率在高速提升：我們之前做過一個調研，發(fā)現(xiàn) A/B 測試在國內整體認知度較低，可能低到一個難以想象的數(shù)字。我們認為在未來5-10年內，A/B 測試的認知度可能會有50-100倍的提升，這個市場還是一片藍海。
● 從 nice-to-have 到 must-have：現(xiàn)在很多人認為 A/B 測試是一個錦上添花的工具，但在數(shù)據(jù)驅動越來越重要的今天，A/B 測試是必須要掌握的工具，是企業(yè)開展業(yè)務過程中的剛需，否則在行業(yè)競爭中就會失去優(yōu)勢。
● 破圈：我們也發(fā)現(xiàn) A/B 測試正在破圈。大家的印象中 A/B 測試只有互聯(lián)網公司會用，但是我們在交流的過程中發(fā)現(xiàn)，很多傳統(tǒng)企業(yè)雖然沒有線上業(yè)務，但如果能解決數(shù)據(jù)收集的問題，A/B 測試也能滿足傳統(tǒng)企業(yè)優(yōu)化的訴求。
● 從技術趨勢上來看，有這樣幾個發(fā)展方向：
● 智能化：A/B 測試目前還處在早期階段，一些實驗結論或實驗洞察對數(shù)據(jù)和用戶屬性的利用還不是很充分。如果 A/B 測試能和統(tǒng)計方法、算法模型相結合，很可能提高整個行業(yè)的水平。
● 場景化：很多場景還沒有開始使用 A/B 測試，未來更多的行業(yè)場景能和 A/B 測試相結合，讓 A/B 測試更易用。
● 被集成：目前我們的 A/B 測試平臺可以一站式管理實驗、查看報告，但是一些用戶的業(yè)務已經很成熟，希望 A/B 測試能夠走入業(yè)務和系統(tǒng)，更順滑地使用。所以 A/B 測試技術也需要提高自身被集成的能力，無縫地和各種業(yè)務、系統(tǒng)結合起來。
Q&A
Q：A/B 測試對用戶體量有沒有基本限制？小用戶量在進行 A/B 測試時有什么要注意的嗎？
A：A/B 測試方法本身對用戶量沒有限制，但是如果實驗樣本太少，就很難看到顯著的結果，收益比較小。
Q：火山引擎 A/B 測試和算法等數(shù)據(jù)科學有哪些結合的嘗試和實踐？
A：我們內部在做的一些事情可以簡單介紹一下：比如基于多臂老虎機的智能實驗，已經在開始應用一些算法。此外我們也在探索參數(shù)搜索的實驗，提升搜索參數(shù)的速度，讓 A/B 測試更智能化。
Q：A/B 實驗一般要測試多才可以看到結果？
A：嚴格意義上，開多久是和實驗能帶來的影響有關系的，以我們的經驗值來看，一般是要覆蓋一個完整的用戶生命周期。我們一般是以周為單位，實驗至少開啟1-2周。
Q：A/B 測試在實驗結果上有沒有自動歸因的能力，幫用戶直接定位到是什么原因引起實驗結果好或者差的？
A：前面提到的一些智能化探索會對自動歸因有幫助，但是自動歸因還有一個很重要的點是，A/B 測試實驗數(shù)據(jù)背后的原因可能需要很多業(yè)務知識的輸入或者很有力的指標建設才能推斷出來。
Q：如此多的實驗，如何保證實驗的正交？
A：我們通過大量的模擬實驗，以及對系統(tǒng)監(jiān)控的自檢來保證正交，一旦發(fā)現(xiàn)數(shù)據(jù)超過了閾值就會及時進行調整。
