[心得] A/B Testing 常見的「偷看結果」問題

看板DataScience作者AgileSeptor (S.Duncan_JB)時間3年前 (2020/08/22 19:26)推噓11(11推 0噓 5→)

留言16則, 12人參與討論串1/2 (看更多)

[關鍵字]: A/B Testing [重點摘要]: - A/B Testing 的正確做法，是預先決定實驗樣本數，並禁止偷看結果、甚至提前結束實驗 - 偷看結果會使偽陽性錯誤率（Type-1 Error）上升 - 在嚴重的狀況，會讓你手中看似有統計顯著性的決策， 20% 以上是錯誤的最近在工作中發現團隊會對 A/B Testing 的統計檢定有些迷思常會因為檢驗出現統計顯著性就想提早結束實驗因此整理成一篇文章，與大家一起探討這樣會有什麼問題我也在文章內附上 Google Colab 的 Python 程式碼，透過實作來呈現問題網誌好讀版： https://haosquare.com/ab-testing-peeking/ # A/B Testing：「偷看結果」將成為最大的錯誤如果你身處該開始推行 A/B Testing 的團隊，相信你曾遇到過這樣的情境：「我們的產品隔日回訪率一般是 40%，我看了數據，現在執行的 A/B Testing，B 組的新設計讓回訪率提升到 42% 了，我們立刻讓所有使用者採用 B 組設計吧！」會議中，同事興奮地提出這項建議，大家也紛紛同意。「原本不是設定 A/B Testing 要執行一週嗎？現在才執行兩天、樣本數總共才蒐集兩萬人而已，要等一週資料蒐集完整才能做決策吧？」有人提出疑惑。「可是 A/B 組的 KPI 差異有統計顯著性啊！就決定讓產品改用新設計的 B 組吧！」主管看完數據就這麼做出決議。乍看之下，只要通過統計顯著性的檢驗，就應該是有科學方法的嚴謹決策。然而，這個 A/ B Testing 情境的問題，是在實驗樣本蒐集完整之前「偷看結果」。偷看結果最嚴重的下場，是讓你手中看似有統計顯著性的決策，20% 以上是錯誤的。這篇筆記將說明為何會有此問題、以及如何避免。如果你喜歡寫 Code 實作，我在 Google Colab 也用 Python 呈現了本文探討的問題。 https://reurl.cc/yggaNa ## 實驗的「預期問題」什麼？產品在執行 A/B Testing 之前，我們會先決定這個實驗所需樣本數。現在網路上也有許多人設計方便的計算機可以使用，不需要統計軟體就能算出所需樣本數。當然，你不需要知道所有統計檢定的數學推導、也能運用 A/B Testing 改善產品，但是，你至少該知道「所需樣本數」背後的假設是什麼。例如，APP 在做 A/B Testing 常見的 KPI 之一是「次日留存率」，也就是新進使用者隔日會再使用此 APP 的比例。如果 APP 目前次日留存率是 40%，團隊做了一項新設計，並期望這項新設計會讓次日留存率提高至少 1%，那麼，為此新設計做的 A/B Testing，所需樣本數計算會如下圖： https://i.imgur.com/u0FktsW.png

「只要 A/B 兩組都各有至少 37,719 個樣本，並且 B 組的次日留存率超過 41%，就能拒絕虛無假設，說明 B 組的設計較好。」這樣的解釋還不足夠，這段敘述忽略了假設檢定預期內會發生的問題，這些預期問題就寫在上圖計算機的下半部： - Statistical Power 80%：如果 A/B 兩組確實有差異，有 80% 的機率，會被統計檢定確實偵測到 - Significance Level 5%：如果 A/B 兩組其實並沒有差異，有 5% 機率，統計檢定會因為隨機性判定成有差異（偽陽性）換句話說，設定 Significance Level 為 5%，用正確的方法持續做多次 A/B Testing 實驗，每 100 次拒絕虛無假設、並決定採用實驗組（ B 組）新設計的狀況，預期約有 5 次會是錯誤的（明明 B 組沒有更好我們還是改採用它）。如果你是決策者，你當然可以覺得 5% 的偽陽性錯誤率風險太高。以此例而言，同樣是現有次日留存率 40%、期望 B 組提高 1%，如果你想要更保守點，把上圖計算機最下方的 Significance Level 從 5% 改成 1%，你就可以讓 A/B Testing 預期內的偽陽性錯誤率（ Type-1 Error）下降到 1%，並看到計算機告訴你，為了讓統計信心提高，你需要增加更多所需樣本數。比起 Statistical Power，對 Significance Level 討論較多，是因為偽陽性錯誤造成的成本較高。以疫苗研發為例，如果檢驗出現偽陽性錯誤，表示明明沒有成效、卻生產千萬支疫苗給全台灣人民使用，這會是多大的浪費！在 Significance Level 的假設下，統計檢定控制了對偽陽性錯誤的預期，但是在 A/B Testing 的情境中，如果決策者偷看了實驗結果，這項控制將失效、偽陽性錯誤率大大提高。 ## 「偷看」的問題在前面段落提及範例：APP 目前次日留存率是 40%、期望的留存率差異是 1%，需要每組至少 37,719 個樣本。下圖是據此設計、實際商業決策會遇到的 A/B Testing 偷看情境：我們預先設定每組總共要蒐集 40,000 個樣本，但是每蒐集 10,000 個樣本我們就偷看一下結果。然而，此情境刻意設計 A/B 兩組母體沒有成效差異。 https://i.imgur.com/3QB5737.png

兩條線分別是 A/B 兩組，隨著蒐集樣本數量增加、次日留存率的變化狀況。如圖所示，這項實驗中，當我們在兩組各只蒐集 10,000 個樣本就急著偷看結果： - 兩組 KPI 分別是 41.2% 與 39.5% - 做了卡方檢定也觀察到顯著性（P-value < 0.05）如果在此就決定 B 組較好並採用，會做出明明 A/B 兩組沒有差異、卻仍改採用實驗組的錯誤決策。也就是說，偷看 A/B Testing 結果提高了偽陽性錯誤率。如果乖乖等到蒐集完預先設定的 40,000 樣本數，並不代表決策者可以完美避免掉偽陽性錯誤，而是可以把偽陽性錯誤率控制在預期內的 5%。若偷看結果、並提早結束 A/B Testing，偽陽性錯誤將會大於 5%，而且偷看越是猴急、錯誤率會越高。 ### 越急著偷看、問題越嚴重實際寫 Python Code (見參考資料) 設計實驗、觀察偷看頻率的差異，在 A/B 兩組實際上並沒有成效差異（也就是 A/A Testing）的狀況下： - 每累積 33.3%（三分之一）所需樣本數偷看一次，若有顯著差異就提前結束實驗，偽陽性決策錯誤率還低於 10% - 更猴急點，每累積 5% 所需樣本數就偷看一次，若有顯著差異就提前結束實驗，偽陽性決策錯誤率會超過 20%！也就是說，如果允許無限制偷看 A/B Testing 結果，那你所做出的改變、並且自以為會讓產品更好的決策，至少 20% 是錯誤的！這並不是一個誇張的情境，實驗者樣本蒐集速度緩慢的時候，更容易失去耐心而步入這項錯誤。40,000 所需樣本數的 5% — 也就是每組各 2,000 人，當你是剛起步、或者仍在測試階段的 APP 設計者，要蒐集 2,000 人樣本可能需要半個月時間，會害你覺得 A/B Testing 進度太慢，就想急著做統計檢定、下結論。 ## 正確做法：預先決定實驗樣本數，並禁止偷看解釋了這麼多，都是為了呈現問題的嚴重性，而要解決這個問題也不難：事先決定好實驗所需樣本數，並且數據分析師要把關 A/B Testing 流程，未達所需樣本數、不可偷看結果也不可貿然決策。 A/B Testing 所需樣本數，來自團隊共同決定出的要素： - 數據分析師提出現有 KPI 為何 - 團隊討論出期望提高 KPI 達到多少量，才值得做出決策、並改變產品 - 統計檢定需要多少信心、可容許多少偽陽性錯誤率 A/B Testing 完整蒐集所需樣本數才做檢定，這些團隊共同決定、對實驗假設的共識才有意義。就算樣本蒐集緩慢，可以考慮提高 Significance Level，增加預期內偽陽性錯誤率、以換取所需樣本數下降；而不是用偷看、提早結束實驗的方式，加快實驗結束的速度、卻讓偽陽性錯誤決策增加到預期外的範圍。註：上述計算機是依照經驗法則的公式找出所需實驗樣本數 https://www.evanmiller.org/how-not-to-run-an-ab-test.html ## 結語偷看 A/B Testing 結果的問題，除了前述在樣本蒐集緩慢的狀態下容易發生以外，我個人認為在熱血沸騰的團隊工作也很容易發生相同問題。產品設計者有過多的點子，都想透過 A/B Testing 來驗證新點子是否有成效，實驗剛上線沒多久就追著數據分析部門要結果：「看起來差異顯著了耶？可以改了嗎？可以執行下一個實驗了嗎？」作為資料科學家、或者作為決策者，為了避免團隊的熱血因為脫韁的偽陽性錯誤、而變成徒勞無功，你必須為了團隊的產品保持耐心，做好事前的實驗設計、並且讓實驗確實遵守設計達到所需樣本數，再做決策。參考資料： - Evan Miller: How Not To Run an A/B Test - https://www.evanmiller.org/how-not-to-run-an-ab-test.html - 好豪的 Google Colab: A/B Testing 問題 Python 實作 - https://reurl.cc/yggaNa -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.12.23.135 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/DataScience/M.1598095615.A.678.html

推

st1009

08/22 22:32, 3年前 , 1^F

08/22 22:32, 1^F

推

art1

08/22 22:54, 3年前 , 2^F

08/22 22:54, 2^F

推

blackmaninEE

08/23 01:24, 3年前 , 3^F

08/23 01:24, 3^F