はじめに
Protected Audience API
- Protected Audience APIとは
- Protected Audience APIの処理フロー
K匿名性
さいごに

はじめに

こんにちは。京都研究所・Tech Labの中野(@tosametal)です。
2024年7月からChromeで3rd Party Cookie¹の廃止が開始され、本格的にPostCookieの時代が到来します。
本記事ではChromeのPrivacy Sandbox²で提供されるProtected Audience APIの仕組みと、関連するK匿名性という性質について解説します。

Protected Audience API

Protected Audience APIとは

Protected Audience APIはPrivacy Sandboxにおけるリターゲティング³の代替案です。
これまでリターゲティングは3rd Party Cookieを用いて実施されていましたが、Protected Audience APIを用いることで3rd Party Cookieを利用せずにリターゲティング広告配信が可能になります。
ただしProtected Audience APIではブラウザ内に保存した情報を用いて処理を行うため、3rd Party Cookieを用いた方法と異なり、ユーザ行動をクロスサイトでトラッキングしません。

※ Protected Audience APIは以前までFLEDGEと呼ばれていたAPIが2023年5月に名称を変更したものです。

privacysandbox.com

マイクロアドでは2023年10月にProtected Audience APIを用いた配信機能をリリースしています。

www.microad.co.jp

また、以前FLEDGEに関するブログも書いているので興味ある方はご一読お願いします。

developers.microad.co.jp

Protected Audience APIの処理フロー

まずProtected Audience APIでリターゲティングを行う仕組みを簡単に説明します。
Protected Audience APIではInterestGroupを所有し入札するbuyer(DSPなど)と、seller(SSPなど)との間でオークションが実施されます。

(1)InterestGroupの登録

InterestGroupとは広告の入札とレンダリングの設定をするためのデータです。
InterestGroupの設定値には保有者(owner)、名前(name)、表示したい広告のURL(renderUrl)、入札処理に用いる入札スクリプトのURL(biddingLogicUrl)などがあります。
サイトにアクセスしたブラウザに対してInterestGroupを登録するにはbuyerの設置したタグでnavigator.joinAdInterestGroupを実行します。

const interestGroup = {
    owner: "https://buyer.microad.jp",
    name: "microad-interest-group",
    lifetimeMs: 30 * kMillisecsPerDay,
    biddingLogicUrl: "https://microad.jp/biddingLogic.js",
    ads: [
        { renderUrl: "https://ads.microad.jp/ad1.html" },
        { renderUrl: "https://ads.microad.jp/ad2.html" },
    ]
}
navigator.joinAdInterestGroup(interestGroup);

上記のサンプルコードでは最小の設定にしていますが、他にも多くの設定項目が存在します。

(2)OnDeviceAuctionの実行

ユーザがメディアなどに設置されたsellerのタグにアクセスした際、navigator.runAdAuctionでOnDeviceAuctionを実行します。
OnDeviceAuctionではブラウザに保存されたInterestGroup同士でオークションを行い、最終的に落札する広告を決定します。

const auctionConfig = {
    seller: "https://seller.microad.jp",
    decisionLogicURL: "https://seller.microad.jp/decisionLogic.js",
    interestGroupBuyers: ["https://buyer.microad.jp"], // OnDeviceAuctionに参加するbuyerを指定
    resolveToConfig: true
}
const result = await navigator.runAdAuction(auctionConfig);

上記のサンプルコードでは最小の設定にしていますが、こちらも他にも多くの設定項目が存在します。

runAdAuction実行時にはbuyerが定義したgenerateBidや、sellerが定義したscoreAdという関数が呼び出され、入札する広告の値段やスコアーを計算します。
最終的に最も高いスコアーがついた広告を落札します。

(3)FencedFrameで広告の表示

Protected Audience APIで落札された広告はFencedFrameという特殊なiframeのような環境で表示する必要があります。
FencedFrameとiframeの違いが参考になります。
ただし現時点でFencedFrameでの広告表示は必須でなく、iframeでも表示可能です。
機能提供のスケジュールによると2026年までに必須になるとのことです。

(4)Reportの送信

impressionやclickを計測するためにbuyerではreportWin、sellerではreportResultでregisterAdBeaconを実行することで計測用ビーコンを登録します。
広告が表示またはクリックされた際にFenced Frame内でレポート送信をトリガーすることでevent-levelのレポート送信を行えます。
https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md

function reportWin(auctionSignals, perBuyerSignals, sellerSignals, browserSignals, directFromSellerSignals) {
  registerAdBeacon({...})
}

function reportResult(auctionConfig, browserSignals, directFromSellerSignals) {
    registerAdBeacon({...})
}

他にもPrivate Aggregation APIを用いたレポートの送信などがありますが、本記事では説明は省略します。

K匿名性

K匿名性とは

データセット内でユーザーが個別に識別されることを防ぐプライバシーの概念です。
少なくともK人を区別できないときデータセットがK匿名性を持つといいます。

例えば以下のデータセットを見てみましょう。

ここで取得可能な列を居住地のみとした場合、東京が2名、大阪が3名となり個人の特定はできません。

このデータセットで居住地のみがわかる場合少なくとも2人を区別できず、K=2の匿名性を持ちます。

また性別と居住地を公開情報とした例を考えます。

この場合、例えば「男・大阪」という組み合わせは1人しかいないため、K=1となり匿名性が維持できません。

Protected Audience APIにおけるK匿名性

Protected Audience APIではユーザーをマイクロターゲティングから保護する目的でK匿名性の性質が利用されています。
InterestGroupのowner、biddingLogicUrl、renderUrlの組み合わせで登録されたブラウザ数がKの閾値を超えない場合は、広告が表示されないという制約があります。
(※ 2025年以降はadSizeも組み合わせの対象となりますが、以下の説明ではadSizeは省略します)
これによってある広告が表示されたユーザから特定のユーザを一意に識別するのを防ぐことができます。

もしK匿名性の制限がない場合

K匿名性が適用されない場合にどのようにマイクロターゲティングに繋がるのかを考えてみます。
例えばrenderUrlに登録する値を https://ads.microad.jp/ad1.html?id=AAAA 、AAAAはlocalStorageなどに保存されたIDとします。
この広告がOnDeviceAuctionで落札されImpressionが発生した際に送信されるReportでは「どのサイトで」「どの広告が表示されたか」という情報を取得可能です。
これによりAAAAというIDを持つユーザーがどの配信面にアクセスしたかという、クロスサイトでのアクセス情報を取得できてしまいます。
K匿名性の制限があるおかげでrenderUrlのパラメータにユーザを一意に特定可能になるような値を設定できず、特定のユーザーのクロスサイトトラッキングを防いでいます。

K匿名性サーバー

対象のowner、renderUrl、biddingLogicUrlの組み合わせがK匿名かを判断するために、サーバー側で処理された情報を利用することが必要です。
このサーバーはK匿名性サーバーと呼ばれます。
K匿名性サーバーはGoogle Chromeが提供するサービスとして運用予定とのことです。

For Chrome we're implementing k-anonymity with a server, and as the provider of Chrome we're planning to operate the k-anonymity server in a similar model to how other server-based Chrome features operate: as a service offered by Google Chrome.

https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#server-ownership より引用。

K匿名性サーバの2つのエンドポイント

K匿名性サーバでは2つのエンドポイントが提供されます。

Join

b(ブラウザ識別子)、t(ブラウザのローカルオブジェクトのタイプ)、s(ブラウザのローカルオブジェクトをハッシュ化した値)の3つの値を受け取ります。
※ ローカルオブジェクトはブラウザに保存された状態（例えばInterestGroup）を指します。

Joinはブラウザからサーバへの書き込みを行い、サーバーがセットに含まれるブラウザ数をカウントする目的で使用します。

Query

t(ブラウザのローカルオブジェクトのタイプ)、s(ブラウザのローカルオブジェクトをハッシュ化した値)の2つの値を受け取り、セットがK匿名性の閾値を超えている場合にtrueを返します。

AboveThresholdWithPeriodicRestartアルゴリズム

各セットのK匿名性ステータスの状態をサーバーで更新するアルゴリズムです。

ステータスを継続的でなく定期的に更新する
セットサイズとK匿名性の閾値の両方にノイズを加えた上で比較する
セットのステータスが変化する頻度を制限する

ことにより、個々のユーザーの行動を学習することを防ぎます。
このアルゴリズムではp, w, k, ε, δのパラメータを使用します。

パラメータ	説明
p	クエリ更新期間を表す
w	集合Sが閾値を超えている必要がある期間を表す
k	K匿名性の閾値を表す。集合Sは少なくともK以上のメンバーを含んでいる必要がある
ε, δ	差分プライバシーで標準的に用いられる。集合サイズの閾値に追加されるノイズの量を制御する際に使用される。

アルゴリズムの詳細を知りたい場合は以下のドキュメントを参考にしてください。

https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_differential_privacy.md
https://github.com/WICG/turtledove/blob/main/DP_kanon_server.pdf

Chromeにおける設定

2025年以降ではAboveThresholdWithPeriodicRestartアルゴリズムのパラメータはk=50、p=1、w=30となります。
また、K匿名性のチェック対象となる項目はowner、biddingLogicUrl、renderUrl、adSizeの組み合わせとなります。
これからパラメータやチェック対象項目がどのように変更されていくかは K匿名性が参考になります。