A/B 测试流量分割：小流量网站的统计正确性

摘要：小流量站點卡住的不是訪客量，而是你在監控過程中願意接受的假陽性率。先把分流做對，再把可檢測效應當預算算清楚，最後選一個不怕被看的方法。

關鍵要點

邊跑邊看，5% 會變成 30%。 用固定樣本方法做連續監控，假陽性率最高放大六倍。
每臂 50 個訪客是地板，不是目標。 低於這個量，"贏家"多半是頭兩天的噪音。
最小可檢測效應要在開測前算，不是事後發現。 小站現實可檢測的相對提升是 20% 到 30%，再小就得換工具。
按用戶分，不按會話分。 會話級分流會把同一個人漏進兩組，把效應悄悄抵消掉。
同一份資料，兩種結論。 p 值 0.061 和貝葉斯 96.9% 可以描述同一場 8,000 訪客的測試。

一、真正的約束是假陽性率

小流量團隊通常把問題描述成"我們訪客不夠"。這個描述會導出錯誤的解法——把測試拖得更長，或者更糟，等一個永遠不會來的 p 值。真正卡住你的是測試在跑的那段時間里，你願意承受的誤差率。

固定樣本方法里，5% 的 alpha 只有在"你只看一次、且樣本量就是規劃的那個數"時才成立。每天早上去看面板、看著好了就停，有效假陽性率會往 30% 爬。針對這種連續監控的研究給出的就是這個結論：名義 5%，在每天看、顯著就停的操作下最高到 30%。也就是說，近三分之一的"贏家"是假陽性。

對一個每月 200 次轉化的站，這個算術是致命的。一季度三個假贏家，意味著路線圖被噪音牽著走；損失不只在統計上——是那個季度被用來做錯的東西，以及本來該上線真改進卻沒上線的復利損失。

更遠一層的影響很少被計價：一個假贏家燒掉的不只是它自己的開發時間。它會變成新基線，下一場測試繼承了一個從來沒起作用的改動，損失在一個季度里悄悄疊加。這就是誤差率比樣本量更要緊的原因——一個壞決定污染整條序列，而慢一點但誠實的測試只花時間。

二、分流做對，有效性就贏了一半

在任何統計選擇之前，分配機制本身必須站得住。小流量測試失效，絕大多數來自四種分流問題：

分流設計	壞了什麼	修法
按會話隨機	同一個人在手機和電腦上被分到兩組	按用戶或賬號 id 哈希
按時間順序（先 A 兩周再 B）	季節性、促銷、發薪日週期混進來	並行跑，或按天做區塊
抽樣導致桶不平衡	52/48 的偏差被讀成真實提升	讀結果前先驗分流比例
開測後剔除登入用戶	分析人群中途變形	開測即凍結分析人群

會話級分流最常見、也最少被討論。一個訪客在手機上看到 A、在電腦上看到 B，他的行為是兩種體驗的平均，測出來的提升自然被拉向零。團隊於是得出"這個改動沒用"，而實驗其實從來沒有把它隔離出來。

有一個很便宜的事前檢查：開測前先記 1,000 個訪客的分配，驗兩件事——比例是否在目標值兩分以內，以及每個 id 是否只出現一次。兩個 bug（不平衡、重復分配）都能在一小時內查出來，而上線之後就完全隱形。

還有一項經常缺的輸入：主指標該用"每訪客收入"，而不是轉化率。兩個版本轉化率相同，但客單價移動 20% 時收入差得很遠，而只按轉化率做的功效計算看不到這一點。在小站上，每訪客收入是更好的主指標——它把客單價折進一個數字，分開兩組需要的樣本也更少。

分流還有一件容易被當成技術細節、其實決定實驗能不能讀懂的事：同一批人反復進同一個實驗。用 cookie 哈希分流時，清緩存、換設備、用隱身模式的訪客會被重新分配到另一組，這類人在兩組之間的漂移會把長期效應和短期效應混在一起。按賬號分流能解決已登入人群，剩下的匿名人群就只能接受這部分噪聲，並在報告里把它寫出來——承認噪聲比假裝沒有噪聲更有價值。

三、可檢測效應是算術，不是觀點

最小可檢測效應是你這場測試能分辨的最小提升。它由流量、基線率和你能接受的 alpha/功效決定，應該在開測前算出來，而不是事後發現。

舉個例子：一個頁面每月 4,000 訪客、轉化率 4%，一個月 160 次轉化；均分後每臂每月 80 次。按常規 80% 功效、5% alpha，要檢測 20% 的相對提升——從 4% 到 4.8%——大致需要每臂 8,000 訪客，在這個流量下就是約 100 周。這個數字就是"我們的測試為什麼永遠跑不完"的答案，而它用樣本量計算器五分鐘就能算出來。

由此只有兩個誠實的選擇。要麼把你承諾要測的效應放大——改版、改定價，而不是按鈕顏色；要麼就別叫它實驗，憑判斷上線，然後做前後對比。給一個 4,000 訪客的頁面定 10% 相對提升的目標，那不是測試，那是排隊。

小站一條可用的規則：只測你預期能帶來 20% 到 30% 相對提升的改動。低於這個量級，換工具——看會話回放、看漏斗流失、做定性判斷——因為這場測試看不見你要追的那個效應。

四、選一個經得起被看的方法

如果你會每天看面板（你會的），方法就必須容忍"被看"這件事。誠實的選項有三個：

任意時刻有效的置信序列。 這一類序貫方法的設計前提就是連續監控不會放大誤差。Adobe 在其實驗平台上部署的正是這套，報告在連續監控下第一類錯誤仍低於 5% 閾值——而被反復偷看的固定樣本測試會往 1 漂。
貝葉斯加預先登記的決策規則。 當"最優概率"跨過閾值就停，同時對每臂樣本設硬地板——50 個訪客是絕對底線，不是目標。後驗持續更新，不像 p 值那樣懲罰偷看。
成組序貫設計。 開測前規劃好少數幾次中期查看，配一個 alpha 消耗函數。查看次數少，但每一次都合法。

同一份資料給出相反結論這件事，值得親眼見一次。一場跑到每臂 8,000 訪客的測試收在對照組 320 次轉化、實驗組 368 次——相對提升 15%。頻率派讀出 p 值 0.061、置信區間跨零：不顯著。貝葉斯用均勻先驗讀出實驗組更優的概率 96.9%。兩個都沒錯，它們回答的是不同問題；而決策規則必須事先選好，否則就是數字在事後替你挑故事。

比框架更要緊的是這個紀律：把停止規則、最小可檢測效應、主指標寫進測試文檔，開測前定死。看完資料再換框架的團隊，買到的不是統計嚴謹，買到的是一套合理化說辭。

五、邊界：什麼時候不該測

有三種情況，統計上正確的答案是"不要測"：

測試頁月訪客低於大約 5,000，多數轉化測試分辨不出任何值得上線的東西。 例外是結構性大改，那種改動有 30% 相對效應才說得過去。
基線轉化率低於 1%，先修漏斗。 在這個水平上，方差被少數邊緣場景主導——支付失敗、移動端流程斷裂——這些要靠讀日誌找出來，不是靠隨機分組。
如果站內其他東西穩不住，你測的就是自己引入的噪音。 同期改定價、同期投campaign，兩組就不可比了，任何方法都修不回來。

還有一條邊界值得提前說：統計顯著和業務顯著是兩個問題。一個每月只產生 40 次轉化的頁面，2% 的相對提升只要有耐心就能測出來，而它值多少錢大概接近零。開測前先問：最小可接受的那個效應，一年對應多少收入？對很多小站答案就是"比這場測試的成本還低"——這完全是一個跳過測試的正當理由。

時長這件事也要說清楚，因為"再跑久一點"是默認建議，而它並不總對。時間混雜會隨時長累積：兩周的測試可能橫跨發薪日和一個活動，跑得越久，新的流量來源接進來導致人群變形的概率也越大。如果受眾中途換了一半，六周並不會把確定性翻四倍，它只是把一群更新、更不一樣的人，加進一個本來圍繞舊人群設計的對照里。

常見問題

問：每個版本需要多少訪客？
A： 50 是底線不是目標。4% 基線、想測 20% 提升，每臂大約要 8,000。

問：為什麼每天看結果是個問題？
A：固定樣本方法下，假陽性率會從 5% 被放大到接近 30%；要看就得換序貫或貝葉斯方法。

問：按會話分還是按用戶分？
A：按用戶或賬號分。會話分流會讓同一個人進兩組，把測出的效應壓小。

問：貝葉斯和頻率派結論不一致時信哪個？
A：開測前就定規則。同樣 8,000 訪客的測試，兩者可以同時給出 0.061 和 96.9%。

問： 2% 的提升值得測嗎？
A：小流量上通常不值得。測預期能帶 20% 到 30% 相對提升的改動，否則改用漏斗分析。

關於通智雲

通智睿見按用戶身份分流、在開測時凍結分析人群，並在報出提升時同時給出不確定性——讓小站能分清一個真實效應和一個週一。

資料來源

A/B 測試的統計顯著性：什麼時候可以下結論——固定樣本方法做連續監控，假陽性率從名義 5% 放大到最高 30%；最小可檢測效應是最常被忽略的輸入；統計顯著與業務顯著是兩個問題。
小電商的 A/B 測試實踐——測試頁月訪客不足約 5,000 時，結果要等數月且不可靠；最小可檢測效應設在 20% 到 30% 相對提升；優先並行而非順序，以避開季節性混雜；偷看會放大誤差率。
同一份資料，兩種結論——每臂 8,000 訪客、320 對 368 次轉化、相對提升 15%；頻率派 p 值 0.061，置信區間跨零；貝葉斯最優概率 96.9%。