アドプライバシーQ&A

Protected Audience APIによるプライバシー保護リターゲティングの実装：技術仕様、課題、および考慮事項

Tags: Protected Audience API, リターゲティング, Privacy Sandbox, Web広告, プライバシー保護

ポストCookie時代におけるリターゲティングの技術的課題

従来のWeb広告において、リターゲティングはコンバージョン効率の高い手法として広く利用されてきました。しかし、サードパーティCookieの廃止を含むブラウザベンダーによるプライバシー保護強化の動きは、この手法の根幹を揺るがしています。クロスサイトでのユーザー識別が困難になる中で、いかにしてユーザーのプライバシーを尊重しつつ、関連性の高い広告を配信するかが喫緊の課題となっています。

このような背景のもと、Googleが提唱するPrivacy Sandboxプロジェクトの一部であるProtected Audience API（旧称Fledge）は、ブラウザ内で広告オークションを実行することで、ユーザーのプライバシーを保護しながらリターゲティングやカスタムオーディエンス広告を実現することを目指しています。本稿では、Protected Audience APIの技術仕様、実装上の課題、および関連する考慮事項について詳細に解説します。

Protected Audience APIの技術仕様

Protected Audience APIは、広告主（購入者）とパブリッシャー（販売者）が、ユーザーのブラウザ内で広告オークションを実行するためのメカニズムを提供します。このAPIの核となる要素は以下の通りです。

  1. インタレストグループ（Interest Groups）:

    • 広告主は、ユーザーが特定のサイトを訪問した際に、そのユーザーを特定のインタレストグループに追加するリクエストをブラウザに対して行います。
    • 例えば、靴のECサイトであれば、「スニーカー購入者」「ランニングシューズ興味者」といったグループにユーザーを追加します。
    • この情報はブラウザにローカルに保存され、サイト間で共有されることはありません。
    • インタレストグループは、名前（name）と所有者（owner, typically the advertiser's domain）を持ち、入札ロジックを記述したJavaScriptファイル（biddingLogicUrl）や、その入札に使用するデータ（userBiddingSignals, trustedBiddingSignalsUrl）への参照を含みます。

    javascript navigator.joinAdInterestGroup({ name: 'running-shoes-enthusiasts', owner: 'https://ads.example.com', // Advertiser's domain lifespanMs: 60 * 1000 * 60 * 24 * 30, // 30 days biddingLogicUrl: 'https://ads.example.com/bidding-logic.js', trustedBiddingSignalsUrl: 'https://ads.example.com/trusted-bidding-signals', trustedBiddingSignalsKeys: ['shoes'], userBiddingSignals: { type: 'running', category: 'trail' } }, 10000); // 10 seconds ko limit for join operation

  2. 広告オークション（Ad Auctions）:

    • パブリッシャーのサイトが読み込まれると、そのサイトはブラウザに対して広告オークションの実行をリクエストします。
    • オークションには、パブリッシャーのサイト情報、コンテキスト情報、およびその時点でブラウザに保存されているインタレストグループの情報が入力されます。
    • オークションは、入札（Bidding）とスコアリング（Scoring）の2つの主要なフェーズで構成されます。

  3. 入札（Bidding）:

    • ブラウザは、オークションに参加する各インタレストグループに対し、biddingLogicUrlで指定されたJavaScript関数（generateBid）を実行します。
    • この関数は、インタレストグループの情報、パブリッシャーのサイト情報、コンテキスト情報、およびTrusted Serverから取得したリアルタイムデータ（trustedBiddingSignals）などを基に、そのインタレストグループからの入札額を計算して返します。
    • generateBid関数はブラウザの隔離された環境で実行され、外部ネットワークへの自由なアクセスは制限されます。

  4. スコアリング（Scoring）:

    • オークションに参加する各販売者（SSPなど）は、自らのスコアリングロジックを記述したJavaScript関数（scoreAd）を提供します。
    • ブラウザは、各入札とそれに対応する広告クリエイティブに対し、このscoreAd関数を実行し、その入札がパブリッシャーにとってどれだけ魅力的か（例えば、入札額、広告の品質など）をスコアリングします。最もスコアが高い入札がオークションの勝者となります。
    • scoreAd関数もブラウザの隔離された環境で実行されます。

  5. Trusted Server:

    • 入札（generateBid）やスコアリング（scoreAd）のプロセスでは、広告のリアルタイム情報（在庫、予算、入札最低価格など）が必要になる場合があります。
    • これらのデータは、ブラウザのローカルストレージではなく、広告主や販売者が運用する「Trusted Server」から取得されます。
    • Trusted Serverは、単にキーに対応する値を返すシンプルなキー/バリューストアとして機能することが推奨されており、ユーザーのプライバシーを侵害するような複雑な処理やロギングは行わない設計が求められます。

  6. レポーティング（Reporting）:

    • オークションが終了した後、落札者（広告主）とパブリッシャーはオークション結果に関するレポートを受け取ることができます。
    • これはreportResult（広告主側）およびreportWin（パブリッシャー側）というJavaScript関数を通じて行われます。
    • これらの関数は、オークションの勝者や入札額などの集計された情報を送信するために使用されます。プライバシー保護のため、個々のユーザーレベルの特定は困難な設計となっています。

実装上の課題と考慮事項

Protected Audience APIは、従来のモデルとは大きく異なるアーキテクチャを採用しているため、実装および運用にはいくつかの課題が存在します。

  1. JavaScriptサンドボックス環境の制約:

    • generateBidおよびscoreAd関数はブラウザの隔離されたJavaScript環境（Worklet）で実行されます。この環境はデバッグが難しく、実行時間やメモリ使用量に制限があります。複雑な入札ロジックを実装する際には、これらの制約を考慮する必要があります。
    • 外部ライブラリの利用や、ローカルストレージ以外へのアクセスが制限されるため、ロジックの実装方法に工夫が必要です。

  2. Trusted Serverの運用:

    • 入札やスコアリングに必要なリアルタイムデータを効率的に提供するため、広告主および販売者は高可用性かつ低遅延なTrusted Serverを運用する必要があります。
    • Trusted Serverは設計思想としてプライバシー保護に徹する必要があり、不正なデータ利用を防ぐための設計、監査、運用体制が求められます。

  3. 遅延とパフォーマンス:

    • ブラウザ内でのオークション実行、Trusted Serverへのデータ取得、JavaScriptワークレットの起動などにより、従来のサーバーサイドオークションと比較して広告表示までの遅延が発生する可能性があります。
    • 特にモバイル環境や低速なネットワーク環境では、ユーザーエクスペリエンスに影響を与える可能性があり、パフォーマンス最適化が重要な課題となります。

  4. データ利用の制限:

    • Protected Audience APIは、インタレストグループ情報がブラウザ内に隔離されるため、広告主が直接的に個々のユーザーのインタレストグループ情報を取得したり、複数のインタレストグループを跨いだ詳細な分析を行ったりすることは困難です。
    • レポーティングも集計レベルの情報に限定されるため、詳細なターゲティング分析やクリエイティブ最適化のためのデータ収集方法を再検討する必要があります。Attribution Reporting APIとの連携により、一定のコンバージョン測定は可能ですが、そのデータもプライバシー保護の制約を受けます。

  5. クロスデバイス課題:

    • Protected Audience APIはブラウザベースの技術であり、異なるデバイスや異なるブラウザ間でのインタレストグループ情報の共有はサポートされていません。
    • ユーザーのオンライン行動が複数のデバイスに跨がる場合、従来のようなクロスデバイスでのリターゲティングは Protected Audience API 単体では実現が困難です。この課題に対しては、First-Party Dataの活用や、将来的にはPrivate State Tokensのような他のプライバシー保護技術との組み合わせが検討される可能性があります。

  6. 同意管理との連携:

    • 多くのデータプライバシー規制（GDPR, CCPA/CPRAなど）では、パーソナライズされた広告配信や特定の目的のためのデータ処理にユーザーの同意が必要です。
    • インタレストグループへのユーザー追加やProtected Audience APIを用いた広告配信がこれらの規制下の「データ処理」に該当するかどうかは、具体的な実装や法域によって解釈が異なりますが、一般的には同意管理プラットフォーム（CMP）と連携し、ユーザーの同意を得た上でAPIを呼び出す実装が求められます。

関連Privacy Sandbox APIとの連携

Protected Audience APIは、Privacy Sandboxエコシステム内で他のAPIと連携することで、より包括的な広告体験と測定を可能にします。

まとめと将来展望

Protected Audience APIは、サードパーティCookieに依存しないプライバシー保護リターゲティングを実現するための有力な技術的アプローチです。ブラウザ内での広告オークション実行、インタレストグループのローカル保存、およびTrusted Serverの活用により、ユーザーのブラウジング履歴がサイト間で共有されることなく、関連性の高い広告配信が可能になります。

しかし、JavaScriptサンドボックスの制約、Trusted Serverの運用負荷、遅延、データ利用の制限、クロスデバイス対応、および同意管理との連携など、実装および運用には多くの技術的課題が存在します。これらの課題に対しては、API仕様の継続的なアップデート、ブラウザベンダーによるツール提供、そして広告業界全体での知見の共有が不可欠となります。

技術専門家やプライバシーコンサルタントとしては、Protected Audience APIの技術仕様を深く理解し、これらの課題を踏まえた上で、クライアントの具体的なビジネス要件や法的要求に適合する最適な実装戦略を提案・支援していくことが求められます。Privacy Sandbox技術は現在も進化の途上にあり、その動向を注視し続けることが重要です。