このドキュメントを Google の公開ガイダンス リポジトリに追加する準備をするにあたり、フィードバックをお寄せください。
広告テクノロジーには、本番環境のトラフィックの 100% で負荷テストを実施することをおすすめします。
- 広告テクノロジーは、レポートのユースケースとして、Attribution Reporting API を使用してコンバージョン アトリビューション測定にアクセスする必要があります。
- 広告テクノロジーはノイズを最小限に抑えながら設計上の決定を行う必要がある（参照: 設計上の決定事項（モデル化））
- テスト中、広告テクノロジーは、1 日に実行するジョブ数（広告主のジョブごとなど）、処理ジョブごとの入力としてのコンバージョン イベント量の推定分布と集計キーの数（集計サービス API ドキュメントの output_domain_blob_prefix ジョブ パラメータを参照）、入力レポートごとの推定平均コンバージョン イベントを追跡する必要があります。
- テストのため、広告テクノロジーは予想されるジョブサイズ（レポート ボリューム、ドメインサイズ）に基づいてサイジング ガイダンスの表で推奨インスタンス タイプを検索し、それに応じてデプロイされる集計サービスのサイズを決定する必要があります。リファレンス: AWS で集約サービスのサイジング ガイダンス
- 広告テクノロジーは負荷テストのために集計ジョブを実行する必要があります。
目標
このガイダンスはコンバージョン アトリビューションの集計測定に特化しており、広告テクノロジーが次のことを行うことを目的とした、主な設定と構成の手順が記載されています。
- 集計コンバージョン アトリビューションの測定で予想される負荷を見積もります。
- 測定対象のディメンションと目標、広告主の規模とセグメントに基づいて、パフォーマンスとノイズを重視してキーの設定と構成を最適化する。
前提条件
このガイドは、広告テクノロジーを対象としています。次の手順に進む前に、ノイズの処理、概要レポートの設計上の決定事項に関するドキュメントを確認し、ノイズラボで最適な構成を確認してください。
手順
1. 最初の集計キーの設定戦略
ビジネスタイプと目標に基づいて、必要なキー構造（ディメンションのセット）の数を決定します。キー構造を最適化すると、レポートのノイズを低減できる可能性があります。
広告主の数
たとえば、1,000 件の広告主があるとします。
広告主間の類似性
類似性は、コンバージョン数、相対的なコンバージョン値、広告主の特徴の一般的なカバレッジに基づいて評価する必要があります。グループ化できるほど、結果がより細かく調整されます（出力値のばらつきが少ないため）、ノイズの影響が少なくなります。詳細については、高度な鍵管理をご覧ください。たとえば、広告テクノロジーは、次のように業種、費用、コンバージョン数で広告主をセグメント化できます。
- 業種（保険、宝石、グロース小売など）
- 費用（例: 四半期あたり $50,000、 四半期あたり $50 ～$150,000、四半期あたり $150,000 ～$250,000）
- コンバージョン数（低、中、高）
作成する集計キー構造の数
例: 27（3x3x3）: 3 つの業種、3 つの費用タイプ、3 つのコンバージョン値のグループ
2. 集計キーのディメンションを特定する
次に、ソース側とトリガー側のキーの数を推定するために、インプレッションとコンバージョンの両方でトラッキングする重要なディメンションを特定します。
集計キーの構造ごとに、インプレッションについてトラッキングする必要がある重要なディメンションによって、ソース側のキーの数を判断できます。ディメンションは、上記の 1 の広告主タイプ（業種、費用、コンバージョン）によって異なります。次の例は、ディメンションを説明するのに役立ちます。
主な構造 1: （業界 = 保険、費用 = 50,000 未満、コンバージョン数 = 低）
- A: 4 つのディメンション: キャンペーン（例:最大 50 個）、広告グループ（例:20 の可能性）、デバイスの種類（例:5 つの可能性）、地域（例:50 個）
- 可能なディメンションの組み合わせは、50 x 20 x 5 x 50 = 250,000 となります。これは、キー構造 1 のソース側のキーに対して可能なディメンションの組み合わせの数を表します。
- 18 ビットを予約する必要がある（18 ビット = 262,144 通りの組み合わせ）
- A: 4 つのディメンション: キャンペーン（例:最大 50 個）、広告グループ（例:20 の可能性）、デバイスの種類（例:5 つの可能性）、地域（例:50 個）
主要構成 2: （業界 = 保険、費用 = 50,000 未満、コンバージョン数 = 中）
- A: 4 つのディメンション: キャンペーン（例:30 種類の可能性）、広告グループ（例:80 の可能性）、広告タイプ（例:3 つの可能性）、地域（例:50 の候補）。
- 可能なディメンションの組み合わせは、30 x 80 x 3 x 50 = 360,000 となります。これは、キー構造 2 の可能なディメンションの組み合わせまたはソース側のキーの数を表します。
- 19 ビット（19 ビット）= 524,288 個の可能な組み合わせを予約する必要がある
- A: 4 つのディメンション: キャンペーン（例:30 種類の可能性）、広告グループ（例:80 の可能性）、広告タイプ（例:3 つの可能性）、地域（例:50 の候補）。
鍵構造 3: 繰り返し（持っているすべての鍵構造についても同様に計画）
集計キーの構造ごとに、コンバージョンのトラッキングに必要な重要なディメンションによって、トリガー側のキーを特定できます。次に例を示します。
主な構造 1: （業界 = 保険、費用 = 50,000 未満、コンバージョン数 = 低）
- A: 2 つのディメンション: 商品カテゴリ（例:100 の可能性）、コンバージョンの種類（例:5 つの可能性）
- 可能なディメンションの組み合わせ = 100 × 5 = 500
- 9 ビットを予約する必要がある（9 ビット = 512 通りの組み合わせ）
- A: 2 つのディメンション: 商品カテゴリ（例:100 の可能性）、コンバージョンの種類（例:5 つの可能性）
主要構成 2: （業界 = 保険、費用 = 50,000 未満、コンバージョン数 = 中）
- A: 3 つのディメンション: 商品カテゴリ（例:50 の可能性）、商品カテゴリ（10 の可能性）、コンバージョン タイプ（3 の可能性）
- 可能なディメンションの組み合わせ = 50 x 10 x 3 = 1,500
- 11 ビットを予約する必要がある（11 ビット = 2,048 通りの組み合わせ）
- A: 3 つのディメンション: 商品カテゴリ（例:50 の可能性）、商品カテゴリ（10 の可能性）、コンバージョン タイプ（3 の可能性）
鍵構造 3: 繰り返し（持っているすべての鍵構造についても同様に計画）
集計キーの見積もり
- 鍵構造 1: インプレッション キー 250,000 個 × 変換キー 500 個 = 125,000,000 キー
- 鍵構造 2: インプレッション キー 360,000 個 × 変換キー 1,500 個 = 540,000,000 キー
- 鍵構造 3: （所有するすべての鍵構造についても同様に計画）
- 鍵構造ごとに繰り返す
- 最大集計キー = 540,000,000 キー（すべてのキー構造で）30 ビットを予約する必要がある（30 ビット = 107 億の組み合わせが可能）
予想されるコンバージョン数
集計キーの構造ごとに、予想されるボリュームを次の例で説明できます。
- 主な構成 1: （業界 = 保険、費用 = 5 万未満、コンバージョン数 = 低）
- A: 鍵構造 1 では、次の四半期における広告主支出額は約 50 万ドル、CPM 価格は平均 8 ドルとなります。これにより、62,500,000 インプレッションの登録が必要になります。
- 次の四半期における鍵構造 1 のコンバージョン率に対するインプレッションの平均値は 0.08% で、貢献度が割り当てられたコンバージョンは 50,000 件取得する必要があります。コンバージョンごとに、購入額と購入数を測定します。
- 主要構成 2: （業界 = 保険、費用 = 50,000 未満、コンバージョン数 = 中）
- A: キー 2 は次の四半期に約 80 万ドル相当の費用となり、平均 CPM 価格は 10 ドルとなります。これにより、80,000,000 インプレッションの登録が必要になります。
- 次の四半期におけるキー 2 のコンバージョン率に対するインプレッションの平均値は 0.03125% で、貢献度が割り当てられたコンバージョンは 25,000 件取得する必要があります。コンバージョンごとに、購入額と購入数を測定します。
- 鍵構造ごとに繰り返す
レポート配信とバッチ処理の頻度（広告主ごとのバッチ）**
集計キーの構造ごとに、コンバージョン レポートを定期的に配信する必要があります。広告テクノロジーは広告主ごとにバッチ処理し（レポートごとのデータをより明確に分離し、集計を効率化するため）、バッチ処理にはレポートの shared_info.scheduled_report_time フィールドを使用することをおすすめします。
- A: 1 時間ごと
- B: 毎日
- C: 毎週
メモ
- 広告主をバッチ処理する場合は、広告主と SLA を確認してください。
バッチ処理を頻繁に行うと、バッチあたりのノイズが多くなります。（決定事項: バッチ頻度をご覧ください）。
誤ったバッチ処理によるエラーを回避するには、バッチで
report arrival timeではなくscheduled_report_timeフィールドを使用します。たとえば、1 時間ごとにバッチ処理する場合、午前 11 時のバッチには、午前 10 時から午前 11 時までのscheduled_report_timeのレポートのみが含まれ、午前 10 時から午前 11 時の間に異なるscheduled_report_timeで到着したレポートは含まれません（例:午前 9 時）。
レポートの量の見積もり
- 主な構造 1: 貢献度が割り当てられたコンバージョン数 50,000 ÷ 2,160（時間単位のレポート、四半期の時間数）= 広告主ごとに 1 時間あたり 24 件のサマリー レポート（24 × 1,000 広告主 = 24,000 の概要レポート）
- 主な構造 2: 貢献度が割り当てられたコンバージョン数 25,000 ÷ 2,160（時間別レポート、四半期の時間数）= 広告主ごとに 1 時間あたり 12 件のサマリー レポート（12 × 1,000 広告主 = 12,000 件のサマリー レポート）
- 主な構造 3: 繰り返し
- 1 時間あたりのサマリー レポートの合計数 = 鍵構造 1 の概要レポート 24 個 + キー構造 2 の概要レポート 12 個 + ... = 1 時間あたり（広告主ごと）
フィードバックの概要
Google では、広告テクノロジーから得られる以下の推定値を把握することで、広告テクノロジーで必要な規模に対応するための機能と改善の計画を立てることができます。以下の情報をご提供いただくことをおすすめします。詳細については、AWS で集計サービスのサイジング ガイダンスをご覧ください。
- 集計サービスジョブあたりの最大入力ドメインキー（集計対象のキー）
- 最大入力レポート量（ジョブあたり）（貢献度が割り当てられたコンバージョン数）
- レポートごとの推定貢献度（レポートの Key-Value ペア）
- ジョブごとに貢献度が割り当てられたコンバージョンの推定分布
- ジョブでのドメインキーの推定分布
- 1 時間/1 日/週あたりのジョブの推定数