Attribution Reporting の提案には、コミュニティからのフィードバックに対応するために、API メカニズムの変更から新機能まで、いくつかの変更が行われています。
変更履歴
- 2022 年 2 月 7 日: ヘッダー トリガー リダイレクトのセクションを追加しました。
- 2022 年 1 月 27 日: 記事を初公開
この投稿の対象者
この投稿の内容:
- API についてすでに理解している場合（たとえば、WICG リポジトリのディスカッションを観察または参加していて、2022 年 1 月に提案に加えられた一連の変更について把握したい場合）。
- デモまたは本番環境のテストで Attribution Reporting API を使用している場合。
この API を使い始めたばかりの場合や、まだテストしていない場合は、API の概要に進んでください。
移行が進行中です
これらの変更を Chrome に実装すると、Attribution Reporting API のイベントレベル レポートをデモや本番環境のテスト（オリジン トライアル）で使用する場合、API が機能し続けるにはコードを編集する必要があります。新しい機能のご利用もご検討ください。
この記事では、集計可能レポートの変更点についても説明します。ただし、このドキュメントを執筆している時点では集計可能レポートにまだブラウザが実装されていないため、これらの変更が実装された場合、アクションや移行は必要ありません。
名前の変更
概要レポートと集計可能レポート
これまで集計レポートと呼ばれていたものは、今後は概要レポートと呼びます。
概要レポートは、複数の集計可能レポート（旧称はコントリビューションまたはヒストグラム コントリビューションと呼ばれていたレポート）を集計した最終的な出力です。
API メカニズムの変更
ヘッダーベースのソース登録（イベントレベル レポート）
変更点とその理由
ユーザーが広告を表示またはクリックすると、ブラウザ（ユーザーのデバイス上のローカル）がこのイベントとともに、アトリビューション レポートに固有のパラメータ（attributionsourceeventid、attributiondestination、attributionexpiry などのパラメータ）とともに記録されます。これらのパラメータの値はアドテックによって設定されます。
これらのパラメータの設定方法が変わります。
以前の提案では、パラメータはクライアント側で、HTML 属性としてアンカータグに含めるか、JS ベースの呼び出しの引数として含める必要がありました。パラメータは、クリック時または表示時に既知である必要があります。
新しい提案では、これらのパラメータの値はアドテック サーバーで定義されます。
これには、特にセキュリティの面でいくつかの利点があります。ヘッダー メカニズムにより、アトリビューション ソースがスコープに登録されているかどうかをレポート生成元（通常はアドテック）が直接制御できます。これにより、正規のブラウザはレポート元のオプトインなしにソースを登録しないため、不正行為の懸念は部分的に軽減されます。
ソース登録の仕組み
- アドテックは特定の広告に対して、特定のクライアントサイド属性
attributionsrcを定義する必要があります。この属性の値は、ブラウザからリクエストを送信する URL です。このリクエストには、ソースがクリックかビューかを示す値navigationまたはevent,を持つ新しい HTTP ヘッダーAttribution-Reporting-Source-Infoが含まれます。 - このリクエストを受信すると、クリックまたはビュー トラッキング サーバーは、目的のアトリビューション パラメータを含む HTTP ヘッダー
Attribution-Reporting-Register-Sourceで応答する必要があります。 このヘッダーを返すオリジンは、レポートのオリジン（以前の
attributionreportto）になりました。HTTP レスポンス ヘッダー
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
技術解説で詳細を見る
公開ディスカッションに参加する
ヘッダーベースのアトリビューション トリガー（イベントレベル レポート）
変更点とその理由
新しい提案では、クリック登録や表示登録と同様に、アトリビューション トリガー（アドテックがブラウザにコンバージョンの記録を指示した場合）がヘッダーベースのアプローチに変更されます。
このメカニズムはヘッダーベースのソース登録と整合しており、以前使用されていたリダイレクト メカニズムよりも従来型です。
また、新しい提案では、コンバージョン ページに attributionsrc 属性が必要です。
その理由は権限の問題です。以前の提案では、トリガー側のサイト（通常は広告主サイト）が Permissions-Policy ヘッダーを介して機能の一般的な制御を行っていましたが、最終的にアトリビューションをトリガーする当事者に要素がリクエストを送信できるかどうかを、要素レベルできめ細かく制御することはできませんでした。attributionsrc はこれを変更します。この必須のマーカーにより、広告主はアトリビューションをトリガーできる要素をモニタリングおよび制御できるようになります。
ソース側（通常はパブリッシャー サイト）には、Permissions-Policy によるページ全体のコントロールと、attributionsrc による要素全体のコントロールがあります。
アトリビューション トリガーの仕組み
ピクセル リクエストを受け取り、コンバージョンとして分類する必要があると判断した場合、アドテックは新しい HTTP
ヘッダー Attribution-Reporting-Register-Event-Trigger で応答する必要があります。
このヘッダーの値では、トリガー イベントを JSON オブジェクトとして扱う方法を指定します。これは、以前の提案でクエリ パラメータとして定義された情報と同じです。
HTTP レスポンス ヘッダー Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
リダイレクト（省略可）
必要に応じて、アドテック サーバーは Attribution-Reporting-Register-Event-Trigger を含むレスポンスをリダイレクト レスポンスにできます。これにより、第三者がコンバージョン イベントを監視し、コンバージョン イベントをアトリビューションするようブラウザに指示できるようになります。
リダイレクトはオプションです。アドテックとサードパーティの両方がページ上にピクセルを持っている場合は不要です。
詳しくは、第三者のレポートをご覧ください。
技術解説で詳細を見る
公開ディスカッションに参加する
ワークレットなし（集計可能レポート）
変更点とその理由
以前の集計可能レポートの提案では、これらのレポートを生成するワークレット（JavaScript ベースのメカニズム）を呼び出すために、JavaScript へのアクセスが必要でした。
新しい提案では、ワークレットは必要ありません。代わりに、アドテックは、ブラウザが集計可能レポートの生成に使用するルールを宣言的に（HTTP ヘッダーを介して）定義します。
新しい提案には次のようなメリットがあります。
- ブラウザの実装: 新しいデザインは、ワークレット設計とは異なり、ブラウザで新しい実行環境を必要としないため、大幅にシンプルになっています。
- デベロッパー エクスペリエンス: 新しいデザインはヘッダーに依存しています。ヘッダーはワークレットとは異なり、一般的に使用されており、デベロッパーによって広く知られています。また、ソース登録の API サーフェスと緊密に連携しているため、API の学習と使用が容易になります。
- 導入: 新しい設計により、より多くの既存の測定システムで集計可能レポートを使用できます。多くの測定ソリューションは HTTP のみで、JavaScript アクセスを必要としない画像リクエスト（ピクセル リクエスト）に依存しています。しかし、ワークレット アプローチでは JavaScript へのアクセスが必要であったため、既存の測定システムからの移行が困難だった可能性があります。
- 堅牢性: 新しい設計では、
keepaliveセマンティクスとの統合が容易になるため（たとえば、ユーザーがページを離れるときにクリックまたはビューが登録された場合）、データ損失が軽減されます。
ワークレットフリー メカニズムの仕組み
この宣言型メカニズムは、イベントレベルのソース登録やアトリビューション トリガー ヘッダーと同様に、HTTP ヘッダーに基づいています。これについては、次のセクションで詳しく説明します。
公開ディスカッションに参加する
ヘッダーベースのソース登録（集計可能レポート）
集計可能レポートにソースを登録するための新しいメカニズムが提案されました。このメカニズムはイベントレベルのソース登録と同じです。
ヘッダー名のみが異なります（Attribution-Reporting-Register-Aggregatable-Source）。
技術解説で詳細を見る
ヘッダーベースのアトリビューション トリガー（集計可能レポート）
集計可能レポートのソースを登録するための新しいメカニズムが提案されました。このメカニズムはイベントレベル アトリビューション トリガーと同じです。
ヘッダー名のみが異なります（Attribution-Reporting-Register-Aggregatable-Trigger-Data）。
技術解説で詳細を見る
新しい機能と特長
サードパーティ レポート（イベントレベル レポートと集計レポート）
変更点とその理由
サードパーティ レポートの用途をより適切にサポートするうえで、新しい提案には以下の 2 つの側面があります。
- 必要に応じて、アドテックはネットワーク リクエストを他のアドテック サーバーにリダイレクトできます。これにより、他のアドテックは独自のソースとトリガーの登録を実行できます。これは現在、サードパーティの一般的な構成方法です。これにより、特に既存のサードパーティのレポート システムへの API の導入が容易になります。
- レポート元（通常はアドテック）がほとんどのプライバシー制限を共有しなくなりました。これは、複数のアドテックが同じパブリッシャーまたは広告主と連携するユースケースをサポートします。
第三者によるレポートの仕組み
新しい提案では、レスポンス ベースのソース登録とトリガーは HTTP ヘッダーに依存します。アドテックは、これらのリクエストに HTTP リダイレクトを利用できます。
パブリッシャー サイトでのクリック/ビュー リクエスト（ソース登録）がその後複数の当事者にリダイレクトされると、各当事者はこのビューまたはクリック（ソースイベント）を登録できます。
同様に、アドテックは広告事業者サイトから行われた特定のアトリビューション リクエストをリダイレクトし、複数の他の当事者がコンバージョンを登録できるようにすることができます（アトリビューション トリガー）。
各当事者は、それぞれ個別のレポートにアクセスし、個別のデータを使用してレポートを設定できます。
リダイレクトなしで複数のトリガーを登録する
また、コンバージョン側に複数のピクセル要素（トリガーごとに 1 つ）を追加して、リダイレクトを使わずに複数のアトリビューション トリガーを登録することもできます。
公開ディスカッションに参加する
ビュースルー測定（イベントレベル レポートと集計可能レポート）
変更点とその理由
新しい提案では、ビュースルー測定とクリックスルー測定が一体となって機能します。
registerattributionsrcは、クリックとともにビューを記録するようにブラウザに指示するビュー固有の属性であり、提案に含まれなくなりました。- クリックとビューのプライバシー メカニズムが統合されました。詳細については、ノイズと透明性をご覧ください。
この変更は、新しいヘッダーベースの登録メカニズムに合わせて提案されています。また、クリックスルーとビュースルーの両方の測定に対応する場合にも、デベロッパー エクスペリエンスが簡素化されます。
ビュースルー測定の仕組み
ビュースルー測定とクリックスルー測定はどちらもヘッダーベースの登録に依存しています。
技術解説で詳細を見る
公開ディスカッションに参加する
デバッグ / パフォーマンス分析（イベントレベル レポートと集計レポート）
変更点とその理由
提案にデバッグ メカニズムが追加され、デベロッパーはバグを検出できるようになりました。また、Attribution Reporting のパフォーマンスを既存の Cookie ベースの測定ソリューションと比較することもできます。
デバッグの仕組み
ソースとトリガーの登録はどちらも、新しいパラメータ debug_key を受け入れます。これは 64 ビットの符号なし整数（つまり、大きな値）です。
ソースとトリガーのデバッグキーを使用してレポートが作成されており、ソースとトリガーの登録時にレポートの送信元の Cookie jar に Samesite=None ar_debug=1 Cookie が存在する場合、デバッグ レポート（JSON）が .well-known/attribution-reporting/debug エンドポイントに送信されます。
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
イベントレベル レポートと集計可能レポートにも、これら 2 つの新しいパラメータが含まれるため、正しいデバッグ レポートに関連付けることができます。
技術解説で詳細を見る
公開ディスカッションに参加する
フィルタリング機能（イベントレベル レポートと集計可能レポート）
変更点とその理由
これらは今日の広告エコシステムの重要なユースケースをサポートしているため、イベントレベル レポートと集計可能レポートの両方で多くのユースケースがサポートされるようになります。
- コンバージョン フィルタリング: ソース側の情報に基づいてコンバージョンをフィルタリングします。たとえば、広告のクリックと視聴とで異なるトリガーデータ（コンバージョン データ）を選択します。
- アトリビューションの不一致: 誤ってアトリビューションされたコンバージョンを除外します。これはコンバージョン フィルタリングの一種です。たとえば、API の etld+1 デスティネーション スコープが原因で間違った広告クリックまたは広告ビューに一致したコンバージョンを除外します。
フィルタリング機能の仕組み（イベントレベル レポートの場合）
ソース側の JSON オブジェクトの source_data フィールド（省略可）では、変換時にフィルタリング ロジックを適用するために後でブラウザが使用するアイテムを定義できます。
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
トリガーの登録で、オプションのヘッダー Attribution-Reporting-Filters が受け入れられるようになりました。
HTTP レスポンス ヘッダー Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
または、Attribution-Reporting-Register-Event-Trigger ヘッダーを filters フィールドで拡張し、選択的フィルタリングを行い、source_data に基づいて trigger_data を設定することもできます。
フィルタの JSON 内のキーが source_data のキーと一致する場合、共通部分が空であればトリガーが完全に無視されます。
技術解説で詳細を見る
公開ディスカッションに参加する
プライバシー保護の変更
ノイズと透明性（イベントレベル レポートと集計レポート）
変更点とその理由
新しい提案では、レポートのプライバシー メカニズムの 1 つが改善され、ランダム化レスポンスがレポートの対象になります。
つまり、実際のコンバージョンの一部が正しくレポートされ、一定の割合で、実際のコンバージョンが抑制されたり、偽のコンバージョンが追加されたりすることがあります。
この新しい手法には、いくつかの利点があります。
- クリックと表示のプライバシー メカニズムを統合します。
- トリガーデータ（コンバージョン データ）とトリガー元リンクのノイズを分離するメカニズムよりも簡単に推論できます。
- このフレームワークではプライバシー フレームワークを確立し、適切なノイズ設定により、いかなる当事者もこの API を使用して、個々のユーザーが特定の広告のコンバージョンを達成した（または達成しなかった）ことを確実に把握できるようにする。
この新しいメカニズムは、トリガーデータ（コンバージョン データ）の 5% がランダムな値に置き換えられていた以前のメカニズムに代わるものです。
また、ランダムなレスポンスの確率値がレポート本文（randomized_trigger_rate フィールド）に追加されました。このフィールドでは、ソースがランダムなレスポンスの対象となる確率（0 ～ 1）を指定します。
これには主に 2 つのメリットがあります。
- これにより、レポートを受け取る側（通常はアドテック）に対して、基盤となるブラウザの動作がtransparentになります。
- これは、API がブラウザ間でサポートされる将来に役立ちます。さまざまなブラウザがプライバシーの目標に応じて異なるレベルのノイズを適用する可能性があり、レポートを処理する関係者がこれを把握する必要があります。
ノイズの仕組み
新しい提案では、ソースの登録時（広告クリックまたは広告ビューが記録されるとき）に、ブラウザがコンバージョンのアトリビューションを正しく関連付けてこの広告クリックまたは広告ビューのレポートを送信するか、代わりに偽の出力を生成するかをランダムに決定します。
架空の出力は次のようになります。
- レポートは一切表示しない - ユーザーがコンバージョンを達成したかどうかに関係なく、
- 偽のレポートが 1 つまたは複数 - ユーザーがコンバージョンを達成したかどうかにかかわらず。
偽のレポートでは、トリガーデータ（コンバージョン データ）はランダムです。クリックの場合は 3 ビットのランダムな値（0 ～ 7 の任意の数）、視聴の場合は 1 ビットのランダムな値（0 または 1）です。
実際のレポートと同様に、ユーザーがコンバージョンに至った直後に偽のレポートは送信されません。ランダムなレポート期間の最後に送信されます。
クリックのレポート期間には、3 つ（クリック後 2 日、7 日、30 日）があります。各架空のレポートは、いずれかのレポート期間にランダムに割り当てられます。
これとは別に、前回の提案で説明したように、期間内のレポートの順序はランダムです。
技術解説で詳細を見る
公開ディスカッションに参加する
レポートに関する制限事項（イベントレベル レポートと集計可能レポート）
変更点とその理由
新しい提案では、2 つのサイト間でイベントを測定できる当事者の数を明示的に制限しています。
- {publisher, Advertiser} ごとにソースを登録できる一意のレポート生成元（通常はアドテック）の最大数は、30 日間あたり 100 個に制限することをおすすめします。このカウンタは、アトリビューションされていないものも含め、広告クリックまたは広告ビュー（ソースイベント）ごとにインクリメントされます。
- {publisher, Advertiser} ごとにレポートを送信できる一意のレポート生成元（通常はアドテック）の最大数は、30 日間あたり 10 個に制限することをおすすめします。このカウンタは、貢献度が割り当てられたコンバージョンごとに加算されます。
これらの上限は、アクターによるコンバージョン測定の能力を制限しない程度に高く、かつ API の不正使用の一部を軽減できる程度に低く抑えるためのものです。
レポートのクールダウン / レート上限
変更点とその理由
レポートのクールダウンは、特定の期間内にこの API を通じてユーザーに送信される情報の合計量を制限するプライバシー メカニズムです。
新しい提案では、{ソースサイト、リンク先、レポート元}（通常は {パブリッシャー、広告主、アドテック}）ごとに 100 件のレポートを 30 日でスケジュールできます。
この制限を超えると、ブラウザは指定された {ソースサイト、リンク先、レポート元}（通常は {パブリッシャー、広告主、アドテック}）に一致するレポートのスケジュール設定を停止します（30 日ごとのレポート数がその {ソースサイト、リンク先、レポート元} で 100 を下回るまで）。
技術解説で詳細を見る
リンク先の上限（イベントレベル レポートのみ）
変更点とその理由
リンク先の上限が変更され、レポートのオリジン（通常はアドテック）がスコープに含まれるようになりました。{publisher, adtech} ごとに、100 個の一意の保留中のリンク先（通常は広告主のサイト、またはコンバージョンの発生が想定されるサイト）が許可されます。
これは、閲覧履歴の再構築を制限するプライバシー保護です。
技術解説で詳細を見る
すべてのリソース
- Attribution Reporting をご覧ください。
- API について知っておくべきことを確認する。
ヘッダー画像は、Diana Polekhina（Unsplash より）の投稿です。