集計キーの概要、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 つ）を生成するようにブラウザに指示します。
後で説明するように、{集計キー、集計可能な値} 集計レポートは、このレポートとまったく同じではありません。まずは、レポートに含まれる情報について説明します。
2 つの貢献を生成するようブラウザに指示すると、ブラウザは集計可能レポートを生成します（コンバージョンを以前の表示またはクリックと照合できる場合）。
集計可能なレポートには、次のものが含まれます。
- 設定した寄付
- クリックまたは表示イベントとコンバージョン イベント（コンバージョンが発生したサイトなど）に関するメタデータ。集計可能レポートですべてのフィールドを表示する
集計可能なレポートは JSON 形式で、最終的な概要レポートのデータ入力として使用されるペイロード フィールドなどが含まれます。
ペイロードには、各要素が {集計キー、集計可能な値} ペアである貢献のリストが含まれます。
bucket: バイト文字列としてエンコードされた集計キー。value: その測定目標の集計可能な値（バイト文字列としてエンコード）。
次の例をご覧ください。
{
"data": [
{
"bucket": "111001001",
"value": "11111010000",
}
],
"operation": "histogram"
}
実際には、集計可能なレポートは、バケットと値が前の例とは異なるようにエンコードされます（バケットは \u0000\u0000\x80\u0000 のように見える場合があります）。バケットと値はどちらもバイト文字列です。
概要レポート
集計可能レポートは、次のように多くのブラウザとデバイス（ユーザー）にわたって集計されます。
- 広告テクノロジーは、特定のキーセットの概要レポートと、さまざまなブラウザ（ユーザー）から取得した特定の集計レポートをリクエストします。
- 集計可能レポートは、集計サービスによって復号されます。
- キーごとに、集計可能レポートの集計可能値が合計されます。
- ノイズはサマリー値に追加されます。
結果は、{集計キー、概要値} ペアのセットを含む概要レポートです。
概要レポートには、JSON 辞書形式の Key-Value ペアのセットが含まれます。各ペアには次のものが含まれます。
bucket: バイト文字列としてエンコードされた集計キー。value: 特定の測定目標の概要値（小数値）。利用可能なすべての集計可能レポートから合計され、ノイズが追加されています。
例:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
実際には、サマリー レポートは、バケットと値が例とは異なるようにエンコードされます（バケットは \u0000\u0000\x80\u0000 のように見える場合があります）。バケットと値はどちらもバイト文字列です。
集計キーの実践
集計キー（バケット）は、広告テクノロジー企業によって定義されます。通常は、広告のクリックまたは表示時と、ユーザーがコンバージョンを達成したときに 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 番目の要素（商品カテゴリ）はコンバージョン時に設定します。
キーのこれらの部分をキーピースと呼びます。
キーは、キーピースの OR（v）を計算することで計算されます。
例:
- 送信側の鍵要素 =
0x159 - トリガー側のキーピース =
0x400 - キー =
0x159 v 0x400 = 0x559
重要な部分の調整
2 つの 64 ビットの鍵要素を、慎重に配置された 64 ビットのフィラー / オフセット（16 個のゼロ）を使用して 128 ビットに拡張すると、鍵要素の OR 演算は連結と同等になり、推論と検証が容易になります。
- ソース側のキーピース =
0xa7e297e7c8c8d0540000000000000000 - トリガー側のキーピース =
0x0000000000000000674fbe308a597271 - キー =
0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271
広告のクリックまたは表示ごとに複数のキー
実際には、アトリビューション ソース イベント（広告のクリックまたは表示）ごとに複数のキーを設定できます。たとえば、次のように設定できます。
- 地域 ID × キャンペーン ID を追跡するキー。
- クリエイティブ タイプ × キャンペーン ID を追跡する別のキー。
別の例については、戦略 B をご覧ください。
ディメンションをキーにエンコードする
サマリー レポートをリクエストするときは、特定の集計キーのセットについてサマリー レポートをリクエストして、アクセスしたい指標を集計サービスに伝える必要があります。
概要レポートには未加工の {key, summary value} ペアが含まれますが、キーに関する追加情報はありません。つまり、以下のようになります。
- ユーザーが広告を表示またはクリックし、その後コンバージョンが達成されるときにキーを設定する場合は、キーが表すディメンションの値に基づいて確実にキーを設定する必要があります。
- 概要レポートをリクエストするキーを定義するときは、集計データを表示するディメンションの値に基づいて、ユーザーが広告を表示またはクリックし、コンバージョンを行ったときに設定したキーと同じキーを確実に生成するか、その場でアクセスできるようにする必要があります。
キー構造マップを使用してディメンションをエンコードする
ディメンションをキーにエンコードするには、キーを定義する際（広告配信前）に、キー構造マップを作成して維持します。
キー構造マップは、各ディメンションと、キー内での位置を表します。
実際には、キー構造マップを作成して維持するには、デコーダ ロジックを実装して維持する必要があります。このような処理を必要としない方法をお探しの場合は、代わりにハッシュベースのアプローチの使用を検討してください。
次の例をご覧ください。
特定のキャンペーン、地域、商品の購入と購入額の両方をトラッキングするとします。
商品カテゴリ、地域 ID、キャンペーン ID は、キーのディメンションである必要があります。また、購入数と購入額という 2 つの異なる測定目標をトラッキングするため、キー内にキータイプを管理するディメンションを 1 つ追加する必要があります。これにより、概要レポートで {キー、集計可能な値} ペアを受け取ったときに、集計可能な値が実際に何を表すかを定義できます。
これらの測定目標では、キーには次のディメンションが含まれます。
- 製品カテゴリ
- 測定の目標タイプ
- 地域 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 ビットのゼロの接尾辞を追加してトリガー側の鍵片と調整し、OR の推論を容易にすることを検討してください。
- ソース側のキーピース
=<64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…> COUNTは、キー構造マップ アプローチのmeasurementGoalType=0と同じものをエンコードします。COUNTはやや簡潔で、より明確です。
- ソース側のキーピース
- コンバージョン時に、トラッキングするすべてのディメンションとその値を含む文字列を生成します。トリガー側のキーピースを生成するには、この文字列をハッシュ化して 64 ビットの接頭辞として 0 を追加します。
- トリガー側のキーピース
=
<64-bit 00000000…><64-bit hex hash("productCategory=25")>
- トリガー側のキーピース
=
- ブラウザはこれらの鍵を OR 結合して鍵を生成します。
- 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"))
- ソース側のキーピース
- ブラウザと同じように、またはこれらの鍵要素を使用して、ブラウザが以前に生成したものと同じ鍵を生成します。
- 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 回のコンバージョン
この例では、次の質問に答えようとしています。
- 各地域で最も価値の高い商品カテゴリ
- 各地域で最も効果的なキャンペーン戦略はどれですか？
また、ユースケースで週単位の分析情報が必要だとします。
次の項目も追跡する必要があります。
- 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） | OR 演算を簡素化するためにゼロが追加された 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 が 52 ドルで 1 回購入されたとします。
これらの値は、集計可能な値として直接設定しません。
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
購入数のスケーリング係数は 32,768 ÷ 1 = 32,768 です。これは、広告のクリックまたは視聴（参照元イベント）ごとに最大 1 件の購入をトラッキングすることにしたためです。
次の値を設定できるようになりました。
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 OR 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 OR 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 ドルの合計購入額。
そのため、サマリー レポートでは次のような分析情報を確認できます。
- Within the reporting time period, campaign #12
run in Europe drove about 156 purchases (± noise)
for the product category #25
```
```text
- Within the reporting time period, campaign #12
run in Europe drove $31,230 of purchases (± noise)
for the product category #25.