アトリビューション レポートの提案では、いくつかの変更が加えられました 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 などのパラメータ）。「
これらのパラメータの値はアドテックによって設定されます。
これらのパラメータの設定方法が変わります。
以前のプロポーザルでは、パラメータをクライアントサイド（アンカータグか）に含める必要がありました。 または JS ベースの呼び出しの引数として指定できます。クリック時または表示時にパラメータを知る必要がある あります。
新しいプロポーザルでは、これらのパラメータの値はアドテック サーバーで定義されます。
この方法には、特にセキュリティの面で利点があります。ヘッダー メカニズムにより、 オリジン（通常はアドテック）が、アトリビューション ソースが あります。これにより、不正行為に関する懸念が部分的に軽減されます。今回の変更により、正規のブラウザが レポートオリジンのオプトインなしでソースを登録する。
ソース登録の仕組みを教えてください。
- 特定の広告について、アドテックで特定のクライアントサイド属性を定義する必要がある
attributionsrc。この属性の値は、ブラウザから送信される requestこのリクエストには、新しい HTTP ヘッダーAttribution-Reporting-Source-Infoが含まれます。次の HTTP ヘッダーは 値、navigationまたはevent,には、それぞれ参照元がクリックかビューかを指定します。 - このリクエストを受信すると、クリック/ビュー トラッキング サーバーが 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 ベースのメカニズム）を使用して、これらのレポートを生成します。
新しい提案では、ワークレットは不要です。代わりに、アドテックが 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: ブラウザに指示するビュー固有の属性 クリック数とともに記録されます。この提案は終了しました。- プライバシーの仕組みはクリック時と表示時で統一されました。詳しくは、ノイズ 透明性を確保します。
この変更は、新しいヘッダーベースの登録メカニズムに合わせて提案されます。 また、クリックスルーとビュースルーの両方をサポートする場合、デベロッパー エクスペリエンスが簡素化されます。 測定します
ビュースルー測定の仕組み
ビュースルー測定とクリックスルー測定は、どちらもヘッダーベースの登録に依存します。
技術解説で詳細を確認する
公開ディスカッションに参加
デバッグ、パフォーマンス分析（イベントレベル レポートと集計レポート）
変更点とその理由
この提案には、デベロッパーがバグを検出できるようにデバッグ メカニズムが追加されています。 アトリビューション レポートのパフォーマンスを、Cookie ベースの既存の測定ソリューションと比較する。
デバッグの仕組み
ソース登録とトリガー登録の両方で、新しいパラメータ debug_key（64 ビット符号なし）を受け取ります。
整数（つまり大きな数値）を指定します。
ソースとトリガーのデバッグキーを使用してレポートが作成され、Samesite=None ar_debug=1 Cookie があるかどうか
ソースとトリガーの登録時にレポート送信元の Cookie jar に存在する（デバッグ
レポート（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 のキーと一致する場合、トリガーは
です。
共通部分が空の場合、完全に無視されます。
技術解説で詳細を確認する
公開ディスカッションに参加
プライバシー保護に関する変更
ノイズと透明性（イベントレベル レポートと集計レポート）
変更点とその理由
新しい提案では、レポートのプライバシー メカニズムの一つであるレポート
ランダムな回答を受けることがあります。
つまり、実際のコンバージョンの一部が正確にレポートされます。一定の割合の
これにより、実際のコンバージョンが抑制されたり、架空のコンバージョンが追加されます。
この新しい手法には次のようなメリットがあります。
- クリックとビューに関するプライバシー メカニズムが統合されています。
- トリガーデータ（コンバージョン データ）とトリガーソースのリンクノイズを分離するメカニズムよりも、推論がシンプルです。
- 適切なノイズ設定を使用することで、どの当事者も API を使用して、個々のユーザーが特定の広告をコンバージョンに至った（またはしていない）ことを確実に知ることができなくなるプライバシー フレームワークが確立されます。
この新しいメカニズムは、5% の確率でデータをトリガーし、 （コンバージョン データ）がランダムな値に置き換えられました。
また、ランダムなレスポンス確率の値がレポートの本文に追加されています。
（randomized_trigger_rate フィールド）。このフィールドは、送信元が特定の IP アドレスに
ランダム化したレスポンスが
適用されるからです
これには、主に 2 つのメリットがあります。
- レポートの送信先に対して、基盤となるブラウザの動作が透過的になる。 （通常はアドテック）。
- これは、将来的に API がさまざまなリージョンでサポートされ、 ブラウザ: ブラウザによって、適用されるノイズレベルはブラウザによって異なります。 報告を処理する当事者がこれを把握する必要があります。
ノイズの仕組み
新しいプロポーザルでは、ソースが登録される（広告のクリックや視聴が記録される）時点で、 ブラウザは、コンバージョンのアトリビューションが正当であるかをランダムに判断し、そのコンバージョンに関するレポートを送信する 広告クリックや広告ビューではなく偽の出力が生成されているかどうかなど、慎重に判断する必要があります。
架空の出力は次のようになります。
- レポートがまったくない - ユーザーがコンバージョンに至るかどうかにかかわらず、
- 偽造の報告が 1 件または複数 - ユーザーがコンバージョンに至るかどうかにかかわらず。
偽のレポートに表示されるトリガーデータ（コンバージョン データ）は、クリック（任意の ビュー（0 または 1）のランダムな 1 ビット値。
実際のレポートと同様に、ユーザーがコンバージョンに至った直後に偽のレポートが送信されることはありません。送付先: ランダムなレポート期間の終わり。
クリック数のレポート期間には、3 つの期間（クリック後 2 日、7 日、30 日）があります。フェイクの いずれかのレポート期間にランダムに割り当てられます。
これとは別に、前述の提案ですでに説明したように、期間内のレポートの順序はランダムです。
技術解説で詳細を確認する
公開ディスカッションに参加
レポートの制限（イベントレベル レポートと集計レポート）
変更点とその理由
新しいプロポーザルでは、2 つのサイト間でイベントを測定できる当事者の数を明示的に制限します。
- 登録できる一意のレポート送信元（通常はアドテック）の最大数 {publisher, advertiser} あたりの参照元は、30 日間あたり 100 件までとすることが提案されています。この カウンタは、広告クリックまたは広告ビュー（ソースイベント）のたびにカウントされ、 できます。
- 1 対 1 でレポートを送信できる一意のレポート送信元（通常はアドテック）の最大数 {publisher, advertiser} の 30 日間あたり 10 回の上限が提案されています。このカウンタは 貢献度が割り当てられたすべてのコンバージョンでカウントされます。
これらの制限は、アクターが測定する能力を制限しない程度に高くすることを意図しています。 ある程度の API の不正使用を軽減できる程度に低いものになります。
レポートのクールダウン / レート制限
変更点とその理由
報告のクールダウンは、送信される情報の合計量を調整するプライバシー メカニズムです 一定の期間にこの API 経由でアクセスした場合です。
新しい提案では、{ソースサイト、リンク先、レポート元} あたり 100 件のレポート （通常は {publisher、advertiser, アドテック}）は 30 日間にわたってスケジュール設定できます。
この制限を超えると、ブラウザは指定された {source site, destination、reporting origin}（通常は {publisher、advertiser、adtech}）- 直近 30 日間まで その {ソースサイト、リンク先、レポート元} のレポート数が 100 を下回っています。
技術解説で詳細を確認する
送信先の上限設定（イベントレベル レポートのみ）
変更点とその理由
リンク先の上限が変更され、スコープにレポート元（通常はアドテック）が含まれる: 100（一意） 保留中のリンク先（通常は、広告主のサイト、またはコンバージョンの発生が予想されるサイト） place）は {publisher, adtech} ごとに許可されています。
これは、閲覧履歴の再構築を制限するプライバシー保護機能です。
技術解説で詳細を確認する
すべてのリソース
- Attribution Reporting をご確認ください。
- API について知っておくべきことを確認します。
ヘッダー画像は、Unsplash の Diana Polekhina によるものです。