A/Bテストのベストプラクティス

ここでは、A/Bテストのデザインやメンテナンスに役立つベストプラクティスを紹介します。始める前に、テストで使えるさまざまな設定アトリビュートやメトリクスについてしっかりと理解しておきましょう。

A/Bテストのステージ

A/Bテストには、3つのステージがあります。

  • デザイン – テストはまだ実施されていません。このフェーズでは、仮説、キーメトリクス、ガードレールメトリクス、コントロールグループのエクスペリエンス、トリートメントグループのエクスペリエンスを定義します。
  • 実行中 – テストを実施中です。このフェーズでは、あらかじめ定義した割合のユーザーが、テストのトリートメントバージョンを受け取ります。
  • 分析 – テストは終了しました。このフェーズでは、収集した結果を分析し、それらの情報に基づいて、今後スキルのコントロールバージョン、トリートメントバージョンのどちらを使うかを判断します。

よくある質問

デザインのベストプラクティス

A/Bテストをデザインする際、どのような点に留意すればよいですか？

次の点について考えておく必要があります。

  • キーメトリクス – トリートメントバージョンでテストしている仮説を評価するのに最適なメトリクスのセットです。
  • テスト固有のガードレールメトリクス – テストに実質的に含まれる一連のメトリクスで、意図しない形でのスキルの機能低下やユーザーエクスペリエンスの低下を検出します。
  • ローンチ基準 – トリートメントバージョンをすべてのユーザーにローンチすることが正しい選択かどうかを確認するために使う、一連の変更です。これらが満たされた場合にローンチできます。注： A/Bテストのデザインスキーマには、これらの値に使える専用のフィールドはありません。これらの値は、自身で定義し、追跡する必要があります。
  • テストの規模 – キーメトリクスが期待どおりの力を発揮できるよう、テストに含める必要のあるユーザーの数です。例：サンプルサイズなど。注： A/Bテストのデザインスキーマには、これらの値に使える専用のフィールドはありません。これらの値は、自身で定義し、追跡する必要があります。
仮説とは何ですか？

仮説とは、A/Bテストの最も重要な要素の1つです。仮説により、テストコンテンツで期待される効果を主張します。たとえば、「アップセルメッセージのコンテンツを変更すると、売上が伸びる」などといった仮説があります。 仮説の是非を主張し、証拠を見つけることで、テスト結果以上の成果を商品にもたらすことができます。

帰無仮説とは何ですか？

帰無仮説とは、2つのテストグループ（コントロールおよびトリートメント）で測定した反応に差がないデフォルトの状態のことです。

キーメトリクスとは何ですか？

キーメトリクスとは、トリートメントによってユーザーエクスペリエンスにもたらされた意図した変化が、明らかな証拠を提示すると期待される（検知できる）最適なメトリクスです。キーメトリクスは、テストの意図した結果を測定できなければなりません。キーメトリクスは、A/Bテストのデザインステージで決める必要があります。テストを開始する前に、トリートメントバージョンをすべてのユーザーにローンチするか（しないか）（そして、新たなコントロールバージョンとするか）を判断するのに最も重要な役割を果たすのはどのメトリクスかを決定します。

ガードレールメトリクスとは何ですか？

A/Bテスト固有のガードレールメトリクスは、トリートメントによって発生したユーザーエクスペリエンスの低下を検出すると期待される（検知できる）最適なメトリクスです。ガードレールメトリクスは、トリートメントバージョンにより意図せず発生する可能性のある逆の行動についての、最も可能性の高い予測となります。テスト固有のガードレールメトリクスは、A/Bテストのデザインステージで定義する必要があります。テストを開始する前に、トリートメントバージョンをすべてのユーザーにローンチするか（しないか）を判断するのに最も重要な役割を果たすのはどのメトリクスかを決定します。

A/Bテストのキーメトリクスはどのように選択すればよいですか？
立てた仮説に基づいて、ユーザー行動の変化を追跡できるキーメトリクスを、1～3個選択する必要があります。たとえば、ISPのアップセルメッセージの場所を変更することでユーザーのサブスクリプションが増えるという仮説を立てた場合、ISPの受け入れ率とISPのコンバージョン率をキーメトリクスとして選択します。
偽陽性の結果とは何ですか？
偽陽性とは、帰無仮説が真であるにもかかわらず棄却されることです。第一種過誤と呼ばれることもあります。
キーメトリクスを1～3個しか選ばないのはなぜですか？
1～3個のキーメトリクスを選択することで、偽陽性率が低下します。これは、複数の仮説をテストする場合に有効です。同じデータに対して複数の仮説のテストを行うと、偽陽性率が高くなります。これは、テストを増やしたにもかかわらず、個々のデータポイントが変わっていないためです。
ガードレールメトリクスはどのように選択すればよいですか？
ガードレールメトリクスは、ユーザーベースに対するあらゆるマイナスの結果を管理できるように選択する必要があります。ガードレールメトリクスは、エンゲージメント、リテンション率、収益化といったユーザーのすべての行動カテゴリーをカバーする必要があります。たとえば、ユーザーのリテンション率をテストする仮説を立てた場合、ダイアログが中断されないこと、手間が増えないこと、スキルの収益が下がらないことを確認するためのガードレールメトリクスを使用します。

テスト実行中のベストプラクティス

A/Bテストの実行中には何を監視すればよいですか？
テストを開始したら、スキルで意図しないバグ、エラー、停止、スロットリングが発生していないかどうかを監視する必要があります。また、ガードレールメトリクスを監視して、トリートメントグループのエクスペリエンスによってスキルのエクスペリエンスが大きく低下していないことも確認する必要があります。さらに、テストの開始から少なくとも3日間は、スキルのパフォーマンスを十分に監視する必要があります。
A/Bテストはどのくらいの期間実施すればよいですか？
A/Bテストは、数週間にわたって実施する必要があります。たとえば、7日間、14日間、21日間などです。これにより、「曜日」による影響を抑えることができます。こうすることで、１つのキーメトリクスが統計上有意な結果に達した時点でテストを終了してしまったり、改変したりすることを防ぐことができます。同様に、事前に定義した特定のローンチ条件を満たす目的で、テストを延長するべきではありません。
A/Bテストの実施中に、コードのバグが見つかった場合はどうすればよいですか？
コードのバグが見つかった場合は次のアクションを実行します。
  1. A/Bテストを直ちに無効にして、ユーザーにマイナスの影響が及ばないようにします。
  2. コードを修正し、変更を公開バージョンにプッシュします。
  3. トリガーの再設定を行い、準備ができ次第、新しいA/Bテストを開始します。コード変更前に収集したデータは、ローンチの判断に一切使用すべきではありません。
A/Bテスト実施中にトリートメント割り当てアラーム（TAA）を受け取りました。どうすればよいですか？
詳細については、問題： A/Bテスト実施中にトリートメント割り当てアラーム（TAA）を受け取ったを参照してください。
TAAアラームが偽陽性かどうかはどのように判断すればよいですか？
すべての統計学的テストでは偽陽性の結果が出る可能性があります。たとえば、第一種過誤率などです。統計学的テストでは絶対に確実ということはありません。

分析のベストプラクティス

P値とは何ですか？
P値とは、帰無仮説が真であると仮定したときに、特定の結果（またはより極端な結果）が得られる確率（最小値はゼロ）のことです。
信頼区間とは何ですか？
信頼区間とは、対象となるパラメーターの特定の測定値に関連する不確かさを表す方法の1つです。
平均トリートメント効果（ATE）とは何ですか？
平均トリートメント効果（ATE）は、トリートメントグループとコントロールグループの平均の差です。つまり、ATE = 平均（トリートメント） - 平均（コントロールとなります。
A/Bテストを分析する際に考慮すべき点は何ですか？
統計上有意な平均トリートメント効果（ATE）のある各キーメトリクスについて、以下の項目を確認してください。
  • 相対変化の95%信頼区間
  • 得られた結果のP値
  • （任意）ATEの差分（%）

また、ガードレールメトリクスがスキルのエクスペリエンスを下げないようにします。たとえば、以下のようなテストの概要を記述できます。

アクティブ日数のメトリクス（キーメトリクス）に関しては、相対的な差分の増加の95%信頼区間が、（0.37%、1.44%）でP値0.001となります。したがって、トリートメントバージョンのアクティブ日数が増加したことの、非常に強力な証拠があります。さらに、ガードレールメトリクスに関して、スキルエクスペリエンス低下の証拠はありません。

A/Bテストを分析する際に避けるべきことは何ですか？
最良の結果を得るためには、これらのよくある分析行動はとらないでください。
  • 異なる期間でメトリクスを分析しないでください。代わりに、同じテスト期間で、同時にすべてのメトリクスを分析します。
  • テストのトリートメントバージョンを公開する唯一の理由として、ガードレールメトリクスを使用しないでください。ガードレールメトリクスは、意図しない結果のためにテスト開始を退ける強力な証拠がある場合にのみ使用します。
  • 最初のローンチ基準に含まれないメトリクスを報告しないでください。判断は、キーメトリクスにおける意図した変化のみに集中する必要があります。
A/Bテストの終了時に行うことのできる判断にはどのようなものがありますか？
A/Bテストを終了したら、以下のアクションを実行する必要があります。
  • ローンチ基準の評価 – テストが成功したか、仮説が検証されたかを判断します。
  • 公開の審査 – テストのトリートメントバージョンを公開してもよいかどうかを判断します。また、テスト以外の要因についても考慮する必要があります。たとえば、トリートメントバージョンがコントロールバージョンのパフォーマンスを上回っていることはテストの評価で判明したけれども、この新バージョンをローンチするコストが見合わないので、当面は公開を見合わせるケースなどです。
  • 結果の調査 – テスト結果を詳細に分析し、キーメトリクスやガードレールメトリクスがなぜ低下したのかを判断します。問題を発見したら、テストのトリートメントバージョンに適切な調整を加え、テストを再度実施します。
  • テストの再実施 – テストをもう一度行うべきかどうかを判断します。テストの欠陥やデータの偏りに気付いた場合は、再実施してもよいかもしれません。
  • 中止 – テストを中止すべきかどうかを判断します。トリートメントバージョンの結果がスキルにとって有益でないと判断した場合は、テストを中止してもよいかもしれません。
  • ユーザートラフィックを増やす – サンプルサイズを増やすべきかどうかを判断します。サンプルサイズが十分でなく、統計上有意な結果が得られない場合は、増やしてもよいかもしれません。この時点で、トリートメントバージョンにユーザートラフィックを追加して、テストを再実施します。

このページは役に立ちましたか？

最終更新日: 2023 年 04 月 03 日