プライバシー技術ナビ

Private Click Measurement (PCM) と Attribution Reporting API の比較：プライバシー保護型アトリビューション計測技術の技術解説とフロントエンドでの実装

Tags: Attribution Reporting API, Private Click Measurement, プライバシー技術, フロントエンド, ウェブトラッキング

はじめに：プライバシー保護時代の効果測定の課題

ウェブのプライバシー保護が強化される中、従来のサードパーティCookieに依存したユーザー行動追跡や広告アトリビューション計測は、主要ブラウザによる制限や規制の導入により困難になっています。特に、Web開発に携わるフロントエンドエンジニアの皆様にとって、マーケティング効果の測定やユーザー体験の最適化に不可欠なアトリビューションデータを、いかにプライバシーに配慮しつつ取得・活用していくかは、喫緊の課題となっています。

本記事では、この課題に対応するために主要ブラウザが提案・実装している二つの重要な技術、「Private Click Measurement (PCM)」と「Attribution Reporting API」に焦点を当てます。それぞれの技術的仕組み、フロントエンド開発への具体的な影響、実装方法、そしてブラウザごとの挙動の違いを深く掘り下げて解説します。

Private Click Measurement (PCM) の技術的仕組み

Private Click Measurement (PCM) は、AppleがSafariブラウザのIntelligent Tracking Prevention (ITP) の一環として導入した、プライバシー保護型のアトリビューション計測技術です。クロスサイトトラッキングを防止しつつ、クリックによるコンバージョンの計測を可能にすることを目的としています。

主要な技術的特徴

  1. クライアントサイドでの匿名化と集計: PCMでは、クリックとコンバージョンに関するデータはブラウザの内部で処理され、IPアドレスなどの識別情報が直接計測サーバーに送信されることはありません。データは集計され、匿名化された状態で一定期間後にレポートとして送信されます。

  2. ソース登録とトリガー登録:

    • ソースイベント (クリック): 広告クリックなどのイベントを指します。<a>タグにattributionsrc属性を追加することで、ブラウザにソースイベントとして登録するよう指示します。この属性にはレポートエンドポイントのURLを指定します。
    • トリガーイベント (コンバージョン): 商品購入やサインアップなどのコンバージョンイベントを指します。こちらも特定のAPIコールやリクエストによってブラウザに登録されます。

  3. データ粒度の制限: レポートされるデータは、特定の粒度（例えば、広告キャンペーンIDとコンバージョンタイプなど）に制限され、個人を特定できるほどの詳細な情報は含まれません。AppleはSource IDを8ビット（256通りの値）、Trigger Dataを4ビット（16通りの値）に制限しています。

  4. レポート送信の遅延とランダム化: ブラウザは、レポートを即座に送信せず、意図的に遅延させ、さらにランダムな時間枠で送信します。これにより、レポート送信タイミングからのユーザー再識別を防ぎます。

  5. HTTPヘッダーによる情報伝達: クリック時にリダイレクトを通じて、Attribution-Reporting-EligibleやAttribution-Reporting-Source-Infoといった特定のHTTPヘッダーを使用して、トラッキングベンダーが計測に必要な情報をブラウザに渡す仕組みが提供されます。

PCMの実装におけるフロントエンドの役割

PCMでは、主にHTMLの<a>タグのattributionsrc属性が重要な役割を果たします。

<a href="https://example.com/product/xyz" attributionsrc="https://measurement.example/report">
  魅力的な商品はこちら
</a>

上記の例では、ユーザーがリンクをクリックすると、ブラウザはattributionsrcで指定されたURL (https://measurement.example/report) に対してAttribution Sourceの登録リクエストを送信します。この際、ブラウザはAttribution-Reporting-Eligibleヘッダーなどを付加します。

コンバージョン発生時も、JavaScriptを用いて特定の画像をリクエストする、または特定のURLにリダイレクトすることでトリガーイベントをブラウザに登録します。

Attribution Reporting API の技術的仕組み

Attribution Reporting API は、GoogleがPrivacy Sandboxの一部としてChromeブラウザに提案・実装を進めているプライバシー保護型アトリビューション計測技術です。PCMと同様にクロスサイト識別子に依存せず、クリックやビューによるコンバージョンを計測することを目的としています。PCMよりも柔軟なレポート機能を提供することを目指しています。

主要な技術的特徴

  1. ソースイベントとトリガーイベント:

    • ソースイベント (広告クリック/ビュー):
      • <a>タグのattributionsrc属性: PCMと同様に、HTMLタグに属性を追加してソースを登録します。
      • <img>タグや<iframe>タグ: attributionsrc属性を付与することで、画像表示やiframe読み込みもソースイベントとして扱えます。
      • JavaScript API: window.attributionReporting.createSource()などのAPIを通じて、動的にソースイベントを登録することも可能です。 これらにより、広告の表示（ビューアトリビューション）も計測対象に含めることができます。
    • トリガーイベント (コンバージョン):
      • HTTPリクエスト: Attribution-Reporting-Register-Trigger ヘッダーをレスポンスに含めることで、コンバージョンをブラウザに登録します。

  2. レポートタイプ: Attribution Reporting APIは、主に二種類のレポートを提供します。

    • イベントレベルレポート (Event-Level Reports): 特定のソースイベント（クリックまたはビュー）と、その後のトリガーイベント（コンバージョン）のシンプルな紐付けを提供します。プライバシー保護のため、データにはノイズが加えられ、レポートの送信も遅延・ランダム化されます。また、トリガーデータも制限されたビット数で表現されます。
    • 集計レポート (Aggregatable Reports): プライバシー保護技術である「差分プライバシー (Differential Privacy)」の概念を用いて、個々のユーザーの行動を特定することなく、特定の集団に関する集計データを提供します。クライアントサイドでデータを暗号化し、集計サービスに送信して復号・集計することで、プライバシーを保護しつつより詳細なコンバージョンデータを取得できます。FLEDGE (Protected Audience API) や Shared Storage と連携することで、より高度な計測が可能です。

  3. アトリビューションロジック: 複数のソースイベントがあった場合、どのイベントをコンバージョンに紐付けるか（アトリビューションロジック）を、ブラウザ側で制御する仕組みが導入されています。例えば、ラストクリックアトリビューションがデフォルトです。

Attribution Reporting APIの実装におけるフロントエンドの役割

Attribution Reporting APIでは、HTML属性とJavaScript APIを組み合わせて利用します。

1. ソースイベントの登録（HTML属性）:

クリックイベントの場合：

<a href="https://example.com/product/xyz" attributionsrc="https://adtech.example/attribution-source?campaign_id=123&creative_id=456">
  魅力的な商品はこちら
</a>

ビューイベントの場合：

<img src="https://adtech.example/ad-impression.png" attributionsrc="https://adtech.example/attribution-source?campaign_id=123&creative_id=456">

attributionsrc属性の値は、ブラウザがソース情報を登録するために呼び出すエンドポイントURLです。このエンドポイントからのレスポンスには、Attribution-Reporting-Register-Sourceヘッダーが含まれる必要があります。

2. ソースイベントの登録（JavaScript API）:

// 例えば、動的に生成された広告要素や、特定のユーザーアクションに基づいてソースを登録する場合
async function registerAttributionSource(sourceUrl) {
  if (window.attributionReporting) {
    try {
      await window.attributionReporting.registerSource({
        url: sourceUrl,
      });
      console.log('Attribution source registered successfully.');
    } catch (error) {
      console.error('Failed to register attribution source:', error);
    }
  } else {
    console.warn('Attribution Reporting API not available.');
  }
}

// 例: 広告が表示されたタイミングでソースを登録
registerAttributionSource('https://adtech.example/attribution-source?campaign_id=789&creative_id=012');

3. トリガーイベントの登録（サーバーからのレスポンスヘッダー）:

コンバージョンページへの遷移後、ブラウザがサーバーにリクエストを送信し、そのレスポンスにAttribution-Reporting-Register-Triggerヘッダーを含めることでトリガーが登録されます。フロントエンドから直接APIを叩くわけではありませんが、このトリガーリクエストを発生させるページ遷移やJavaScriptの非同期リクエストの設計はフロントエンドの責任範囲となります。

例（サーバーレスポンスヘッダー）： Attribution-Reporting-Register-Trigger: {"event_trigger_data":[{"trigger_data":1,"priority":100}], "aggregatable_trigger_data":[{"key_piece":"0x1","source_keys":["campaignId"]}], "aggregatable_values":{"campaignId":100}}

実務への影響とフロントエンドでの対応策

これらの新しいプライバシー保護型アトリビューション技術は、従来のトラッキング手法が通用しなくなる中で、フロントエンドエンジニアに新たな設計と実装の課題をもたらします。

  1. 既存のアトリビューションロジックの見直し: サードパーティCookieやlocalStorageに依存していた計測ロジックは、そのままでは機能しなくなります。PCMやAttribution Reporting APIの仕様に合わせて、ソースイベントとトリガーイベントの登録フローを再構築する必要があります。

  2. HTMLとJavaScriptによる実装の変更: 広告リンクやコンバージョン要素にattributionsrc属性を追加したり、JavaScript API (window.attributionReporting) を利用して動的にソースを登録したりする実装が必要になります。特にシングルページアプリケーション (SPA) においては、クライアントサイドでのルーティング変更時に適切なタイミングでソース登録・トリガー登録を行う設計が重要です。

  3. サーバーサイドとの連携強化: Attribution Reporting APIのソース登録レスポンスやトリガー登録レスポンスには、特定のHTTPヘッダーを含める必要があります。フロントエンドとサーバーサイドの間で、計測に必要な情報の受け渡しとヘッダー設定に関する密な連携が求められます。集計レポートの場合、クライアントで暗号化されたデータを集計サーバーに送信するフローも考慮する必要があります。

  4. プライバシー保護の意識向上: 計測するデータの粒度や種類を最小限に抑え、差分プライバシーの原則を理解して適用することが重要です。ユーザーのプライバシーを侵害しない範囲で、最大限のビジネスインサイトを得られるよう、データ設計を慎重に行う必要があります。

  5. テストとデバッグの複雑化: レポート送信の遅延やランダム化、データ粒度の制限などにより、実装した計測が正しく動作しているかの検証は従来のツールだけでは難しくなります。Chrome DevToolsのApplicationタブの「Attribution Reporting」セクションなど、ブラウザ提供のデバッグツールを積極的に活用することが求められます。

主要ブラウザごとの挙動の違い

PCMとAttribution Reporting APIは、それぞれ異なるブラウザベンダーによって提案・実装されているため、その挙動には明確な違いがあります。

これらの違いを理解し、対象とするユーザー層が利用するブラウザに合わせて最適な実装戦略を立てることが重要です。

将来展望：標準化と進化

Private Click MeasurementとAttribution Reporting APIは、現在W3CのPrivacy Community GroupやWeb Platform Incubator Community Group (WICG) などで、プライバシー保護型アトリビューション計測技術の標準化に向けた活発な議論が交わされています。

フロントエンドエンジニアは、これらの動向を注視し、将来のウェブ開発に備える必要があります。

まとめ

プライバシー保護の重要性が高まる現代において、Private Click Measurement (PCM) と Attribution Reporting API は、サードパーティCookieに依存しないアトリビューション計測の実現に向けた重要な一歩となります。

本記事では、PCMとAttribution Reporting APIのそれぞれの技術的仕組み、具体的なHTML属性やJavaScript APIを利用した実装方法、そしてSafariとChromeにおける挙動の違いを詳細に解説しました。これらの知識は、フロントエンドエンジニアの皆様が、プライバシーに配慮した効果的なウェブサービスや広告体験を構築するために不可欠です。

ブラウザ間の仕様の違いや、レポートの遅延・粒度制限といった特性を理解し、実務における計測ロジックの再設計、サーバーサイドとの密な連携、そして適切なデバッグ手法の適用が成功の鍵となります。今後も進化を続けるこれらの技術と標準化の動向に注目し、変化に対応できるスキルを身につけていくことが、現代のフロントエンドエンジニアには求められます。