A/B Testing:「偷看結果」將成為最大的錯誤

by 好豪
Published: Last Updated on

如果你身處該開始推行 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 呈現了本文探討的問題。

實驗的「預期問題」什麼?

產品在執行 A/B Testing 之前,我們會先決定這個實驗所需樣本數。現在網路上也有許多人設計方便的 計算機 可以使用,不需要統計軟體就能算出所需樣本數。當然,你不需要知道所有統計檢定的數學推導、也能運用 A/B Testing 改善產品,但是,你至少該知道「所需樣本數」背後的假設是什麼。

例如,APP 在做 A/B Testing 常見的 KPI 之一是「次日留存率」,也就是新進使用者隔日會再使用此 APP 的比例。如果 APP 目前次日留存率是 40%,團隊做了一項新設計,並期望這項新設計會讓次日留存率提高至少 1%,那麼,為此新設計做的 A/B Testing,所需樣本數 計算 會如下圖:

A/B Testing 所需樣本數,計算機範例(Source: Evan Miller

「只要 A/B 兩組都各有至少 37,719 個樣本,並且 B 組的次日留存率超過 41%,就能拒絕虛無假設,說明 B 組的設計較好。」這樣的解釋還不足夠,這段敘述忽略了假設檢定預期內會發生的問題,這些預期問題就寫在上圖計算機的下半部:

  • Statistical Power 80%:如果 A/B 兩組確實有差異,有 80% 的機率,會被統計檢定確實偵測到
  • Significance Level 5%:如果 A/B 兩組其實並沒有差異,有 5% 機率,統計檢定會因為隨機性判定成有差異(偽陽性)

如果你覺得 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 兩組母體沒有成效差異

兩條線分別是 A/B 兩組,隨著蒐集樣本數量增加、次日留存率的變化狀況。
(Source: 好豪的 Google Colab

如圖所示,這項實驗中,當我們在兩組各只蒐集 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,增加預期內偽陽性錯誤率、以換取所需樣本數下降;而不是用偷看、提早結束實驗的方式,加快實驗結束的速度、卻讓偽陽性錯誤決策增加到預期外的範圍。

註:計算機 是依照 經驗法則的公式 找出所需實驗樣本數


    \[n = 16 \frac{\sigma^2}{\delta^2}\]


    \[\sigma^2 = p \times (1 - p)\]


p: 二項式比率(KPI),例如 APP 再訪率、疫苗有效比率等等
\delta: 期望提高 KPI 多少量

結語

偷看 A/B Testing 結果的問題,除了前述在樣本蒐集緩慢的狀態下容易發生以外,我個人認為在熱血沸騰的團隊工作也很容易發生相同問題。產品設計者有過多的點子,都想透過 A/B Testing 來驗證新點子是否有成效,實驗剛上線沒多久就追著數據分析部門要結果:「看起來差異顯著了耶?可以改了嗎?可以執行下一個實驗了嗎?」

作為資料科學家、或者作為決策者,為了避免團隊的熱血因為脫韁的偽陽性錯誤、而變成徒勞無功,你必須為了團隊的產品保持耐心,做好事前的實驗設計、並且讓實驗確實遵守設計達到所需樣本數,再做決策。


參考資料:

你正在學習 A/B Testing、還想知道更多相關知識嗎?推薦你繼續閱讀我的 系列文章

如果這篇文章有幫助到你,歡迎追蹤好豪的 粉絲專頁、我會持續撰寫資料科學的知識文章;或者點選下方按鈕分享給需要的朋友們。

推薦閱讀