集計キーの概要、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 形式で、最終的な概要レポートのデータ入力として使用されるペイロード フィールドなどが含まれます。
ペイロードには、各要素が {集計キー、集計可能な値} ペアである貢献のリストが含まれています。
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 つの値が考えられます。
- 最初のタイプは購入数です。
- 2 つ目の測定目標は購入価値です。
測定目標が n 個ある場合、測定目標タイプには n 種類の値が設定されます。
キーのディメンションは指標と考えることができます。たとえば、「特定の地域のキャンペーンあたりの特定の商品の購入数」などです。
キーサイズ、ディメンション サイズ
最大キーサイズはビット単位で定義されます。これは、完全なキーを作成するためにバイナリでゼロと 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 をご覧ください。
ディメンションをキーにエンコードする
概要レポートをリクエストする際は、特定の集計キーのセットの概要レポートをリクエストして、アクセスする指標を集計サービスに伝える必要があります。
概要レポートには、元の {キー、概要値} ペアが含まれ、キーに関する追加情報は含まれません。つまり、以下のようになります。
- ユーザーが広告を表示またはクリックした後にコンバージョンに至ったとしてキーを設定する場合は、キーが表すディメンションの値に基づいて、信頼性の高いキーを設定する必要があります。
- 概要レポートをリクエストするキーを定義する際は、集計データを表示するディメンションの値に基づいて、ユーザーが広告を表示またはクリックしてコンバージョンを達成したときに設定されたキーと同じキーを、信頼性を持って生成するか、その場でアクセスする必要があります。
キー構造マップを使用してディメンションをエンコードする
ディメンションをキーにエンコードするには、キーを定義する際に（広告配信時間の前に）キー構造マップを事前に作成して維持します。
キー構造マップは、各ディメンションとキー内のディメンションの位置を表します。
実際に鍵構造マップを作成して維持するには、デコーダ ロジックを実装して維持する必要があります。このような処理を必要としない方法をお探しの場合は、代わりにハッシュベースのアプローチの使用を検討してください。
次の例をご覧ください。
特定のキャンペーン、地域、商品の購入と購入額の両方をトラッキングするとします。
商品カテゴリ、地域 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 ビットのゼロの接頭辞を追加します。
- トリガー側のキーピース
=
<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"))
- 送信側の鍵要素
- ブラウザと同様に、これらの鍵片を OR 演算して、ブラウザが先ほど生成した鍵と同じ鍵を生成します。
- 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 では、次の質問に回答します。
| 質問 | 回答 |
|---|---|
| 各地域で最も価値の高い商品カテゴリはどれですか？ | すべてのキャンペーンの概要レポートに含まれる概要の購入数と値を合計します。 これにより、地域 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 では、戦略 A よりもノイズの影響が小さくなる可能性があります。
どの戦略を使用するかを判断するにはどうすればよいですか？既存の広告主様やキャンペーンの場合は、過去のデータに基づいて、コンバージョン数が多い方が戦略 A に適しているのか、戦略 B に適しているのか判断できます。ただし、新しい広告主様やキャンペーンの場合は、次の対応を検討してください。
- 詳細なキーを使用して 1 か月分のデータを収集する（戦略 A）。データ収集期間を延長するため、概要の値は高くなり、ノイズは相対的に低くなります。
- 週あたりのコンバージョン数と購入額を適度な精度で評価します。
この例では、戦略 A では、ユースケースで許容できるノイズ率が得られると想定しています。これは、週あたりの購入数と購入額が十分に多いためです。
戦略 A はシンプルで、ノイズの影響が意思決定能力に影響しないため、戦略 A を選択することにしました。
ハッシュ アルゴリズムを選択する
ハッシュベースのアプローチを使用して鍵を生成することにしました。そのためには、そのアプローチをサポートするハッシュ アルゴリズムを選択する必要があります。
SHA-256 を選択したとします。MD5 など、よりシンプルで安全性の低いアルゴリズムを使用することもできます。
ブラウザでキーと値を設定する
キー構造とハッシュ アルゴリズムを決定したので、ユーザーが広告をクリックまたは表示してコンバージョンに至った場合に、キーと値を登録する準備が整いました。
次に、ブラウザでキーと値を登録するために設定するヘッダーの概要を示します。
ソースサイドの鍵要素を設定する
ユーザーが広告をクリックまたは表示したときに、Attribution-Reporting-Register-Aggregatable-Source ヘッダーに集計キーを設定します。この段階では、キーごとに設定できるのは、広告配信時に既知のキーの一部（キーピース）のみです。
必要なファイルを生成しましょう。
| キー ID のソースサイド キーピース | 設定するディメンション値を含む文字列 | この文字列のハッシュ（16 進数で最初の 64 ビット（64/4 = 16 文字）に切り捨て）1 | OR 演算を簡素化 するためにゼロが追加された 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 | 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 をリストすることで、同じキーピースを複数のキーに追加しています。キーピースは両方のキーに追加されます。
集計可能な値を設定する
集計可能な値を設定する前に、ノイズを低減するために値をスケールアップする必要があります。
商品タイプ 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.