アトリビューション レポート: システム全体の概要

技術的な意思決定者向けに、Attribution Reporting の連携サービスの概要を説明します。

Attribution Reporting API を使用すると、広告テクノロジーと広告主は、広告クリックまたは広告ビューが購入などのコンバージョンにつながったタイミングを測定できます。この API は、ビジネスニーズに応じて、クライアント側とサーバー側の統合の組み合わせに依存します。

続行する前に、アトリビューション レポートの概要を必ずお読みください。これにより、API の目的と、さまざまな出力レポート(イベントレベル レポート概要レポート)のフローを理解できます。不明な用語については、プライバシー サンドボックスの用語集をご覧ください。

この記事の対象読者

次の場合は、この記事をお読みください。

  • 広告テクノロジーまたは広告主の技術的な意思決定者である。運用、DevOps、データ サイエンス、IT、マーケティングなど、技術的な実装に関する意思決定を行う職種に携わっていただきます。あなたは、この API がプライバシーに配慮した測定においてどのように機能するのでしょうか。
  • この API と集計サービス環境を使用してテストを設定する技術担当者(デベロッパー、システム オペレータ、システム アーキテクト、データ サイエンティストなど)である。

この記事では、Attribution Reporting API におけるサービスの仕組みについて、全体にわたって全体的に説明します。技術者は、ローカルでこの API を試すことができます。

概要

Attribution Reporting API は多くのサービスで構成されており、特定の設定、クライアント側の構成、サーバーのデプロイが必要です。何が必要かを判断するには、まず次のことを行います。

  • 設計に関する意思決定。収集する情報を定義し、特定のキャンペーンでどのようなコンバージョンが想定されるかを特定し、収集するレポートタイプを決定します。最終的な出力は、イベントレベル レポートと概要レポートのいずれかまたは両方になります。

レポートをサポートするために、常に 2 つ(場合によっては 3 つ)のコンポーネントが連携して機能します。

  • ウェブサイトとブラウザの通信:Cookie ベースのシステムでは、コンバージョンと広告エンゲージメントの情報が識別子に関連付けられ、お客様や分析サービスが後でこれらのイベントを結合できるようになります。この API では、ブラウザはユーザーの指示に基づいて、コンバージョンを広告のクリック/表示と関連付けてから、分析に送ります。そのため、広告レンダリング コードとコンバージョン トラッキングは、以下の要件を満たす必要があります。
    • どのコンバージョンをどの広告クリックやインプレッションに関連付けるかをブラウザに伝えます。
    • その他のデータがある場合は、それを最終レポートに含めます。
  • データの収集。ユーザーのブラウザで生成されたレポートを受信するには、コレクタ エンドポイントが必要です。ブラウザからの出力は、イベントレベル レポートと集計可能レポート(暗号化され、概要レポートの生成に使用される)のいずれかになります。

集計可能レポートを収集した場合は、3 つ目のコンポーネントが必要です。

  • 概要レポートの生成。集計可能レポートをバッチ処理し、集計サービスを使用してレポートを処理し、概要レポートを生成します。

設計上の意思決定

Attribution Reporting の重要な原則は、初期の設計上の決定です。どのデータをどのカテゴリでどのように処理するかをユーザーが決定します。出力レポートでは、キャンペーンやビジネスに関する分析情報を確認できます。

出力レポートは次のいずれかです。

  • イベントレベル レポートでは、(広告側の)特定の広告クリックまたは広告ビューを、コンバージョン側のデータと関連付けます。サイト間でのユーザー ID の結合を制限することで、ユーザーのプライバシーを保護するため、コンバージョン側のデータは極めて限定的であり、データに不要な情報が含まれています(つまり、ごく一部のケースでは、実際のレポートではなくランダムなデータが送信されます)。
  • 概要レポートは、広告側の特定のイベントには関連付けられていません。これらのレポートでは、より詳細なコンバージョン データが得られ、クリックや表示のデータとコンバージョン データを柔軟に結合できます。

レポートの選択内容によって、収集する必要があるデータが決まります。

最終出力は、意思決定に使用するツールへの入力と考えることもできます。たとえば、ある総支出額につながったコンバージョン数を特定するために概要レポートを生成する場合、チームはそれに基づいて総支出額を高めるために次の広告キャンペーンの目標を決定できます。

測定する対象を決定したら、Attribution Reporting API のクライアントサイドを設定できます。

ウェブサイトとブラウザの通信

パブリッシャーのウェブサイトのアトリビューション ソースは、広告主のウェブサイトのトリガーと接続されます。
パブリッシャーのウェブサイト上のアトリビューション ソースは、広告主のウェブサイトのトリガーと接続されます。

アトリビューション イベントのフロー

広告を掲載するパブリッシャー サイトについて考えてみましょう。広告主や広告技術プロバイダは、広告に対するインタラクションについて把握し、コンバージョンを適切な広告に結び付けたいと考えています。レポート(イベントレベルと集計可能の両方)は次のように生成されます。

  1. パブリッシャー サイトで、特別な属性 attributionsrc を使用して広告要素(<a> または <img> タグ)が設定されています。値は URL です(例: https://adtech.example/register-source/ad_id=...)。

    クリックされたときにソースを登録するリンクの例を次に示します。

    <a href="https://shoes.example/landing" 
      attributionsrc="http://adtech.example/register-source?..."
      target="_blank">
    Click me</a>
    

    以下は、表示されるときにソースの登録を引き起こす画像の例です。

    <img href="https://advertiser.example/landing" 
      attributionsrc="https://adtech.example/register-source?..."/>
    

    HTML 要素の代わりに、JavaScript 呼び出しを使用することもできます。

    以下は、window.open() を使用した JavaScript の例です。特殊文字の使用を避けるために、URL は URL エンコードされています。

    const encodedUrl = encodeURIComponent(
      'https://adtech.example/attribution_source?ad_id=...');
    window.open(
      "https://shoes.example/landing",
      "_blank",
      attributionsrc=${encodedUrl});
    
  1. ユーザーが広告をクリックまたは表示すると、ブラウザから attributionsrc(通常は広告主または広告技術プロバイダのエンドポイント)に GET リクエストが送信されます。
  2. このリクエストを受け取った広告主または広告技術プロバイダは、広告とのインタラクションのソースイベントを登録するようブラウザに指示し、後でコンバージョンをその広告に関連付けることができます。そのために、広告主または広告技術プロバイダはレスポンスに特別な HTTP ヘッダーを含めます。ソースイベント(広告クリックまたは広告ビュー)に関する情報を提供するこのヘッダーのカスタムデータに追加されます。この広告でコンバージョンが発生した場合、このカスタムデータは最終的にアトリビューション レポートに表示されます。

    広告を表示またはクリックします。

  3. その後、このユーザーが広告主のサイトにアクセスします。

  4. 広告主のサイトの関連するページ(購入確認ページや商品ページなど)で、コンバージョン ピクセル(<img> 要素)または JavaScript 呼び出しが https://adtech.example/conversion?param1=...&param2=... にリクエストを送信します。

  5. この URL のサービス(通常は広告主または広告技術プロバイダ)がリクエストを受信します。コンバージョンとして分類されるため、ブラウザにコンバージョンを記録する(つまりアトリビューションをトリガーする)よう指示する必要があります。そのためには、広告主または広告技術プロバイダが、ピクセル リクエストに対するレスポンスに、コンバージョンに関するカスタムデータを含む特別な HTTP ヘッダーを含めます。

  6. ブラウザ(ユーザーのローカル デバイスのブラウザ)がこのレスポンスを受け取り、コンバージョン データを元のソースイベント(広告クリックまたは広告表示)と照合します。詳しくは、ソースとトリガーを照合するをご覧ください。

  7. ブラウザにより、レポートが attributionsrc に送信されるようにスケジュール設定されます。このレポートには次の内容が含まれます。

    1. ステップ 3 で広告技術プロバイダまたは広告主がソースイベントに添付したカスタム アトリビューション設定データ。
    2. ステップ 6 のカスタム コンバージョン データセット
    コンバージョン。
  8. その後、ブラウザは attributionsrc で定義されたエンドポイントに、遅延とノイズを加えてレポートを送信します。集計可能レポートは暗号化されますが、イベントレベル レポートは暗号化されません。

アトリビューション トリガー(広告主様のウェブサイト)

アトリビューション トリガーは、コンバージョンを取得するようにブラウザに指示するイベントです。

購入など、広告主にとって最も重要なコンバージョンをキャプチャすることをおすすめします。概要レポートでは、複数のコンバージョンの種類とメタデータを取得できます。

これにより、これらのイベントの集計結果が詳細かつ正確になります。

ソースとトリガーを照合する

ブラウザはアトリビューション トリガーのレスポンスを受信すると、ローカル ストレージにアクセスして、アトリビューション トリガーの生成元とそのページ URL の eTLD+1 の両方に一致するソースを探します。

たとえば、ブラウザは shoes.example/shoes123adtech.example からアトリビューション トリガーを受け取ると、adtech.exampleshoes.example の両方に一致するソースをローカル ストレージで探します。

フィルタ(またはカスタムルール)を設定すると、トリガーが特定のソースに一致するタイミングを決定できます。たとえば、特定の商品カテゴリのコンバージョンのみをカウントするようにフィルタを設定し、他のカテゴリはすべて無視します。フィルタと優先順位付けモデルを使用すると、より高度なアトリビューション レポートを作成できます。

ローカル ストレージに複数のアトリビューション ソースがある場合、ブラウザは最後に保存されたアトリビューション ソースを選択します。アトリビューション ソースに優先度が割り当てられている場合、ブラウザは最も優先度が高いソースを選択します。

データの収集

対応するソースに一致するアトリビューション トリガーが、ブラウザから広告テクノロジー所有のサーバー(収集エンドポイントまたは収集サービスとも呼ばれる)上のレポート エンドポイントにレポートとして送信されます。これらのレポートは、イベントレベル レポートまたは集計可能レポートです。

集計可能レポートは、概要レポートの生成に使用されます。集計可能レポートは、(パブリッシャーのサイト上の)広告から収集されたデータと(広告主のサイトから)コンバージョン データを組み合わせたものです。これは、広告テクノロジーが収集する前にユーザーのデバイスのブラウザで生成および暗号化されます。

イベントレベル レポートの遅延は 2 ~ 30 日です。集計可能レポートは 1 時間以内のランダムな遅延で送信されます。イベントは、コントリビューション バジェット内に収まる必要があります。これらの選択は、プライバシーを保護し、個々のユーザーのアクションの悪用を防止します。

イベントレベル レポートのみに関心がある場合は、これがインフラストラクチャの最後の部分となります。ただし、概要レポートを生成する場合は、追加のサービスで集計可能レポートを処理する必要があります。

概要レポートの生成

概要レポートを生成するには、広告テクノロジーが運用する集計サービスを使用して集計可能レポートを処理します。集計サービスは、ユーザーのプライバシーを保護するためにノイズを追加し、最終的な概要レポートを返します。

集計可能レポートは、収集、バッチ処理されて、広告テクノロジー環境に送信されます。
この図は、収集エンドポイント(レポートのバッチ処理)から、広告テクノロジーが所有する集計サービスでの処理までの非同期データフローを表しています。

収集された集計可能レポートをバッチ処理した後、バッチは集計サービスによって処理されます。コーディネーターは、証明済みのバージョンの集計サービスにのみ復号鍵を提供します。次に、集計サービスはデータを復号して集計し、ノイズを追加してから、結果を概要レポートとして返します。

バッチ集計可能レポート

集計可能レポートは、処理する前にバッチ処理する必要があります。バッチは、戦略的にグループ化された集計可能レポートで構成されます。戦略はほとんどの場合、特定の期間(毎日、毎週など)を反映します。このプロセスは、レポート エンドポイントとして機能するのと同じサーバー上で実行できます。

高い信号対雑音比を確保するためには、バッチに多くのレポートを含める必要があります。

期間を長くすると、ノイズが少ない結果になります。
待機状態を 1 日と 1 週間で比較します。1 時間経過すると、サマリー値が小さくなり、ノイズの多い結果が表示されるようになります。ある日、サマリー値が大きくなってしまうため、ノイズが少なくなる可能性があります。

毎年恒例のセールなど、量の増加が予想される特定のイベントを確実に捉えられるように、バッチ期間はいつでも変更できます。バッチ処理期間は、アトリビューション ソースやトリガーを変更せずに変更できます。

集計サービス

集計サービスは、集計可能レポートを処理してサマリー レポートを生成します。集計可能レポートは暗号化され、高信頼実行環境(TEE)で実行される集計サービスのみが読み取ることができます。

集計サービスは、データを復号して集計するためにコーディネーターに復号鍵をリクエストします。復号されて集計された結果は、プライバシーを保護するためにノイズがかけられ、概要レポートとして返されます。

実務担当者は、集計サービスをローカルでテストするために、集計可能なクリアテキスト レポートを生成できます。Nitro Enclaves を使用して AWS で暗号化されたレポートでテストすることもできます。

次のステップ

Google は、誰にとっても有効な API を構築するために、お客様との会話に参加したいと考えています。

API についてディスカッションする

他のプライバシー サンドボックス API と同様に、この API はドキュメント化され、一般公開で議論されています。

API のテスト

Attribution Reporting API に関する会話をテストして参加できます。