本篇為實驗三部曲的完結，主要供有一些實驗經驗、或者對實驗感興趣的同學瞭解。增長實驗中，除了之前提到的“可比性”以外，還存在這樣或那樣的分析陷阱，文中主要講兩個代表性問題：正交分層及其局限性，SRM問題及其應對方法。
01 正交分層如何實現“平行宇宙”
在之前有關實驗設計的文章中，我們簡單提到過正交分層，它的作用在於將有限的用戶數或流量，同時用於多個實驗中而互不干擾。
理想情況下，正交分層體系中的每一層，就像是一個“平行宇宙”，可以各自進行獨立的實驗。在正交分層的體系里，一個用戶很可能是同時被多個實驗命中的。既然這樣，如何能做到實驗間沒有互相干擾呢？
AB實驗中的隨機分組通過性能較好的哈希算法，將用戶ID進行特殊轉換處理，確保分組時盡可能做到隨機。可以理解成對我們每個人的手機號做一些複雜處理，避免直接按照尾號分組時，出現尾號8用戶群和尾號4用戶群之間的樣本有偏差。
隨機分組是發生在每一個分層中的，而正交分層是指層與層之間需要保證正交性，有現成的檢驗方法，感興趣的同學可以自行查找，此處先不做贅述。借助一系列正交哈希算法（目前較多採用正交表算法），我們可以保證任意兩層之間的實驗獨立性。
如上圖，假設我們選擇同一個用戶群體，任意取到若干正交分層中的兩層：分別記為第N層和第N+1層。
我們決定對第N層進行AB實驗，即將該層的用戶隨機分為A、B兩組；同時我們再對第N+1層進行AB實驗，記為A1、B1兩組。
兩組實驗覆蓋到的人群是一樣的，我們下發不同的策略。正交分層能夠做到第N層中的A組用戶，在第N+1層隨機分散到A1和B1兩個組。當我們在分析第N+1層實驗效果時，可以認為A1組和B1組所受到來自第N層策略的影響是相同的。因此，在分析A1、B1兩組間的效果差異時，可以將來自其他層的影響忽略不計。
通過正交分層，我們可以做到樣本量有限時，依然可以同時進行多組實驗，這有助於我們更快速找到有效的策略。因此，正交分層也成為了成熟實驗平臺的標配。然而，並不是滿足了正交分層，我們就可以認為可以無視不同層間的策略干擾，下麵我們詳細介紹。
02 正交分層存在局限性
正交分層若想保證策略間“無干擾”，還需要一個前提：不同層間策略的相關性需要盡可能低。先舉個例子說明策略相關性。
比如，常見的給用戶發紅包的策略，假定策略1是每人發0.5元，策略2是每人發1.0元。這兩個策略都是發紅包，是高度相關的（本質上是同一類），其效果會產生干擾。
試想，如果我們實驗時分別取一層來下發策略1，另一層與之正交，下發策略2。由第一部分的解釋，策略2將會均勻的影響到策略1的實驗組和對照組。就這個例子看，因為策略2下發的金額較高，效果大概率會好於策略1，所以當分析策略1效果時，很可能發現其實驗組相比對照組沒有提升，得到“發錢無效“的實驗結論。其原因是策略1（弱策略）的實驗組和對照組均勻的受到了策略2（強策略）的影響，而策略2覆蓋掉了策略1的效果。
策略相關性難以準確量化，可以通過策略種類、參數是否會出現增強、削弱、替代等，來判斷策略是否會存在相互影響。上面是一個典型的強策略覆蓋弱策略的例子，它會讓弱策略看起來是無效的。可見正交分層有其明顯的局限性，即便是使用了正交分層，依然無法避免相關策略間的干擾。
下麵再舉一些常見的、需要註意的場景：
- 頭條、抖音信息流，針對某特征設置不同權重的推薦算法實驗。如果使用正交分層，權重較高的策略效果很可能覆蓋權重較低的策略，得到低權重策略無效的結論
- 在百度搜索結果頁中，用戶點擊會調起百度，這是一種常見的拉活方式（如下圖）。對不同調起方式（例如點擊百度知道、點擊貼吧調起）做效果分析時，二者可能存在干擾。比如說，百度知道能夠覆蓋的關鍵詞和問題更多，極有可能每一位搜索用戶每天都會被它調起1次，而貼吧覆蓋的搜索query相對少，使用正交分層去做這個實驗（一層是點擊知道調起，另一層是點擊貼吧調起），很有可能會得到“通過貼吧調起百度App是無效的”這種結論
類似的情形，你還碰到哪些？
實驗分析需要基於實驗場景制定針對性的分析方法，更需要選擇對正確的實驗方式。當需要驗證這種相關策略的差異時，建議使用同一層來進行分組，對每個組進行策略互斥的實驗。
03 樣本比率偏差問題
實驗的樣本比例偏差問題（Sample Ratio Mismatch，SRM）指實驗組和對照組樣本比例偏離預期，所帶來的對實驗分析結論的影響。平時大家可能沒有特別關註SRM問題，但是它在很多環節都存在。有時它的差別可以忽略不計，有時卻能夠顛覆實驗結論。我們先介紹SRM問題可能帶來的影響，接著列舉可能產生SRM問題的原因，以及應對方法。
SRM問題的核心，是實驗組和對照組的實際比例和理論比例有所偏差，而分析時使用的是理論比例，這個偏差就使分析結果失真，嚴重時會得到錯誤結論。
比如，我們選取一個人群按照50%/50%的比例設計了實驗組和對照組，這時的理論樣本比例為1.0/1.0；假設實驗下發過程中因為某種原因，部分的對照組也被策略影響（或污染）到了，使得實際的樣本比例是1.05/0.95。這會造成什麼後果？
如前面實驗分析的文章所說，在分析效果時，需要以理論的樣本比例為基礎，來對比實驗組與對照組的指標之差。也就是說，沒做實驗時，這個指標差應該是0，做了實驗它會偏離0，這個偏離值大小就是實驗帶來的影響。這個例子中，便於理解不妨把實驗前各組的指標都設為100（可以不用在意是什麼），SRM問題的影響可概括如下表：
表1 SRM對實驗結果分析的影響示例：
註：有SRM-實驗組的實驗後指標為105*1.05=110.25；其中1.05是策略的提升效果
如表1所示，這個例子中SRM問題將實驗效果誇大了兩倍以上，雖然實際工作中，SRM一般不會如例子中這麼明顯，但依然需要註意。
比如，實際樣本比例是1.01/0.99，上述例子中實驗效果偏差依然可以達到41%；而實際樣本比例低至1.001/0.999，實驗效果偏差也還有0.2%左右（感興趣的同學可以自行計算）。判斷樣本偏差是否顯著，可以使用卡方檢驗；而造成SRM問題的原因很多，也可能遍及實驗各主要環節，下一小節將詳細介紹。
04 SRM問題成因和應對
SRM問題存在於實驗部署、執行、數據採集、實驗分析等主要環節，以及實驗時的外部干擾。這五個原因，來自一篇SRM論文的概括，我結合實踐經驗給出如下一些理解，如果大家對全文感興趣可以進一步細讀（文末參考文獻）。
1. 實驗部署
實驗部署階段，涉及到分層、分組的隨機算法的性能和穩定性。包含但不限於能否完成理想的正交分層，能否完成大量、實時的隨機分組，能否在一段時間後依然保持這種效率。這算是SRM問題產生的主要根源。此外，一些實時服務的Bug，也會導致分組不符合預期，實驗平臺在有重要迭代或修改後，尤其需要測試是否對分層分組產生影響。
2. 實驗執行
實驗部署完畢，下一步就需要下發策略，而下發策略需要對齊時機。假設客戶端需要給用戶展示兩套UI，這個策略需要同時對實驗組和對照組來下發，以避免下發時機不同帶來的偏差。如果實驗組下發完，再下發對照組，很可能兩個時間段網絡情況不一致、用戶活躍度有差異，引發很多不必要的變量，最終會體現到實際樣本比例的偏差上。
即使是同時下發，也需要註意避免引入“不必要的過濾條件”，比如我們經常會遇到的實驗場景，A組下發某策略、B組不下發，如果實驗具體執行時是A組下發而B組不下發，最後拿A組下發策略的用戶來和B組對比，可能引入了一個“過濾條件”。因為A組並非100%能下發成功，如果拿A中下發成功的用戶對比整個B組，可能會出錯。如果A組下發策略，B組不是不發而是下發“空策略”，那麼“下發成功”這一層過濾可以避免掉。
3. 數據採集
這裡主要關註實驗組和對照組的數據上報是否一致、是否準確，數據存取過程是否可靠。這些需要實驗平臺、策略下發平臺、用戶端產品聯動來檢查確認，並且每增加一個需要實驗的功能點、資源位，都需要確保數據上報的方式、數據質量是否能滿足未來實驗分析的要求，即數據可比性。
4. 實驗分析
分析過程中的SRM問題，類似於前面提到的不滿足“可比性”，即分析時因為一些樣本偏差被忽視，以理論的樣本比例進行分析造成的錯誤。這裡具體會涉及到分析起點問題——即選取那兩個人群進行對比，一般需要從樣本源頭來分析，保證可比性。這個問題比較寬泛，我們後面結合一些具體案例繼續討論。
5. 外部干擾
外部干擾通常來自用於實驗設計之外的不可控因素。比如AB兩套落地頁實驗，其中一套不小心被用到了其他活動，分析時，實際樣本比例就會和理論值有較大的偏差。
上面提到的造成SRM的可能原因，可以簡單的分為兩類來處理：哪些是實驗平臺需要剋服，哪些是實驗分析需要註意。表2做了簡要的梳理。
表2 主要的SRM問題原因及應對方法：
SRM問題的產生原因很多，但其最終影響到實驗分析結果時，都是通過破壞了實驗組和對照組間的“可比性”來實現，和我們之前提到的很多分析錯誤可謂殊途同歸。實驗平臺設計和實驗分析時，需要針對具體問題來找合適的應對方法。
以上是我個人理解，經驗和能力所限，難免會一些偏差或錯誤，還請指出。
參考文獻
Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners
相關閱讀
《用戶增長實驗三部曲（1）：生活中需要實驗思維》
《以抖音為案例，講清楚“用戶增長實驗”在做什麼》
《用戶增長實驗三部曲（2）：如何準確評估「產品和運營策略」的效果？ 》
作者：jinlei886；5年+用戶增長的一手經驗，前騰訊、滴滴出行用戶增長產品經理，專註增長策略挖掘、增長工具搭建、實驗設計分析。本碩博均就讀於浙江大學高分子系。微信公眾號：用戶增長實戰筆記
本文由 @jinlei886 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議