往期系列原創文章集錦：

數據分析36計(14)：A/B測試中的10個陷阱，一不注意就白做

數據分析36計(13)：中介模型利用問卷數據探究用戶心理過程，產品優化思路來源

數據分析36計(12)：做不了AB測試，如何量化評估營銷、產品改版等對業務的效果

數據分析36計(11)：如何用貝葉斯概率準確提供業務方營銷轉化率

數據分析36計(十)：Facebook開源時間序列預測算法 Prophet

數據分析36計(九)：傾向得分匹配法(PSM)量化評估效果分析

數據運營36計(八)：斷點回歸(RDD)評估產品設計效果

數據分析36計(七)：營銷增益模型(uplift model)如何識別營銷敏感用戶群-Python

數據運營36計(六)：BG/NBD概率模型預測用戶生命周期LTV-Python

數據運營36計(五)：馬爾可夫鏈對營銷渠道歸因建模，R語言實現

數據運營36計(四)：互聯網廣告渠道歸因分析之Sharply Value

數據運營36計(三)：熵權法如何確定指標權重構建評價體系

數據運營36計(二)：如何用合成控制法判斷策略實施效果

數據運營36計(一)：生存分析與用戶行為如何聯系起來

1. Netflix如何合理地縮短實驗時間

提高實驗效率能帶來很多好處：

• 在相同的時間內可以運行更多的測試了，從而增加為用戶找到更好的體驗的機會。

• 可以快速測試各個領域，以找出最佳的投資領域，為未來的創新作準備。

• 更早地結束實驗，就可以更快地為用戶帶來更多的樂趣。

當然，不可否認的是，進行一個短期的實驗也有風險：

• 通常，真正的測試時間要比根據功效分析（power analysis）所確定的最短時間長得多，這是為了緩解潛在的季節性波動（例如，一天中的時間，一周中的某天，不同周之間等等）、識別到新奇效應的影響，或考慮到某些實驗效果可能需要更長時間才能夠顯現出來。

• 假期和某些特殊事件的發生，例如新標題的發布，可能會吸引一些不具有代表性的觀眾。使得測試結果難以推廣。

• 過早地將實驗運用到實戰中（例如發生HARKing或p-hacking）可能會增加誤報率，導致努力白費。

2. 實驗設計確定最佳實驗結束時間

假設說某個實驗處理，既跟時間沒有關系（通過使用元分析評估出此結論）而且樣本也足夠大，那我們就可以應用多種不同的策略來盡早且合理的結束實驗。簡單地說，我們可以不斷地偷看實驗結果，但是有時這樣的做法會造成假陽性，這時即使實驗并沒有效果，我們可能會誤以為它有效果。此時則可以使用一些方法來防止這種偷窺中（或者用更正式的說法是：中期分析）假陽性的發生（I類錯誤）。
我們用回顧性研究評估了幾種方法，例如序貫概率比檢驗（SPRT），序貫三角檢驗，以及成組序貫實驗（GST）。在我們的研究中，GST表現最好且最具實用價值。它通常被廣泛的應用到臨床實驗中，樣本隨著時間逐漸積累增多，這非常適用于我們的案例。

它的思路大致是這樣的：

• 在測試開始之前，我們先確定所需的最短運行時間和中期分析的次數。

• 然后，GST將所有可容許的I類錯誤總數（例如0.05）分配到所有中期分析中，以使I類錯誤加和起來為I類錯誤總數。這樣，每個中期測試都比定期的peeking更為保守。

• 一旦統計學上足夠顯著，我們就可以立即停止實驗。當觀察到效果明顯大于預期時，通常就是這種情況。

下圖展示了五次中期分析下，GST的臨界值以及單獨和累積的Alpha-spending。通過這樣的策略，我們可以節省大量的實驗時間，同時能夠更早且更準確的估計出效果的臨界點。盡管說，獲得的置信區間略寬，而且效果有些許的夸大。當我們想要快速測試某個想法，而且對效果的準確性要求不高，或者當我們發現一個很嚴重的負面影響而需要提前結束測試時，這種方法最有效。

下圖展示了功效分析固定樣本大小情況下，一個成功的GST提前停止案例（FSS完全停止）。由于觀察到的效果足夠大，我們可以使用相似點估計更早地停止測試。整合決策支持的實驗平臺，現在，我們的初步研究已經完成，我們正在積極地拓展元分析，優化最佳停止時間，異質性效果檢測，以及將更多內容擴展到更大的Netflix實驗和因果推理平臺中。

3. 成組序貫實驗原理 Group?Sequential?Test

序貫檢驗是在 A/B 測試過程中通過時間順序監視累積的數據，用停止規則來作出是否繼續實驗的決定，以確保過程中的總體 I 類錯誤率不超過閥值。序貫檢驗通常使用成組序貫檢驗，使用序貫檢驗方法可以提高大約20%-80%的樣本量/實驗時間，同時控制總體?I 類錯誤率。但是該方法本身增加了計算復雜度，因為停止時間本身現在是一個隨機變量，需要在適當的統計模型中加以考慮才能得出有效結論。總體?I 類錯誤率的控制是通過 alpha-spending 函數實現的，而?II?類錯誤率的控制則是通過 beta-spending?函數實現的，這兩個函數產生兩個決策邊界，有效性邊界?（efficacy boundary）從上方限制測試統計量（z得分），無效邊界從下方限制測試統計量。即使在期中分析的數量和時間偏離了原始設計，也可以保持邊界。越過邊界之一將導致試驗終止，并決定拒絕或接受原假設。目前Netflix采用的成組序貫檢驗方法實現實驗早停。

因此這里重點關注 4 個方面：

• alpha消耗函數和beta消耗函數?alpha-spending function&beta-spending function

• 有效性邊界和無效性邊界 efficacy and futility boundary

• 停止規則 early stopping rule

• 平均樣本量?average sample size

Alpha-spending function

目的：盡早停止本身效果提升的方案測試，提前上線方案。

原理：決定每次期中分析的一類錯誤率 alpha。

從推廣性和樣本代表性的角度來看，alpha-spending function應該是凸函數的：在測試的早期階段開始緩慢消耗，然后在整個過程中更快地消耗，最后降低消耗。這樣，只有非常極端的結果才會導致測試在很短的時間內就被終止，而樣本量較小，可能會帶來一些外部有效性問題。alpha消耗函數為以下四種：

• Pocock-like

• O’Brien-Fleming-like

• Hwang-Shih-DeCani Gamma family

• Kim-DeMets power family

beta-spending function

目標：盡早停止無用方案測試，對于本身效果不好的方案，繼續測試時，不太可能產生具有統計意義的結果。

原理：決定每次期中分析的二類錯誤率 beta。

efficacy and futility boundary &?early stopping rule

efficacy boundary：使其將 I 類錯誤率 alpha 維持在指定水平之下。通常使用alpha-spending函數計算。越過邊界意味著已經越過統計顯著性閾值，因此拒絕H0。

futility boundary：使 II 類錯誤概率 β 保持在指定水平之上。通常使用Beta-spending函數計算。越過邊界意味著檢測到具有統計學意義的結果的可能性已經低于期望值，因此接受H1。

比如下圖中的綠線是由alpha-spending構成的邊界，紅線是由Beta-spending構成的邊界：

實驗Z值越過efficacy boundary：拒絕H0

實驗Z值越過futility?boundary：接受H1

Average sample size

平均樣本量是對序貫檢驗中預期樣本量的估計，在該測試中，可以執行可選的停止操作并保證錯誤率水平。

• alpha: 5%

• power: 90%

• relative lift: 10%

• baseline: 1.5%

• analyses: 12

注意：期中分析越多，maximum sample size就越大，但盡早停止的機會就越大，因此平均樣本量越小。

圖表的x軸為不同的真實效果大小（提升百分比），而y軸將為固定樣本大小的百分比。百分比越高，說明為了獲得與固定樣本量實驗相同的結論并具有相同的錯誤保證，需要一起運行測試的用戶越多，這意味著較高的百分比等同于效率較低的測試。對于提升比例越小，所需樣本量越多，efficacy boundary保證了相對提升較為明顯的測試節約樣本量，但是對于提升0%的測試，仍然需要比固定樣本多3%的樣本量。因此引入futility boundary，對于沒有明顯提升的測試也能節約樣本量。

4. 參考資料

1、成組序貫檢驗原理視頻資料：https://www.bilibili.com/video/BV1jy4y1k7eW?from=search&seid=678793497631760876

2、analytics-toolkit采用成組序貫實現早停的原理和案例?https://www.analytics-toolkit.com/glossary/sequential-testing/

3、成組序貫檢驗原理書籍：clincal trial design:bayesian and frequentist?adaptive?methods

4、序貫概率比檢驗方法原理 https://online.stat.psu.edu/stat509/node/77/

總結

以上是生活随笔為你收集整理的数据分析36计(15)：这个序贯检验方法让 A/B 实验节约一半样本量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。