為什麼要進行 A/B 實驗？
決策無處不在，小到一個活動标題、一個 icon 的顔色，大到産品的互動形式、甚至是戰略。每個決策都會影響一部分使用者的使用體驗。長遠看，他們都将或大或小影響産品價值。我們該如何做決策、如何量化收益？這些問題，我們無法通過産品、UI設計、營運等同學的主觀判斷來得到答案。與此同時，任何一個功能從開發到上線，我們也無法保證整個過程中不出任何 BUG。如果直接對全量使用者推全新功能，而新功能存在 BUG 的話，影響将非常大。為了避免此類情況發生，我們有必要先小流量測試一下。這就是我們進行 A/B 實驗的原因。
什麼是 A/B 實驗？
A/B 實驗中，将使用者随機分為至少兩組。如果樣本足夠大，那麼我們可以認為不同組别的使用者無差異。在某個時間節點，對他們施加不同的方案或政策（一般隻設定一個唯一的變量，除此之外，不同組别的其他條件完全一樣）。不施加其他影響的組為對照組（A 組），實施新方案（政策）的組為實驗組（B 組）。A/B 實驗就是通過對比 A 組和 B 組的差異，評估所施加的方案（政策）的收益，達到幫助業務決策的目的。
A/B 實驗的基本原理為假設檢驗。假設的形式為：原假設 H0、備擇假設 H1。一般在工作中用的場景是雙尾檢驗，即 H0 為 A 組 B 組的資料名額無統計學意義上的差異（包括使用者數、使用者畫像、使用者活躍度分布等）。其原理基礎為小機率事件。即事件 A（小機率事件）在一次試驗中幾乎不可能發生的，如果在一次實驗中 A 就發生了，那麼我們應當合理懷疑該假設的真實性，拒絕原假設。常用的方法有 F 檢驗法、T 檢驗法、χ2檢驗法(卡方檢驗)等。
A/B 實驗适用場景
理論上，方案不唯一的場景，都可以通過 A/B 實驗來解決。我們平時會接觸到的 A/B 場景可以歸為以下 3 類。
産品功能優化
産品功能優化細分可以有幾大類：
一是功能的去留決策，新功能是否上線、舊功能是否下線，比如前段時間微信上線的視訊号就是一個新功能；
二是功能政策優化，比如微信公賬号裡，打賞作者的幾種預設打賞金額；
三是産品功能的 UI 優化，比如微信聊天裡的預設表情包的優化、甚至 App LOGO 的優化；
四是産品文案的優化，比如微信紅包的預設文案以及紅封包案節假日時的變更。
營運政策優化
營運政策也有很多種。
一是營運政策設定，比如很多 app 都有打卡獎勵活動，打卡的頻次設定、獎勵金額設定；電商 App 裡給使用者送優惠券，優惠券的額度、滿減标準、發放人群等。
二是活動文案優化，标題的重要性不言而喻，會直接影響參與活動的使用者數，标題的選擇也可以通過小流量 A/B 決定。
三是 Push 促活等優化，Push 的發送時間段、發送頻次、Push 内容等等，這些也可以通過 A/B 實驗，選擇使用者轉化率最高的方案。
推薦算法優化
相比産品和營運的優化，A/B 實驗在推薦算法優化中使用的更為廣泛。産品和營運還能依靠我們的主觀判斷完成部分決策，推薦算法相對來說，是算法模型封裝的黑盒。調整推薦模型中某個參數，影響的使用者量級、對名額的影響程度，都必須通過 A/B 實驗來量化算法優劣。
A/B 實驗優缺點
A/B 實驗可以量化不同方案的影響程度，進而回答不同方案的優劣。但是 A/B 實驗也是有局限的，它并不能告訴我們最優答案，隻能對比不同方案的差別；它也不能告訴我們直接的因果關系。我們能通過 A/B 實驗等到結果，但是結果産生的原因卻不能通過資料得到。另外，A/B 實驗也不能回答戰略性選擇的問題，比如一個實驗會導緻活躍使用者數下降，但是也能提升使用者使用 App 的時長和打開 App 的次數。這種偏戰略的資料結果，我們很難通過資料來決策。
目前 A/B 實驗的方法已經比較普及了，甚至一些公司出現過分依賴 A/B 實驗，造成 A/B 實驗濫用的現象。我們知道 A/B 實驗有諸多優點，但是 A/B 實驗也是有成本的。多種方案就意味着，對應的産品、UI 設計、開發、測試、資料分析等等，都需要相應的資源來支援，另外，A/B 實驗是需要流量的，也會出現使用者産品體驗不一緻的問題。是以，現實中我們要輔以對業務的專業判斷，及曆史累計的經驗來綜合決策，避免 A/B 實驗造成的資源浪費。
盡管有以上問題，我們不能是以忽視 A/B 實驗優勢。那麼如何設計和評估 A/B 實驗呢？
如何完成一個 A/B 實驗？
我們以産品功能優化為例來說，根據業務流程，産品方案 → 功能開發→功能上線→産品決策，來說說資料分析師在各環節應該準備的 A/B 流程有哪些
A/B 實驗設計（産品方案階段）
在産品方案預評審階段，我們基本可以知道功能的優化點或是新上線的功能形式。基于對業務的判斷，和産品共同決策是否需要實行 A/B 實驗，如果需要的話，前期我們需要完成以下準備工作。
首先，資料分析師需要根據功能特征，制定功能上線後的評估名額。預先做好評估方案，一是可以與各方業務達成一緻的資料預期，作為後續功能上線、擴量等決策的依據；二是根據評估名額Check 目前的日志或者埋點資料，判斷是否滿足我們的需求。如果缺少資料，需要一并送出開發需求，以保證 A/B 實驗的可評估性。
其次，我們要确定 A/B 實驗的流量選取方案。流量的選取最好滿足以下條件：一是每組使用者的數量相當，且可以確定 A/B 實驗的結果是可讀的（量級太大會擴大影響範圍、量級太小得不到置信結果）；二是保證各組使用者是随機分組産生的，即每組使用者無顯著差異，以此保證後續試驗時，實驗組（B 組）和對照組（A 組）隻有唯一變量；最後，依照通常情況，每種方案最好選取 2 組使用者，這樣可以排除不同組别使用者的随機波動影響。你可能會問，如果滿足以上全部條件，一個方案至少需要 4 組使用者（AABB 組）。那麼在活躍使用者數一定的情況下，如果同時有多個 A/B 實驗需要并行，那如何保證有足夠的流量使得不同實驗之間互相不影響呢？這就涉及一個實驗設計的概念：使用者（流量）分層正交。
我們假設，根據目前 App 活躍使用者數的量級來看，需要每組至少 10% 的流量才能得到統計學相對置信的結果。此時我們可以随機将使用者分為 10 組，每組 10% 的流量，即 A1、B1、C1……這樣的分組結果，可以支援我們同時進行 2 個 A/B 實驗（每個 A/B 實驗，有 AABB 共 4 組使用者）。如果，此時想同時進行第三個、第四個實驗怎麼辦呢？此時，我們把剛剛分為 A1、B1、C1 等的 10 組稱為第一層，再将第一層的使用者随機分到第二層的 10 個組裡，即将 A1 組 10% 的流量随機分為 10 個 1% 的流量分到第二層的 A2、B2、C3 等組中。同理 B1、C1 等也各自随機分到第二層每個組中，以此可以得到第二層 10 個 10% 流量的實驗組。以此内推，可以得到第三層、第四層等。通過上述的分層規則，我們可以看到，不同層之間的實驗是互相不影響的，即不同層的使用者是正交的。通過這種方式，我們可以實作多個 A/B 實驗的同時進行。
埋點驗證（功能開發階段）
進入開發階段，如果有新增埋點，我們需要檢驗上報埋點的準确性。如果等到功能上線再來介入，可能會因為埋點的缺失或者不準确，導緻 A/B 實驗的結果無法評估。是以埋點驗證需要在前置到開發階段進行，以此保證後續資料的可用性。
實驗分析（功能上線階段）
功能上線後，一般需要使用者更新安裝新版本後，才能體驗到新功能。是以，為了保證一定量級的使用者體驗到新功能，必須保證新版本的使用者滲透率達到一定水準。也因為這個原因，A/B 實驗通常需要一段觀察周期。觀察周期的長短與産品形态有關，像微信、微網誌這種高頻 App，通常一周時間就夠了；像淘寶這種相對低頻的 App，需要的時間周期更長一些。
在評估名額時，有一點我們需要注意：我們必須排除實驗前 AB 組差異的影響，即排除 preAA 的差異。下圖為每組日活使用者數的曲線圖，假如實驗在第 9 天上線，如果隻看上線後的趨勢圖，我們會得出，B2 組的活躍使用者數明顯低于 A1 和 A2 組。是以會得出，實驗組 B2 的方案會造成 DAU 下降。但是，如果我們多觀察實驗上線前的資料會發現，B2 的 DAU 在實驗上線前就低于 A1 和 A2 組，他們之間的 diff 并非實驗造成。
實驗決策（功能決策階段）
通過上一步，我們可以得到實驗組各項名額收益與對照組的對比情況。這就需要針對實驗方案作出決策。我們知道 A/B 實驗不适宜長期觀察，因為對于一個産品，不宜同時存在多種方案，讓使用者之間存在明顯差異。另外，A/B 實驗的用戶端代碼也會增加 App 包的大小，新使用者對此比較敏感，可能會影響使用者的下載下傳轉化；再次，A/B 實驗可用的流量是有限的，長期占據流量也是一種資源浪費。是以需要對實驗結果盡快決策。如果實驗組的關鍵名額顯著負向，可能需要繼續優化功能後再上線；如果觀察到的關鍵名額變化不大，但是功能本身的改動很大，可以建議擴大流量觀察；如果實驗組名額有正向收益，也可以建議直接推全。