このドキュメントは公開ガイダンス リポジトリに追加する予定です。皆様からのフィードバックをお待ちしております。
広告テクノロジー プロバイダには、本番環境トラフィックの 100% に対して負荷テストを実施することをおすすめします。
- 広告テクノロジーは、レポートのユースケースとして Attribution Reporting API を使用してコンバージョン アトリビューション測定にアクセスする必要があります。
- 広告テクノロジーは、ノイズを最小限に抑えながら設計上の決定を行う必要があります（参照: モデル化された設計上の決定）。
- テスト中は、1 日に実行するジョブの数（広告主様ごとのジョブ数など）、コンバージョン イベント数の推定分布、処理ジョブあたりの入力として集計キーの数（Aggregation Service API のドキュメントの output_domain_blob_prefix ジョブ パラメータを参照）、入力レポートあたりの推定平均コンバージョン イベント数を記録する必要があります。
- テストでは、想定されるジョブサイズ（レポートのボリューム、ドメインサイズ）に基づいて、サイズ設定ガイダンスの表から推奨されるインスタンスタイプを検索し、デプロイされた集計サービスのサイズを適切に設定する必要があります。リファレンス: AWS の集約サービスのサイズ設定ガイダンス
- 広告テクノロジーは、負荷テスト用に集計ジョブを実行する必要があります。
目標
このガイダンスは、コンバージョン アトリビューションの集計測定に固有のものであり、アドテックが次の目的で使用する主な設定手順が含まれています。
- コンバージョンの貢献度を集計して測定する際の負荷の見込みを推定します。
- 測定対象のディメンションと目標、広告主様の規模とセグメンテーションに基づいて、パフォーマンスとノイズを重視したキーの設定と構成を最適化します。
前提条件
このガイドは、広告テクノロジー ユーザーを対象としています。次の手順に進む前に、ノイズの処理と概要レポートの設計に関する決定に関するドキュメントを確認し、ノイズラボで最適な構成をテストしてください。
手順
1. 最初の集計キーの設定戦略
ビジネスの種類と目標に基づいて、必要なキー構造（ディメンションのセット）の数を決定します。キー構造を最適化すると、レポートのノイズを減らすことができます。
広告主の数
たとえば、1,000 人の広告主が登録されているとします。
広告主様の類似性
類似性は、コンバージョン数、コンバージョン値の相対値、広告主様の特性の一般的な範囲に基づいて評価する必要があります。グループ化できる値が類似しているほど、出力値のばらつきが小さくなるため、結果の微調整が容易になり、ノイズの影響が小さくなります。詳細については、高度な鍵管理をご覧ください。たとえば、広告テクノロジーは、次のように業界、費用、コンバージョン数で広告主をセグメント化できます。
- 業種（保険、宝石、成長中の小売など）
- 費用（例: 四半期あたり 5 万ドル未満、四半期あたり 5 万～ 15 万ドル、四半期あたり 15 万～ 25 万ドル）
- コンバージョン数（低、中、高）
作成する集計キー構造の数
たとえば、27（3x3x3）: 業種 3 つ、費用タイプ 3 つ、コンバージョン値のグループ化 3 つ。
2. 集計キーのディメンションを特定する
次に、インプレッションとコンバージョンの両方でトラッキングする重要なディメンションを特定して、ソースサイド キーとトリガーサイド キーの数を見積もります。
集計キー構造ごとに、インプレッションのトラッキングに必要な重要なディメンションに基づいて、ソースサイド キーの数を決定します。ディメンションは、業種、費用、コンバージョンなど、広告主のタイプによって異なります。次の例は、ディメンションを説明するのに役立ちます。
キー構造 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 x 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:（業種 = 保険、費用 = 50,000 円未満、コンバージョン数 = 低）
- A: キー構造 1 は、来四半期に平均 CPM 単価 $8 で約 50 万ドルの広告費用になると予測されます。これにより、登録が必要なインプレッションが 62,500,000 回になると予想されます。
- キー構造 1 が来四半期に占めるインプレッションからコンバージョンへの平均コンバージョン率は 0.08% と予想され、その結果、50,000 件の貢献コンバージョンを獲得する必要があります。コンバージョンごとに、購入額と購入回数を測定します。
- キー構造 2:（業種 = 保険、費用 = 50,000 未満、コンバージョン数 = 中程度）
- A: キー 2 は、今後 3 か月間で約 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 社あたり 1 時間あたり 24 件の概要レポート（24 x 1,000 広告主様 = 24,000 件の概要レポート）
- キー構造 2: アトリビューション コンバージョン 25,000 件 ÷ 2,160（時間単位のレポート、四半期の総時間）= 広告主様 1 社あたり 1 時間あたり 12 件の概要レポート（12 x 1,000 社 = 12,000 件の概要レポート）
- キー構造 3: 繰り返し
- 1 時間あたりのサマリー レポートの合計数 = キー構造 1 のサマリー レポート 24 件 + キー構造 2 のサマリー レポート 12 件 + ... = 広告主様ごとに 1 時間あたり... 件
フィードバックの概要
広告テクノロジーからの次の推定値を理解することで、広告テクノロジーに必要な規模をサポートする機能と改善を計画できます。以下の情報をお知らせください。詳細については、AWS の Aggregation Service のサイズ設定ガイダンスをご覧ください。
- 集計サービス ジョブあたりの最大入力ドメインキー（集計対象のキー）
- ジョブあたりの最大入力レポート数（貢献度割り当てコンバージョン）
- レポートあたりの推定貢献度（レポート内のキー/値ペア）
- ジョブあたりの貢献度割り当てコンバージョンの推定分布
- ジョブ内のドメインキーの推定分布
- 1 時間/1 日/1 週間あたりの推定ジョブ数