集計キーの概要、Attribution Reporting API での使用方法、目標をキーに変換する方法。
あなたは広告テクノロジー企業が、複数の場所でさまざまな商品カテゴリのキャンペーンを実施しています。広告主が次の質問に答えられるよう支援したいと考えています。
- 各地域のキャンペーンごとに、各商品カテゴリの購入が何回発生したか。
- 各地域の各キャンペーンで、各商品カテゴリの収益はどの程度だったか。
多くの広告テクノロジー企業は、広告主様にさまざまなコンバージョンの種類を設定するよう推奨していますが、これらの重要なイベントの結果の概要が詳細かつ正確であるように、特に重要なコンバージョン（購入など）を重視することをおすすめします。
そのためには、データを収集する前にどのような質問に答えたいかを検討する必要があります。
ディメンション、キー、値
これらの問いに答えるために、ディメンション、キー、値について見ていきましょう。
ディメンション
ここで説明するように、キャンペーンでどのように収益が発生しているかを把握するには、次のディメンションをトラッキングします。
- 広告キャンペーン ID: 特定のキャンペーンの識別子。
- 地域 ID: 広告が配信された地域。
- 商品カテゴリ: 定義した商品のタイプ。
キャンペーン ID と地域 ID のディメンションは広告配信時（広告配信時間）からわかりますが、商品カテゴリはユーザーがコンバージョンを完了したとき（コンバージョンの日時）のトリガー イベントからわかります。
この例でトラッキングするディメンションは、次の図のようになります。
集計キー（バケット）とは
集計キーとバケットという用語は同じものを指します。集計キーは、レポートの設定に使用するブラウザ API で使用されます。バケットという用語は、集計レポートと概要レポート、集計サービス API で使用されます。
集計キー（略してキー）は、トラッキングするディメンションの値を表すデータです。データは、後で各集計キーに沿って集計されます。
たとえば、「商品カテゴリ」、「地域 ID」、「キャンペーン ID」の各ディメンションをトラッキングしているとします。
地域 ID 7 のユーザーがキャンペーン ID 12 の広告を表示し、その後商品カテゴリ 25 の商品を購入してコンバージョンを達成した場合、次の図のような集計キーを設定できます。
集計キーは実際にはこのとおりに見えないことは後で説明しますが、ここでは、キーに含まれる情報に注目してみましょう。
集計可能値とは
ここまでに説明した項目に関する疑問の答えを得るために、次のことを確認しましょう。
- 購入回数（購入回数）。集計されて概要レポートで利用できるようになると、合計購入数（サマリー値）になります。
- 購入ごとの収益（購入額）。集計されて概要レポートで利用できるようになると、合計収益（集計値）になります。
これら（1 回のコンバージョンの購入回数と 1 回のコンバージョンの購入額）のそれぞれが集計可能な値です。集計可能値は、測定目標の値と考えることができます。
| 問題 | 集計可能値 = 測定目標 |
|---|---|
| 購入件数 | 購入回数 |
| 収益... | 購入額 |
地域 ID 7 のユーザーがキャンペーン ID 12 の広告を見た後、商品カテゴリ 25 の商品を 120 ドルで購入してコンバージョンを達成した場合（通貨が米ドルの場合）、次のような集計キーと集計値を設定できます。
集計可能な値は多数のユーザーのキーごとに合計され、サマリー レポートにサマリー値の形式で集計インサイトが生成されます。
集計可能な値が合計され、測定目標に応じた集計インサイトが生成されます。
この図では復号を省略し、ノイズを適用していない簡略化した例を示しています。次のセクションでは、ノイズを使用したこの例の概要を説明します。
キーと値からレポートへ
次に、集計可能なキーと値とレポートの関係について説明します。
集計可能レポート
ユーザーが広告をクリックまたは表示した後でコンバージョンが発生した場合、ブラウザに {集計キーと集計可能な値} のペアを保存するよう指示することになります。
。この例では、ユーザーが広告をクリックまたは表示した後でコンバージョンを達成した場合に、2 つの貢献度（測定目標ごとに 1 つ）を生成するようにブラウザに指示しています。
集計可能レポート {集計キー, 集計可能値} は、このとおりに見えないことは後で説明しますが、ここでは、レポートに含まれる情報に注目してみましょう。
ブラウザに 2 つのコントリビューションを生成するよう指示すると、ブラウザは集計可能レポートを生成します（前のビューまたはクリックとコンバージョンを一致させる場合）。
集計可能レポートには以下が含まれます。
- 設定した寄付。
- クリックまたはビュー イベントとコンバージョン イベントに関するメタデータ（コンバージョンが発生したサイトなど）。集計可能レポートのすべてのフィールドを確認する。
集計可能レポートは JSON 形式で、最終サマリー レポートのデータ入力として使用されるペイロード フィールドなどが含まれています。
ペイロードにはコントリビューションのリストが含まれ、それぞれが {集計キー、集計可能な値} のペアです。
- バケット: バイト文字列としてエンコードされた集計キー。
- value: その測定目標の集計可能値。バイト文字列としてエンコードされます。
次の例をご覧ください。
{
"data": [
{
"bucket": "111001001",
"value": "11111010000",
}
],
"operation": "histogram"
}
実際の集計可能レポートは、バケットと値が前の例とは異なる方法でエンコードされます（つまり、バケットは \u0000\u0000\x80\u0000 のようになります）。bucket と value はどちらもバイト文字列です。
概要レポート
集計可能レポートは、多くのブラウザとデバイス（ユーザー）から次のように集計されます。
- 広告テクノロジーは、特定のキーセットの概要レポートと、さまざまなブラウザ（ユーザー）から集計可能レポートのセットをリクエストします。
- 集計可能レポートは、集計サービスによって復号されます。
- キーごとに、集計可能レポートの集計可能値が合計されます。
- ノイズがサマリー値に追加されます。
その結果、{集計キー、サマリー値} のペアのセットを含むサマリー レポートが作成されます。
概要レポートには、JSON 辞書形式の Key-Value ペアのセットが含まれます。各ペアには次のものが含まれます。
- バケット: バイト文字列としてエンコードされた集計キー。
- value: 特定の測定目標について、利用可能なすべての集計可能レポートから集計し、ノイズレベルを加えて合計した 10 進数のサマリー値。
例:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
実際の概要レポートは、バケットと値がこの例とは異なる方法でエンコードされます（つまり、バケットは \u0000\u0000\x80\u0000 のようになります）。bucket と value はどちらもバイト文字列です。
集計キーの実践
集計キー（バケット）は、通常、広告がクリックまたは表示されたときと、ユーザーがコンバージョンしたときの 2 つのステップで、広告テクノロジー企業によって定義されます。
鍵の構造
ここで「キー構造」という用語は、キーにエンコードされた一連のディメンションを指します。
たとえば、「キャンペーン ID x 地域 ID x 商品カテゴリ」が主要な構造です。
キーのタイプ
集計可能値は、複数のユーザーやブラウザで特定のキーについて合計されます。集計可能値を使用すると、購入額や購入回数など、さまざまな測定目標をトラッキングできます。集計サービスで同じタイプの集計可能な値が合計されるようにしたいと考えています。
そのためには、サマリー値が何を表すか、つまりこのキーが参照している測定目標を示すデータを、各キー内でエンコードします。その方法の一つとして、測定の目標タイプを表す追加のディメンションをキーに作成する方法があります。
先ほどの例を使用すると、この測定目標タイプには 2 つの異なる値を指定できます。
- [購入数] は、測定目標の最初のタイプです。
- [購入額] は、2 つ目の測定目標タイプです。
測定目標が n 個ある場合、測定目標タイプには n 種類の値が含まれます。
キーのディメンションは指標と考えることができます。（例: キャンペーンごとの地域ごとの特定商品の購入数）。
キーサイズ、ディメンション サイズ
鍵の最大サイズはビット数で定義されます。つまり、完全な鍵を生成するためのバイナリの 0 と 1 の数です。API では、鍵の長さは 128 ビットです。
このサイズを使用すると非常にきめ細かなキーが可能になりますが、キーが細かくなるほどノイズが多くなる可能性が高くなります。ノイズについて詳しくは、ノイズについてをご覧ください。
前述のとおり、ディメンションは集計キーにエンコードされます。各ディメンションには特定の基数、つまり、ディメンションが取り得る個別の値の数があります。基数に応じて、各次元を特定のビット数で表す必要があります。n ビットを使用すると、2n 個の異なる選択肢を表現できます。
たとえば、世界には約 200 か国があるため、国ディメンションの基数は 200 になります。このディメンションをエンコードするために必要なビット数
7 ビットは 27 =128 個の異なるオプションのみを格納します。これは必要な 200 個未満です。
8 ビットの場合、必要な 200 個を超える 28 =256 個のオプションを格納できるため、n=8 ビットを使用してこの次元をエンコードできます。
キー エンコード
ブラウザでキーを設定するときは、キーを 16 進数でエンコードする必要があります。概要レポートでは、キーはバイナリ形式（名前付きのバケット）で表示されます。
完全な鍵の鍵を 2 つ設定する
たとえば、キーを使用して次のディメンションをトラッキングするとします。
- キャンペーン ID
- 地域 ID
- 製品カテゴリ
キャンペーン ID と地域 ID のディメンションは広告配信時（広告配信時間）からわかりますが、商品カテゴリはユーザーがコンバージョンを完了したとき（コンバージョンの日時）のトリガー イベントからわかります。
実際には、次の 2 つのステップで鍵を設定します。
- クリック時または表示時にキーの一部（キャンペーン ID x 地域 ID）を設定します。
- コンバージョン発生時に、キーの 2 番目の要素である商品カテゴリ（商品カテゴリ）を設定します。
キーの各部分はキーピースと呼ばれます。
キーは、キーピースの XOR（^）を取ることで計算されます。
例:
- ソース側のキーピース =
0x159 - トリガー側のキーピース =
0x400 - キー =
0x159 ^ 0x400 = 0x559
重要なピースを揃える
慎重に配置された 64 ビットのフィラー/オフセット（16 個のゼロ）を使用して 128 ビットに拡張された 2 つの 64 ビットキーピースで、キーピースの XOR 演算は連結と同じになり、推論と検証が容易になります。
- ソース側のキーピース =
0xa7e297e7c8c8d0540000000000000000 - トリガー側のキーピース =
0x0000000000000000674fbe308a597271 - キー =
- 0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 =
- 0xa7e297e7c8c8d054674fbe308a597271
広告のクリックまたは表示ごとに複数のキー
実際には、アトリビューション ソースのイベント（広告クリックまたは広告ビュー）ごとに複数のキーを設定できます。たとえば、次のように設定できます。
- 地域 ID とキャンペーン ID をトラッキングするキー。
- クリエイティブ タイプ x キャンペーン ID をトラッキングする別のキー。
戦略 B で別の例を見てみましょう。
キーへのディメンションのエンコード
概要レポートをリクエストするときは、特定の集計キーのセットについて概要レポートをリクエストして、アクセスする指標を集計サービスに伝える必要があります。
概要レポートには、未加工の {キー, サマリー値} のペアが含まれます。キーに関する追加情報はありません。これは次のことを意味します。
- ユーザーが広告を表示またはクリックし、その後コンバージョンを達成したときにキーを設定する場合は、キーが表すディメンションの値に基づいて、キーを確実に設定する必要があります。
- 概要レポートをリクエストするキーを定義する場合、集計データを確認するディメンションの値に基づいて、ユーザーが広告を表示またはクリックしてコンバージョンしたときに設定されたキーと同じキーを、その場で確実に生成するかアクセスする必要があります。
キー構造マップを使用したディメンションのエンコード
ディメンションをキーにエンコードするには、キーを定義する際（広告配信時間の前）にキー構造マップを作成して管理できます。
キー構造マップは、各ディメンションとキー内の位置を表します。
実際には、キー構造マップを作成して維持するには、デコーダ ロジックを実装して維持する必要があります。このような処理を必要としない方法を探している場合は、代わりにハッシュベースのアプローチの使用を検討してください。
次の例をご覧ください。
たとえば、特定のキャンペーン、地域、商品について、購入額と購入額の両方をトラッキングするとします。
商品カテゴリ、地域 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 ビットのゼロのサフィックスを追加してトリガー側のキーピースに合わせて調整し、XOR を簡単に推測できるようにすることを検討してください。
- ソース側のキーピース
= <64 ビットの 16 進数ハッシュ("COUNT, campaignID=12, geoID=7"))><64 ビット 00000000...> - COUNT は、キー構造マップのアプローチでは、measurementGoalType=0 と同じものをエンコードします。COUNT はもう少し簡潔で、より明示的です。
- ソース側のキーピース
- コンバージョン時に、トラッキングするすべてのディメンションとその値を含む文字列を生成します。トリガー側のキーピースを生成するには、この文字列をハッシュ化し、64 ビットの接頭辞ゼロ（0）を追加します。
- トリガー側のキーピース = <64 ビット 00000000...><64 ビット 16 進数ハッシュ("productCategory=25")>
- ブラウザは、これらのキーピースを XOR 演算してキーを生成します。
- 128 ビット集計キー
= <64 ビット 16 進数ソース側のキーピース ハッシュ><64 ビット 16 進数ソース側のキーピース ハッシュ>
- 128 ビット集計キー
- 後で、このキーの概要レポートをリクエストする準備ができたら、その場でキーを生成します。
- 目的のディメンションに基づいて、前述のようにソース側とトリガー側のキーピースを生成します。
- ソース側のキーピース
= <64 ビットの 16 進数ハッシュ("COUNT, campaignID=12, geoID=7"))><64 ビット 00000000...> - トリガー側のキーピース
= <64 ビット 00000000...><64 ビット 16 進数ハッシュ("productCategory=25")> - トリガー側のキーピース = toHex(hash("productCategory=25"))
- ソース側のキーピース
- ブラウザと同様に、これらのキーピースを XOR 演算して、ブラウザが以前に生成したものと同じキーを生成します。
- 128 ビット集計キー
= <64 ビットソース側のキーピース ハッシュ><64 ビットソース側のキーピース ハッシュ>
- 128 ビット集計キー
- 目的のディメンションに基づいて、前述のようにソース側とトリガー側のキーピースを生成します。
このハッシュベースのアプローチを使用する場合の実用的なヒントは次のとおりです。
- 常に同じディメンションの順序を使用してください。これにより、ハッシュを確実に再生成できます。（「COUNT, CampaignID=12, GeoID=7」と指定すると、「COUNT, GeoID=7, CampaignID=12」と同じハッシュは生成されません）。これを簡単に行う方法の一つは、ディメンションを英数字順に並べ替えることです。これが例で行う処理です。ただし、常に 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 は「一本深い」戦略と考えることができます。
- 概要レポートの各サマリー値は、トラッキングしているすべてのディメンションと関連付けられています。
- これらの集計値を各ディメンションとともにロールアップできるため、これらのロールアップはディメンションの数と同じ深さにすることができます。
戦略 A では、次のような問いに対する答えが得られます。
| 問題 | 正解 |
|---|---|
| 各地域で最も価値が高い商品カテゴリは？ | すべてのキャンペーンについて、概要レポートに記載されている購入概要レポートと値を合計します。 これにより、地域 ID × 商品カテゴリごとの購入回数と購入額がわかります。 地域ごとに、さまざまな商品カテゴリの購入額と数を比較します。 |
| 各地域で最も効果的なキャンペーン戦略はどれか | すべての商品カテゴリの概要レポートにある購入概要レポートにある購入数と値を合計します。 これにより、キャンペーン ID x 地域 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 は戦略 A よりもノイズによる影響が小さくなると考えられます。
どの戦略を採用するか、どのように判断すればよいでしょうか。既存の広告主やキャンペーンの場合は、過去のデータに基づいて、コンバージョン数が戦略 A と戦略 B のどちらに適しているかを判断できます。ただし、新しい広告主やキャンペーンの場合は、次のように設定することもできます。
- きめ細かいキーを使用して 1 か月分のデータを収集します（戦略 A）。データ収集の期間を延長するため、サマリー値は大きくなり、ノイズは比較的少なくなります。
- 週あたりのコンバージョン数と購入額を妥当な精度で評価します。
この例では、週あたりの購入数と購入額が十分に高く、戦略 A ではユースケースで許容できるノイズ率になると仮定します。
戦略 A はシンプルで、意思決定に影響しないノイズの影響が生じるため、戦略 A を採用することにしました。
ハッシュ化アルゴリズムを選択する
鍵の生成にはハッシュベースのアプローチを採用することにします。そのためには、そのアプローチをサポートするハッシュ アルゴリズムを選択する必要があります。
SHA-256 を選択したとします。MD5 などのよりシンプルで安全性の低い アルゴリズムを使用することもできます
ブラウザの場合: キーと値を設定する
鍵の構造とハッシュ化アルゴリズムを決定したら、広告をクリックまたは表示してコンバージョンを達成したときにキーと値を登録できます。
次は、ブラウザでキーと値を登録するために設定するヘッダーの概要です。
ソース側の重要なピースを設定する
ユーザーが広告をクリックまたは表示したら、Attribution-Reporting-Register-Aggregatable-Source ヘッダーで集計キーを設定します。この段階では、キーごとに、広告配信時に判明しているキーの一部（キーピース）のみを設定できます。
重要なピースを生成しましょう。
| 鍵 ID のソース側のキーピース | 設定するディメンション値を含む文字列 | この文字列のハッシュを 16 進数で、最初の 64 ビットにカット（64÷4 = 16 文字1） | XOR 演算を簡素化 するためのゼロが追加された 16 進数ハッシュ。これはソース側のキーピースです。 |
|---|---|---|---|
| key_purchaseCount | COUNT、CampaignID=12、GeoID=7 | 0x3cf867903fbb73ec | 0x3cf867903fbb73ec0000000000000000 |
| key_purchaseValue | VALUE、CampaignID=12、GeoID=7 | 0x245265f432f16e73 | 0x245265f432f16e730000000000000000 |
それでは、重要な部分を設定しましょう。
// 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 をリストすることで、同じ鍵を複数の鍵に追加する方法に注目してください。鍵部分は両方の鍵に追加されます。
集計可能値を設定する
集計可能な値を設定する前に、ノイズを減らすために値をスケールアップする必要があります。
商品カテゴリ 25 で 5,200 円で 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
広告クリックまたは視聴（ソースイベント）ごとに最大 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 x 地域 ID 7 x 商品カテゴリ 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.
Within the reporting time period, campaign #12
run in Europe drove $31,230 of purchases (± noise)
for the product category #25.