MDE の要件を理解して、設計出力のトラブルシューティングを行います。このガイドでは、過去のデータに照らして設計指標を検証し、結果が測定目標を満たしていない場合に調査パラメータを調整する方法を説明します。
最小検出可能効果（MDE）の詳細
各設計の出力には、最小検出可能効果（MDE）が示されます。MDE は、テストで統計的に測定可能な最小リフト率を表します。テストの検出力を十分に確保するには、キャンペーンで想定される実際のリフトよりも MDE が小さくなるようにする必要があります。実際によくある落とし穴は、過大な MDE で Meridian GeoX を設計して実施することです。キャンペーンの想定パフォーマンスが不明な場合は小さめの MDE を選択して、控えめな設定にすることをおすすめします。これにより、テストの感度が十分に高くなり、わずかな変化も検出できるようになります。
ゴーダークまたはヘビーアップのテスト オプションで既存のキャンペーンをテストする場合、過去の増分調査に同様の設定があるか、あるいはマーケティング セグメントに対するマーケティング ミックス モデル（MMM）が利用可能であれば、選択した MDE が現実的かどうかを確認できます。これを行うには、「設計上の想定 CpIC」と「推定 CpIC」を比較します。
この比較を簡素化するために、次の 3 つのコア指標（次の図にも示されています）を考えます。これは、メディア費用とレスポンスが凹型の広告リターン曲線（飽和曲線）に従うことを示しています。
- アクション単価（CPA）: 標準のコンバージョン単価。費用（$S$）÷ コンバージョン数（$C$）に等しくなります。ここでの合計コンバージョン数には、増分コンバージョンと非増分コンバージョンの両方が含まれます。たとえば、有料メディアを介さないオーガニック コンバージョン イベントなどがこれに該当します。
- 弾力性: 図の \(\frac{\Delta C / C}{\Delta S / S}\) に相当します。これは、コンバージョンが費用の変化にどの程度敏感であるかを示す指標であり、過去の調査や MMM から推測できます。
- $\Delta S = -100\% * S$ のゴーダークの調査の場合、弾力性は基本的に $-\Delta C / C$（調査で想定される相対リフト）になります。
- 増分コンバージョン単価（CpIC）: $\Delta S / \Delta C$ に等しく、マーケティング介入による増分費用の変化によって発生した増分コンバージョン 1 件あたりの実際の費用を意味します。
適切に設計されたテストでは、設計上の想定 CpIC（予算を最小限必要な増分コンバージョンで割って算出）が、理論上の CpIC（アクション単価を弾力性で割って算出）と整合します。テストの検出力を十分に確保するには、設計上の想定 CpIC が推定 CpIC を下回らないことが理想的です。
選択した単一セルのテスト設計について、設計上の想定 CpIC を抽出します。
select_design = single_cell_design_set.designs[single_cell_selected_design_id]
select_design.designs['cell_1'].design_implied_cpic
予算、MDE、設計上の想定 CpIC の関係を理解する
混乱しがちなのは、予算の調整がテストの感度にどのように影響するかという点です。
- MDE は予算に依存しない: 統計的な MDE（テストで検出できるコンバージョンの最小変化率）は、過去の変動性と地域マッチングのみによって決まります。
Constraintsで予算を変更するだけでは、この統計上の制限は変わりません。 - 予算によって設計上の想定 CpIC が決まる: MDE（必要なリフト率）は一定ですが、設計上の想定 CpIC は予算に比例して変化します。
- 高い予算: 設計上の想定 CpIC が高く（効率が低く）なります。これにより、パフォーマンスが中程度のキャンペーンで、確実なテスト結果が得られる可能性が高まります。
- 低い予算: 設計上の想定 CpIC が非常に低く（効率が高く）なるよう制限されます。キャンペーンの実際のパフォーマンスが非常に高いのではなく、中程度である場合、テスト結果は確実でない可能性があります。
測定目標に適合する設計出力がない場合
設計の最適化を行っても、上位の設計候補の最小 MDE が、対象のケースに対して大きすぎる可能性があります。これは通常、指定された調査設定と KPI データに固有のノイズレベルに基づいて、テスト キャンペーンが GeoX を強化するのに十分な予算で実施されていないことを示しています。まず、geox.Constraints() でパラメータの予算を明示的に増やす必要があります。その後、次の 2 つのオプションのいずれかを使用してテスト予算を増やした後、調査の設定を調整する必要がある場合があります。
geox.DesignConfig()のexperiment_durationを変更することで、調査の期間を延長できます。- 既存の期間を維持することもできますが、
geox.Constraints()のパラメータmax_conversions_percentを増やすと、介入の影響を受ける地域の割合が高くなります。
どちらの方法でも、調査の設定を更新することで、増分コンバージョンを増やせます。また、ページビューやカートへの追加など、ファネル上流のコンバージョン目標を含めるようにテストを設計することも検討してください。これらのファネル上流のコンバージョンもキャンペーンの影響を受けると想定されます。これにより、より多くのデータが提供され、MDE が低下する可能性があります。
キャンペーンの 1 日の予算を直接増やすこともできますが、テストで予算を直接増やすことはおすすめしません。対照群の地域は常に BAU の下にあるという前提が崩れるためです。キャンペーンの予算を増やす必要がある場合は、まず予算を増やし、新しい BAU で十分なテスト前設計データが収集されるまで待ってから、新しい調査設計を実行して実際の GeoX を進めることをおすすめします。
季節的な急増に合わせてテストを最適化する
第 4 四半期のホリデー シーズンや大規模なセールイベントなど、季節的な需要の急増時に GeoX を実施すると、高い変動性や商業上の制約（メディアをオフにできない「触れることのできない」期間など）といった問題が生じます。こうした期間を考慮して調査を構成する方法に関するガイドラインは次のとおりです。
「触れることのできない」ピーク期間や商業上の制約への対応
販売のピーク期間中に主要市場で広告をオフ（ゴーダーク）にできない場合:
- ゴーダークではなく、ヘビーアップ戦略を使用する:
- 費用対効果をゼロ費用（ゴーダーク）と比較してテストするのではなく、追加費用の限界効果をテストします。
- 対照群の地域では計画したベースライン予算（BAU）を維持し、介入群の地域では費用をさらに増やします（例: +20%～+50%）。これにより、すべての市場でピーク時の需要を捉えながら、追加投資の増分リフトを測定できます。
- 部分的にゴーダークを使用してリスクを最小限に抑える:
- 部分的なゴーダークは、ゴーディム（go-dim）と呼ばれることがあります。これは、限界効率（部分的な削減による、最後に上乗せした費用の ROI）をテストするものです（たとえば、介入群の地域で支出を 20% 削減します）。これにより、ピーク時の収益リスクを最小限に抑えながら、特定の予算スライスのインクリメンタリティを測定できます。これは、BAU 費用とゼロ費用を比較するベースラインの効率全体を測定するものではなく、完全なゴーダーク テストが必要になることに注意してください。
季節的な急増期間におけるテスト前後の対応期間を管理する
季節的なピーク期への移行やピーク期からの脱却においては、ユーザーの行動やプラットフォームの入札動向の急激な変化が見られることがよくあります。モデルの安定性を確保するには、以下の点に留意してください。
- 急増期のテスト切り替えを避ける: テストの開始日と終了日が急激な移行の真っ只中にならないようにしてください（たとえば、ブラック フライデーの前日にテストを開始するなど）。モデルは、介入群と対照群の地域の関係が一貫している場合に最も安定します。
- テストを早めに開始する: 季節的な変動が始まる数週間前に、予算の分割（ゴーダークまたはヘビーアップ）を行います。これにより、ピーク時のトラフィックが本格化する前に、新しい地域予算の下で、広告プラットフォームの入札アルゴリズムが安定する時間を確保できます。
- テストの終了を遅らせる: ピーク時もテストを継続し、ピーク時のトラフィックが収束して通常のレベルに安定してから BAU に戻します。
- 検証用のテスト前データを拡張する: 季節性の高いビジネスの場合、最小限必要な \( 3N \) テスト前データでは通常不十分です。設計を検証するために、少なくとも 1 年分の過去データを準備します。
- 過去のピークで設計を検証する（プラセボテスト）:
- テストを実行する前に、前年の同じ季節のピーク時を検証期間とし、そのときのデータを使用して設計検索を実行します。
- 候補となる設計が A/A プラセボテスト（p 値\( \ge \alpha \)）に合格し、その過去のピーク時に良好な適合度（\( R^2 \ge 0.8 \)）を維持していることを確認します。確認できない場合、トラフィックが多い期間に地域間の関係が不安定になるため、ピーク時のテストは避ける必要があります。