集計キーとは何か、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: 指定された測定目標の要約値（10 進数）。利用可能なすべての集計可能レポートから合計され、ノイズが追加されています。
例:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
実際には、要約レポートは、バケットと値が例に示されているものとは異なるようにエンコードされます（つまり、バケットは \u0000\u0000\x80\u0000 のように見えることがあります）。バケットと値はどちらもバイト文字列です。
集計キーの実際
集計キー（バケット）は、通常、広告テクノロジー企業によって 2 つのステップで定義されます。広告がクリックまたは表示されたときと、ユーザーがコンバージョンしたときです。
キー構造
キーにエンコードされるディメンションのセットを指定するために、「キー構造」という用語を使用します。
たとえば、キャンペーン ID × 地域 ID × 商品カテゴリはキー構造です。
キーの種類
集計可能な値は、複数のユーザー/ブラウザにわたって特定のキーごとに合計されます。ただし、集計可能な値を使用すると、購入額や購入数など、さまざまな測定目標をトラッキングできることがわかっています。集計サービスが同じタイプの集計可能な値を合計することを確認します。
そのためには、各キー内で、要約値が何を表しているか（このキーが参照している測定目標）を示すデータをエンコードします。その方法の 1 つは、測定目標タイプを表すキーのディメンションを追加することです。
前の例を使用すると、この測定目標タイプには次の 2 つの異なる値が考えられます。
- 購入数は、測定目標の最初のタイプです。
- 購入額は、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 をご覧ください。
ディメンションをキーにエンコードする
サマリー レポートをリクエストする際は、特定の集計キーのセットのサマリー レポートをリクエストすることで、アクセスする指標を集計サービスに伝える必要があります。
概要レポートには、{キー, 概要値} のペアがそのまま含まれており、キーに関する追加情報はありません。つまり、以下のようになります。
- ユーザーが広告を表示またはクリックした後でコンバージョンに至ったときにキーを設定する場合は、キーが表すディメンションの値に基づいて、キーを確実に設定する必要があります。
- 要約レポートをリクエストするキーを定義する際は、集計データを取得するディメンションの値に基づいて、ユーザーが広告を閲覧またはクリックしてコンバージョンしたときに設定されたキーと同じキーを、オンザフライで確実に生成またはアクセスする必要があります。
キー構造マップを使用したディメンションのエンコード
ディメンションをキーにエンコードするには、キーを定義する際（広告配信前）に、キー構造マップを事前に作成して維持します。
キー構造マップは、各ディメンションとそのキー内の位置を表します。
実際には、キー構造マップを作成して維持することは、デコーダ ロジックを実装して維持することを意味します。このような処理を必要としない方法をお探しの場合は、代わりにハッシュベースのアプローチの使用をご検討ください。
次の例をご覧ください。
特定のキャンペーン、地域、商品について、購入数と購入額の両方をトラッキングするとします。
商品カテゴリ、地域 ID、キャンペーン ID は、キーのディメンションである必要があります。また、購入数と購入額という 2 つの異なる測定目標をトラッキングする必要があるため、キータイプをトラッキングするディメンションをキーに追加する必要があります。これにより、サマリー レポートで {キー, 集計可能な値} のペアを受け取ったときに、集計可能な値が実際に何を表すかを定義できます。
これらの測定目標を使用すると、キーには次のディメンションが設定されます。
- 製品カテゴリ
- 測定の目標タイプ
- 地域 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 の購入数を表します。
ハッシュ関数を使用したディメンションのエンコード
キー構造マップを使用する代わりに、ハッシュ関数を使用して、一貫性のある信頼性の高い方法でキーを動的に生成できます。
この機能は次のように動作します。
- ハッシュ アルゴリズムを選択します。
- 広告配信時に、トラッキングするすべてのディメンションとその値を含む文字列を生成します。ソース側のキー部分を生成するには、この文字列をハッシュします。トリガー側のキー部分と整合性を取り、OR の理由を簡単に把握できるように、64 ビットのゼロの接尾辞を追加することを検討してください。
- ソース側のキーピース
=<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 回の例をご覧ください。
集計可能な値の実際
アドテック企業は、ユーザーがコンバージョンを達成したときに集計可能な値を設定します。
ユーザーのプライバシーを保護するため、各ユーザーの投稿には上限があります。1 つのソース（広告のクリックまたはビュー）に関連付けられたすべての集計可能な値について、特定の貢献度上限を超える値は存在できません。
この上限を CONTRIBUTION_BUDGET と呼びます。説明では、この上限は L1 バジェットと呼ばれますが、CONTRIBUTION_BUDGET と同じです。
貢献度予算の詳細については、概要レポートの貢献度予算をご覧ください。
例: 1 回のクリックまたはビューにつき 1 件のコンバージョン
この例では、次の質問に回答することを想定します。
- 各地域で最も価値の高い商品カテゴリはどれですか？
- 各地域で最も効果的なキャンペーン戦略はどれですか？
また、ユースケースでは週単位の分析情報が必要であるとします。
また、次のこともトラッキングする必要があります。
- 16 個の異なるキャンペーン。
- 8 つの異なる地域: 北米、中米、南米、ヨーロッパ、アフリカ、アジア、カリブ海、オセアニア。
- 29 種類の異なる商品カテゴリ。
What to measure
多くの広告テクノロジー企業は、広告主様にさまざまな種類のコンバージョンを設定することを推奨していますが、購入などの最も重要なコンバージョンに焦点を当てることで、これらの重要なコンバージョン イベントについて集計結果が詳細かつ正確であることを確認できます。実際、測定する指標が多いほど、指標あたりの貢献度予算が小さくなり、各値のノイズが大きくなる可能性があります。そのため、測定対象を慎重に選択する必要があります。
この例では、クリックまたはビューごとに 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 を使用すると、ユースケースで許容できるノイズの割合になるほど、1 週間の購入数と購入額が十分に高いと仮定します。
戦略 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 の購入が 1 件あり、価格が 52 ドルだったとします。
これらの値を直接集計可能な値として設定することはありません。
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 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.