コンバージョンの測定を有効にする

コンバージョン アトリビューションの測定には、パブリッシャー、広告主、配信広告テクノロジー（広告を配信するエンティティ）、測定プロバイダなど、複数の関係者が関与する場合があります。このドキュメントでは、一般的なコンバージョン測定シナリオについて説明しますが、一般的に、Attribution Reporting API（ARA）からアトリビューション レポートを受け取る場合は、このドキュメントで説明する統合手順を実施する必要があります。

たとえば、一般的にパブリッシャーは 1 つ以上の広告テクノロジーに広告の配信を担当します。これには、クリエイティブのマークアップを提供する当事者、クリエイティブのインプレッションまたはトラッキング ピクセルを提供する当事者、パブリッシャー ページの広告スロット用の SDK またはタグを提供する当事者が含まれる場合があります。これらの広告テクノロジーは、ARA からアトリビューション レポートを受け取りたい場合もあれば、受け取りたくない場合もありますが、ダウンストリームの広告テクノロジーがアトリビューション レポートを受信できるように配置されています。

また、クロスネットワーク アトリビューションやその他のレポート機能で、サードパーティのコンバージョン測定プロバイダを使用している場合もあります。広告主はこのデータを使用して、複数の固有のパブリッシャーとチャネルにおける広告の費用対効果を把握します。そのため、これらのユースケースに対応するために Attribution Reporting API を有効にする方法を DSP や広告サーバーが理解することが重要です。サードパーティを使用したい広告主は、引き続き第三者測定プロバイダを利用するか、社内サーバーを設定して API でレポートを登録し、受信することができます。

Attribution Reporting API を使用すると、複数の広告テクノロジーが、同じインプレッションまたはコンバージョンのアトリビューション ソースとトリガーを登録し、API から個別のレポートを受け取ることができます。たとえば、DSP は Attribution Reporting API から独自のアトリビューション レポートを受け取ることや、広告主の第三者測定プロバイダ向けに個別のレポートを作成できます。広告テクノロジーは、API からレポートを受け取るためにアトリビューション ソースとトリガーの両方を登録する必要があります。広告テクノロジーが API に個別に登録したアトリビューション ソースとトリガー間でアトリビューションが行われます。

一般的なコンバージョン測定シナリオ

このセクションでは、コンバージョン測定の一般的な 2 つのシナリオを見ていきます。

シナリオ 1: 配信広告テクノロジーと第三者測定プロバイダの両方が Attribution Reporting API からレポートを受け取る必要がある

広告主は、サードパーティの測定プロバイダを使用して広告在庫にコンバージョンを関連付けることを希望し、クリエイティブをホストしている広告テクノロジーは広告在庫でコンバージョンを関連付けることを希望しています。これは、広告クリエイティブのマークアップを提供し、独自のアトリビューション レポートを実行し、第三者測定プロバイダや分析プロバイダと統合する広告主と連携している DSP や広告主の広告サーバー（第三者広告サーバー、3PAS）などによくあることです。

この場合、配信広告テクノロジーは、現在の設定でクリック イベントとインプレッション イベントを発生させる当事者でもあります。配信広告テクノロジーは、新しい attributionsrc を適切な場所に設定し、リダイレクトが正しく構成されるようにする必要があります。また、配信広告テクノロジーと第三者測定プロバイダの両者は、プロバイダが登録済みで、サーバーが Attribution Reporting API リクエストを受信して応答できる状態であることを確認する必要があります。

一般的なキャンペーン設定は次のようになります。

  1. 広告主の広告サーバー（3PAS）が、広告クリエイティブのマークアップを DSP に提供します。DSP には、第三者測定プロバイダのインプレッション トラッキング ピクセルとクリック トラッキング ピクセルが含まれます。広告サーバーは、広告クリエイティブのマークアップに attributionsrc が含まれていることを確認する必要があります。

  2. DSP では、インプレッションとクリック トラッキングのピクセルを追加する機能があるため、入札に使用する最終的な広告クリエイティブのマークアップに attributionsrc を含める必要があります。

シナリオ 2: 第三者測定プロバイダのみが Attribution Reporting API からレポートを受信する必要がある

広告主は、サードパーティの測定プロバイダを使用して広告枠でコンバージョンをアトリビューションしたいと考えていますが、クリエイティブをホストする広告テクノロジーにアトリビューション測定の要件がありません。これは、クリエイティブをホストしており、自身でアトリビューション レポートを使用する予定はないパブリッシャー、SSP、パブリッシャー広告サーバーで、DSP パートナーや、測定用のタグ設定会社（第三者広告サーバー、測定、分析プロバイダなど）向けに Attribution Reporting API を有効にしたい場合によく見られます。

この場合は、現在の設定でクリック イベントとインプレッション イベントを発生させる責任がある当事者が、新しい attributionsrc 属性をクリエイティブに追加し、リダイレクトが意図したとおりに機能することを確認する必要があります。これは各パブリッシャーの統合に大きく依存しますが、クリック イベントの場合、これは SSP、配信広告テクノロジー、またはパブリッシャー自体である可能性があります。インプレッション イベントでは、第三者測定プロバイダが一般的に使用されます。

シナリオ 1 の典型的なキャンペーン設定例の場合、パブリッシャーの広告サーバー、SSP、またはパブリッシャー自身が、DSP から提供された attributionsrc 属性をパブリッシャーのページに反映させるだけで済みます。

実装の詳細

次の表に、Attribution Reporting API の実装手順の概要を示します。

手順 業務の責任 例
ステップ 1: 既存のクリエイティブと測定コードに対してアトリビューション ソースを有効にする インプレッション イベントの呼び出しまたはクリック イベントの処理を担当するエンティティが attributionsrc 属性を追加します。 クリック イベントの場合、通常はクリエイティブをレンダリングする購入者（DSP または広告主の広告サーバー）が属性を追加します。

インプレッション イベントの場合、この属性は、デマンドサイド プラットフォーム（DSP）、サプライサイド プラットフォーム（SSP）、パブリッシャー、広告サーバー、または測定プロバイダによって追加されます。この属性は、パブリッシャーの設定によって異なります。

VAST フォーマットを使用する動画広告の場合は、パブリッシャーと動画 SDK がこの属性を追加します。
ステップ 2: サードパーティのオリジンのアトリビューション レポートを有効にする 既存のリダイレクト パスを 302 リダイレクトとともに使用する場合は、すぐに使用できます。

302 リダイレクトを使用できない場合は、attributionsrc 属性を使用して複数の広告テクノロジー サーバーをリストできます。

 一般的に、attributionsrc 属性がクリエイティブに追加されている限り、サードパーティのリダイレクトは Attribution Reporting API 呼び出しを受け取ります。
ステップ 3: Attribution Reporting API リクエストに対するレスポンスを設定する Attribution Reporting API からレポートを受け取る任意のエンティティ 広告主様がご利用の DSP と第三者測定プロバイダ

なお、各ステップの詳細は、パブリッシャーのページでクリエイティブがどのようにレンダリングされて配信されるか、どの広告テクノロジー エンティティが Attribution Reporting API から送信されたレポートを受信するかによって異なります。

ステップ 1: 既存のクリエイティブと測定コードに対してアトリビューション ソースを有効にする

最初のステップでは、アトリビューション ソースを有効にします。

attributionsrc 属性の仕組み

新しい attributionsrc 属性は、Attribution Reporting API リクエストの送信先を指定します。インプレッション イベントとクリック イベントを発生させるエンティティは、attributionsrc 属性を使用してクリエイティブを更新する必要があります。attributionsrc は既存のクリック イベントとインプレッション イベントに追加する必要があります。空にすることも、空にすることもできます。

リダイレクトを使用するクリック イベントの場合は、attributionsrc 属性をナビゲーションに追加する必要があります。ナビゲーション後の 302 リダイレクトでは、attributionsrc 属性を追加する必要はなく、最初のナビゲーションに attributionsrc が追加されていれば ARA の対象となります。

attributionsrc が空の場合、ARA リクエストはアンカータグの href 属性で定義された URL（リンク先 URL）に送信されます。attributionsrc 属性が定義されると、ARA リクエストは attributionsrc 属性で定義された URL に送信されます。リンク先 URL でもソースを登録できます。

通常、リンク先 URL をホストしているサーバーが Attribution Reporting API リクエストを受信して応答できる場合は、空の attributionsrc 属性を使用します。Attribution Reporting API リクエストを別のサーバーに送信する場合は、独自の attributionsrc URL を定義します。

空の attributionsrc 属性の例:

既存の設定 ARA との統合あり
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>

attributionsrc 属性が空の場合、Attribution Reporting API リクエストはアンカータグの href 属性で定義された URL に送信されます。

空でない attributionsrc 属性の例:

既存の設定 ARA との統合あり
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[ATTRIBUTION_SRC_URL]">...</a>

attributionsrc が空でない場合、Attribution Reporting API リクエストは attributionsrc タグで定義された URL に送信されます。リンク先 URL でもソースを登録できます。

クリック イベントとインプレッション イベント用に attributionsrc を追加

  • クリック イベント:
    • 通常、attributionsrc の追加を担当するエンティティは、配信広告テクノロジーです。
    • クリック イベントを含むアンカータグには、attributionsrc 属性を追加する必要があります。
    • window.open を使用するクリックでは、window.open 呼び出しの windowFeatures 引数を使用してアトリビューション ソースを指定する必要があります。
  • インプレッション イベント:
    • 通常、attributionsrc を追加するエンティティは、配信広告テクノロジーと測定プロバイダです。
    • <img> タグまたは <script> タグから配信されたインプレッション イベントには、attributionsrc 属性を含める必要があります。
    • Fetch API を使用するインプレッション イベントでは、Fetch API 呼び出しに渡される options 引数に attributionReporting オブジェクトを含める必要があります。

クリック イベントとインプレッション イベントに必要な変更の概要については、次の表をご覧ください。

イベント タグ 既存の設定 ARA の統合後
。 HTML <a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
JavaScript window.open("[CLICKTHROUGH_URL]", "_blank"); window.open("[CLICKTHROUGH_URL]", "_blank", "attributionsrc");
インプレッション HTML <img> タグ <img src="[IMPRESSION_URL]"> <img src="[IMPRESSION_URL]" attributionsrc>
HTML <script> タグ <script src="[IMPRESSION_URL]"></script> <script src="[IMPRESSION_URL]" attributionsrc></script>
JavaScript const options = {...}
window.fetch("[IMPRESSION_URL]", options); 		const options = {
  attributionReporting: {
    eventSourceEligible: true,
    triggerEligible: false,
  },
  ...
};
window.fetch("[IMPRESSION_URL]", options);

Protected Audience オークションでアトリビューション ソースの登録を有効にする

Protected Audience のオークションでコンバージョンを測定する場合は、attributionsrc を使用する代わりに、registerAdBeacon/registerAdMacro と setReportEventDataForAutomaticBeacons/reportEvent を使用してアトリビューション ソースの登録を有効にできます。

Protected Audience シグナルをレポートする場合、registerAdBeacon 関数はレポート ワークレット内で、registerAdMacro は購入者獲得レポート ワークレット内でそれぞれ使用できます。その後、Fenced Frame Ads Reporting API の reportEvent 関数と setReportEventDataForAutomaticBeacons 関数を使用して、広告フレーム内のイベントデータを登録済みのビーコンとマクロに追加できます。これにより、Protected Audience レポート ワークレットのシグナルと広告クリエイティブのフレーム イベント ペイロードを相互に関連付けることができます。

Attribution-Reporting-Eligible HTTP ヘッダーは、フレームからの reportEvent 呼び出しによってビーコンとマクロがトリガーされたとき、またはブラウザによって自動ビーコンがトリガーされたときに、リクエストに追加されます。ビーコンのレスポンスを使用して、アトリビューション ソースを登録できます。第三者による測定を許可するために、ビーコン リクエストがリダイレクトされる場合があります。

詳しくは、Fenced Frame Ad Reporting API の Attribution Reporting のサポートに関するセクションをご覧ください。

VAST フォーマットのアトリビューション レポートを有効にする

VAST は動画広告枠の配信と測定によく使用される形式です。この標準で定義されているイベントの多くは、Attribution Reporting API への登録の対象となるソースイベントであると考えられます。詳しくは、アトリビューション レポート サポートに関する VAST の追加条項をご覧ください。端的に言えば、<Tracking>、<Impression>、<*ClickThrough>、<*ClickTracking> のイベントはすべて、アトリビューション ソース イベントとなる可能性があります。すべての VAST 実装では、これらのイベントの登録対象カバレッジを指定する必要があります。

VAST の追加条項では、これらの要素の新しい属性が定義されています。これにより、アトリビューション登録専用のセカンダリ URL を設定できます。イベントに attributiontype="DOUBLE_PING" と attributionsrc="[URL]" が含まれている場合、そのイベントを起動するコードでは、Attribution Reporting API を有効にする際に attributionsrc 属性の値として [URL] を使用する必要があります。VAST の追加条項には各シナリオの例が記載されています。

最大限のカバレッジを確保するため、VAST の実装では、イベントの ping を呼び出したときに、リストされているすべてのイベントがデフォルトで登録の対象となるようにする必要があります。たとえば、<Impression> イベント URL を呼び出す場合、リクエストの送信に使用する <img> 要素（またはフェッチ呼び出しの同等の要素）で（空の）attributionsrc 属性を使用して、受信側がそのイベントを Attribution Reporting API に登録できるようにする必要があります。

ステップ 2: サードパーティのオリジンのアトリビューション レポートを有効にする

サードパーティが Attribution Reporting API を使用できるようにするには、既存のリダイレクトを使用するか、第三者のリストを attributionsrc 属性に追加します。ほとんどの場合、広告テクノロジーごとに独自のインプレッション トラッカーがあるため、クリック トラッカーにはリダイレクトの方が適しています。

既存のリダイレクト チェーン内のサードパーティのオリジンを処理する

通常の広告のクリックでは、多くのクリック トラッカーが、最終的なランディング ページへのナビゲーションの一環として行われる 302 リダイレクトのチェーンとして表示されることがあります。元のクリック ターゲットに attributionsrc アノテーションが付けられているか、Protected Audience API で registerAdBeacon/registerAdMacro を使用して登録されていれば、リダイレクト チェーンのすべてのリクエストが Attribution Reporting API への登録の対象となります。リダイレクト チェーンの広告テクノロジーも登録されている必要があります。

最初のリクエストの本文は、リダイレクトでは送信されないことに注意してください。Protected Audience のオークションでは、reportEvent と setReportEventDataForAutomaticBeacons に渡された eventData をリダイレクトの一部として使用する必要がある場合は、リダイレクト URL の一部として明示的に渡す必要があります。

次の例では、アトリビューション レポートを生成して受信する 2 つの異なるエンティティとして、配信広告テクノロジー（serving-adtech.example）と第三者測定プロバイダ（3p-measurement.example）を使用します。この例の配信広告テクノロジーは、パブリッシャーのサイトにクリエイティブを表示する DSP で、独自のレポート プロダクトを備えています。第三者測定プロバイダは、広告主がコンバージョン レポートに使用するエンティティである場合があります。

ファースト パーティがソースを登録し、サードパーティがソースを登録する方法を示す図

ソースの登録時に、次の処理が行われます。

  1. serving-adtech.example がクリエイティブに attributionsrc 属性を設定します。ユーザーがパブリッシャーのページにアクセスすると、ブラウザが serving-adtech.example. にリクエストを送信します。
  2. serving-adtech.example は Attribution-Reporting-Register-Source ヘッダーと Location ヘッダーを返します。
    1. serving-adtech.example は Attribution-Reporting-Register-Source ヘッダーを使用して、登録するソースに関するメタデータを返します。
    2. serving-adtech.example は、Location ヘッダーを使用して 3p-measurement.example へのリダイレクトを含めます。第三者への 302 リダイレクトをサポートするため、既存のクリック トラッキング フローで Location ヘッダーがすでに使用されている可能性があります。
  3. ブラウザは serving-adtech.example からレスポンスを受け取り、Attribution-Reporting-Register-Source ヘッダーを解析します。ブラウザは、serving-adtech.example をレポート送信元として使用して、ソースイベントを保存します。
  4. このリクエストはリダイレクトであるため、ブラウザは 3p-measurement.example に対して新しいリクエストも送信します。
  5. 3p-measurement.example は、Attribution-Reporting-Register-Source ヘッダーを含むレスポンスを返します。
  6. ブラウザは 3p-measurement.example からこのレスポンスを受け取り、Attribution-Reporting-Register-Source を読み取ります。ブラウザは、3p-measurement.example をレポート送信元として使用して、ソースイベントを保存します。

リダイレクト チェーンに含まれていないサードパーティのオリジンには attributionsrc を使用

複数のレポーターのオリジンがナビゲーション イベントにソースを登録する必要があるものの、なんらかの理由でリダイレクト チェーンに表示されない場合は、代替ソリューションとして複数のサイトをアトリビューション ソースとして attributionsrc にリストします。

既存の設定 ARA の変更あり
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[REPORTING_URL_1] [REPORTING_URL_2]">...</a>

この例では、Attribution Reporting API の対象となるリクエストが REPORTING_URL_1 と REPORTING_URL_2 の両方に送信されます。リンク先 URL に送信されたナビゲーション リクエストも、アトリビューション ソースの登録対象となります。

ステップ 3: Attribution Reporting API リクエストに対するレスポンスを設定する

Attribution Reporting API リクエストを受信するすべてのオリジンについて、サーバーが適切な Attribution-Reporting-Register-Source ヘッダーで応答していることを確認します。レスポンスの作成方法については、ソースの登録ガイドと説明をご覧ください。

複数のトリガーを登録する

コンバージョン側に複数のピクセル要素（トリガーごとに 1 つ）を追加すると、複数のアトリビューション トリガーを登録できます。トリガー登録では、attributionsrc 要素は省略可能です。

ソース登録と同じ方法で、リダイレクト リクエストを使用するか、attributionsrc 要素に複数の URL を指定することで、1 つのピクセル要素から複数のトリガーを登録することもできます。同じオリジンによって生成されたソースイベントとトリガー イベントが一致します。