アドプライバシーQ&A - Privacy Sandbox環境におけるフリークエンシーキャップの実装技術：Shared Storage APIとProtected Audience APIの連携

Privacy Sandbox環境におけるフリークエンシーキャップの実装技術：Shared Storage APIとProtected Audience APIの連携

Tags: Privacy Sandbox, Protected Audience API, Shared Storage API, Frequency Capping, Web広告技術

Privacy Sandbox環境下でフリークエンシーキャップを実装するには、どのような技術的アプローチが可能ですか？

サードパーティCookieの廃止が進む中で、ウェブサイトを横断したユーザーの識別に基づいた広告制御が困難になっています。特に、特定のユーザーに対して広告が表示される頻度を制限するフリークエンシーキャップは、ユーザー体験の向上や広告費の効率化のために重要な機能ですが、従来のCookieベースの実装が成り立たなくなります。Privacy Sandbox環境において、ユーザーのプライバシーを保護しつつフリークエンシーキャップを実現するための技術的アプローチとして、Shared Storage APIとProtected Audience APIの連携が主要な手段となります。

Shared Storage APIの概要とフリークエンシーキャップへの適用可能性

Shared Storage APIは、クロスサイトで書き込み可能ですが、そのデータへのアクセスはプライバシーを保護する限定的なAPI群（ワークレット内実行）を通じてのみ許可されるストレージメカニズムです。これにより、サイトを横断して特定の情報を共有しつつ、その情報がユーザー追跡に直接悪用されることを防ぎます。

フリークエンシーキャップの実装において、Shared Storageは以下の目的で利用できます。

インプレッションカウントの保存: サイトAで広告が表示された回数などのインプレッション情報を、Shared Storageに格納します。この情報は他のサイトBからも特定のAPIを通じてアクセス可能です。
フリークエンシーキャップ基準の保存: 特定の広告キャンペーンに対するフリークエンシーキャップの上限値などを格納することも考えられますが、これは広告選択ロジックとの連携が重要になります。

Shared Storage APIの重要な特性は、データへの直接的な読み出しが制限されている点です。格納されたデータは、プライバシーを守るための「ワークレット」と呼ばれる安全な実行環境内で処理する必要があります。フリークエンシーキャップのコンテキストでは、このワークレット内でインプレッションカウントを更新したり、特定の基準と比較したりする処理が実行されます。

Protected Audience APIとShared Storage APIの連携によるフリークエンシーキャップ

Protected Audience APIは、ブラウザ内で広告オークションを実行し、ユーザーのブラウジング履歴に基づくリターゲティング広告などをプライバシーを保護しつつ配信するためのAPIです。広告オークションのプロセスにおいて、買い手（DSPなど）はgenerateBid関数をブラウザワークレット内で実行し、売り手（SSPなど）はscoreAd関数を実行します。

この広告オークションのワークレット実行中に、Shared Storage APIへアクセスすることが可能です。この連携がフリークエンシーキャップ実装の核となります。具体的な流れは以下のようになります。

インプレッション発生時のShared Storageへの書き込み: 広告が表示された際（または、表示される直前や表示が確認された後）、発行元サイトのスクリプトからShared Storage APIを利用して、特定の広告IDやキャンペーンIDに関連付けられたインプレッションカウントを更新します。これはsharedStorage.runメソッドを通じてワークレットを実行し、そのワークレット内でsharedStorage.setやsharedStorage.get、sharedStorage.updateのような操作を行うことで実現します。例えば、特定のキー（例: fc_campaign_123）に対して、インプレッション数をインクリメントする処理をワークレットで実行します。
Protected Audienceオークション時のShared Storageからの読み出し: 次に広告オークションが実行される際、買い手のgenerateBid関数または売り手のscoreAd関数が実行されるブラウザワークレット内で、Shared Storage APIを通じて先ほど保存したインプレッションカウントを読み出します。sharedStorage.runメソッドを呼び出し、読み出しと判定ロジックを含むワークレットを実行します。
フリークエンシーキャップ判定と入札調整/表示制御: 読み出したインプレッションカウントが、設定されたフリークエンシーキャップの上限値を超えているか否かをワークレット内で判定します。
- 買い手のgenerateBidワークレット内で判定する場合、上限を超えていれば入札額をゼロにするか、非常に低い値に設定します。
- 売り手のscoreAdワークレット内で判定する場合、上限を超えていれば広告のスコアを非常に低く設定し、その広告が選択されないようにします。

この一連のプロセスを通じて、ブラウザ内でプライベートにインプレッションカウントを管理し、その情報に基づいて広告の表示を制御することが可能になります。Shared Storage APIの特性により、他のサイトや第三者が生のインプレッションカウントを直接読み出すことはできないため、ユーザーのプライバシーが保護されます。

技術的な課題と考慮事項

Privacy Sandbox APIを用いたフリークエンシーキャップ実装には、いくつかの技術的な課題が存在します。

Shared Storageの容量とパフォーマンス: Shared Storageに保存できるデータの量や、ワークレットの実行にはブラウザリソースの制約があります。多数のキャンペーンや広告に対して詳細なフリークエンシー情報を保存しようとすると、容量や読み書きのパフォーマンスがボトルネックになる可能性があります。
データの鮮度: Shared Storageへの書き込みからProtected Audienceオークションでの読み出しまでにタイムラグが生じる可能性があります。リアルタイムに近い厳密なフリークエンシーキャップが必要なシナリオでは、この遅延を考慮する必要があります。
集計レポートの利用: Shared Storageに保存した情報を集計レポートとして取得するには、Private Aggregation APIと連携させる必要があります。これにより、キャンペーン全体の集計されたインプレッション数などを把握できますが、個別のユーザーのフリークエンシー違反状況を直接確認することはできません。これはプライバシー保護の設計によるものですが、デバッグや効果測定の際に考慮が必要です。
オークション外での表示制御: Protected Audienceオークションを介さない広告表示（例: コンテクスチュアル広告やシンプルバナー）に対するフリークエンシーキャップは、Shared Storage API単独では困難です。表示制御のロジックをブラウザ側で実行する必要があり、Shared Storageと連携させる追加の実装が必要になるか、あるいは別の技術的アプローチ（例: ファーストパーティデータと組み合わせた集計レベルでの制御）を検討する必要があります。
モバイルアプリ環境: 上記の技術はWebブラウザを対象としています。モバイルアプリ環境でのフリークエンシーキャップには、Android Privacy Sandbox for AdsやSKAdNetworkのような、それぞれのプラットフォームが提供するプライバシー保護APIを利用する必要があります。

まとめ

Privacy Sandbox環境におけるフリークエンシーキャップの実装は、Shared Storage APIとProtected Audience APIの連携を中心に実現されます。Shared Storageにインプレッションカウントをプライベートに保存し、Protected Audienceオークションのワークレット内でその情報を参照して入札や表示を制御するアプローチが技術的に可能です。しかし、ストレージ容量、データ鮮度、集計レポートへの依存、Protected Audienceオークション外での制御など、解決すべき技術的な課題も存在します。これらの課題を理解し、Privacy Sandboxの技術仕様を深く踏まえた設計と実装が求められます。

今後もPrivacy SandboxのAPI仕様は進化する可能性があります。最新の仕様動向を注視し、利用可能なAPIを適切に組み合わせることで、ポストCookie時代における効果的かつプライバシーに配慮したフリークエンシーキャップを実現することが重要です。