樣本比率不匹配 (SRM)：包含客戶案例解決方案的完整指南

有什麼比失敗的測試更糟糕的呢？

使測試結果不可靠的測試數據質量問題。

但是如何才能遠離不良數據呢？

檢查採樣率不匹配 (SRM) 是及早發現潛在問題的簡單方法。 如果某事是可疑的，那麼您越早發現越好。

繼續閱讀以了解有關採樣率不匹配、如何發現它、它如何影響您的測試以及哪些 A/B 測試平台帶有內置 SRM 檢查的更多信息（因此您不必保留電子表格） .

什麼是採樣率不匹配 (SRM)？

當樣本（或處理組中的訪問者）的實際數量與預期不匹配時，A/B 測試中會發生樣本比率不匹配或 SRM。

讓我們用一個例子來說明這一點。

假設一個網站每周有大約 15,000 名訪問者。 我們有 3 個變體，原始（即未更改的頁面）和 2 個變體。 如果流量平均分配，您希望每個人收到多少流量？ 在理想的世界中，答案是每個變體都應該接收 15,000 / 3 = 5000 名訪問者。

現在，每個變體實際上不太可能收到 5000 名訪問者，但一個非常接近的數字，例如 4982 或 5021。這種微小的變化是正常的，並且是由於簡單的隨機性！ 但是，如果其中一種變體要接待 3500 名訪問者，而其他變體中的訪問者約為 5000 人，那麼那個變體可能有問題！

與其依靠我們自己的直覺來發現這些問題，不如進行 SRM 測試。 它使用卡方擬合優度檢驗來告訴我們，例如，4850 或 4750 名訪問者與接收到的其他訪問者數量相比是否“正常”！

在統計方面，卡方擬合優度檢驗將觀察到的樣本數與預期樣本數進行比較。 如果存在真正的差異，則 p 值將低於設定的顯著性水平 0.01，這對應於 99% 的置信度。

您的 A/B 測試有 SRM 嗎？ 如何計算採樣率不匹配？

在 A/B 測試中，SRM 可能是一個真正的惡魔，導致不准確的結果和錯誤的結論。 好消息是，有一些工具可以幫助您避免頭痛。

使用電子表格

由於 Microsoft Excel 和/或 Google 產品的廣泛可用性，電子表格是計算 SRM 的最簡單方法。

讓我們再舉一個例子。

我們將為 A/B 測試計算 SRM，流量拆分為 50/50，觀察到的訪問者數量分別為 214,598 和 241,156 的原始和變體。

我們將使用卡方檢驗來查看觀察到的流量拆分是否與預期的流量拆分匹配。 如果沒有，您將想知道觀察到的值是否與預期值有足夠的差異以引起關注並保證丟棄結果。

您需要使用電子表格中的 CHISQ.TEST 函數來計算 p 值，如下面的電子表格所示。

在我們的示例中，p 值為 0。當 p 值低於 0.05 時，您手頭上有一個 SRM，並且在大多數情況下有足夠的證據來駁回測試結果。

使用在線採樣率不匹配計算器

1. Convert 的計算器可以幫助診斷樣本比率不匹配，它還告訴您需要等待多長時間才能完成實驗！
   

   

2. 另一個 SRM 特定的在線計算器是由 Lukas Vermeer 設計的。 此方法以與先前技術相同的方式計算 SRM，因此如果您遵循並理解該過程，您應該能夠使用此在線 SRM 計算器。 只需填寫樣品的數字，結果將如下所示
   

   

SRM 如何影響 A/B 測試？

您可能已經在實驗期間查看了變體之間的流量分配，並質疑它的準確性。

也許一個看起來像下面的報告。 您可能會看到它並想知道原版有 1330 名訪問者但變體 1713 是否正常。

SRM 比率的簡短統計計算（使用上述兩種方法之一）將告訴您變化比率是否可以接受。

兩個變體（原始和變體 1）之間的實際分割是否對應於預期值？ 如果不是這種情況，您應該拒絕數據並在解決問題後重新啟動測試。

SRM 會影響頻率統計模型和貝葉斯統計模型嗎？

是的。

無論是使用貝葉斯（Google Optimize、Optimizely、VWO、A/B Tasty）還是頻率論（Convert Experiences、Dynamic Yield）方法分析數據，SRM 的原因對實驗結果的有效性都有相同的影響。

所以上面的 SRM 計算器也可以用來檢查使用貝葉斯統計的平台上的 SRM。

什麼時候應該考慮 SRM？

在您的測試中發現樣本比率不匹配並不一定意味著您需要丟棄結果。

那麼什麼時候真的有必要認真對待 SRM 計算呢？

讓我們通過幾個例子來了解一下。

示例 #1

您運行一個實驗，其中原始和變體各分配了 50% 的用戶。 因此，您希望在每個中看到大約相同數量的用戶。

結果返回為

• 控制：21,588 名用戶
• 治療：15,482 名用戶

讓我們通過 SRM 檢查器檢查它們：

這是否值得關注？

上述樣本比率的 p 值 <0.0001，因此在要求等比例的設計下，看到這個比率或更極端的比率的概率是 <0.0001！

您絕對應該擔心出現問題，因為您剛剛觀察到一個極不可能發生的事件。 因此，在實驗的實施中更有可能存在一些錯誤，您不應該相信任何結果。

示例 #2

您運行另一個實驗，其中原始和變體分配了相同百分比的用戶。 您計算 p 值，它 <0.002，所以這是一個非常不可能的事件。

指標有多差？ 你真的必須放棄結果嗎？

使用 Convert Experiences 之類的實驗平台，您可以對結果應用一些測試後細分，並發現如果您排除 Internet Explorer 用戶，SRM 就消失了。

在這種情況下，被排除的用戶很可能使用舊的 IE 瀏覽器，這就是 SRM 的原因； 由於變異的一些變化，機器人沒有正確分類，導致比率不匹配。

如果沒有該細分，剩餘的用戶百分比會得到適當的平衡，並且指標看起來很正常。

如果沒有發現 SRM，整個實驗將被視為重大失敗。

但是一旦發現 SRM，就可以刪除一小部分，並將實驗用於適當的分析。

在類似的情況下，您可以放心地忽略排除的用戶，並且可以使用實驗。

示例#3

您運行了一個實驗，並發現您的測試中有 SRM 標記。

但是，如果您注意圖表，您會注意到轉化率曲線保持平行，計算得出的置信度為 99.99%。 該模式應該為您提供足夠的確定性來證明測試是有效的。

在這種情況下，您可以放心地忽略 SRM 並繼續信任您的數據。

您應該在哪裡檢查 SRM 是否存在？

有幾個領域可能會發生 SRM。 讓我們看一下 Lukas Vermeer 的原因分類法：

1. 實驗分配——可能存在不正確的分桶（用戶被放置在不正確的集群中）、錯誤的隨機化函數或損壞的用戶 ID 的情況。
2. 實驗執行——變化可能在不同的時間開始（導致差異），或者可能存在過濾器執行延遲（確定哪些組接受實驗）。
3. 實驗日誌處理——自動機器人刪除真實用戶，延遲信息到達日誌。
4. 實驗分析- 錯誤觸髮變化或錯誤啟動它。
5. 實驗干擾——實驗可能會受到攻擊和黑客攻擊，或者另一個正在進行的實驗的影響可能會干擾當前的實驗。

如果您有 SRM 並且不確定從哪裡尋找答案，那麼上面的分類是一個有價值的起點。

為了讓事情更清楚，我們現在將為您提供每個案例的真實示例。

實驗作業

這裡需要關注的最有趣的事情之一是您的 A/B 測試平台正在使用的隨機化功能。

在下面的示例中，Wish 的數據科學家在 A/A 測試中發現了 SRM 問題，經過長期調查，得出的結論是 SRM 的出現是因為它們的隨機化不是完全隨機的。

為了獲得有效的實驗結果，隨機化程序至關重要。

A/B 測試中使用的統計測試的一個關鍵假設是使用隨機樣本。 在實驗桶之間，隨機化平衡了觀察到的和未觀察到的用戶屬性，在被測產品功能與試驗結果的任何結果差異之間建立了因果關係。

實驗執行

在實驗執行方面，有兩個主要原因可能會導致您的體驗中出現 SRM。

1. 腳本未正確安裝在其中一個變體上

始終檢查您的 A/B 測試平台的腳本是否正確安裝在 Original 和 Variations 上。

我們的客戶支持團隊最近解決了一個案例，即未在其中一個變體中添加轉換腳本，導致測試出現 SRM。

確保在您希望運行體驗的所有頁面上添加腳本，如下所示：

2.頁面定位配置錯誤

在這種情況下，SRM 不匹配是因為測試的目標設置不正確。

如果設置錯誤，一些訪問者被選擇轉發到變體，但重定向失敗，這很可能是因為原始 URL 表達式與在測試中存儲並重定向的所有訪問者的每個 URL 都不匹配。

為避免這種情況，請重新配置實驗變體 URL 表達式並重新運行測試。

這裡還有兩個場景，向您展示如何使用轉換體驗設置頁面定位，以避免拆分 URL 測試中的 SRM。

場景 1：僅使用拆分 URL 定位主頁 (https://www.convert.com) 並傳遞訪問者可能擁有的所有查詢參數

在這裡，在站點區域中，頁面 URL 需要與https://www.convert.com 完全匹配。 在排除部分，查詢字符串應包含v1=true以避免任何重定向（因為如果您最終訪問https://www.convert.com ?v1=true和流量，實驗條件仍將匹配分佈可能最終不均勻）。

然後，當你定義你的變體時，保持這樣：

場景 2：使用拆分 URL 並傳遞查詢參數來定位所有頁面，而不僅僅是主頁 (https://www.convert.com)

在這裡，您需要使用包含https://www.convert.com的“頁面 URL”定義您的站點區域。 在排除部分，查詢應包含v1=true。

定義變體時，使用下面的正則表達式來捕獲所有頁面：

實驗日誌處理

在這裡，作為 SRM 的主要原因，我們確定了可以針對您的體驗的機器人。 如果我們在用戶代理上發現任何異常模式，您可以聯繫我們檢查我們保留的其他日誌。

例如，我們的支持團隊幫助了一位測試有 SRM 的客戶。

在他們的案例中，當我們通過Browser=Other過濾報告時，我們看到了不均勻的拆分和 SRM。 但是當我們通過Browser=Chrome+Safari過濾相同的報告時，沒有檢測到 SRM，也沒有分佈不均。

因此，我們檢查了幾個將Browser設置為Other的事件，它們都顯示了“site24x7”的用戶代理。 我們立即知道這是某種監控軟件，幸運的是，它是廣告並且使用不同的用戶代理。 如果它隱藏在一個普通的用戶代理後面，就不可能找到它。

為了解決這個問題，我們繼續將此用戶代理添加到我們從流量中排除的機器人列表中。 不幸的是，在我們將機器人添加到列表之後，這種變化可能會對未來的數據產生影響，但至少它被找到並修復了。

實驗分析

此類別主要影響手動觸發設置的體驗。

例如，這發生在您需要自己處理觸發的單頁應用程序上。

因此，每當您必須使用與下麵類似的代碼手動執行此操作時，請密切注意測試中潛在的 SRM。

 window._conv_q = _conv_q || [];
window._conv_q.push(["run","true"]);

實驗干擾

這是指用戶干預，其中一種變化在體驗期間暫停。 想像一下，您有一個拆分 URL 測試運行了幾個星期，並且您不小心或故意暫停了變體，只保留原始運行。

緊接著，根據您的網站流量，您會注意到為您的測試計算的 SRM。

在這種情況下，您可以排除暫停變體的日期範圍或重置體驗數據。

非實驗原因

如果以上類別都不能揭示您的 SRM 的根本原因，我們建議您在您的網站上添加錯誤跟踪軟件（如 Sentry），以識別您網站的更深層次的問題。

支持 SRM 警報的 A/B 測試平台

您可能想知道哪些 A/B 測試平台支持此 SRM 功能並為您提供警報，而無需您自己計算。

我們完成了研究並編制了一份工具清單。

轉換體驗

截至 2021 年 12 月，我們引入了自己的 SRM 方法。

如果您是用戶，您可以從項目配置 > 更多設置中啟用 SRM 檢查。

然後您將能夠在報告中看到 SRM 標籤：

優化

2021 年 9 月優化開源了順序測試解決方案，任何人都可以實施該解決方案來檢測 SRM。

Optimizely 已將 ssrm-test 轉變為生產就緒的後端微服務，可以同時在所有正在運行的實驗上運行。

在 Optimizely 的結果頁面上，您可以設置警報並從 ssrm-test 獲取實時結果：

Optimizely 員工統計學家 Michael Lindon 說，SRM 是一個典型的問題，當測試執行不佳時會出現。

要運行產品實驗，需要大量的基礎設施，因此可能會出現錯誤。 例如，如果網站訪問者沒有始終如一地被分到實驗變體中並在原始條件和變體條件下進行轉換，則為該用戶獲得的數據對於評估實驗的影響無效。

主要問題是當 SRM 產生可能會影響您的指標並且未被檢測到的不准確數據時。

通過 MiaProva 實現的 Adob​​e Target

2021 年 4 月，Adobe Target 與 MiaProva 合作，提供有關 A/B 活動的 SRM 警報。

當檢測到不匹配時，這些警報會通知使用 Adob​​e Target 的 MiaProva 客戶。 這種方法會自動將卡方測試應用於每個實時 A/B 測試。

成長書

GrowthBook 是一個開源 A/B 測試平台，具有貝葉斯統計引擎和針對每個實驗的自動 SRM 檢查。

每個實驗都會尋找一個 SRM，並在識別出一個 SRM 時向用戶發出警告。

當您預測某個流量拆分（例如 50/50），但看到一些截然不同的情況（例如 40/60）時，您會收到警告。 這僅在 p 值小於 0.001 時顯示，表明它極不可能偶然發生。

這種測試的結果不應該被信任，因為它們可能具有欺騙性，因此發出警告。 相反，用戶應該在重新開始實驗之前找到並糾正錯誤的來源。

分裂.io

Split 是一個功能交付平台，可為功能標誌管理、軟件實驗和持續交付提供支持。

每次計算更新時，Split 平台都會檢查採樣率，以查看目標採樣率和當前採樣率之間是否存在顯著差異。 此樣本比率檢查可以在關鍵和組織指標的摘要下方找到，以及其他重要詳細信息，例如持續時間和上次更新時間。

樣本量比不匹配揭秘

您可能會問，多久查看一次 SRM 是“正常的”？

盧卡斯·維米爾（Lukas Vermeer）說得最好。 即使是大型科技公司在其在線對照實驗中也觀察到 SRM 的自然頻率為 6% 到 10%。

現在，如果 SRM 更頻繁地重複，則需要對實驗設計或網站進行更深入的調查。

如果您遇到上述問題，我們的團隊隨時為您提供幫助！ 點擊這里聯系我們的團隊。