產品實驗設計踩雷實務分享：隨機分配好重要！

以前在做實驗分析的時候都是自己用 Flurry、Amplitude 或 Firebase Analytics 等第三方工具看資料，現在的團隊內配有資料分析師（Product/Data Analyst），早在加入前我就非常期待這個配置！心想以後再也不用面對第三方分析工具的 Metrics 限制，可以看更多不同的使用者族群（Segmentation）；也再也不會因為看到詭異的數字而不知所措（不是自己親手 Query 的還真難 Debug）

沒想到事情沒有我想像中的那麼輕而易舉。

跑 AB testing 的時候，你有檢查過實驗組和對照組的隨機分配比率（Assignment Ratio）嗎？

在我加入前不久公司有換過實驗分組的工具，而我當時還不知道我們其實是前幾組利用新工具跑實驗的團隊。而我在旋轉拍賣做的第一個實驗，是首頁的大改版，好不容易開發完成上線，小心翼翼的 Roll out 馬來西亞 30% 的實驗組，團隊歡天喜地的慶祝我們的第一個 Release 🎉

實驗跑完後我回去看 Dashboard，哇！所有的成功指標（Success Metrics）都是綠色的（代表實驗組優於對照組），於是我非常開心的跟我主管分享成果。結果他一看我們的 Dashboard 說「實驗組只有 27–29%，對照組是 71–73%，跟我們設定的 30% 不一致」，並要求我跟我的分析師一起驗證資料的正確性。

當時的我不知道事情嚴重性，想說只有一點點誤差可能還好，沒想到這件事情變成我接下來兩個月的惡夢 😂

差 2–3% 的分組結果，實驗結果有差嗎？

有欸很有差！

和工程師們一起研究之後，才發現我們用的第三方分組工具回傳分組的速度，比我們開啟首頁的速度慢，也就是所謂的延遲速度（ Latency）有點高。（我們的分組工具主要是控制功能的開關，雖然可以控制功能在哪些國家 Roll out 多少百分比等等，但並不算是專門為了做實驗而設計的平台）

這樣的結果導致更新後第一次使用、或剛下載的使用者都無法看到新功能，也就是新手用戶永遠不會進到實驗組的意思，因此我們的實驗組充滿了一天會開多次 App 的忠實用戶，再也不是隨機分配。

這是一種蠻嚴重的選擇性偏差（Selection bias），畢竟如果實驗組的人本來就是愛用者，那實驗結果自然好棒棒！

註：我們也有去檢驗各個國家這個誤差在統計上是否顯著，結論是以當時流量來說，就算是 2–3% 也是「顯著錯誤」的分組。

我們如何驗證與調整這樣的分組誤差？

老實說這是一場蠻痛苦的過程，我們先再度確認問題的來源，工程師會是你 debug 的好朋友，可以去驗證下面兩個問題是否存在：

(1) 驗證追蹤事件（ Event tracking）的正確性，確定不是追蹤的問題 (2) 驗證延遲（Latency）的問題，找來我們的 Platform engineer 跟我們一起 debug，跟第三方平台也 con-call 無數次

確定問題的同時，我們開始想辦法讓資料變得可用，資料分析師會是你修復報告的好朋友，以下有幾個方法可以參考：

(3) 從資料中移除新手用戶，讓分組正確（不過這樣就無法得知新首頁在新手用戶身上的影響） (4) 等到 App 收到第三方平台回傳的分組資訊後，才開啟首頁（不過這樣又有風險，如果第三方工具掛了我們也掛了，後來只上線一下下又 Roll back）

但老實說，上面方法都不甚理想，只是 workaround 而已。最理想的解法還是不要依賴第三方工具，自己利用後端程式做分組。讓實驗一開始就得到正確的隨機分配才是正途。

過程中真的非常感謝我的團隊，特別是我的產品分析師 Kim，還有公司其他團隊像是 Platform Engineerng 的支援，才可以慢慢讓整件事情水落石出。雖然過程很艱辛，時間的消耗也拖累蠻多進度，但也因為這個事件，我開始更注重實驗資料的正確性，也累積了很多相關知識，算是個不錯的學習！

同場加映：之前在讀 Designing with Data 這本書的時候，有提到有團隊會做 AA Testing 去驗證實驗的正確性（AA Testing 顧名思義就是放兩組一模一樣的組別，因為功能都一樣，所以實驗結果不應該有顯著差別）有興趣的人也可以在自己的專案中嘗試看看唷。

謝謝你的閱讀！如果有任何疑問、想聽的主題也歡迎留下 Private Note 或留言給我 📒

如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多產品實驗相關的文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我知道 👏🏻

想要持續追蹤我們的最新文章，請追蹤產品三眼怪實驗室 (◉◉◉)
每週六下午三點，準時發文！