サンプル比率の不一致(SRM):顧客の事例に対するソリューションを含む完全なガイド
公開: 2022-04-07失敗したテストよりも悪いことは何ですか?
テスト結果の信頼性を低下させるテストデータ品質の問題。
しかし、どうすれば悪いデータを避けることができますか?
サンプル比率の不一致(SRM)をチェックすることは、潜在的な問題を早期に発見するための簡単な方法です。 何かが怪しい場合は、早く見つけた方がいいです。
サンプル比率の不一致、それを見つける方法、それがテストにどのように影響するか、およびどのA / BテストプラットフォームにSRMチェックが組み込まれているのか(スプレッドシートを横に置く必要がない)について詳しくは、以下をお読みください。 。
- サンプル比率ミスマッチ(SRM)とは何ですか?
- あなたのA/BテストにはSRMがありますか? サンプル比率の不一致を計算する方法は?
- スプレッドシートの使用
- オンラインサンプル比率不一致計算機の使用
- SRMはA/Bテストにどのように影響しますか?
- SRMは頻度主義統計モデルとベイズ統計モデルの両方に影響しますか?
- いつSRMを考慮に入れる必要がありますか?
- SRMが存在するかどうかをどこで確認する必要がありますか?
- 実験の割り当て
- 実験の実行
- 実験ログ処理
- 実験分析
- 実験干渉
- 実験以外の理由
- SRMアラートをサポートするA/Bテストプラットフォーム
- エクスペリエンスを変換する
- Optimizely
- MiaProva経由のAdobeTarget
- GrowthBook
- Split.io
- サンプルサイズ比の不一致がわかりやすく説明されています
サンプル比率ミスマッチ(SRM)とは何ですか?
サンプル比率の不一致(SRM)は、A / Bテストで、実際のサンプル数(または治療グループの訪問者)が予想と一致しない場合に発生します。
これを例で説明しましょう。
Webサイトが週に約15,000人の訪問者を獲得するとします。 オリジナル(変更されていないページ)と2つのバリエーションの3つのバリエーションがあります。 トラフィックが均等に割り当てられている場合、それぞれが受け取るトラフィックはどれくらいになると思いますか? 理想的な世界では、答えは、各バリエーションが15,000 / 3=5000の訪問者を受け入れる必要があるということです。
現在、各バリエーションが実際に5000人の訪問者を受け入れる可能性はほとんどありませんが、4982や5021のように、それに非常に近い数です。このわずかなバリエーションは正常であり、単純なランダム性によるものです。 しかし、バリエーションの1つが3500人の訪問者を受け入れ、他のバリエーションが約5000人を受け入れる場合、そのバリエーションに何か問題がある可能性があります。
これらの問題を見つけるために私たち自身の直感に頼るのではなく、代わりにSRMテストに行くことができます。 カイ二乗適合度検定を使用して、たとえば、4850または4750の訪問者が、他の訪問者数と比較して「正常」であるかどうかを示します。
統計的には、カイ2乗適合度検定は、観測されたサンプル数を予想されたサンプル数と比較します。 また、実際の差がある場合、p値は設定された有意水準0.01よりも劣ります。これは、99%の信頼度に相当します。
ルーカスフェルメールがSRMの詳細や、このトピックに関するその他のFAQについて詳しく説明しているので、このビデオをご覧ください。
あなたのA/BテストにはSRMがありますか? サンプル比率の不一致を計算する方法は?
A / Bテストでは、SRMは真のブギーマンになる可能性があり、不正確な結果と誤った結論を引き起こします。 良いニュースは、頭痛を避けるのに役立つツールが世の中にあるということです。
スプレッドシートの使用
スプレッドシートは、Microsoft ExcelやGoogle製品が広く利用できるため、SRMを計算する最も簡単な方法です。
別の例を示しましょう。
50/50のトラフィック分割を使用したA/BテストのSRMを計算し、オリジナルとバリエーションでそれぞれ214,598と241,156の訪問者数を観測します。
カイ二乗検定を使用して、観測されたトラフィック分割が予想されるトラフィック分割と一致するかどうかを確認します。 そうでない場合は、観測値が期待値と十分に異なるかどうかを知り、懸念を引き起こし、結果を破棄する必要があります。
以下のスプレッドシートに示すように、スプレッドシートでCHISQ.TEST関数を使用してp値を計算する必要があります。
この例では、p値は0です。p値が0.05未満の場合、SRMが手元にあり、ほとんどの場合、テスト結果を却下するのに十分な証拠があります。
オンラインサンプル比率不一致計算機の使用
- Convertの計算機は、サンプル比率の不一致を診断するのに役立ち、実験が完了するまでに必要な時間を教えてくれます。
- もう1つのSRM固有のオンライン計算機は、ルーカスフェルメールによって設計されたものです。 この方法では、前の手法と同じ方法でSRMを計算するため、プロセスを実行して理解すれば、このオンラインSRM計算機を使用できるはずです。 サンプルの番号を入力するだけで、結果は次のように表示されます
SRMはA/Bテストにどのように影響しますか?
実験中にバリアント間のトラフィック分割を確認し、それがどれほど正確であるかを疑問視した可能性があります。
おそらく、以下のレポートのように見えるものです。 あなたはそれを見て、オリジナルが1330人の訪問者を持っていたが、バリエーションは1713人だったのは普通かどうか疑問に思うかもしれません。
SRM比の簡単な統計計算(上記の2つの方法のいずれかを使用)により、変動比が許容できるかどうかがわかります。
2つのバリエーション(元のバリエーションとバリエーション1)の間の実際の分割は、期待値に対応していますか? そうでない場合は、データを拒否し、問題が解決したらテストを再開する必要があります。
SRMは頻度主義統計モデルとベイズ統計モデルの両方に影響しますか?
はい。
SRMの原因は、データがベイジアン(Google Optimize、Optimizely、VWO、A / B Tasty)アプローチまたは頻度主義(Convert Experiences、Dynamic Yield)アプローチのどちらで分析されても、実験結果の妥当性に同じ影響を及ぼします。
したがって、上記のSRM計算機を使用して、ベイズ統計を使用するプラットフォームでSRMをチェックすることもできます。
いつSRMを考慮に入れる必要がありますか?
テストでサンプル比率の不一致を見つけても、必ずしも結果を破棄する必要があるとは限りません。
では、SRMの計算を真剣に受け止める必要があるのはいつですか。
いくつかの例で調べてみましょう。
OriginalとVariationにそれぞれ50%のユーザーが割り当てられている実験を実行します。 したがって、それぞれにほぼ同じ数のユーザーが表示されると予想されます。
結果は次のように返されます
- コントロール:21,588ユーザー
- 治療:15,482ユーザー
それらをSRMチェッカーに通してみましょう。
これは懸念の原因ですか?
上記のサンプル比率のp値は<0.0001であるため、等しい比率を要求する設計では、この比率またはより極端な比率が見られる確率は<0.0001です。
非常にありそうもない出来事を観察したばかりなので、何かが間違っていることを絶対に心配する必要があります。 したがって、実験の実装にバグがある可能性が高く、結果を信頼するべきではありません。
別の実験を実行します。この実験では、オリジナルとバリエーションに同じ割合のユーザーが割り当てられます。 p値を計算すると、0.002未満であるため、非常にまれなイベントです。
メトリックはどのくらいずれている可能性がありますか? 本当に結果を破棄する必要がありますか?
Convert Experiencesなどの実験プラットフォームを使用すると、テスト後のセグメンテーションを結果に適用して、InternetExplorerユーザーを除外するとSRMがなくなっていることがわかります。
この場合、除外されたユーザーはおそらく古いIEブラウザーを使用しており、これがSRMの原因でした。 バリエーションの変更によりボットが適切に分類されず、比率の不一致が発生しました。
セグメントがない場合、残りのユーザーの割合は適切にバランスが取れており、メトリックは正常に見えます。
SRMが発見されなかったとしたら、実験全体が大きな失敗と見なされていたでしょう。
しかし、SRMが発見されると、小さなセグメントを削除し、実験を適切な分析に使用することができます。
同様のシナリオでは、除外されたユーザーを安全に無視して、実験を使用できます。
実験を実行すると、テストにSRMのタグが付けられていることがわかります。
ただし、グラフに注意を払うと、コンバージョン率の曲線が平行に保たれ、計算された信頼度が99.99%であることがわかります。 そのパターンは、テストが有効であるという十分な確実性を提供するはずです。
この場合、 SRMを安全に無視して、データを信頼し続けることができます。
SRMが存在するかどうかをどこで確認する必要がありますか?
SRMが発生する可能性のある領域がいくつかあります。 ルーカスフェルメールの原因の分類法を見てみましょう。
- 実験の割り当て–誤ったバケット(ユーザーが誤ったクラスターに配置されている)、誤ったランダム化機能、または破損したユーザーIDの場合があります。
- 実験の実行–変動が異なる時間に開始された可能性があり(不一致の原因)、またはフィルターの実行遅延が発生した可能性があります(どのグループが実験の対象となるかを決定します)。
- 実験ログ処理–自動ボットが実際のユーザーを削除し、情報がログに到着するのを遅らせます。
- 実験分析–バリエーションの誤ったトリガーまたは誤った開始。
- 実験の干渉–実験は攻撃やハッキングの対象となる可能性があります。または、別の進行中の実験の影響が現在の実験を妨害している可能性があります。
SRMがあり、答えを探す場所がわからない場合は、上記の分類法から始めるとよいでしょう。
そして、物事をより明確にするために、これらの各ケースの実際の例を示します。
実験の割り当て
ここで、注目すべき最も興味深い点の1つは、A/Bテストプラットフォームが使用しているランダム化機能です。
以下の例では、WishのデータサイエンティストがA / AテストでSRMの問題を発見し、長い調査の結果、ランダム化が完全にランダムではなかったためにSRMが発生したと結論付けました。
有効な実験結果を達成するには、ランダム化手順が重要です。
A / Bテストで使用される統計的テストの重要な前提は、ランダム化されたサンプルの使用です。 実験バケット間で、ランダム化は観察されたユーザー属性と観察されなかったユーザー属性の両方のバランスを取り、テスト対象の製品機能と試行結果の結果の違いとの因果関係を確立します。
プロのヒント:Convertには、バリエーション間の均等な分散を保証する独自のランダム化アルゴリズムがあるため、これによってSRMが発生することはありません。 ただし、別のツールを使用してランダム化を実装している場合は、次の手順に従って、訪問者をバリエーションにまとめることができます。
実験の実行
実験の実行に関しては、エクスペリエンスにSRMを引き起こす可能性のある主な理由が2つあります。
1.スクリプトがバリエーションの1つに正しくインストールされていない
A/Bテストプラットフォームのスクリプトがオリジナルとバリエーションに正しくインストールされているかどうかを常に確認してください。
私たちのカスタマーサポートチームは最近、変換スクリプトがバリエーションの1つに追加されず、テストでSRMが発生するケースを解決しました。
以下に示すように、エクスペリエンスを実行するすべてのページにスクリプトを追加してください。
2.ページターゲティングが正しく構成されていない
この場合、SRMの不一致は、テストのターゲティングが正しく設定されていないことが原因です。
設定が間違っていると、一部の訪問者がバリエーションに転送されるように選択されますが、リダイレクトは失敗します。これは、元のURL式が、テストでバケット化されてリダイレクトされたすべての訪問者のすべてのURLと一致しないためと考えられます。
これを回避するには、実験バリエーションのURL式を再構成し、テストを再実行します。
分割URLテストでSRMを回避するために、ConvertExperiencesを使用してページターゲティングを設定する方法を示すもう2つのシナリオを次に示します。
シナリオ1:分割URLを使用してホームページ(https://www.convert.com)のみをターゲットにし、訪問者が持つ可能性のあるすべてのクエリパラメーターを渡します
ここで、サイトエリアでは、ページのURLがhttps://www.convert.comと完全に一致している必要があります。 除外セクションでは、リダイレクトを回避するために、クエリ文字列にv1 = trueを含める必要があります( https://www.convert.com?v1 = trueに到達し、トラフィックが発生した場合でも、実験の条件は一致するため)分布が不均一になる可能性があります)。
次に、バリエーションを定義するときは、次のようにします。
シナリオ2:ホームページ(https://www.convert.com)だけでなく、すべてのページをスプリットURLでターゲットにしてクエリパラメーターを渡す
ここでは、 https://www.convert.comを含む「ページURL」を使用してサイトエリアを定義する必要があります。 除外セクションでは、クエリにv1=trueが含まれている必要があります。
バリエーションを定義するときは、以下の正規表現レシピを使用してすべてのページをキャッチします。
実験ログ処理
ここでは、SRMの主な理由として、ユーザーのエクスペリエンスをターゲットにできるボットを特定します。 ユーザーエージェントに異常なパターンが見つかった場合は、追加のログを確認するために私たちに連絡することができます。
たとえば、サポートチームは、テストにSRMが含まれるクライアントを支援しました。
彼らの場合、 Browser = Otherでレポートをフィルタリングすると、不均一な分割とSRMが見られました。 しかし、同じレポートをBrowser = Chrome + Safariでフィルタリングした場合、SRMは検出されず、不均一な分布もありませんでした。
そこで、ブラウザがその他に設定されているいくつかのイベントを確認したところ、すべてのイベントで「site24x7」のユーザーエージェントが表示されました。 これはある種の監視ソフトウェアであることがすぐにわかりました。これは広告であり、個別のユーザーエージェントを使用しているため幸運です。 これが通常のユーザーエージェントの背後に隠されていたとしたら、それを見つけることは不可能だったでしょう。
この問題を解決するために、先に進み、このUser-Agentをトラフィックから除外するボットのリストに追加しました。 残念ながら、この変更は、ボットをリストに追加した瞬間以降、将来のデータに影響を与える可能性がありますが、少なくともそれが見つかり、修正されました。
実験分析
このカテゴリは、主に手動トリガーで設定されたエクスペリエンスに影響します。
これは、たとえば、トリガーを自分で処理する必要があるシングルページアプリケーションで発生します。
したがって、以下のコードと同様のコードを使用して手動で行う必要がある場合は、テストで発生する可能性のあるSRMに細心の注意を払ってください。
window._conv_q = _conv_q || []; window._conv_q.push(["run"、 "true"]);
実験干渉
これは、エクスペリエンス中にバリエーションの1つが一時停止されるユーザー介入を指します。 数週間実行されているスプリットURLテストがあり、誤ってまたは故意にバリエーションを一時停止し、オリジナルのみを実行したままにしたとします。
直後、およびWebサイトのトラフィックに応じて、テスト用に計算されたSRMに気付くでしょう。
この場合、バリエーションが一時停止された日付範囲を除外するか、エクスペリエンスデータをリセットすることができます。
実験以外の理由
上記のカテゴリのいずれもSRMの根本的な原因を明らかにしていない場合は、Webサイトにエラー追跡ソフトウェア(Sentryなど)を追加して、サイトのより深い問題を特定することをお勧めします。
SRMアラートをサポートするA/Bテストプラットフォーム
どのA/BテストプラットフォームがこのSRM機能をサポートしていて、自分で計算しなくてもアラートを表示できるのか疑問に思われるかもしれません。
調査が完了し、ツールのリストが作成されました。
エクスペリエンスを変換する
2021年12月より、独自のSRM方式を導入しました。
ユーザーの場合は、[プロジェクトの構成]>[その他の設定]からSRMチェックを有効にできます。
次に、レポートにSRMタグを表示できるようになります。
Optimizely
2021年9月に、SRMを検出するために誰でも実装できる順次テストソリューションをOptimizelyでオープンソース化しました。
Optimizelyは、ssrm-testを、実行中のすべての実験で同時に実行できる本番環境に対応したバックエンドマイクロサービスに変えました。
Optimizelyの結果ページで、アラートを設定し、ssrm-testからリアルタイムの結果を取得できます。
Optimizely StaffStatisticianのMichaelLindonは、SRMは、テストの実行が不十分な場合に発生する典型的な問題であると述べています。
製品実験を実行するには、かなりの量のインフラストラクチャが必要であるため、エラーが発生する可能性があります。 たとえば、ウェブサイトの訪問者が一貫して実験のバリエーションにバケット化されておらず、元の条件とバリエーションの条件の両方で変換されていない場合、そのユーザーに対して取得されたデータは、実験の影響を評価するために有効ではありません。
主な懸念事項は、SRMが不正確なデータを生成し、メトリックに影響を与えて検出されなくなる可能性がある場合です。
MiaProva経由のAdobeTarget
2021年4月、Adobe TargetはMiaProvaと提携して、A/Bアクティビティに関するSRMアラートを提供しました。
これらのアラートは、不一致が検出されたときにAdobeTargetを使用するMiaProvaの顧客に通知します。 このアプローチは、すべてのライブA/Bテストにカイ2乗検定を自動的に適用します。
GrowthBook
GrowthBookは、ベイズ統計エンジンとすべての実験の自動SRMチェックを備えたオープンソースのA/Bテストプラットフォームです。
すべての実験でSRMが検索され、SRMが特定された場合はユーザーに警告されます。
特定のトラフィック分割(例:50/50)を予測したが、代わりに大幅に異なるもの(例:40/60)が表示された場合、警告が表示されます。 これは、p値が0.001未満の場合にのみ表示され、偶然に発生する可能性が非常に低いことを示しています。
そのようなテストの結果は、潜在的に欺瞞的であり、したがって警告であるため、信頼されるべきではありません。 代わりに、ユーザーは実験を再開する前にバグの原因を見つけて修正する必要があります。
Split.io
Splitは、機能フラグ管理、ソフトウェア実験、および継続的配信を強化する機能配信プラットフォームです。
計算が更新されるたびに、Splitプラットフォームはサンプル比率をチェックして、ターゲットと現在のサンプル比率の間に実質的な違いがあるかどうかを確認します。 このサンプル比率チェックは、期間や最終更新などの他の重要な詳細とともに、主要なメトリックと組織のメトリックの要約の下にあります。
サンプルサイズ比の不一致がわかりやすく説明されています
SRMを見るのはどのくらいの頻度で「正常」ですか?
ルーカスフェルメールはそれを最もよく言った。 大手テクノロジー企業でさえ、オンライン制御の実験でSRMの固有振動数が6%から10%であることが観察されています。
現在、SRMがより頻繁に繰り返される場合は、実験計画またはWebサイトをより深く調査する必要があります。
上記のような問題が発生した場合は、いつでも私たちのチームがお手伝いします。 私たちのチームに連絡するには、ここをクリックしてください。