このアトリビューション レポートの提案には、コミュニティからのフィードバックに対応するため、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 です。このリクエストには新しい HTTP ヘッダーAttribution-Reporting-Source-Infoが含まれます。その値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 にアクセスして、集計可能レポートを生成するワークレット（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 ビットの符号なし整数（大きい数値）です。
レポートがソースとトリガーのデバッグキーで作成され、ソースとトリガーの登録時にレポート送信元の Cookie ジャーに 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 内のキーと一致する場合、共通集合が空であれば、トリガーは完全に無視されます。
技術的な説明で詳細を確認する
公開ディスカッションに参加する
プライバシー保護に関する変更
ノイズと透明性（イベントレベルのレポートと集計レポート）
変更点とその理由
新しい提案では、レポートのプライバシー メカニズムの一つが改善され、レポートがランダム化されるレスポンスの対象となります。
つまり、正しくレポートされるのは実際のコンバージョンの一部であり、一定の確率で、実際のコンバージョンの一部が抑制されたり、偽のコンバージョンが追加されたりすることになります。
この新しい手法には以下のようなメリットがあります。
- クリックと視聴のプライバシー メカニズムが統合されます。
- トリガーデータ（コンバージョン データ）とトリガーソースのリンクのノイズを分離するメカニズムよりもわかりやすくなります。
- 次のようなプライバシー フレームワークを設定できます。ノイズを適切に設定することで、関係者が誰も、特定の広告でコンバージョンに至った（または至らなかった）ユーザー個人の識別に API を利用できないようにするフレームワークです。
この新しいメカニズムは、5% の確率でトリガーデータ（コンバージョン データ）がランダムな値に置き換えられていた以前のメカニズムに代わるものです。
さらに、ランダム化されるレスポンスの確率値がレポート本体に追加されました（randomized_trigger_rate フィールド）。このフィールドは、ソースがランダム化されるレスポンスの対象となる確率（0 ～ 1）を示します。
これには主に 2 つのメリットがあります。
- ブラウザの基本動作の透明性を、レポートを受け取る対象者（通常はアドテック）に対して保ちます。
- これは、API がすべてのブラウザでサポートされる将来にとって有用です。ブラウザごとに、プライバシーに関する目標に応じて、異なるレベルのノイズを適用できるようになり、レポートを取り扱う関係者にとって、こうした可視性が必要になるからです。
ノイズの仕組み
新しい提案では、ソースの登録時（広告クリックまたは広告視聴が記録されたとき）に、コンバージョンのアトリビューションを正しく行ってこの広告クリック/視聴に関するレポートを送信するかどうか、または偽の出力を代わりに生成するかどうかを、ブラウザがランダムに決定します。
偽の出力は次のようになります。
- レポートを一切出力しない - ユーザーのコンバージョンがあったかどうかにはよりません。
- 1 つまたは複数の偽のレポート - ユーザーのコンバージョンがあったかどうかにはよりません。
偽のレポートでは、トリガーデータ（コンバージョン データ）はランダム値です。クリックの場合は 3 ビットのランダム値（0 ～ 7 の任意の数値）、視聴の場合は 1 ビットのランダム値（0 または 1）です。
実際のレポートと同様に、偽のレポートもユーザーのコンバージョン直後には送信されません。ランダムなレポート期間の終わりに送信されます。
クリックの場合のレポート期間は、3 種類（クリック後 2 日間、7 日間、30 日間）あります。偽のレポートはそれぞれランダムに、レポート期間のいずれかに割り当てられます。
また、前回の提案ですでに説明したように、各期間内のレポートの順序はランダムです。
技術解説で詳細を見る
公開ディスカッションに参加する
レポートに関する制限事項（イベントレベルのレポートと集計レポート）
変更点とその理由
新しい提案では、2 つのサイト間でイベントを測定できる当事者の数が明示的に制限されます。
- {パブリッシャー、広告主} あたりのソース登録が可能な固有のレポート送信元（通常はアドテック）の上限数を 30 日間で 100 件に制限することが提案されています。この数は、広告のクリックや視聴（ソースイベント）ごとにカウントされ、関連付けが行われていない場合もカウントされます。
- {パブリッシャー、広告主} あたりのレポート送信が可能な固有のレポート送信元（通常はアドテック）の上限数を 30 日間で 10 件に制限することが提案されています。この数は、関連付けが行われたコンバージョンごとにカウントされます。
これらの上限数は、当事者によるコンバージョンの測定を妨げない程度に十分大きく、かつ API の一部の不正使用による影響を軽減できる程度に十分小さい値となっています。
レポートのクールダウン / レート制限
変更点とその理由
レポートのクールダウンは、1 人のユーザーについて、この API を介して一定期間に送信される情報の合計量を抑制するプライバシー メカニズムです。
新しい提案では、{ソースサイト、送信先、レポートの送信元}（通常は {パブリッシャー、広告主、アドテック}）あたり 30 日間にスケジュール作成できるレポートが 100 件に制限されます。
この制限に達すると、ブラウザは該当の {ソースサイト、送信先、レポートの送信元}（通常は {パブリッシャー、広告主、アドテック}）に一致するレポートのスケジュール作成を停止します。その後、該当の {ソースサイト、送信先、レポートの送信元} のレポート数が 100 件を下回ってから 30 日間が経過すると再度スケジュール作成できるようになります。
技術解説で詳細を見る
送信先の制限（イベントレベルのレポートのみ）
変更点とその理由
送信先の制限で、スコープにレポート送信元（通常はアドテック）を含めるよう修正: {パブリッシャー、アドテック} あたり 100 件の固有の保留中の送信先（通常は広告主のサイト、またはコンバージョンが発生すると想定されるサイト）が許可されます。
これは、閲覧履歴の再構成を制限するプライバシー保護です。
技術的な説明で詳細を確認する
すべてのリソース
- アトリビューション レポートをご覧ください。
- API について知っておくべきことをご覧ください。
ヘッダー画像は、Unsplash の Diana Polekhina によるものです。