集約サービスの負荷テストフレームワーク

このドキュメントを公開ガイダンスリポジトリに追加する準備を進めています。ぜひフィードバックをお寄せください。

広告テクノロジー企業には、本番環境のトラフィックの 100% で負荷テストを実施することをおすすめします。

広告テクノロジーは、レポートのユースケースとして Attribution Reporting API を使用して、コンバージョンアトリビューションの測定にアクセスする必要があります。
広告テクノロジーは、ノイズを最小限に抑えながら設計上の決定を行う必要があります（参照: 設計上の決定のモデル化）。
テスト中、広告テクノロジー企業は、1 日に実行するジョブの数（広告主様ごとのジョブなど）、コンバージョンイベントの量の推定分布、処理ジョブごとに入力される集計キーの数（集計サービス API ドキュメントの output_domain_blob_prefix ジョブパラメータを参照）、入力レポートあたりのコンバージョンイベントの推定平均数を追跡する必要があります。
テストでは、広告テクノロジーは、想定されるジョブサイズ（レポートの量、ドメインサイズなど）に基づいて、サイズ設定ガイダンス表から推奨されるインスタンスタイプを検索し、デプロイされた集計サービスのサイズをそれに応じて設定する必要があります。リファレンス: AWS の集約サービスに関するサイジングガイダンス
広告テクノロジーは、負荷テストの集計ジョブを実行する必要があります。

目標

このガイダンスは、集計コンバージョンアトリビューション測定に固有のもので、アドテックが次の目的で使用するための重要な設定と構成の手順が含まれます。

集計コンバージョンアトリビューション測定の負荷の予測。
測定するディメンションと目標、広告主の規模とセグメンテーションに基づいて、パフォーマンスとノイズに関する主要な設定と構成を最適化します。

前提条件

このガイドは、広告テクノロジーのユーザーを対象としています。以下の手順に進む前に、ノイズの処理、概要レポートの設計に関する決定事項に関するドキュメントを確認し、ノイズラボで最適な構成を試してください。

手順

1. 初期集計キー設定戦略

業種と目標に基づいて、必要なキー構造（ディメンションのセット）の数を決定します。キー構造を最適化すると、レポートのノイズを減らすことができます。

広告主様の数
たとえば、1,000 社の広告主様がいるとします。

広告主間の類似性
類似性は、コンバージョン数、相対的なコンバージョン値、広告主の特性の一般的なカバレッジに基づいて評価する必要があります。類似したグループに分類できるほど、結果はより細かく調整され（出力値の分散が小さくなるため）、ノイズの影響は小さくなります。詳細については、高度な鍵管理をご覧ください。たとえば、広告テクノロジーは、次のように業種、費用、コンバージョン数で広告主をセグメント化できます。

業種（例: 保険、ジュエリー、成長小売業）
費用（例: 四半期あたり 50,000 ドル未満、四半期あたり 50,000 ～ 150,000 ドル、四半期あたり 150,000 ～ 250,000 ドル）
コンバージョン数（低、中、高）

作成する集計キー構造の数
例: 27（3×3×3）: 3 つの業種、3 つの費用タイプ、コンバージョン値の 3 つのグループ。

2. 集計キーのディメンションを特定する

次に、インプレッションとコンバージョンの両方で追跡する重要なディメンションを特定して、ソースサイドキーとトリガーサイドキーの数を推定します。

各集計キー構造について、インプレッションのトラッキングに必要な重要なディメンションを把握することで、ソースサイドキーの数を決定できます。ディメンションは、業種、費用、コンバージョンなどの広告主のタイプによって異なります。次の例は、ディメンションを説明するのに役立ちます。

キー構造 1:（業種 = 保険、費用 = 50,000 未満、コンバージョン数 = 少ない）
- A: 4 つのディメンション: キャンペーン（例: 50 個の可能性）、広告グループ（例: 20 種類）、デバイスの種類（例: 5 つの可能性）、地域（例: 50 個の可能性）
  1. 考えられるディメンションの組み合わせ = 50 x 20 x 5 x 50 = 250,000。これは、キー構造 1 のソース側のキーの可能なディメンションの組み合わせの数を表します。
  2. 18 ビットを予約する必要があります（18 ビット = 262,144 通りの組み合わせ）
キー構造 2:（業種 = 保険、費用 = 50,000 未満、コンバージョン数 = 中）
- A: 4 つのディメンション: キャンペーン（例: 30 個の可能性）、広告グループ（例: 80 個の可能性）、広告タイプ（例: 3 つの可能性）、地域（例: 50 通りの可能性があります）。
  1. ディメンションの組み合わせの可能性 = 30 × 80 × 3 × 50 = 360,000。これは、キー構造 2 の可能なディメンションの組み合わせまたはソース側のキーの数を表します。
  2. 19 ビット（19 ビット）を予約する必要があります（524,288 通りの組み合わせが可能）。
キー構造 3: 繰り返し（同様に、すべてのキー構造を計画します）

各集計キー構造について、コンバージョンをトラッキングするために必要な重要なディメンションを把握することで、トリガー側のキーを特定できます。次に例を示します。

キー構造 1:（業種 = 保険、費用 = 50,000 未満、コンバージョン数 = 少ない）
- A: 2 つのディメンション: 商品カテゴリ（例: 100 個の可能性）、コンバージョンの種類（例: 5 つの可能性）
  1. 可能なディメンションの組み合わせ = 100 x 5 = 500
  2. 9 ビットを予約する必要がある（9 ビット = 512 通りの組み合わせ）
キー構造 2:（業種 = 保険、費用 = 50,000 未満、コンバージョン数 = 中）
- A: 3 つのディメンション: 商品カテゴリ（例: 50 通り）、商品カテゴリ（10 通り）、コンバージョンタイプ（3 通り）
  1. 可能なディメンションの組み合わせ = 50 x 10 x 3 = 1,500
  2. 11 ビットを予約する必要があります（11 ビット = 2,048 通りの組み合わせ）
キー構造 3: 繰り返し（同様に、すべてのキー構造を計画します）

集計キーの見積もり

キー構造 1: 250,000 個のインプレッションキー × 500 個のコンバージョンキー = 125,000,000 個のキー
キー構造 2: 360,000 個のインプレッションキー × 1,500 個のコンバージョンキー = 540,000,000 個のキー
キー構造 3:（同様に、すべてのキー構造について計画します）
各キー構造について繰り返す
最大集計キー数 = 540,000,000 個のキー（すべてのキー構造にわたる）。30 ビットを予約する必要があります（30 ビット = 10 億 7,000 万通りの組み合わせが可能）

見込みコンバージョン数

各集計キー構造について、想定されるボリュームを次の例で説明します。

キー構造 1:（業種 = 保険、費用 = 50,000 未満、コンバージョン数 = 少ない）
- A: キー構造 1 は、次の四半期に広告主様の費用が約 $500,000 に達すると予想され、平均 CPM 価格は $8 です。これにより、62,500,000 回のインプレッションを登録する必要が生じると予測します。
- キー構造 1 の平均インプレッションからコンバージョンへの割合は、次の四半期に 0.08% になると予想され、50,000 件のコンバージョンをキャプチャする必要があります。コンバージョンごとに、購入額と購入回数を測定します。
キー構造 2:（業種 = 保険、費用 = 50,000 未満、コンバージョン数 = 中）
- A: キー 2 は、次の四半期に約 $800,000 の費用を費やすと予想され、平均 CPM 価格は $10 です。これにより、登録が必要なインプレッションが 80,000,000 回発生すると予想されます。
- キー 2 の平均インプレッションからコンバージョンへの割合は、次の四半期に 0.03125% になると予想され、25,000 件のコンバージョンをキャプチャする必要があります。コンバージョンごとに、購入額と購入回数を測定します。
各キー構造について繰り返す

レポートの配信とバッチ処理の頻度（広告主ごとにバッチ処理）**

集計キー構造ごとに、コンバージョンレポートを定期的に配信する必要があります。広告技術プロバイダは、広告主ごとにバッチ処理（レポートごとのデータの分離を明確にし、集計を効率化するため）を行い、バッチ処理にレポートの shared_info.scheduled_report_time フィールドを使用することをおすすめします。

A: Hourly
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 × 1,000 人の広告主 = 24,000 件の概要レポート）
キー構造 2: 25,000 件のコンバージョン / 2,160（時間別レポート、四半期内の時間数）= 広告主 1 社あたり 1 時間に 12 件の概要レポート（12 × 1,000 社の広告主 = 12,000 件の概要レポート）
キー構造 3: 繰り返し
1 時間あたりのサマリーレポートの合計数 = キー構造 1 のサマリーレポート 24 件 + キー構造 2 のサマリーレポート 12 件 + ... = 広告主様 1 社あたり 1 時間あたり... 件

フィードバックの概要

広告テクノロジー企業からの以下の見積もりを把握することで、広告テクノロジー企業が必要とする規模をサポートするための機能や改善を計画できます。以下の情報を共有することをおすすめします。詳細については、AWS のアグリゲーションサービスのサイジングガイドをご覧ください。

集計サービスジョブあたりの最大入力ドメインキー（集計対象のキー）
ジョブあたりの最大入力レポート数（貢献度の割り当てられたコンバージョン）
レポートあたりの推定貢献度（レポート内のキーと値のペア）
ジョブあたりの貢献度の割り当てられたコンバージョン数の推定分布
ジョブ内のドメインキーの推定分布
1 時間/1 日/1 週間あたりの推定ジョブ数