A/BテストにおけるSample Ratio Mismatch（SRM）をどのように診断しますか？

プロンプトと適用されるコンテキスト

あるプロダクト実験では、設定された50/50の分割比率で、ユーザーごとの安定したランダム割り当てを使用しています。100,000人の対象ユーザーの後、分析には51,000人のコントロール群ユーザーと49,000人のトリートメント群ユーザーが含まれています。トリートメント群のコンバージョンは1.8%高く、通常のエフェクト検定ではp値が0.01未満と報告されています。この結果が信頼できるかどうかを判断し、Sample Ratio Mismatch（SRM）を検出、診断、修復、防止するためのプロセスを設計してください。

この質問は、データサイエンス、プロダクトアナリティクス、ビジネスインテリジェンス、および実験プラットフォームの職種に適用されます。Amazonの現在のデータ職種向け面接ガイダンスでは、統計学、曖昧なデータの処理、分析を実行可能な意思決定に変換することが明示的に求められています。Microsoftの実験研究では、SRMを信頼性の中核的なシグナルとして扱っています。主要なカテゴリはdataです。中心的なタスクは統計的検定とデータリネージの診断であり、実験プラットフォーム全体を設計することではありません。

100,000、51,000、49,000、および1.8%という値は面接上の前提であり、業界のベンチマークではありません。この解答では、ユーザーがランダム化単位であり、各ユーザーが正確に1つのバリアントに現れる必要があると仮定しています。デバイス、アカウント、ワークスペース、世帯、または地域によってランダム化された実際の実験では、対応する単位をテストする必要があります。

面接官が評価するポイント

第1のシグナルは、候補者がビジネスインパクトを読み取る前に実験の完全性（インテグリティ）を確認するかどうかです。不十分な回答では、「p値が0.01未満で1.8%のリフト」を見てリリースを推奨します。優れた回答では、まず観察された母集団が設定された割り当てと一致していることを検証します。エフェクト検定は、観察された2つの結果が異なることを示すことはできますが、それらのグループに残っているユーザーが依然として比較可能なランダム化サンプルを構成していることを証明することはできません。

第2のシグナルは、目に見える比率の違いを統計的検定に落とし込めるかどうかです。同じ51/49の比率であっても、1,000人のユーザーと100,000人のユーザーでは意味が大きく異なります。SRM検定は、観察されたバリアントのカウントと、設定された割り当てによって示唆される期待カウントを比較します。データ量が増えるほど、体系的な小さな偏差を偶然によるものと区別しやすくなります。

第3のシグナルは診断の網羅性です。SRMは、割り当て設定、不安定な識別子、バリアントの実行、テレメトリの欠落、botフィルタリング、データの結合（join）、またはトリートメント後に定義された分析条件を通じて発生する可能性があります。すべてのSRMを「ランダム性の不具合」と呼ぶことは、実行やデータ処理における多くの一般的な障害を見落とすことになります。

最後に、面接官は意思決定の規律を評価します。SRMは症状であり、重み付けによって自動的に除去される無害なノイズではありません。公開された事例では、トリートメントによってエンゲージメントが変化したため、botフィルターによってエンゲージメントの高いユーザーが多く削除され、欠陥が修正された後にビジネス上の結論が逆転しました。根本原因が理解されるまでは、有意なままの別のメトリクスを探すのではなく、リリース決定を保留してください。

回答前に明確にすべき質問

50/50は、割り当て、露出、トリガー、または最終的な分析母集団のどれを表していますか？ 割り当てが正常であっても、露出、適格性、または下流の分析でSRMが発生する可能性があります。各ステージをテストしてください。
ランダム化の単位は何ですか？ ワークスペース単位で割り当てられている場合、メンバー数は自然に異なる可能性があります。まずワークスペース数をテストし、クラスター割り当てに適した方法で結果を分析してください。
識別子は安定しており、相互排他的ですか？ クロスデバイスログイン、Cookieの削除、匿名からアカウントへのマージ、およびID移行によって、ユーザーが再割り当てされたり重複したりする可能性があります。
実験の実行中に割り当て比率が変更されましたか？ 10/90から50/50へのランプアップ（段階的拡大）では、実験全体に適用される最終的な分割比率ではなく、各インターバルからの期待カウントが必要です。
「適格ユーザー（eligible user）」はどのように定義されていますか？ トリートメント専用の新しいボタンをクリックするなど、トリートメントの影響を受ける条件は、トリートメント後の選択バイアス（post-treatment selection）となり、比較可能性を損なう可能性があります。
一方のバリアントでリダイレクト、障害、またはログ記録の違いが発生する可能性はありますか？ 読み込みの遅延、クラッシュ、およびバージョン固有のテレメトリにより、実行中および収集段階でユーザーが排除される可能性があります。
どのパイプラインが最終カウントを生成しますか？ 割り当て、露出、イベント収集、重複排除、botフィルタリング、ディメンションの結合、およびメトリクスウィンドウを分離してください。
実験を再実行できますか？ 未加工ログからの偏りのない再構築が不可能な場合、現在のサンプルから結論を無理に導き出すよりも、欠陥を修正して再実行する方が妥当です。

30秒の回答フレームワーク

「リリースはしません。50/50の割り当てでは、グループごとの期待カウントは50,000です。カイ二乗統計量は(51,000 - 50,000)² / 50,000 + (49,000 - 50,000)² / 50,000 = 40であり、自由度1においてp値は約2.54 × 10^-10です。したがって、最終的な母集団には深刻なサンプル比率の不一致（SRM）が存在するため、ビジネス効果のp値はリリースの根拠にはなりません。割り当て、露出、トリガー、ログ処理、および最終分析の各ステージでカウントを比較し、時間、プラットフォーム、バージョン、および識別子タイプごとにセグメント化して、最初の乖離箇所を特定します。原因を修復した後、SRM、テレメトリ、およびA/Aチェックを再実行します。偏りなくサンプルを再構築できない場合は、実験を再実行します。」

ステップバイステップの詳細な回答

明確な意思決定ゲートから始めます。実験は、ランダム化、データの完全性、およびビジネス効果のチェックに合格する必要があります。効果分析の前にSRMを実行し、実験プラットフォーム上で目立つように表示します。Microsoftの公開されているプラクティスでは、プラットフォーム規模でのフォールスポジティブ（偽陽性）を減らすための保守的なアラートしきい値としてp < 0.0005を使用しています。これは文書化された一例であり、普遍的な定数ではありません。チームは、結果を見てからではなく、事前に対象の品質しきい値を選択する必要があります。

ステップ1：SRMを正しく計算する。

合計100,000人のユーザーで50/50に設定された2つのバリアントの場合、各期待カウントは50,000です。カイ二乗適合度統計量は次のとおりです。

χ² = Σ (observed - expected)² / expected = 40

2つのグループがあり、追加の推定パラメータはないため、自由度は1となり、p値は約2.54 × 10^-10になります。これは保守的な完全性しきい値をはるかに下回っており、通常の割り当てノイズとは考えられません。カイ二乗近似には十分な期待カウントが必要です。一般的なNISTのルールでは、グループあたり約5つの期待観測数とされています。非常に小さなサンプル、極端な割り当て比率、またはスパースなバリアントが多数ある場合は、正確二項検定または多項検定が必要です。

比率はそのサンプルサイズとともに解釈する必要があります。合計が1,000でカウントが510/490であった場合、期待カウントは500/500、χ² = 0.4となり、p値は約0.527になります。目に見える51/49の比率は同一ですが、統計的証拠は異なります。

ステップ2：カウントが乖離する最初のステージを見つける。

バリアントごとに一意のランダム化単位カウントを保持するステージファネルを構築します。

ステージ	質問	典型的な原因
割り当て（Assignment）	ハッシュと設定によって期待通りの分割が生成されたか？	誤った割り当て、ソルトの変更、不安定なID、重複
露出（Exposure）	割り当てられたユーザーは意図したバリアントを受け取ったか？	デプロイの失敗、キャッシュ、リダイレクト、利用できないクライアント
トリガー（Trigger）	トリートメント前に適格性を知ることはできたか？	バリアント専用のログ記録、トリートメントによるトリガー確率の変化
ログ処理（Log processing）	両方のバリアントがファクトテーブルに等しく取り込まれたか？	イベントの欠落、不適切な重複排除、botフィルター、結合のドロップ
分析（Analysis）	クエリは割り当てセマンティクスを保持しているか？	トリートメント後のフィルター、不均等な期間ウィンドウ、一貫性のない除外

割り当ての時点ですでに不均衡である場合は、実験設定、バケッティングコード、およびランダム化IDを検査します。割り当ては正常であるものの露出で乖離している場合は、バリアント固有の読み込み失敗、クラッシュ、およびリダイレクトを調査します。トリガーされていない母集団は正常であるものの、「チェックアウトを訪問したユーザー」で乖離している場合は、トリガーがトリートメントの影響を受けているか、コントロール群で欠落していないかを判断します。最終的なファクトテーブルでのみ乖離している場合は、フィルタリング、重複排除、および結合に焦点を当てます。

ステップ3：時間とセグメントを用いて原因を局所化する。

時間ごとの累積の観察カウントと期待カウントをプロットし、乖離がいつ始まるかを特定します。突然の不連続性は、設定、デプロイ、またはパイプラインの変更を示唆します。実験開始時からの持続的な偏差は、バケッティングまたはトリガーの欠陥とより整合性があります。セグメントサイズ、方向、および最初の異常発生時刻を示しながら、プラットフォーム、ブラウザ、アプリバージョン、地理、ログイン状態、識別子タイプ、およびトラフィックソースごとにセグメント化します。

セグメンテーションは診断ツールであり、偶然SRMを通過するサブグループを探すための手段ではありません。多くの切り口（スライス）を作成すれば、自然といくつかの小さなp値が生成されます。有用なスライスとは、メカニズムを裏付けるものです。SRMが特定の古いiOSバージョンに集中しており、そのバージョンでトリートメントの露出ログが欠落している場合は、クライアント配信とテレメトリを検査します。単にiOSを除外して、残りの実験が信頼できると宣言してはいけません。

ステップ4：ランダム化と識別子のセマンティクスを検証する。

バケッティングは、安定したランダム化ID、実験ID、および固定ソルトの決定論的関数である必要があります。同じ単位は、実験全体を通じて1つのバリアントにとどまる必要があります。以下を確認してください。

1つのランダム化単位が複数のバリアントに現れていないか。
匿名IDがアカウントIDにマージされる際に再割り当てされていないか。
Cookieの消去やクロスデバイスの使用によって「新規ユーザー」が繰り返し作成されていないか。
従業員、bot、および除外ルールが割り当ての前後で一貫して適用されているか。
すべてのランプアップ設定に監査可能な有効タイムスタンプがあるか。

ワークスペースまたは世帯のランダム化の場合、まずクラスター数をテストします。トリートメントバリアントが偶然いくつかの大規模なワークスペースを受け取り、バケッティングの欠陥なしにメンバー行の比率が51/49を示すことがあります。メンバー行を独立したランダム化サンプルとして扱うと、偽陽性のアラート（誤検出）が発生します。

ステップ5：トリートメント後の選択バイアスとデータの欠落を監査する。

有効なトリガーは、可能な限りトリートメント前に利用可能な情報から決定される必要があります。「チェックアウトに到達した」は、両方のバリアントで記録されたページの露出を通じて定義できます。「トリートメントの新しいクーポンボタンをクリックした」は、コントロール群に対応する観測がなく、当然トリートメント群のユーザーを多く選択することになります。また、トリートメントのパフォーマンスによってテレメトリの完了率が変化することもあります。bot、タイムアウト、およびエラーのフィルターによって、変更の影響を最も受けたユーザーが削除される可能性があります。

欠落しているユーザーがランダムであると仮定してはいけません。不変の割り当てログを各下流テーブルと比較し、欠落しているIDをサンプリングして、そのプラットフォーム、時間、バージョン、および行動を調査します。トリートメントがユーザーの分析テーブルへの取り込み確率に影響を与える場合、観察されたコンバージョンの差には選択バイアスが含まれます。

ステップ6：修復、再構築、または再実行を選択する。

誤った割り当てまたはバリアント間のユーザー重複：停止し、割り当てを修復し、再度ランダム化して再実行します。
割り当てと露出は完全であるが、ETLで可逆的なドロップがある場合：ジョブを修復し、偏りのないrawイベントから再構築して、SRMを再実行します。
トリートメントに依存するトリガー：トリートメント前の条件を使用するか、トリガーされていないITT（intent-to-treat）母集団に戻します。
バックフィル不可能なクライアントバージョンでの必要なテレメトリの欠落：計測を修正し、その対象母集団に対して再実行します。
計画された割り当てのランプアップ：各設定インターバルからの期待カウントを合算し、設定履歴を保持します。

重み付け（ウェイティング）は、選択メカニズムが既知であり、推定可能で、独立して検証されている場合にのみ正当化されます。ほとんどのSRMは、欠落メカニズムが不明であることを示しています。合計が50,000のように見えるまで49,000人のトリートメントユーザーに重みを掛けても、欠落したユーザーの行動は復元されず、ランダム化も回復しません。

ステップ7：実験プラットフォームに防止策を組み込む。

不変の割り当てレコード、設定された比率、および有効タイムスタンプを保持します。割り当て、露出、トリガー、および分析された母集団に対してSRMを個別に計算します。整合性チェックに合格するまで、ビジネス結果によってリリース決定を下してはなりません。プロダクトの違いが存在しない場合にバケッティング、テレメトリ、および分析が正常であることを確認するために、定期的なA/Aテストを実行します。

アラートには、合計サイズ、観察カウントおよび期待カウント、p値、方向、最初の異常発生時刻、および主要なセグメントを含める必要があります。デプロイ、識別子、bot検出、またはETLの変更後は、監視を強化します。ダッシュボードの画像のみを保存するのではなく、過去の設定から期待カウントを再現できるように、実験終了後も十分なリネージを保持してください。

質の高い模範解答

「報告された1.8%のリフトは比較可能なランダム化サンプルを前提としているため、リリースはしません。設定された50/50の分割比率では、コントロール群51,000人とトリートメント群49,000人の期待カウントはそれぞれ50,000人です。自由度1におけるカイ二乗統計量は40であるため、p値は約2.54 × 10^-10です。この実験にはSRMが存在するため、ビジネス上の結論を凍結します。

まず、ユーザーが実際のランダム化単位であること、および実行全体で50/50が適用されていたことを確認します。次に、割り当て、実際の露出、トリガー適格性、イベントファクトテーブルへの取り込み、および最終分析を通じてカウントを比較します。最初に乖離したステージによって調査方針が決まります。割り当てのSRMは、設定、安定したID、ソルト、またはバリアント間の重複を示唆します。割り当ては正常だが露出が不均衡である場合は、デプロイ、パフォーマンス、クラッシュ、またはリダイレクトが疑われます。トリガーのみのSRMは、トリートメントに依存する条件を示唆します。最終テーブルのSRMは、テレメトリ、botフィルタリング、重複排除、または結合の問題を示します。

都合の良いクリーンなサブグループを恣意的に選ぶ（チェリーピッキングする）のではなく、あるメカニズムの証拠を見つけるために、時間、プラットフォーム、アプリバージョン、地理、ログイン状態、およびIDタイプごとにセグメント化します。偏りのないrawイベントで母集団を再構築できる場合は、パイプラインを修復し、すべての完全性チェックを再実行します。ユーザーがバリアントをまたいでいた場合、トリガーがトリートメントに依存している場合、または必要なテレメトリが復元できない場合は、システムを修復して実験を再実行します。

防止策として、プラットフォームはビジネス結果を開示する前にSRMを実行し、不変の割り当ておよび配分履歴を保持し、割り当て、露出、トリガー、および分析の各カウントを個別に監視する必要があります。A/Aテスト、安定したバケッティング、およびトリートメント前のトリガーによってプロセスを検証します。根本原因が説明され、修復された母集団がSRMを通過した後にのみ、1.8%のリフトとガードレールメトリクスを再検討します。」

よくある間違い

結果のp値が小さいからといってリリースする → 効果の推論は比較可能なサンプルを前提としている → まずSRMとデータの完全性チェックに合格すること。
51/49の割合（パーセンテージ）だけを見る → 同じ比率でもサンプルサイズが異なれば統計的証拠も異なる → 期待カウントと統計検定を使用すること。
SRMを乱数の問題としてのみ扱う → 実行、ログ、フィルターによってもユーザーが排除される → 全経路を通じて最初の乖離を追跡すること。
カウントが近づくのを待つ → 偏ったデータを増やしてもランダム化は回復しない → 決定を凍結し、直ちに診断すること。
50/50に直接リウェイティング（再重み付け）する → 重み付けでは体系的に欠落した行動を回復できない → 検証された欠落モデルの下でのみ修正すること。
最終的な分析テーブルのみを確認する → 割り当てまたは下流の処理のどちらが失敗したかが隠れてしまう → すべてのステージでカウントを保持すること。
トリートメント専用の行動をトリガーにする → コントロール群がサンプルに入る機会が均等でなくなる → トリートメント前の対称的な条件を使用すること。
クラスター実験でメンバー行を検定する → クラスターサイズのばらつきにより誤ったSRMが発生する → まず実際のランダム化単位をテストすること。
結果を見た後に問題のあるプラットフォームを除外する → 事後的な母集団選択はバイアスを生む → 診断にはスライスを使用し、計画された母集団で再実行すること。
修復後に古いエフェクトレポートを再利用する → 欠陥のあるサンプルから計算されたものである → 完全性、エフェクト、およびガードレール分析を再生成すること。

フォローアップの質問と回答

フォローアップ1：分割比率が51/49のままで、総サンプル数が1,000人のみの場合はどうなりますか？

期待カウントはそれぞれ500で、観察カウントは510と490です。カイ二乗統計量は(510 - 500)² / 500 + (490 - 500)² / 500 = 0.4となり、自由度1でのp値は約0.527になります。これはSRMを示す証拠としては不十分です。これが、固定的な「1パーセントポイント以上」といったルールが統計的検定の代わりにならない理由ですが、既知のエンジニアリング上の欠陥については依然として調査されるべきです。

フォローアップ2：全体的な割り当てはSRMを通過していますが、iOSユーザーで失敗しています。この実験はまだ使用できますか？

スライスの数、iOSのサンプルサイズ、および1つのメカニズムが異常を説明できるかどうかを検討してください。SRMが事前に指定された重要なiOSバージョンに集中しており、露出の欠落によってそれが説明される場合、その母集団の結果は信頼できません。他の母集団が引き続き使用可能かどうかは、分析計画および原因が真に分離されているかどうかによります。結果を見た後でiOSだけを除外してはいけません。クライアントを修復し、計画された対象母集団に対して再実行する方が安全です。

フォローアップ3：トリガーされていない母集団は正常ですが、トリガーされた分析でSRMが発生しています。最も可能性の高い原因は何ですか？

まずトリガーを調査してください。一方のバリアントでのみログが記録されているか、トリートメントによって引き起こされた行動に依存している可能性があります。新しいコンポーネントをクリックするのではなくページに到達するなど、トリートメント前に両方のグループが満たすことができる条件に置き換えます。また、トリガテレメトリのカバレッジを比較してください。トリガーされていないカウントが正常であることは、ベースとなる割り当てが健全である可能性を示唆しますが、トリガーされた効果分析を検証するものではありません。

フォローアップ4：観察されたサイズでグループを再重み付けしないのはなぜですか？

SRMは誰が欠落しているかを特定しません。トリートメントによって最もアクティブなユーザー、最もコンバージョン率の高いユーザー、または最もクラッシュしやすいユーザーが失われた場合、カウントの重み付けは合計を復元するだけであり、行動の分布は復元しません。選択確率がトリートメント前の変数によって完全に説明され、モデルが検証されている場合は修正が可能かもしれませんが、それは追加の仮定であり、デフォルトの救済策ではありません。

フォローアップ5：ワークスペースは50/50でランダム化されましたが、ユーザーカウントは55/45です。これはSRMですか？

まずワークスペースのカウントを確認してください。ワークスペースの割り当てが50/50であっても、トリートメント群が偶然いくつかのアカウント規模の大きいワークスペースを受け取った場合、メンバーの不均衡はバケッティングの失敗ではなく、通常のクラスターサイズのばらつきである可能性があります。結果の分析では、ワークスペース内の依存性も考慮する必要があります。バランスの取れたメンバートラフィックが必要な場合は、後からメンバー行を独立した割り当てとして扱うのではなく、実験設計においてサイズ層別化またはマッチドランダム化を使用してください。

フォローアップ6：実験が10/90から50/50にランプアップしました。期待カウントはどのように計算しますか？

各割り当てインターバル内で期待カウントを計算し、それらを合算します。10/90の下で20,000人のユーザーが流入し、50/50の下で80,000人が流入した場合、総期待カウントはそれぞれ50,000人ではなく、42,000人と58,000人になります。割り当て時にアクティブだった設定と有効時間を使用してください。実験全体に対して最終的な分割比率を遡及的に適用してはいけません。