A/A テストを実行する

A/A テストは品質保証手法であり、2 つの同一のバリエーションを使用して実験を実施して実験設定を検証します。 A/B テストとは異なり、A/A テストは同じエクスペリエンスを得る 2 つのグループにトラフィックを分割します。

A/A テストを実施する理由

A/A テストは、実際の実験を実行する前に、実験インフラストラクチャが正しく機能していることを検証するのに役立ちます。 A/A テストは次の場合に役立ちます。

• **初めての実験のセットアップ。**SDK連携、トラフィック割り当て、メトリック追跡が適切に機能していることを検証します。
• 新しいメトリックの実装。 新しい成功指標が期待どおりに動作し、誤検出が発生していないことを確認します。
• 予期しない結果を診断する。 A/Bテストで意外な結果が得られた場合の実装上の問題を排除します。
• 大規模なテスト。 大量のトラフィックに対してランダム化が正しく機能することを確認してください。

A/Aテストで検出される一般的な問題

A/A テストは、いくつかの実装上の問題を明らかにする可能性があります。

• 不適切なランダム化。 Amplitudeはユーザーをバリアント間で均等に分散させていないため、サンプル比率の不一致が生じたり、ユーザーがバリアント間を移動してセッションやページの読み込みごとに異なるエクスペリエンスを得たりすることがあります。原因と修正の詳細については、「バリアントのジャンプ」を参照してください。
• 不整合の追跡。 タイミングの問題や条件付きロジックエラーのため、イベントの発生方法はバリアント間で異なります。
• サンプル汚染。 露出前バイアスは、Amplitudeがバリアントに割り当てる前にユーザーがコンテンツを取得した場合に発生します。
• 統計情報の設定。 不正確な有意閾値、または適切な修正なしに行われる多重検定。

A/A テストを実行するタイミング

A/A テストは診断ツールであり、日常的な運用ではありません。設定を検証する必要がある場合は、戦略的にそれらを実行してください。

A/A テストを実施する正当な理由

• 初期設定。 Amplitude 実験を初めて実装。すべてが正しく動作することを確認してください。
• インフラストラクチャの大幅な変更。 SDKバージョンの更新、トラッキング実装の変更、または新しいプラットフォームへの移行後。
• 予期しない結果のトラブルシューティングA/Bテストで意外な結果が出て、実際のユーザーの行動の違いではなく技術的な問題を疑う場合。
• 新しいチームメンバー。 エンジニアをオンボードして実験を行う場合、A/Aテストによって実装を実際に検証できます。

次の場合のA/Aテストを実行しないでください。

• セットアップをすでに検証済みの場合の定期的な実験。
• あらゆる新しい実験 実験ごとにA/Aテストを実行するとトラフィックが浪費され、実際のインサイトが得られるのが遅れます。
• 特定の懸念事項を伴わない検証。

Web 実験でA/Aテストを実行する

カスタムコードのアプローチ

1. Web Experimentで新しい実験を作成します。
2. トラフィックを50/50に分割して2つのバリアント（コントロールとテスト）を設定します。
3. 両方のバリアントで、同じ変更を適用します：
   • オプション 1: カスタムコードを使用してconsole.logステートメントを追加します: console.log('A/A test variant');。
   • オプション 2: ユーザー体験に影響を与えない HTML コメントを挿入してください: ``。
4. 成功指標（検証したいコンバージョンイベント）を設定します。
5. 少なくとも1つの完全なビジネスサイクルについて実験を実行してください。
6. 結果を分析して、バリアント間に有意な差がないことを確認します。

ビジュアルエディタのアプローチ

1. Web Experimentで新しい実験を作成します。
2. トラフィックを50/50に分割して2つのバリアント（コントロールとテスト）を設定します。
3. 各バリアントについて、ビジュアルエディタを開きます。
   1. バリアントを選択して、サイト上のビジュアルエディタを開きます。
   2. 要素セレクタを使用して、ページ上の任意の要素（ヘッダー、ボタン、divなど）を選択できます。
   3. [その他] を選択し、右側のパネルで要素選択フィールドを見つけます。
   4. セレクターをページ上のどの項目にも一致しない無効なものに変更します (例: #nonexistent-element-aa-test)。
4. 成功指標（検証したいコンバージョンイベント）を設定します。
5. 少なくとも1つの完全なビジネスサイクルについて実験を実行してください。
6. 結果を分析して、バリアント間に有意な差がないことを確認します。

このアプローチにより、ユーザーに表示されるものを何も変更することなく、実験が適切にロードされ、トラッキングされます。

フィーチャーエクスペリメントでA/Aテストを実行する

1. 2つのバリアントを持つ新しいフラグベースの実験を作成します。
2. 両方のバリアントが同じフィーチャーフラグ値または設定を返すことを確認してください。
3. コードにフラグを実装しますが、その体験はバリアントに関係なく同じです。
4. 両方のグループについて同じコンバージョンイベントを追跡します。
5. 数日間実験用ダッシュボードをモニターして、トラフィック分布とメトリック追跡が適切であることを検証します。

A/A テスト結果を解釈する

A/A テストではランダムな変動が予想されます。 健全なA/Aテストの重要な指標は、変異体間に統計的に有意な差がないことです。

成功した A/A テスト

バリアント間に統計的に有意な違いはなく、Amplitudeはトラフィックを均等に分割し、メトリックは同等です。自信を持って実際のA/Bテストを実行できます。

A/Aテストに失敗

統計的に有意な結果はすべて、調査が必要な潜在的な実装上の問題を示しています。 大きな違いがある場合は、以下を確認してください。

• 実験ダッシュボードでのトラフィック割り当て率。
• バリアントに異なる影響を与える可能性がある条件付きロジックのイベントトラッキング実装。
• 実験は結果に影響を与える可能性のあるページのコンテンツよりも前に開始されること。
• Amplitude は、両方のバリアントにわたって一貫してメトリクスを計算します。

ベストプラクティス

• **代表的なトラフィック発生期間にA/Aテストを実行します。**結果を歪める可能性がある休日や異常なトラフィックパターンは避けてください。
• 実際の実験に使用するのと同じサンプルサイズを使用してください。 サンプルサイズを一致させることで、統計的検出力計算が有効になります。
• 最も重要な指標をテストしましょう。 ビジネスにとって最も重要なコンバージョンイベントに焦点を当てましょう。
• 設定を文書化してください。 A/Aテストはベースライン検証として機能し、今後の実験のトラブルシューティングを行う際に参照できます。
• **ノイズを過剰に解釈しないでください。**ランダムな変動を想定してください。 バリアント間のパーセンテージ差の大きさよりも統計的有意性に重点を置いてください。
• **バリアントジャンプが発生することを想定してください。**ごく一部のユーザーは、セッション間で異なるバリアントを取得することがあります。 バリアントジャンプは正常な現象であり、適切に設定されたテストでは統計的に有意な差異を引き起こすことはありません。

A/Aテストをスキップすべき場合

A/Aテストは貴重な検証ツールですが、すべての実験でテストを実行する必要はありません。次の場合、A/Aテストをスキップしてください。

• 実績のあるインフラストラクチャを備えた成熟した実験プログラムがあります。
• あなたは以前に検証したものと同じような実験を行っています。
• 前回のA/Aテストは最近実施されたもので、クリーンな結果が得られました。
• 洞察を得るまでの時間は重要であり、お客様はご自分のセットアップに高い信頼性を有しています。

A/B テストで予期しない結果が発生した場合や、実装に大きな変更を加えた場合でも、A/A テストを使用することで技術的な問題を迅速に排除し、デバッグ時間を節約できます。