テストの設計

明確で有意義なビジネス仮説を確立するには、テストを設計するとき、次の問いを考慮してください。

どのような種類の変更を加えますか。
その変更によってどのようなメリットが期待されますか。
なぜその変更によってメリットが得られますか。

例: 検索結果ページで製品リストを単一列形式から二重列形式に変更すると、表示される製品オプションの数が増え、製品詳細ページへのクリックスルーが向上します。

仮説は、定量データ(Webアナリティクス、過去のテスト・データ、キャンペーン・インサイト、オーディエンス・インサイト、ヒートマップ)と、定性データ(ユーザー・テスト、フォーカス・グループ、顧客サポート・フィードバック)で通知されるようにする必要があります。

テストを定義する手順は、次のとおりです。

テスト・ページおよびエクスペリエンスを定義します。
プライマリ・メトリックを定義します。
信頼度レベルを定義します。
テスト設計を検証します。
低トラフィック・テストにあわせて調整します。
最小検出可能アップリフトを定義します。
最大許容テスト期間を定義します。

テスト・ページおよびエクスペリエンスの定義

次のようなテストの仮説および考慮事項に基づいて、1つまたは複数のページおよびエクスペリエンスを識別します。

既存のテストの結果に影響を与える可能性がある場合は、ページに他のテストを含めないでください。よくわからない場合は、1ページに1つのテストのみを設定してください。
ページのトラフィックは大きければ大きいほど望ましく、これは、短い時間枠内により多くのデータを収集できることでテスト期間が短くなるためです。
日々の一意の訪問者数とページのコンバージョン率がわかっている場合は、テスト開始前に平均テスト期間の予測を得ることができます。

各エクスペリエンスは、テスト中に検証されるビジネス仮説に対応しています。デフォルトのエクスペリエンスは、Webサイトの既存のバージョンに対応しています。テストが完了すると、仮説ごとに回答が生成され、変更を加えたことでページの既存バージョンと比較してメリットがあるかどうかが示されます。

エクスペリエンスの数を多くするとテスト期間が長くなるため、テストするエクスペリエンスの数を最小限まで減らすことをお薦めします。テストするエクスペリエンスの数が10を超える場合は、ビジネス目標を見直すことを検討してください。
A/Bテストまたはエクスペリエンスが2つ含まれるテストの場合は、トラフィックを等しく分割することをお薦めします。異なる数に分割することもできますが、テスト期間の観点からは最適でないとみなされることが一般的です。
エクスペリエンスが3つ以上含まれるテストの場合、コントロール・エクスペリエンスに送られるトラフィックの割合を大きくすることをお薦めします。これにより、トラフィックを等しく分割した場合に比べてテストの結論付けまでの時間が短くなる可能性があります。詳細は、最適なトラフィック分割の適用を参照してください。
テスト中は、エクスペリエンスの数とそのトラフィック・シェアを変えないことをお薦めします。高度なユースケースではテスト中のトラフィック抑制やエクスペリエンス除外がサポートされていますが、最大10エクスペリエンスに制限されています。詳細は、複数のメトリックがあるテストを参照してください。
コントロール・エクスペリエンスによってレポートのベースラインが決まり、アップリフトと信頼度のすべての比較はこのベースラインに対して行われるため、テスト中にベースラインを変えないでください。このコントロールは、別のエクスペリエンスとの比較を実行することが特に要求されないかぎり、Webサイトの既存バージョンである必要があります。

プライマリ・メトリックの定義

各テストには、次のプライマリ・メトリックが必要です。

テストにおける各エクスペリエンスの効果を測定するために使用されます。
ビジネス目標および対応する仮説から直接導出されます。
コンバージョン率、エンゲージメントまたは収益で測定できるアクション(カートへの追加、予約、購入など)。

重要: テスト中にプライマリ・メトリックを変更しないでください。

プライマリ・メトリックがファネルの最後のアクション(購入など)を追跡している場合、適切な時間枠内にテストを結論付けするための十分なトラフィックがあることを確認してください。テストの結論付けまでに時間がかかりすぎている場合、後続のテストではAddToCartなどの別のプライマリ・メトリックの使用を検討することをお薦めします。このメトリックにより、ビジネス要件にとって許容できる間接的な改善が得られることがあります。

例: 購入収益をプライマリ・メトリックとして使用してE-Store WebサイトのホームページでA/Bテストを実行したところ、購入のコンバージョン率が低いため、平均テスト期間が4か月となっています。AddToCartメトリックのコンバージョン率の改善に基づいて、テストを結論付けすることを決定しました。一般的に、このメトリックの方が高くなり、通常はテスト期間が短くなります。収益に与える影響を厳密には測定できません。

また、詳細なインサイトを得るために、最大10個のセカンダリ・メトリックを追跡できます。ただし、テストでセカンダリ・メトリックを使用すると、テストの分析や結論付けが難しくなります。意思決定にはプライマリ・メトリックのみを使用することをお薦めします。これらのガイドラインでは、テストにプライマリ・メトリックがあり、セカンダリ・メトリックがないことを前提としています。セカンダリ・メトリックが含まれるユースケースと、テストが結論付けされるケースについては、複数のメトリックがあるテストを参照してください。

信頼度レベルの定義

信頼度レベルによって、偽ウィナーが宣言されるリスクの許容範囲が決まります。テストが開始する前にこれについて合意するようにし、テスト中は変更しないでください。信頼度レベルは、キャンペーン仕様に必要な部分となり、テストの結論付けフェーズで使用します。

次の信頼度レベルがサポートされています。

推奨値は95%です。低トラフィックのサイト(エクスペリエンス当たり1日に100件未満の生成)の場合は、値を小さくすることを検討してください。信頼度レベルが高ければ高いほど、テスト期間が長くなります。その一方で、偽陽性テスト結果の数が少なくなります。

例: 特定のテストでテスト対象のエクスペリエンス間に差異がない場合、100件のテストのうち約5件で偽ウィナーがレポートされると想定しています。この要件においては、95%の信頼度レベルを使用する必要があります。

テスト設計の検証

テストを稼働させる前に、Test Duration Calculatorを使用して平均テスト期間を見積もることができます。テストの実行に時間がかかりすぎると考えられる場合は、テスト設計を見直すことをお薦めします。

平均テスト期間のサンプル見積:

チャートには、1%から20%まで1%刻みによるアップリフトを想定したテスト期間が示されています。アップリフトの実際の値は事前にはわからないため、このチャートを使用すると、テストの期間と、特定のサイズの差異を検出できるかどうかとのトレードオフを理解できます。

見積テスト期間を得るには、次の情報が必要です。

テスト・ページへの1日当たりの一意の訪問者
プライマリ・メトリックのコンバージョン率
テスト・エクスペリエンスの数
信頼度レベル

見積テスト期間はテスト結果に影響を及ぼさず、単にその見積期間に関するガイダンスを提供するため、これらのパラメータのおおよその値を使用できます。見積テスト期間が長すぎる場合は、テスト設計を見直し、次の点を検討してください。

テストに含まれるエクスペリエンスの数を減らします。
信頼度レベルを下げて、テストから偽陽性結果が得られるリスクを高くします。
コンバージョン率が高い別のプライマリ・メトリックを選択することを検討します。
トラフィックが高い別のページでテストすることを検討します。

低トラフィック・テストにあわせた調整

低トラフィック・テストは、結論付けまでの時間が長くなる場合があります。次の基準で低トラフィック・テストを定義しています。

バリアント当たり1日に100件未満の生成のテストは、有意に達する可能性が低くなります。このようなテストを実行しても、統計からガイダンスが得られるのみで、明確な結果は得られません。
推奨事項に従ってバリアント当たり1日に100から1000件の生成でテストを実行すると、テスト期間を短縮できます。

テストの大半が低トラフィックに分類される場合は、サイトを低トラフィック・テスト向けに最適化します。このアプローチによって、低トラフィック・テストのテスト期間が短縮され、標準的なトラフィック・アプローチを使用した場合よりもテストを迅速に結論付けできます。

キャンペーンでこの機能を有効にする手順は、次のとおりです。

「Campaign Designer」の「Overview」タブにナビゲートします。
「Settings」をクリックします。
「Low Traffic」オプションを選択します。テストの大半が低トラフィックである場合、サイト管理者は「Site Administration」ページで「Default Stats Methodology」として「Low Traffic」を選択できます。

さらに学ぶ: 結論付けの準備

最小検出可能アップリフトの定義

最小検出可能アップリフトによって、ビジネスの仮説で最小限どれだけの利益が証明された場合に成功とするかが決定されます。テストが開始する前にこの値について合意し、テスト中はこの値を変更しないことをお薦めします。最小検出可能アップリフトは、フラット・テストを識別するためのしきい値としてテストの結論付けフェーズで使用される、キャンペーン仕様のオプション部分です。この値は、デフォルトでは2%に設定されますが、キャンペーン・パフォーマンス・レポートのオプション・セクションから任意のテストに対して変更できます。

サンプルのキャンペーン・パフォーマンス・レポート:

例1: ホーム・ページ・バナー・テストでは、クリックスルーをプライマリ・メトリックとして使用するため、有意な効果にのみ関心があります。そのため、最小検出可能アップリフトとして20%を指定します。

例2: 検索結果テストで、予約収益をプライマリ・メトリックとして使用し、少額でも収益にプラスの変化があれば受け入れます。そのため、最小検出可能アップリフトとして1%を指定します。

最大許容テスト期間の定義

影響が非常に小さいかまったくないテストは、統計的に有意に達するまでに非常に長い時間がかかる場合や有意に達しない場合があります。不要な待機を回避する手順は、次のとおりです。

テスト設計ステージで最大許容テスト期間を定義します。
変更の重要性または潜在的な影響を考慮して、ビジネスの観点からテストの時間ボックスを定義します。

最大許容テスト期間は厳密な期限ではなく、テストが稼働中になった後に定義または再定義できます。

例: ビジネスにとって非常に重要な可能性がある支払オプションの変更をテストします。そのため、この変更が購入収益メトリックに及ぼす影響を正確に把握するために最大3か月待つことにしました。

さらに学ぶ

テストのガイドライン

検索エンジン最適化のガイドライン

ヒートマップ