サンプル比率の不一致

Amplitude実験では、観測されたバリアント割り当てが指定された割り当てと大きく異なる場合にサンプル比率不一致（SRM）が発生します。たとえば、実験トラフィックの 50% をコントロールに、50% をトリートメントに割り当てた場合、コントロールが 55% に対してトリートメントが 45% という比率が観察されます。

SRMはデータにバイアスがあることを示しており、これを解決しないと予期しない結果につながる可能性があります。SRMが発生した実験の結果は、疑わしいものとして扱います。

Amplitude は、SRM を検出するためにシーケンシャルバージョンのカイ2乗検定を alpha = .01と共に使用します。

このガイドでは、SRMの原因を最も一般的なものから順に説明し、それぞれの原因をデバッグする方法を説明します。このページでは、エンドツーエンドの実験プロダクトを使用していることを前提としていますが、これらの手順の多くは、実験結果で設定された実験に適用できます。

Amplitude エクスポージャーイベントとカスタムエクスポージャーイベントの比較

AmplitudeはAmplitude エクスポージャーイベントを推奨しています。クライアント側のSDKでは、Amplitudeはバリアントをフェッチしたときではなく、バリアントがキャッシュから読み込まれた時点で露出イベントを自動的に追跡します。ローカル評価では割り当てイベントは生成されないため、カスタム露出イベントを使用する必要があります。

カスタム露出イベントを使用している場合は、ユーザーがそのバリアントを体験したときにそのイベントを送信してください。 カスタム露出イベントは割り当ての前に発生することがあります。 この場合、ユーザープロパティはまだ設定されていないため、Amplitudeは最初のカスタム露出イベントを分析の露出としてカウントしません。 Amplitudeの露出イベントには追加料金は発生しません。

実験期間中にバリアント分布の重みが変更されました

ベストプラクティスとして、ユーザーがバリアント間を移動するような方法で実行中の実験を変更しないでください。このような変更により、SRM が引き起こされる可能性があります。

たとえば、50% のトリートメント / 50% のコントロールを 60% のトリートメント / 40% のコントロールに変更すると、実験の実行中にユーザーがバリアント間を移動してしまう可能性があります。SRM テストでは、実験の実行中もトラフィック割り当ては変更されないと仮定しています。 実験中にトラフィック割り当てを変更すべきでない理由についての詳細なコンテキストについては、「Amplitude実験における累積エクスポージャーグラフの解釈」を参照してください。

分析ウィンドウが始まる前に実験のエクスポージャーが開始されました

あるバリアントによってユーザーがプロダクトを再訪することが多くなる場合、そのバリアントは公開ウィンドウと分析ウィンドウが一致していない場合に予想以上に多くのユーザーを表示することがあります。

分析ウィンドウとトラフィックウィンドウが異なる場合は、分析ウィンドウを変更してトラフィックウィンドウ全体をカバーし、SRM が残っているかどうかを確認してください。

バリアント・ジャンプ

バリアント ジャンプとは、ユーザーがあるバリアントから別のバリアントへ（場合によっては複数回）移動する場合を指します。 バリアントジャンプにより、メトリックを特定のバリアントに帰属させることが困難になります。Amplitude実験の組み込み診断機能には、バリアント間を移動するユーザーの割合を追跡するチャートが含まれています。

ユーザーがバリアント間を切り替えた場合は、その原因が匿名ユーザー（頻繁にログインおよびログアウトするユーザー）であるか、デバイスIDの変更であるかを確認してください。このことをユーザーストリームで確認してください。

ベストプラクティスとして、ユーザーがバリアント間を移動するような方法で実行中の実験を変更しないでください。このような変更により、SRM が引き起こされる可能性があります。

1つのバリアントについて割り当てからエクスポージャーにコンバージョンしたユーザー数が大幅に増加

「割り当てからエクスポージャーへのファネル」チャートは、実験の「診断」カードで確認できます。コンバージョン率とサンプルサイズをこの計算機に入力すると、メトリクスが95%レベルで統計的に有意かどうかを確認できます。 割り当てイベントはユーザーをランダムに割り当てられた2つの等しいコホートに分割するため、バリアント間のコンバージョン率はランダム性の範囲内で類似している必要があります。Amplitudeはユーザーがバリアントを体験する直前に露出イベントを送信するため、ユーザーは割り当てと露出イベントの間で同じ体験を得ることができます。

実験で追加または削除されたバリアント

実験の実行中にバリアントを追加または削除すると、SRM が発生する可能性があります。 ベストプラクティスとして、ユーザーがバリアント間を移動するような方法で実行中の実験を変更しないでください。

実験中のスティッキ バケットの有効または無効

実行中の実験でスティッキ バケット設定を有効または無効にすると、期待するバリアントとユーザーが受け取るバリアントとの間に不一致が生じる可能性があります。 実験でスティッキー バケット設定を有効にした後、Amplitudeは現在のターゲティングに関係なく、各ユーザーを常に以前にバケット設定された同じバリアントに評価します。これは後でスティッキー バケット設定を無効にした場合でも同様です。

ユーザーの特定のセグメントに影響を与えた変更

SRM が特定のユーザーセグメントにのみ影響を与えるかどうかを確認してください。 たとえば、国、OS バージョン、アプリのバージョン、またはプラットフォームでフィルタリングできます。

この種の問題のトラブルシューティングを行うには、この変更によって影響を受けた特定のユーザーを特定します。次のような質問をしてください。

• 誰かが計測バグを一部のユーザーが使用しているアプリバージョンにプッシュしましたか？
• 特定の国のユーザーのみに影響を与える変更を誰かがプッシュしましたか？

多数のユーザーの個別割り当て

多数のユーザーを個別に割り当てたかどうかを確認してください。個々の割り当てはランダムではなく、割合を歪めることがあり、それがSRMの原因となる可能性があります。

実験に少数のユーザーを個別に追加しても問題ありませんが、多くのユーザーを追加することは避けてください。

最初の実験

最初の実験でSRMが表示された場合、原因は計装のバグである可能性があります。複数の SRM がある場合、SRM が誤検出に起因することはほとんどありません。根本原因を特定する必要があります。

ユーザーが頻繁にログアウトする

頻繁なログアウトは、バリアントのジャンプチャートに表示されることがあります。 この実験により、ユーザーが頻繁にログアウトするようになったかどうかを確認してください。 このパターンは金融機関で一般的であり、アプリケーションはユーザーを 15 分間非アクティブにするとログアウトします。

1. ログアウト時に、アプリケーションはデバイスIDを再生成します。
2. Amplitudeはセッションを新しいユーザーとして扱います。
3. Amplitudeはユーザーを別のバリアントに振り分けます。
4. ユーザーIDは後で解決されます。

このパターンは、サインアップフロー実験の匿名ユーザーにも関連している可能性があります。

欠落しているエクスポージャー

2人のユーザーが同じイベントシーケンスを持っているが、一方のユーザーがエクスポージャーイベントを欠落しているかどうかを確認してください。エクスポージャーイベントを送信しない場合や、送信すべきでないときに送信してしまう場合があります。

フォールバックバリアントのエクスポージャーを誤って送信しています

実験 SDK を使用してエクスポージャーを自動的に追跡していない場合は、フォールバック（デフォルト）バリアントのエクスポージャーを誤って送信していないかどうかを確認してください。

フラグがデフォルトでコントロールに設定されており、フラグが時間内にレスポンスを返さなかった場合、Amplitude はそれをエクスポージャーとみなすケースを確認してください。この場合、コントロールはトリートメントよりも多くのエクスポージャーを伴います。