黃金占卜：這輩子如果會大發財，錢從哪來？
現在請靜下心來，在下列黃金塔羅牌中憑直覺選出一張，老師要幫你分析，這輩子如果你會大發財，錢財會從哪裡來？記得請朋友、閨蜜一起來測試，看看未來自己很有可能因為何事而發財，朝著心願前進！💰💰💰
A、羽毛筆下的金幣
B、面具和手捧著金幣
C、沙漏與黃金樹
D、天秤與金幣
。
。
。
。
。
選
好
看
答
案
。
。
。
。
。
👑答案A、羽毛筆下的金幣
選中這張牌的朋友，科學家富蘭克林曾說過，「勤奮是幸運之母」，這句名言正套用在你身上。你是一個工作相當勤奮、努力的人，不僅上班工作十分認真，下班後也勤於四處進修，有別於其他人在休閒玩樂，你卻選擇於此時繼續打拚上進，堅忍不拔的性格，使你在面對困難時不願輕易低頭，最終獲得幸運之母的眷顧，將你辛苦付出的心力換成錢財回報給你，靠努力發大財肯定是有機會成真的！只要肯真心打拚、努力不懈、永不放棄，加上保有一顆善良的心，幸運財神會隨時在你身邊。
👑答案B、面具和手捧著金幣
選中這張牌的朋友，這輩子你很有可能仰靠親戚、長輩的祖業大發財喔！由於你上輩子做了不少好事，加上此生也經常行善積德，且不求回報，讓你這一生為自己增加不少福報，自然能給你帶來衣食無憂的好日子。受到親戚家人的恩賜，使你有幸能承襲祖業與祖產，不用在外地過於辛苦的工作，已有人幫你打好事業根基，只需要接過手努力經營、腳踏實地的做，心地要向善，不枉費給予者一片苦心和期待，自然比別人能更快有一番成績，讓人生邁向發財之路。
👑答案C、沙漏與黃金樹
選中這張牌的朋友，你自身為人古道熱腸，慈善義舉一向不落人後，一生中做了不少助人好事，不管在職場上、生活中，只要看到有需要幫忙的人，會二話不說地立即給予幫助，不僅得到心靈上的富足，也使幸運之神找上你，讓你在冥冥之中獲得不少好運氣，所謂行善總會有回報，而你也靠著做許多好事、秉持善心，「錢途」獲得一片光明，加上你天生樂觀，每件事幾乎都往好的地方想，樂觀、正面思考的人運氣總是特別好，自然能在這輩子富貴好命、不愁吃穿。
👑答案D、天秤與金幣
選中這張牌的朋友，未來你很有可能受到貴人指點，而有發大財的機會喔！由於你本身是一個剛正不阿、不循私逢迎的人，加上擁有一副好心腸，讓生活周遭的貴人不知不覺地被你所吸引，願意在你需要幫忙時立即伸出援手、出面相挺，且也十分給力為你的事業大大地推一把，將事業層次推上高峰，自然錢財也就源源不絕地跑進口袋內。面對大發財的自己從不忘本，沒有忘記過曾經給予幫助、指點的貴人，懂得感恩的個性，讓你的財運更加順暢，財富也累積更多。
a b 測試 為何 在 [心得] A/B Testing 常見的「偷看結果」問題- 看板DataScience 的美食出口停車場
[關鍵字]: 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，所需
樣本數計算會如下圖：
「只要 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 兩組母體沒有成效差異。
兩條線分別是 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
然後帶著假設去按文中的計算機決定樣本數
至於要多久時間, 就看你實際收樣本的速度了
可是如果你偷看又不會做決策... 何必偷看？
※ 編輯: AgileSeptor (60.250.32.97 臺灣), 09/03/2020 10:51:30
... <看更多>