集計キーの概要、Attribution Reporting API での使用方法、目標をキーに変換する方法。
ある広告テクノロジー企業が、複数の地域でさまざまな商品カテゴリのキャンペーンを実施しており、広告主が以下の質問に答えられるように支援したいと考えています。
- 地域ごとの各キャンペーンで、商品カテゴリごとの購入数は何回か？
- 各地域における各キャンペーンで、商品カテゴリごとの収益はどの程度だったか？
多くの広告テクノロジー企業は、さまざまなタイプのコンバージョンを設定することを広告主に推奨していますが、購入などの最も重要なコンバージョンに焦点を当てることで、それらの重要なイベントについて詳細かつ正確な結果の概要を確認できます。
そのためには、データを収集する前に、どのような問いに答えたいのかを考える必要があります。
ディメンション、キー、値
これらの疑問に答えるために、ディメンション、キー、値を見てみましょう。
ディメンション
ここで説明するように、キャンペーンによる収益の発生を把握するには、次のディメンションをトラッキングする必要があります。
- 広告キャンペーン ID: 特定のキャンペーンの識別子。
- 地域 ID: 広告が配信された地域。
- 商品カテゴリ: 定義した商品のタイプ。
キャンペーン ID と地域 ID のディメンションは広告の配信時（広告配信日時）にわかりますが、商品カテゴリはユーザーがコンバージョンを完了した（コンバージョンの日時）トリガー イベントからわかります。
この例でトラッキングするディメンションは、次の画像に示すとおりです。
集計キー（バケット）とは
集計キーとバケットという用語は同じものを指します。集計キーは、レポートの設定に使用するブラウザ API で使用されます。バケットという用語は、集計可能レポートとサマリー レポート、および集計サービス API で使用されます。
集計キー（キー）は、トラッキングするディメンションの値を表すデータです。データはその後、各集計キーに沿って集計されます。
たとえば、「商品カテゴリ」、「地域 ID」、「キャンペーン ID」の各ディメンションをトラッキングしているとします。
地域 ID 7 にいるユーザーがキャンペーン ID 12 の広告を見て、その後商品カテゴリ 25 の商品を購入してコンバージョンを達成した場合、次の画像のような集計キーを設定できます。
集計キーが実際にはこのように見えないことは後ほど説明しますが、ここではキーに含まれる情報に焦点を当てましょう。
集計可能値とは
これまでに説明したディメンションに関する質問の答えを見つけるには、次の情報が必要です。
- 購入回数（購入回数）。集計されて概要レポートで利用可能になると、これが合計購入数（概要値）になります。
- 購入ごとの収益（購入額）。集計されて概要レポートで利用可能になると、これが総収益（概要値）になります。
1 回のコンバージョンの購入回数と 1 回のコンバージョンの購入額は、それぞれ集計可能な値です。集計可能値は、測定目標の値と考えることができます。
| 質問 | 集計可能な値 = 測定の目標 |
|---|---|
| 購入の件数... | 購入数 |
| 収益額 | 購入額 |
地域 ID 7 にいるユーザーがキャンペーン ID 12 の広告を見た後、商品カテゴリ 25 の商品を 120 ドルで購入し（通貨が米ドルと仮定）、次のような集計キーと集計値を設定できます。
集計可能な値は、多くのユーザーのキーごとに合計され、サマリー レポートのサマリー値の形式で集計された分析情報が生成されます。
集計可能な値が合計され、測定目標に沿った集計インサイトが生成されます。
この図では復号を省略しており、ノイズを適用していない簡素化された例を表しています。次のセクションでは、ノイズを含めたこの例の概要を説明します。
キーと値からレポートへ
次に、集計可能なキーと値がレポートにどのように関連しているかを説明します。
集計可能レポート
ユーザーが広告をクリックまたは表示して、その後コンバージョンが達成されたら、{aggregate key, aggregatable value} ペアを保存するようブラウザに指示します。
この例では、ユーザーが広告をクリックまたは表示して、その後コンバージョンを達成した場合、2 つの貢献度（測定目標ごとに 1 つ）を生成するようブラウザに指示します。
後で、{aggregate key, aggregatable value} 集計可能レポートがこのようには見えていないことはわかるでしょうが、ここではレポートに含まれる情報に焦点を当てましょう。
2 つのコントリビューションを生成するようブラウザに指示すると、ブラウザは集計可能レポートを生成します（コンバージョンを以前の表示またはクリックと一致できる場合）。
集計可能レポートには以下が含まれます。
- 設定した資金提供。
- クリックまたは表示イベントとコンバージョン イベント（コンバージョンが発生したサイトなど）に関するメタデータ。集計可能レポートですべてのフィールドを表示する
集計可能レポートは JSON 形式で、とりわけ最終的な概要レポートのデータ入力として使用されるペイロード フィールドが含まれます。
ペイロードには、コントリビューションのリストが含まれます。各コントリビューションは、{集計キー、集計可能な値} のペアです。
bucket: バイト文字列としてエンコードされた集計キー。value: その測定目標の集計可能な値（バイト文字列としてエンコード）。
次の例をご覧ください。
{
"data": [
{
"bucket": "111001001",
"value": "11111010000",
}
],
"operation": "histogram"
}
実際には、集計可能レポートはバケットと値が前の例とは異なる方法でエンコードされます（つまり、バケットは \u0000\u0000\x80\u0000 のようになります）。Bucket と value はどちらもバイト文字列です。
概要レポート
集計可能レポートは、次のようにさまざまなブラウザとデバイス（ユーザー）から集計されます。
- 広告テクノロジーは、特定のキーセットに関するサマリー レポートと、さまざまなブラウザ（ユーザー）からの特定の集計可能レポートをリクエストします。
- 集計可能レポートは、集計サービスによって復号されます。
- 集計可能レポートの集計可能値がキーごとに合計されます。
- ノイズはサマリー値に追加されます。
その結果、{aggregate key, summary value} のペアを含む概要レポートが作成されます。
概要レポートには、JSON 辞書形式の Key-Value ペアのセットが含まれます。各ペアには次のものが含まれます。
bucket: バイト文字列としてエンコードされた集計キー。value: 特定の測定目標のサマリー値（10 進数）。利用可能なすべての集計可能レポートから合計され、ノイズが追加されています。
例:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
実際のところ、概要レポートはバケットと値がこの例とは異なる方法でエンコードされています（つまり、バケットが \u0000\u0000\x80\u0000 のようになります）。Bucket と value はどちらもバイト文字列です。
集計キーの実践
集計キー（バケット）は広告テクノロジー会社によって定義されます。通常は 2 つのステップ（広告がクリックまたは表示されたときと、ユーザーがコンバージョンを達成したとき）です。
キーの構造
ここでは、キーにエンコードされるディメンションのセットを指定するために「キー構造」という用語を使用します。
たとえば、「キャンペーン ID × GeoID × 商品カテゴリ」がキー構造です。
キーのタイプ
集計可能値は、複数のユーザーまたはブラウザで特定のキーについて合計されます。しかし、集計可能値を使用することで、購入額や購入回数など、さまざまな測定目標をトラッキングできることもわかっています。集計サービスによって、同じ型の集計可能な値が確実に合計されるようにしたいと考えています。
これを行うには、各キー内で、サマリー値が何を表しているか（このキーが参照している測定目標）を示すデータをエンコードします。これを行う方法の一つは、測定の目標タイプを表す追加のディメンションをキーに作成することです。
先ほどの例の場合、この測定の目標タイプには 2 種類の値があります。
- 1 つ目の測定目標は「購入数」です。
- 2 つ目の測定目標は購入額です。
測定目標が n 個ある場合、測定の目標タイプには n 種類の値があります。
キーのディメンションは指標と考えることができます。たとえば、「地域ごとのキャンペーンごとの特定の商品の購入数」などです。
キーサイズ、ディメンション サイズ
キーの最大サイズはビット数で定義されます。つまり、完全なキーを作成するためのバイナリの 0 と 1 の数です。この API で使用できる鍵長は 128 ビットです。
このサイズに設定するとキーが非常に細かくなりますが、キーが粒度が高いほど、ノイズの多い値が多くなる可能性が高くなります。ノイズの詳細については、ノイズを理解するをご覧ください。
すでに紹介したように、ディメンションは集計キーにエンコードされます。各ディメンションには特定の基数（ディメンションがとることができる個別の値の数）があります。基数に応じて、各次元を特定のビット数で表す必要があります。n ビットでは、2n 個の異なるオプションを表現できます。
たとえば、世界には約 200 の国があるため、「国」ディメンションの基数は 200 になることがあります。この次元をエンコードするのに必要なビット数は何ですか。
7 ビットには 27 = 128 個の異なるオプションのみが格納されますが、これは必要な 200 を下回っています。
8 ビットには 28 = 256 個の異なるオプションが格納されますが、これは必要な 200 を超えるオプションなので、この次元は n=8 ビットでエンコードできます。
鍵エンコード
ブラウザでキーを設定する場合は、16 進数でエンコードする必要があります。概要レポートでは、キーはバイナリ形式（名前付きバケット）で表示されます。
完全なキーに 2 つのキーピースを設定する
キーを使用して次のディメンションをトラッキングしていると仮定します。
- キャンペーン ID
- 地域 ID
- 製品カテゴリ
キャンペーン ID と地域 ID のディメンションは、広告が配信されるとき（広告配信時間）にわかりますが、商品カテゴリは、ユーザーがコンバージョンを完了したとき（コンバージョンの日時）トリガー イベントからわかります。
実際には、キーは次の 2 つのステップで設定します。
- クリック時または表示時にキーの一部（キャンペーン ID × 地域 ID）を設定します。
- キーの 2 番目の要素（商品カテゴリ）はコンバージョン時に設定します。
鍵のこうした異なる部分は「鍵ピース」と呼ばれます。
キーは、キーピースの XOR（^）を取って計算されます。
例:
- ソース側のキーピース =
0x159 - トリガー側のキーピース =
0x400 - キー =
0x159 ^ 0x400 = 0x559
重要な部分の調整
2 つの 64 ビットキーピースを慎重に配置した 64 ビットのフィラー/オフセット（16 個の 0）を使用して 128 ビットに拡張すると、XOR キーピースはそれらを連結することと同等であり、推論と検証が簡単です。
- ソース側のキーピース =
0xa7e297e7c8c8d0540000000000000000 - トリガー側のキーピース =
0x0000000000000000674fbe308a597271 - キー =
0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271
広告のクリックまたは表示ごとに複数のキー
実際には、アトリビューション ソース イベント（広告のクリックまたは表示）ごとに複数のキーを設定できます。たとえば、次のように設定できます。
- 地域 ID × キャンペーン ID をトラッキングするキー。
- クリエイティブ タイプ × キャンペーン ID をトラッキングする別のキー。
戦略 B で別の例を見てみましょう。
ディメンションをキーにエンコードする
サマリー レポートをリクエストするときは、特定の集計キーのセットについてサマリー レポートをリクエストして、アクセスしたい指標を集計サービスに伝える必要があります。
概要レポートには未加工の {key, summary value} ペアが含まれますが、キーに関する追加情報はありません。つまり、以下のようになります。
- ユーザーが広告を表示またはクリックし、その後コンバージョンが達成されるときにキーを設定する場合は、キーが表すディメンションの値に基づいて確実にキーを設定する必要があります。
- 概要レポートをリクエストするキーを定義するときは、集計データを表示するディメンションの値に基づいて、ユーザーが広告を表示またはクリックし、コンバージョンを行ったときに設定したキーと同じキーを確実に生成するか、その場でアクセスできるようにする必要があります。
キー構造マップを使用してディメンションをエンコードする
ディメンションをキーにエンコードするには、キーを定義する際（広告配信前）に、キー構造マップを作成して維持します。
キー構造マップは、各ディメンションと、キー内での位置を表します。
実際には、キー構造マップを作成して維持するには、デコーダ ロジックを実装して維持する必要があります。そうする必要がない方法をお探しの場合は、代わりにハッシュベースのアプローチの使用を検討してください。
次の例をご覧ください。
特定のキャンペーン、地域、商品について、購入額と購入額の両方をトラッキングするとします。
商品カテゴリ、地域 ID、キャンペーン ID は、キーのディメンションである必要があります。また、購入数と購入額という 2 つの異なる測定目標をトラッキングするため、キー内にキータイプを管理するディメンションを 1 つ追加する必要があります。これにより、概要レポートで {key, aggregatable value} ペアを受け取ったときに、集計可能値が実際に何を表しているかを定義できます。
これらの測定目標では、キーには次のディメンションが含まれます。
- 製品カテゴリ
- 測定の目標タイプ
- 地域 ID
- キャンペーン ID
では、各ディメンションについて、ユースケースについて以下をトラッキングする必要があると仮定しましょう。
- 29 種類の商品カテゴリ。
- 北アメリカ、中央アメリカ、南アメリカ、ヨーロッパ、アフリカ、アジア、カリブ海、オセアニアの 8 つの地理的なエリア。
- 16 種類のキャンペーン
キー内の各ディメンションをエンコードする必要があるビット数は次のとおりです。
- 商品カテゴリ: 5 ビット（25 = 32 > 29）。
- 測定目標タイプ: 1 ビット。測定の目標は購入回数または購入額のいずれかです。つまり、2 つの異なる可能性が考えられます。したがって、1 ビットで十分です。
地域 ID: 3 ビット（23 = 8）。また、各バイナリ値がどの地域を表すかを把握するために、地域 ID のディメンション マップも定義します。[地域 ID] ディメンションのディメンション マップは次のようになります。
キーのバイナリ値 地域 000 北米 001 中米 010 南アメリカ 011 ヨーロッパ 100 アフリカ 101 アジア 110 カリブ諸国系 111 オセアニア キャンペーン ID: 4 ビット（24 = 16）
この構造に続くキーは、13 ビット長になります（5 + 1 + 3 + 4）。
この例では、これらのキーのキー構造マップは次のようになります。
キー内のディメンションの順序は任意です。
ディメンションがキー構造を構成する仕組みを説明するために、バイナリ表現を使用します。キャンペーン ID（最初のビット）が右端に、商品カテゴリ（最後のビット）が左端に配置されます。
各次元内で、最上位ビット（最大数値を格納できるビット）が左端のビットとなります。最下位ビット（最も小さい数値が格納されるビット）は、右端のビットです。
キー構造マップを使用してキーをデコードする方法を見てみましょう。
任意の例として、0b1100100111100 をキーとして考えてみましょう。このキーが前の図のキー構造マップに従っていることを確認する方法があるとしましょう。
キー構造マップに従って、このキーは 11001 0 011 1100 にデコードされます。
したがって、キー 0b1100100111100 は、キャンペーン ID 12 の商品カテゴリ 25 がヨーロッパで開始された購入回数を表します。
ハッシュ関数を使用してディメンションをエンコードする
キー構造マップを使用する代わりに、ハッシュ関数を使用すると、一貫性のある信頼性の高い方法でキーを動的に生成できます。
この処理は次のように行われます。
- ハッシュ化アルゴリズムを選択します。
- 広告配信時に、トラッキングするすべてのディメンションとその値を含む文字列を生成します。ソース側のキーピースを生成するには、この文字列をハッシュし、64 ビットの 0 のサフィックスを追加してトリガー側のキーピースとアライメントし、XOR を簡単に推測できるようにします。
- ソース側のキーピース
=<64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…> COUNTは、キー構造マップ アプローチでmeasurementGoalType=0と同じものをエンコードします。COUNTはやや簡潔で、より明確です。
- ソース側のキーピース
- 変換時に、トラッキングするすべてのディメンションとその値を含む文字列を生成します。トリガー側のキーピースを生成するには、この文字列をハッシュ化して 64 ビットの接頭辞としてゼロを追加します。
- トリガー側のキーピース =
<64-bit 00000000…><64-bit hex hash("productCategory=25")>
- トリガー側のキーピース =
- ブラウザはこれらの鍵の XOR を計算して鍵を生成します。
- 128 ビット集計キー
=<64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
- 128 ビット集計キー
- 後で、このキーの概要レポートをリクエストする準備ができたら、その場で生成します。
- 前述のように、目的のディメンションに基づいて、ソース側とトリガー側のキーピースを生成します。
- ソース側のキーピース
=<64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…> - トリガー側のキーピース
=<64-bit 00000000…><64-bit hex hash("productCategory=25")> - トリガー側のキーピース =
toHex(hash("productCategory=25"))
- ソース側のキーピース
- ブラウザと同様に、これらの鍵を XOR 演算して、ブラウザで以前に生成したものと同じ鍵を生成します。
- 128 ビット集計キー
=<64-bit source-side key piece hash><64-bit source-side key piece hash>
- 128 ビット集計キー
- 前述のように、目的のディメンションに基づいて、ソース側とトリガー側のキーピースを生成します。
このハッシュベースのアプローチを使用している場合の実用的なヒントをいくつか紹介します。
- ディメンションは常に同じ順序にしてください。これにより、ハッシュを確実に再生成することができます。（
"COUNT, CampaignID=12, GeoID=7"は"COUNT, GeoID=7, CampaignID=12"と同じハッシュを生成しません）。これを簡単に実現する方法の 1 つは、ディメンションを英数字で並べ替えることです。サンプルでは、このようにします。ただし、COUNTまたはVALUEは常にディメンションの最初の項目とします。COUNTまたはVALUEは、他のすべてのディメンションとは概念的にわずかに異なる情報をエンコードするため、読みやすさを優先します。 - キーで使用しているディメンションのセットを追跡します。使用したことがない一連のディメンションに基づいてキーを生成することは避けたいと考えています。
- 適切なハッシュ関数が使用されている場合、ハッシュの競合はまれですが、以前に使用されたハッシュ（集計サービスからの結果を解釈するために保存する必要があります）と照合することで、古いキーと競合する新しいキーの導入を回避できます。
実際にハッシュベースのキーを使用する方法については、クリックまたはビューごとに 1 つのコンバージョンの例をご覧ください。
集計可能な値の実践
広告テクノロジー会社は、ユーザーがコンバージョンを達成したときに集計可能な値を設定します。
ユーザーのプライバシーを保護するため、各ユーザーの投稿には上限が設けられています。1 つのソース（広告のクリックまたは表示）に関連付けられたすべての集計可能な値において、貢献度が特定の上限を超えることはできません。
この上限を CONTRIBUTION_BUDGET と呼びます。説明では、この上限を L1 予算と呼びますが、CONTRIBUTION_BUDGET と同じです。
資金提供の予算について詳しくは、概要レポートの資金提供の予算をご覧ください。
例: クリックまたは視聴ごとに 1 回のコンバージョン
この例では、次の質問に答えようとしています。
- 各地域で最も価値が高い商品カテゴリはどれか？
- 各地域で最も効果的なキャンペーン戦略は？
また、ユースケースでは週 1 回の分析情報が必要であると仮定します。
次の項目も追跡する必要があります。
- 16 種類のキャンペーン
- 北アメリカ、中央アメリカ、南アメリカ、ヨーロッパ、アフリカ、アジア、カリブ海、オセアニアの 8 つの地理的なエリア。
- 29 種類の商品カテゴリがあります。
測定データ
多くの広告テクノロジー企業は、さまざまなタイプのコンバージョンを設定することを広告主に推奨していますが、特に重要なコンバージョン イベント（購入など）に重点を置くことで、集計結果が詳細かつ正確になることを確認できます。 実際、測定する指標が多いほど、指標あたりの予算が減るため、それぞれの値のノイズが多くなる可能性が高くなります。そのため、測定対象は慎重に選択する必要があります。
この例では、クリックまたは視聴ごとに 1 つのコンバージョン（購入）のみを測定するキャンペーン設定について説明します。
引き続き購入数と購入額の両方を測定し、合計購入額や地域別の内訳など、さまざまな重要な集計統計情報にアクセスできます。 これにより、ノイズを合理的な範囲に抑え、寄付予算のスケーリング アプローチを簡素化できます。
通貨についてはどうですか？
複数の地域でキャンペーンを実施する場合は、通貨を考慮する必要があります。 以下の方法をお試しください。
- 通貨を集計キーの専用のディメンションにする。
- または、キャンペーン ID から通貨を推測し、すべての通貨を参照通貨に換算します。
この例では、キャンペーン ID から通貨を推測できるものとします。これにより、購入金額をユーザーの現地通貨から任意の参照通貨に換算できます。ユーザーがアイテムを購入した際に、その場でコンバージョンを実行することもできます。
この手法では、集計可能な値はすべて同じ参照通貨になるため、集計して合計購入額（サマリーの購入額）を生成できます。
目標をキーに変換する
測定の目標と指標に応じて、主要な戦略に応じてさまざまな選択肢があります。このうちの 2 つの戦略に注目してみましょう。
- 戦略 A: 1 つのきめ細かなキー構造。
- 戦略 B: 2 つの大まかなキー構造。
戦略 A: 1 つの深いツリー（1 つのきめ細かなキー構造）
戦略 A では、必要なすべてのディメンションを含む 1 つのきめ細かなキー構造を使用します。
すべての鍵でこの構造が使用されます。
このキー構造を 2 つのキータイプに分割して、2 つの測定目標をサポートします。
- キータイプ 0: 測定目標タイプ = 0。ここでは、購入数として定義します。
- キータイプ 1: 測定目標タイプ = 1。購入額として定義します。
概要レポートは次のように表示されます。
戦略 A は「1 つのディープツリー」戦略と考えることができます。
- サマリー レポートの各サマリー値は、トラッキングするすべてのディメンションに関連付けられます。
- これらの概要値を各ディメンションとともにロールアップできるため、ディメンションの数だけロールアップできます。
戦略 A では、次のような問いに答えます。
| 質問 | 回答 |
|---|---|
| 各地域で最も価値が高い商品カテゴリはどれか？ | すべてのキャンペーンについて、概要レポートにある購入数と値の概要を合計します。 これにより、Geo ID × 商品カテゴリごとの購入数と購入額が得られます。 地域ごとに、さまざまな商品カテゴリの購入額と数を比較します。 |
| 各地域で最も効果的なキャンペーン戦略は？ | すべての商品カテゴリについて、概要レポートにある購入数と値の概要を合計します。 これにより、キャンペーン ID × 地域 ID ごとの購入数と購入値が得られます。 地域ごとに、異なるキャンペーンの購入額と購入数を比較します。 |
戦略 A では、次の 3 つ目の質問に直接答えることもできます。
「各地域の各キャンペーンで獲得した商品ごとの収益は？」
サマリー値はノイズが多くなりますが、各キャンペーン間で測定された値の差がノイズのみによるものではないかどうかを判断できます。これを行う方法については、ノイズについてをご覧ください。
戦略 B: 2 本の浅いツリー（2 つの大まかな鍵構造）
戦略 B では、必要なディメンションのサブセットを含む 2 つの大まかなキー構造を使用します。
各キー構造を 2 つのキータイプに分割し、2 つの測定目標をサポートします。
- 測定の目標タイプ = 0。ここでは購入数として定義します。
- 測定の目標タイプ = 1。購入額として定義します。
最終的には、次の 4 つのキータイプになります。
- キータイプ I-0: キー構造 I、購入数。
- キータイプ I-1: キー構造 I、購入額。
- キータイプ II-0: キー構造 II、購入数。
- キータイプ II-1: キー構造 II、購入額。
概要レポートは次のように表示されます。
戦略 B は「2 本の浅いツリー」戦略と考えることができます。
- 概要レポートの概要値は、2 つの小さなディメンション セットのいずれかにマッピングされます。
- これらの概要値は、これらのセットの各ディメンションとともにロールアップできます。つまり、ロールアップするディメンションが少ないため、オプション A ほど詳細ではありません。
戦略 B では、次のような問いに答えます。
| 質問 | 回答 |
|---|---|
| 各地域で最も価値が高い商品カテゴリはどれか？ | 概要レポートの概要の購入数と値に直接アクセスする。 |
| 各地域で最も効果的なキャンペーン戦略は？ | 概要レポートの概要の購入数と値に直接アクセスする。 |
決定: 戦略 A
戦略 A はよりシンプルです。すべてのデータが同じキー構造に従います。つまり、維持するキー構造は 1 つだけです。
ただし、戦略 A では、一部の質問に答えるために、サマリー レポートで受け取ったサマリー値を合計する必要があります。これらのサマリー値は、それぞれノイズが多くなります。そのデータを合計することで、ノイズも合計されます。
戦略 B はこれに当てはまりません。戦略 B では、概要レポートで公開されている概要値から、必要な情報をすでに得ることができます。つまり、戦略 B ではノイズの影響が戦略 A よりも少ない可能性があります。
使用すべき戦略をどのように決定すればよいでしょうか。既存の広告主やキャンペーンの場合は、過去のデータに基づいて、コンバージョン数が戦略 A と戦略 B のどちらに適しているかを判断できます。ただし、新しい広告主またはキャンペーンの場合は、次のことを決定できます。
- 詳細なキーを使用して 1 か月分のデータを収集します（戦略 A）。データの収集期間を延長するため、サマリー値は高くなり、ノイズは相対的に小さくなります。
- 週あたりのコンバージョン数と購入額を妥当な精度で評価します。
この例では、週ごとの購入回数と購入額が十分に高く、戦略 A でユースケースで許容できるノイズの割合が発生するとします。
戦略 A はシンプルで、ノイズへの効果があり、意思決定の能力に影響しないため、戦略 A を採用することにしました。
ハッシュ化アルゴリズムを選択
ハッシュベースのアプローチで鍵を生成することにします。これを行うには、そのアプローチをサポートするハッシュ アルゴリズムを選択する必要があります。
ここでは SHA-256 を選択したとします。MD5 などのよりシンプルで安全性の低いアルゴリズムを使用することもできます。
ブラウザの場合: キーと値を設定する
キーの構造とハッシュ アルゴリズムを決定したら、ユーザーが広告をクリックまたは表示してコンバージョンを達成したときに、キーと値を登録します。
次に、ブラウザでキーと値を登録するために設定するヘッダーの概要について説明します。
ソース側の主要部分の設定
ユーザーが広告をクリックまたは表示したときに、Attribution-Reporting-Register-Aggregatable-Source ヘッダーで集計キーを設定します。この段階では、鍵ごとに、広告配信時に判明している部分（キーピース）のみを設定できます。
鍵となる要素を生成しましょう。
では、鍵となる要素を設定しましょう。
// Upon receiving the request from the publisher site
res.set(
"Attribution-Reporting-Register-Aggregatable-Source",
JSON.stringify([
{
"id": "key_purchaseCount",
"key_piece": "0x3cf867903fbb73ec0000000000000000"
},
{
"id": "key_purchaseValue",
"key_piece": "0x245265f432f16e730000000000000000"
}
])
);
キー ID は最終的なレポートには表示されません。これらはブラウザでキーを設定する場合にのみ使用され、ソース側とトリガー側のキーピースを互いにマッピングして完全なキーに結合できます。
省略可: イベントレベル レポート
イベントレベルのレポートと集計可能レポートを併用する必要がある場合は、特定のソースでイベントレベルのデータ（ソースイベント ID とトリガーデータ）と集計キーが一致するようにする必要があります。
たとえば、イベントレベル レポートで、購入に至る可能性が高い広告のタイプをモデル化する場合、両方のレポートを使用できます。
ユーザーがコンバージョンに至る
ユーザーがコンバージョンに至ると、通常、ピクセル リクエストが広告テクノロジー サーバーに送信されます。このリクエストを受け取った場合:
- コンバージョン側（トリガー側）のキーピースを設定して、キーを完成させます。これらの主要な要素は、ヘッダー
Attribution-Reporting-Register-Aggregatable-Trigger-Dataで設定します。 - ヘッダー
Attribution-Reporting-Register-Aggregatable-Valuesを使用して、そのコンバージョンの集計可能値を設定します。
トリガー側の鍵を設定して鍵を完成させる
鍵となる要素を生成しましょう。
| 鍵 ID のトリガー側のキーピースは... | 設定するディメンション値を含む文字列 | この文字列のハッシュを 16 進数で表し、最初の 64 ビットにカット（64÷4 = 16 文字1） | XOR 処理を簡略化simplifyするために、ゼロが追加された 16 進数ハッシュ。これがソース側のキーピースです。 |
|---|---|---|---|
key_purchaseCount |
ProductCategory=25 |
0x1c7ce88c4904bbe2 | 0x0000000000000000f9e491fe37e55a0c |
key_purchaseValue |
（同じ） | （同じ） | （同じ） |
では、鍵となる要素を設定しましょう。
// Upon receiving the pixel request from the advertiser site
res.set(
"Attribution-Reporting-Register-Aggregatable-Trigger-Data",
JSON.stringify([
// Each dictionary independently adds pieces to multiple source keys
{
"key_piece": "0x0000000000000000f9e491fe37e55a0c",
"source_keys": ["key_purchaseCount", "key_purchaseValue"]
},
])
);
source_keys に複数のキー ID をリストして、同じキーピースを複数のキーに追加していることに注意してください。1 つのキーピースは両方のキーに追加されます。
集計可能な値を設定する
ノイズを減らすために、集計可能な値を設定する前に、値をスケールアップする必要があります。
商品タイプ 25 の 1 回の購入が 5,200 円で行われたとします。
これらの値を集計可能な値として直接設定することはありません。
key_purchaseCount: コンバージョン 1 件key_purchaseValue: 52 ドル
代わりに、これらの集計可能値を登録する前に、ノイズを最小限に抑えるために値をスケーリングする必要があります。
資金提供予算を消費する目標は 2 つあるため、資金提供予算を 2 つに分割することもできます。
この場合、各目標に最大 CONTRIBUTION_BUDGET/2（65,536÷2=32,768）が割り当てられます。
サイトのすべてのユーザーの購入履歴に基づく、1 ユーザーの最大購入額が $1,500 であるとします。外れ値（この合計を費やしたユーザーが非常に少ないなど）があるかもしれませんが、そのような外れ値は無視することもできます。
購入額のスケーリング ファクタは次のとおりです。
((CONTRIBUTION_BUDGET÷2) ÷ 1,500) = 32,768÷1,500 = 21.8 約 22
広告のクリックまたは表示（ソースイベント）ごとに最大 1 回の購入をトラッキングすることになっているため、購入数のスケーリング ファクタは 32,768÷1 = 32,768 です。
次の値を設定できるようになりました。
key_purchaseCount: 1 × 32,768 = 32,768key_purchaseValue: 52 × 22 = 1,144
実際には、専用のヘッダー Attribution-Reporting-Register-Aggregatable-Values を使用して、次のように設定します。
// Instruct the browser to schedule-send a report
res.set(
"Attribution-Reporting-Register-Aggregatable-Values",
JSON.stringify({
"key_purchaseCount": 32768,
"key_purchaseValue": 1144,
})
);
集計可能レポートが生成されます
ブラウザは、コンバージョンを以前のビューまたはクリックと照合し、集計可能なレポートを生成します。このレポートには、レポート メタデータの横に暗号化されたペイロードが含まれます。
以下に、クリアテキストで読み取り可能な場合に、集計可能レポートのペイロード内にあるデータの例を示します。
[
{
key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece XOR conversion-side key piece for the key key_purchaseCount
value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
},
{
key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece XOR conversion-side key piece for the key key_purchaseValue
value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
},
]
この例では、1 つの集計可能レポート内に 2 つの異なる寄与度が表示されています。
概要レポートをリクエストする
- バッチ集計可能レポート。バッチ処理で提示されているアドバイスに従います。
- データを表示する鍵を生成します。たとえば、キャンペーン ID 12 × 地域 ID 7 × 商品カテゴリ 25 の
COUNT（合計購入回数）とVALUE（合計購入額）の概要データを表示するには、次のようにします。
| リクエストする指標1 | ソース側の主要部分 | トリガー側のキーピース | 集計サービスへのリクエストのキー2 |
|---|---|---|---|
合計購入数（COUNT） |
0x3cf867903fbb73ec 0000000000000000 |
0x00000000000000 00f9e491fe37e55a0c |
0x3cf867903fbb73 ecf9e491fe37e55a0c |
合計購入額（VALUE） |
0x245265f432f16e73 0000000000000000 |
0x0000000000000000 f9e491fe37e55a0c |
0x245265f432f16e73 f9e491fe37e55a0c |
- これらのキーの概要データを集計サービスにリクエストします。
概要レポートを処理する
最終的に、次のような概要レポートを受け取ります。
[
{"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
"value": "2558500"},
{"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
"value": "687060"},
…
]
最初のバケットはバイナリの COUNT キーです。2 番目のバケットはバイナリの VALUE キーです。キーは異種ですが（COUNT と VALUE）、同じレポートに含まれます。
値をスケールダウンする
- 2,558,500 は、このキーの購入回数を表し、以前に計算したスケーリング ファクタでスケールアップされます。購入数のスケーリング ファクタは 32,768 です。2,558,500 を予算の分担額で割ります。2,558,500÷32,768 = 購入数 156.15 です。
- 687,060 → 687,060÷22 = 合計購入額 $31,230
その結果、概要レポートでは次のような分析情報が得られます。
- レポート対象期間内で、ヨーロッパで実施されたキャンペーン 12 では商品カテゴリ #25 の購入数が約 156 回（±ノイズ）で発生しました。
- レポート対象期間内で、ヨーロッパで実施されたキャンペーン 12 では商品カテゴリ #25 の購入額が 31,230 ドル（±ノイズ）となりました。