數位實驗團隊依賴 A/B 測試來針對使用者介面設計、結帳流程以及功能發布做出基於證據的決策。然而，要確定基準版本（Baseline）與變體版本（Variation）之間觀察到的差異究竟代表真實的業務提升，還是僅僅由隨機統計噪聲引起，需要嚴謹的數學方法論支撐。Optimizely 透過其專有的 Stats Engine 解決了這一挑戰。Stats Engine 推動了 Web 實驗的現代化，從傳統的固定樣本量（Fixed-Horizon）假設檢驗轉向基於**混合序貫概率比檢驗（mixture Sequential Probability Ratio Test, mSPRT）**的序貫檢驗架構。該架構允許產品經理和增長行銷人員在不膨脹假陽性率的前提下持續監控實驗結果，同時提供了一套整合架構，用於在規劃階段估算樣本量需求並在運行階段即時評估統計顯著性。
傳統檢驗的缺陷：「窺探」問題（Peeking Problem）
要理解 Optimizely 如何計算統計顯著性，首先必須認識到傳統頻率學派統計檢驗（例如標準學生 t 檢驗或雙比例 z 檢驗）在應用於 Web 實驗時的根本脆弱性。
在傳統的固定樣本量測試中，實驗人員需根據統計功效（Statistical Power）、顯著性水準（Significance Level）以及最小可檢測效應（Minimum Detectable Effect, MDE）預先計算好樣本量。經典假設檢驗在數學上的嚴謹性取決於一條嚴格的操作規則：數據只能在達到預定樣本量的時刻評估一次。
在實際業務中，數位團隊極少能遵守這一限制。產品經理、設計師和工程師往往每天甚至每小時查看實驗看板以監控表現。當團隊反覆查看結果，並在某個變體剛剛顯示出統計顯著性時便機會主義地終止實驗（這通常被稱為「窺探」或數據窺探，Peeking / Data Snooping），真實的假陽性率（第一類錯誤，Type I error）將會急劇膨脹。
| 測試期間窺探次數 | 名義顯著性水準 ($\alpha$) | 實際假陽性率 |
|---|---|---|
| 1 次（僅在結束時評估） | 5%（95% 信賴度） | ~5.0% |
| 5 次窺探 | 5%（95% 信賴度） | ~14.2% |
| 10 次窺探 | 5%（95% 信賴度） | ~19.3% |
| 50 次窺探 | 5%（95% 信賴度） | ~32.0% |
| 持續即時監控 | 5%（95% 信賴度） | > 50.0% |
由於正常的網路流量存在隨機波動，任何指標在純粹的機率作用下都可能偶爾擺動進入「統計顯著」區間。在經典檢驗體系下，在轉瞬即逝的峰值處停止實驗，必然導致大量被判定為「勝出」的變體在全量上線後無法復現效果，從而侵蝕商業收入並損害組織對實驗文化的信任。
Optimizely 如何即時計算統計顯著性
為了根除窺探問題，Optimizely 與史丹佛大學的研究人員（Leonid Pekelis、David Walsh 和 Ramesh Johari）合作開發了 Stats Engine。Stats Engine 的數學基石正是混合序貫概率比檢驗（mSPRT）。
1. 混合序貫概率比檢驗（mSPRT）
與傳統的沃爾德序貫概率比檢驗（Wald SPRT）針對單一固定對立效應大小檢驗簡單虛無假設不同，mSPRT 檢驗的是虛無假設與可能存在的非零效應大小的連續機率分佈混合體之間的關係。
在 Web 實驗中，真實的提升參數 $\theta$（變體與基準版本之間轉換率的真實差異）在實驗運行前是未知的。mSPRT 在觀察到 $n$ 個訪客後計算混合似然比 $\Lambda_n$：
$$\Lambda_n = \int \frac{\prod_{i=1}^n f(X_i; \theta)}{\prod_{i=1}^n f(X_i; 0)} dH(\theta)$$
在此公式中：
- $f(X_i; 0)$ 是虛無假設下的機率密度或機率質量函數（無效應，$\theta = 0$）。
- $f(X_i; \theta)$ 是在對立效應量 $\theta$ 下的機率密度函數。
- $H(\theta)$ 是混合分佈（通常選取以 0 為中心的正態分佈，其方差根據典型 Web 實驗效應大小進行校準）。
透過對所有合理的 $\theta$ 取值進行積分，檢驗統計量 $\Lambda_n$ 在虛無假設下構成一個期望值為 1 的非負鞅（Martingale）。
2. 始終有效 P 值（Always-Valid P-Values）
應用鞅機率論中的基礎結論——維爾不等式（Ville's inequality），可以得出 $\Lambda_n$ 超過給定閾值機率的嚴格上界：
$$P(\sup_{n \ge 1} \Lambda_n \ge \frac{1}{\alpha}) \le \alpha$$
基於這一界限，Optimizely 在任意樣本步驟 $n$ 處計算始終有效 p 值 $p_n$：
$$p_n = \min \left( 1, \frac{1}{\sup_{k \le n} \Lambda_k} \right)$$
這種數學性質保證了無論團隊查看看板多少次，或者在哪個停止時間 $\tau$ 決定終止實驗，整體的第一類錯誤率始終被嚴格限制在 $\alpha$ 以內：
$$P(\text{在虛無假設 } H_0 \text{ 成立時在任意時間點拒絕 } H_0) \le \alpha$$
如果團隊將信賴度閾值設定為 95%（$\alpha = 0.05$），那麼即使連續幾個月每分鐘監控一次實驗，該實驗將中性變體錯誤判定為勝出者的機率最高也只有 5%。
3. 動態信賴區間（Dynamic Confidence Intervals）
Optimizely 不僅展示單一的 p 值，還會為每個變體所帶來的相對提升（Lift）展示始終有效信賴區間。
- 初期階段： 當訪客數量較少時，信賴區間較寬且相對保守，反映了初期數據的高方差。即使某個變體在前 50 名訪客中轉換率暫時達到基準版本的兩倍，信賴區間依然足夠寬並包含零點，從而防止過早下定結論。
- 數據積累階段： 隨著樣本量擴大，混合似然比不斷積累證據，信賴區間逐漸圍繞真實效應量收窄。
- 宣布勝出 / 敗出： 一旦信賴區間完全脫離零點（即正向提升的下界高於 0%，或負向效應的上界低於 0%），Optimizely 就會在確切的時刻將該變體標記為具有統計顯著性（確認為勝出者或失敗者）。
處理多重比較：錯誤發現率（FDR）控制
在複雜的數位實驗中，團隊很少只針對一個轉換目標測試單個變體。現代實驗通常包含：
- 多個測試變體（A/B/C/D 測試）。
- 多個追蹤的轉換指標（例如點擊量、加入購物車、完成結帳和頁面留存）。
- 細分受眾群體分析（例如行動端 vs. 桌面端，或新使用者 vs. 回訪使用者）。
同時運行多個統計檢驗會引發多重性問題（Multiplicity Problem）。如果一個實驗在 95% 信賴水準下追蹤 10 個獨立的二級指標，那麼僅憑機率導致至少一個指標出現假陽性的累計機率會上升至 40% 以上（$1 - (1 - 0.05)^{10} \approx 40.1%$）。
為了防止團隊追逐虛假的次要指標，Optimizely 將錯誤發現率（False Discovery Rate, FDR）控制直接整合到了 Stats Engine 中。
Stats Engine 中的 Benjamini-Hochberg 架構
Optimizely 沒有採用像 Bonferroni 校正那樣過於嚴苛的族錯誤率（FWER）調整——這種調整會嚴重削弱統計功效並需要極大的流量——而是採用基於 Benjamini-Hochberg 流程改進的演算法來控制錯誤發現率：
- 排序排列： 實驗中跨所有變體和指標的所有活躍假設檢驗按其報告的 p 值進行升序排列：$p_{(1)} \le p_{(2)} \le \dots \le p_{(m)}$。
- 自適應顯著性閾值： 每個檢驗根據其排序位置縮放後的閾值進行評估：$p_{(k)} \le \frac{k}{m} \cdot \alpha$。
- 發現率保證： 透過動態調整報告的 p 值和信賴區間，Optimizely 確保在實驗聲明的所有顯著結果中，錯誤發現的預期比例不超過 $\alpha$（通常為 5%）。
這種自動化的多重性控制使團隊能夠追蹤廣泛的二級護欄指標組合，而無需手動計算繁瑣的統計懲罰。
計算樣本量需求：規劃階段 vs. 執行階段
數位產品團隊經常產生困惑的一點是：樣本量需求在 Optimizely 中究竟扮演什麼角色。由於 Stats Engine 支援持續監控和安全的手動提前終止，實驗在技術上並不需要達到死板的樣本量才能結束。然而，估算樣本量需求對於實驗規劃、流量預算和路線圖優先級排序仍然至關重要。
Optimizely 樣本量計算器的核心輸入參數
在啟動實驗之前，團隊可以使用 Optimizely Sample Size Calculator 預測每個變體所需的訪客數。計算器需要四個核心統計參數：
- 基準轉換率（Baseline Conversion Rate, $p_0$）： 目標頁面上主要指標的當前歷史轉換表現（例如 3.0% 的結帳轉換率）。
- 最小可檢測效應（Minimum Detectable Effect, MDE, $r$）： 團隊希望可靠檢測到的最小相對百分比提升。例如，如果基準轉換率為 3.0%，團隊希望檢測出大於或等於 0.3 個百分點的提升，則相對 MDE 為 $10%$（$0.3 / 3.0 = 0.10$）。
- 統計顯著性水準（Statistical Significance Level, $1 - \alpha$）： 宣布結果顯著所需的信賴度閾值（預設為 95%，對應 $\alpha = 0.05$）。
- 統計功效（Statistical Power, $1 - \beta$）： 當真實存在 MDE 幅度的差異時，實驗能夠成功檢測出該差異的機率（行業通用標準將統計功效設為 80%，對應 $\beta = 0.20$）。
參數之間的數學關係
在經典雙樣本二項分佈檢驗中，每個變體所需的樣本量 $N$ 與絕對效應量的平方成反比：
$$N \approx \frac{2 \left( Z_{\alpha/2} + Z_{\beta} \right)^2 \cdot p_0(1 - p_0)}{(p_0 \cdot \text{MDE})^2}$$
其中：
- $Z_{\alpha/2}$ 是顯著性水準對應的標準正態臨界值（雙側 95% 檢驗為 1.96）。
- $Z_{\beta}$ 是統計功效對應的臨界值（80% 功效為 0.84）。
在 Optimizely 的序貫檢驗架構下，得出決策所需的期望樣本量（$E[N]$）動態取決於真實的潛在提升幅度：
- 當真實提升等於 MDE 時： 序貫檢驗所需的期望樣本量與固定樣本量檢驗大致相當或略高，以保證對微小變體具有 80% 的統計功效。
- 當真實提升遠超 MDE 時： 序貫檢驗會迅速積累證據並提前終止——通常比傳統固定樣本量測試減少 30% 到 70% 的訪客需求。
- 當真實提升為零時： 實驗將持續運行，直至團隊觸碰其實際停止規則，而不會錯誤觸發假陽性。
樣本量參考矩陣（80% 統計功效，95% 顯著性水準）
下表展示了常見基準轉換率與不同相對 MDE 下，每個變體預計所需的訪客規模：
| 基準轉換率 ($p_0$) | 相對 MDE: $\pm 5%$ | 相對 MDE: $\pm 10%$ | 相對 MDE: $\pm 20%$ | 相對 MDE: $\pm 30%$ |
|---|---|---|---|---|
| 1.0% | 約 1,220,000 訪客 | 約 305,000 訪客 | 約 77,000 訪客 | 約 34,000 訪客 |
| 3.0% | 約 400,000 訪客 | 約 100,000 訪客 | 約 25,000 訪客 | 約 11,000 訪客 |
| 5.0% | 約 235,000 訪客 | 約 59,000 訪客 | 約 15,000 訪客 | 約 6,500 訪客 |
| 10.0% | 約 110,000 訪客 | 約 28,000 訪客 | 約 7,000 訪客 | 約 3,100 訪客 |
這種反向平方縮放關係解釋了為什麼在低轉換率頁面上測試微小提升（例如 2% 或 5%）需要數百萬訪客，而預期產生更高業務影響的顛覆性設計則可以用顯著更小的樣本規模完成驗證。
Optimizely 的防線機制與實用決策規則
雖然序貫檢驗提供了抵抗隨機波動的數學防護，但現實中的網路流量仍受操作偏差、數據同步延遲和人類行為週期模式的影響。Optimizely 實施了多項實用防護機制以確保決策可靠性。
1. 顯著性判定的硬性最低閾值
即便數學公式在實驗早期指示達到了顯著性，Optimizely 也不會過早宣布統計顯著，直到實驗滿足最低實證數據門檻：
- 二項 / 轉換指標： 每個變體必須記錄至少 100 名獨立訪客，並且必須有至少 25 次轉換。
- 連續 / 數值型指標（例如收入、訂單金額）： 每個變體必須記錄至少 100 名獨立訪客。
這些最低門檻可防止孤立的異常事件（例如內部測試人員的意外採購或自動爬蟲突發流量）在標準分佈生效前扭曲分析結論。
2. 商業週期規則（Business Cycle Rule）
常見的營運失誤是在測試運行到第 3 天、Stats Engine 剛剛亮起綠色的「勝出」徽章時便立即叫停實驗。使用者行為在一週內的不同日期存在顯著差異：
- B2B 軟體採購行為在週二至週四達到高峰。
- 電子商務流量通常在週末激增，且瀏覽模式和購買轉換速度截然不同。
- 早期訪客可能會表現出新奇效應（Novelty Effect），僅僅因為某些新 UI 元素看起來不熟悉而產生點擊。
即便 Optimizely 在 48 小時內判定了統計顯著性，實驗團隊也應堅持至少運行 一到兩個完整商業週期（7 到 14 個完整日曆日） 的操作規範。這確保了觀察到的效應在時間週期和代表性客戶群體中具有持續性。
3. 利用 Stats Accelerator 進行流量最佳化
對於以最大化測試期間轉換為商業目標、而非純粹科學衡量的敏捷最佳化場景，Optimizely 提供了 Stats Accelerator。
Stats Accelerator 將序貫檢驗與**多臂老虎機（Multi-Armed Bandit, MAB）**演算法相結合。在整個實驗生命週期中，它不再保持生硬的 50/50 靜態流量劃分，而是：
- 即時評估新流入的表現數據。
- 動態將更大比例的流量分配給表現頂尖的勝出變體。
- 向表現欠佳的變體分配維持驗證所需的最低流量，以確認其確實屬於敗出版本。
透過將訪客集中在表現出色的體驗上，Stats Accelerator 不僅能更快達到統計顯著性，同時大幅減少了讓使用者暴露於次優方案所造成的機會成本。
固定樣本量模式 vs. Stats Engine：選型對比
雖然 Stats Engine 是 Optimizely 針對 Web 實驗推薦的預設分析架構，但 Optimizely 也在專案配置中提供了**頻率學派固定樣本量（Frequentist / Fixed Horizon）**測試模式。理解何時使用何種模型是企業數據治理的關鍵環節。
| 功能 / 考量維度 | Stats Engine（序貫檢驗） | 頻率學派（固定樣本量） |
|---|---|---|
| 統計學理論基礎 | 混合 SPRT 與維爾鞅不等式 | 經典雙樣本 z 檢驗 / t 檢驗 |
| 持續監控支援 | 完全支援。 P 值與信賴區間始終有效。 | 嚴禁窺探。 中途窺探會導致錯誤率失控。 |
| 終止規則 | 靈活。一旦達到顯著性即可終止，或運行至最大預算。 | 嚴格。必須嚴格運行至預定樣本量收集完畢。 |
| 多重性調整 | 跨目標與變體自動進行錯誤發現率（FDR）控制。 | 需要手動進行 Bonferroni 或 Šidák 調整。 |
| 平均決策耗時 | 在高影響變體上更快。 若提升明顯可大幅提前終止。 | 固定。始終需要運行完整的預估時長。 |
| 最佳適用場景 | 增長行銷、UI 最佳化、敏捷產品探索及快節奏 Web 實驗。 | 受監管的醫藥 / 臨床試驗、嚴苛學術合規或審計政策僵化的團隊。 |
數位團隊分步落地流程
為了使用 Optimizely 建立可複用且數學嚴謹的實驗流程，團隊應遵循由四個階段組成的標準工作流：
第 1 步：實驗前規模估算與可行性分析
- 提取基準數據： 獲取過去 30 天內目標 URL 及細分受眾群體主要指標的歷史基準轉換率（$p_0$）。
- 確定合理的 MDE： 根據團隊交付能力和商業目標設定最小可檢測效應。除非頁面月獨立訪客達到數百萬，否則切忌設定過小的 MDE（如 1%）。
- 計算目標樣本量： 將基準轉換率、MDE 與 95% 信賴度輸入 Optimizely Sample Size Calculator。
- 評估運行週期： 將所需總樣本量除以日均獨立訪客數。如果所需測試時間超過 4 至 6 週，說明實驗統計功效不足；應重新設計實驗，聚焦於更高影響力的干預手段或漏斗上游指標。
第 2 步：在 Optimizely 中配置實驗
- 確定核心指標： 指定一個唯一的決策核心指標（例如成功交易或帳戶註冊）。
- 設置護欄指標： 添加二級指標（例如跳出率、頁面載入時間及工單提交量）以監控意外副作用。
- 確認統計模型： 確保在專案設定中啟用了 Stats Engine（預設開啟），並確認已為多變體實驗啟動 FDR 控制。
第 3 步：實驗執行與過程監控
- 檢查樣本比例失配（SRM）： 檢查對照組與各變體之間的訪客流量分佈。如果訪客比例出現統計顯著失配，表明存在埋點失效、重新導向缺陷或投遞錯誤，這會直接導致實驗數學失效。
- 監控信賴區間： 觀察始終有效的信賴區間隨時間推移收窄的過程。切勿因初期數據的波動而過早恐慌。
- 遵循週期時長： 切勿在測試未滿 7 個完整日曆日之前關閉實驗，即便 Optimizely 在第 2 天便給出了勝出提示。
第 4 步：決策制定與後續推廣
- 驗證顯著性： 確認核心指標已實現統計顯著，且信賴區間已清晰完全脫離零點。
- 審查護欄表現： 審查受 FDR 控制的二級指標，確保核心轉換目標的增長沒有以犧牲平均客單價或頁面效能為代價。
- 歸檔與全量上線： 在 Optimizely 中將實驗歸檔，並將勝出代碼直接硬編碼部署至生產環境代碼庫，以消除標籤管理器帶來的效能延遲。對於在達到預定樣本窗口後仍未達到顯著性的實驗，記錄分析洞察並下調中性迭代方案的優先級。
透過將序貫檢驗的數學嚴密性與嚴謹的營運規範相結合，產品團隊既能保持敏捷迭代與高頻測試，又能做出具備堅實統計學證據支撐的商業決策。