3rd-party cookieの引退とブラウザのアドテック進出
クッキーに代わる技術まとめシリーズ第1回「3rd-party cookieのない2年後のアドテックに向けた動きまとめ」からすでに３年経っていますが、3rd-party cookie廃止まではあと１年です。
廃止に向けてPrivacy Sandboxの名前で知られている代替技術は一般公開が進められています。Chromeを利用されている皆様はすでにユーザへの広告機能有効化の告知をご覧になり、「理解した」ボタンを押されたかと思いますが、ここで有効化したものを含めて、主要ブラウザの各種代替APIについて説明したいと思います。
ちなみにEUでは「理解した」と「設定」ではなく、「Turn it on」と「No Thanks」の選択になっています（しかもボタンの色が同じ）。
それでは2021年のシリーズ第2回の投稿から約2年ぶりとなる今回は、前回ご紹介した各技術の変化を中心にまとめたいと思います。
機能一覧
代替技術はChromeのPrivacy Sandboxだけではありません。SafariとFirefoxはすでに3rd-party cookieを廃止していて、ユースケースを計測とフラウド対策に絞って対応を進めています。Chromeは3rd-party cookieのほとんどのユースケースを代替技術で対応し、代替技術が軌道に乗ってから廃止する計画です。
２年前、3rd-party cookieに代わるブラウザの機能（API）をこのようにまとめていました。
それが2023年9月現在ではこのように増えています。行（ユースケース・技術）もカラム（提案者・ブラウザ）も増えています。
たとえば計測に関して今までの経緯をまとめると、
2019年5月に、クリックとコンバージョンの紐付けをブラウザ側で行う新しい機能をWebKitとChromeから相次いで提案（PCMとARAPI）
SafariとFirefoxはARAPIのClick IDが長すぎてトラッキングに使えると指摘。逆にFirefoxとChromeはPCMのClick IDが短すぎて配信最適化や効果測定に使いにくいと指摘。ARAPIの集計モードについてあまり議論されず。
2021年にSafariがPCMをリリース
2022年FirefoxとMetaは、ブラウザ側でユーザIDを記録して、IDを隠しながらサーバ側で秘密計算（MPC）を使って紐付けと集計を行う計測API（IPA）の共同開発を発表。
2023年8月にChromeがARAPIをリリース
2023年9月にSafariはブラウザ側の紐付けとMPCの仕組みを使って広告インプレッション計測に対応したPrivate Ad Measurement機能を提案。
Chrome/Privacy Sandboxの中でも、複数の計測APIが混在しています（Shared Storage、Private Aggregation、ARAPI）。
計測以外（配信最適化）はChromeだけが対応を進めているので、状況はもっとシンプルです。
Googleがアドテック企業である以上、代替手法を用意せずに勝手に3rd-party cookieを廃止するわけにはいかず、各国の競争規制当局にも監視されています。
コンバージョン計測
まずは、すべてのブラウザベンダーが必要性を認めている広告効果計測機能の状況です。
ChromeのAttribution Reporting API
2021年4月に名前がConversion Measurement APIからAttribution Reporting API（ARAPI）に変わり、その後１年かけて仕様も大きく変わりました。
ARAPIは２種類のレポーティング機能がありますが、どちらもsourceイベント（クリックまたはインプレッション）とtrigger（コンバージョン、CV）の紐付けを行います。紐付け処理の基本的な流れは、
広告が表示またはクリックされた時に、そのイベントを識別するためのsource ID（64ビット）をブラウザ側で記録し、
30日以内に広告主（広告の遷移先）のドメインでCV（trigger）が発生したら、
source IDとtriggerデータ（0~7までの値）のペアをレポートとして、広告のレポート送信先に（ブラウザから）送る。
となっていましたが、以下の変更が加わりました。
source ID等、APIに必要な計測パラメータは広告のHTMLタグ（<a>または<img>）ではなく計測サーバにリクエスト送って、サーバから設定情報を受信。
HTMLタグにはsource IDの代わりに、計測（サーバ）URLを記述（クエリパラメータ等は自由、source ID入れても良い、1st-party cookieもOK）。計測URLと広告画像が同じであれば省略可能。
計測サーバからsource IDを載せた特定のレスポンスヘッダを付与するとブラウザがsourceを登録。
その結果、元々広告タグに計測パラメータを追加する必要がありましたが、
<a href="https://shoes.example/..."
attributiondestination="advertiser.example"
attributionsourceeventid=123456789
attributionexpiry=...
attributionreportto="ad-network.example">
靴を買ってください
</a>今はattributionsrcという属性だけ書いて、サーバ側で計測パラメータを生成してブラウザに返します。
<a href="https://shoes.example/..." attributionsrc="https://ad-network.example/register-source?ad_id=123456789">
靴を買ってください
</a>aタグではなくimgタグ、scriptタグにattributionsrc属性を追加すると計測対象のインプレッションとして認識されます。attributionsrcの値を省略すれば、広告の配信元URLや遷移先URLが計測URLとしても使われます。JavaScriptでsourceを登録するAPIも用意されています。
trigger（CV）は元からサーバ経由で登録する仕組みになっていたので、sourceもtriggerも計測サーバにリクエストが飛んで、しかもサーバ側でsource IDが生成されるというところが従来の3rd-party cookieと近い仕様になりました。cookieとの違いは、
source IDの長さが制限されています（といっても人類が追跡可能な64ビットなので広告媒体はユーザを特定できます）
trigger IDも制限されます（３ビットなので広告主はユーザの特定ができません）
sourceとtriggerの紐付けはブラウザ側で行います
source/triggerと関係ないサイトでのユーザ追跡はできません
最後に、冒頭に書いたARAPIの２種類のレポーティング機能の特徴とユースケースをまとめます。
Event-level Reports：一つのsourceとtriggerで構成されるレポート。sourceごとの評価ができるので広告配信の自動最適化に使えます。その代わりにレポートに載せるtrigger情報（商品情報、購入金額）の量が厳しく制限。アドテックベンダーはブラウザから直接受け取ったレポートを復号化や集計しなくてもそのまま使えます。
Summary Reports：ブラウザからのレポートにtrigger詳細情報を載せられる代わりに、１ブラウザから受け取ったレポートはそのまま使えず、複数レポートをまとめて集計サービスに送信して集計してもらう必要があります。ブラウザからのレポートにランダムなノイズが加えられているので１レポートだけは使い物にならず、集計が不可欠です。また、source単位で集計されるので、source情報もキャンペーン、地域などの粗い粒度にしなければ、ノイズの影響で集計結果も使い物になりません。
iOS/SafariのPrivate Click Measurement
SafariのPCMはARAPIと同様に、ブラウザがsourceとtriggerを検知して、ブラウザ側で紐づいて、sourceとtriggerのペアをアトリビューションレポートとして配信面や広告主サーバーに送る仕組みです。sourceとしてはクリックだけ対応しています（広告表示は不可）。
PCMはiOSのApp Tracking Transparency（ATT）に対応しているため同意不要だと明記されています。
「Its privacy-preserving nature means it can be used without getting the user’s permission to track according to AppTrackingTransparency」
Private Browsingでも、セッション内のsource-trigger紐付けであれば利用できます。
PCMの最近（２年以内…）の仕様変更をまとめると、
配信面に加えてレポートはtriggerが発生したサイト（=クリックの遷移先、広告主）にも送信
3rd-party配信広告（クロスサイトiframe内広告）の計測に対応。
ただしレポートは変わらずAd Networkではなく配信面と広告主に送信。偽造レポート対応
ブラウザがクリック（に紐づいたトークン）の署名を配信面に依頼し、その後レポートに署名が確認できるトークンを載せます。配信面はクリックのトークンとレポートのトークンの紐付けができないが、レポートの署名を確認できる仕組み（"Blind Signature"）アトリビューションレポートはIPアドレスが隠蔽される（iCloud Private Relayを利用）。IPアドレスでクリックとCVを関連付けできないように。
アプリ内広告クリックとアプリ内ブラウザ（SFSafariViewController）のコンバージョン計測に対応。残念ながらFacebook/Instagramのアプリ内ブラウザはSFSafariViewControllerではなくいまだにWKWebViewを使っています。
source IDの長さ（64ビット=1844京6744兆クリック、vs. 8ビット=255キャンペーン）を決定的な違いとして認めながら、一時、PCMとARAPIの仕様をできるだけ合わせる動きがありました。しかし去年のARAPIのsource登録の仕様変更の時に仕様が再び乖離。
ちなみにARAPIが64ビットを必要としているのは、配信最適化の機械学習のためです。Safariは機械による配信最適化ではなく計測のためのAPI。
Chromeの汎用的なクロスサイト計測API
Chromeはクロスサイトのsourceとtriggerの紐付けではなく、クロスサイトで同一イベントを計測するための機能も実装されています。例えば複数のサイトで同じ3rd-party埋め込みコンテンツの閲覧状況を計測するために使えます。この機能は二つのAPIで構成されています。
Shared Storage API
入力・書き込みが自由で、出力・読み込みが制限されているクロスサイトストレージです（3rd-party cookieは入力も出力も無制限なのに対して）。出力はStorageの中身を元にしたURL出し分け（A/Bテストやフリークエンシーキャップ用）、または複数のブラウザのStorageの中身を集計したもの、の２種類。集計するためにARAPIのSummary Reportsと同じ技術を使ったPrivate Aggregation APIを使います。Private Aggregation API
Shared Storage APIで記録した情報を集計してレポートとしてアドテックベンダーに送る機能。Protected Audience API（リタゲティング）の配信結果の集計にも使えます。
つまりユーザのクロスサイトな動きに合わせた表示の切り替えはShared Storage API単体でよくて、レポーティングが必要なときはPrivate Aggregation APIと組み合わせて使う必要があります。広告効果測定はこちらのAPIではなくARAPIを使う想定です。頑張ればShared Storage APIでもコンバージョン測定できるかもしれませんが。
Mozilla/MetaのInteroperable Private Attribution
IPAはARAPI（特にEvent-level Reports）のプライバシー課題と、PCMの実用的課題を解決するためにMozillaとMetaが共同提案を進めている計測API。実装はまだです。将来的にクロスデバイス計測もできるように設計されていることも特徴です。
他のAPIと違ってアトリビューション（sourceとtriggerの紐付け）はブラウザではなくサーバ側で行われます。サーバで紐付けできるように、source/triggerの際にユーザIDを付与します。アドテックサーバはユーザIDをwriteできますが、readできません。そして、暗号化したユーザIDが付与されたsourceとtriggerイベントは複数の集計サーバに送信され、秘密計算（MPC）を使ってイベントの紐付けと集計を行います。一つの集計サーバはユーザIDを復元できない仕組みになっています。
書き込むユーザIDはプラットフォーマー等のユーザIDを使えるので、将来的にクロスデバイス計測への対応が可能になります。
SafariのPrivate Advertising Measurement
最後に、１ヶ月前にApple WebKit陣営から新たに提案が公開されたPAMの紹介です。ブラウザ側でアトリビューションを行い、サーバ側で集計する、という点はARAPIのSummary Reportsと共通ですが、何が違うかというと、おそらくですが、
広告主（or アドテック）はコンバージョンの時に、どの広告(ID)のインプレッションがアトリビューション対象かを指定します（上の図の真ん中の表）。
コンバジョン時にアトリビューションモデル（対象インプレッションの貢献度付け）も指定できます。first click (view?), last click, all equal等
こちらの提案ではなぜかsource/triggerではなくアドテック寄りのimpression/conversionをそのまま使います。
そこまで広告効果測定のためにWebKitがエネルギーを使ってくれているのも意外ですね。
ターゲティング技術
次にターゲティングや配信するためのブラウザ機能の話です。
リターゲティングできる「Protected Audience」 API
まずはブラウザ側でユーザを追いかける（リターゲティングする）機能と入札・配信機能がセットになっているPAAPI。３年前はTURTLEDOVEというコンセプトから生まれた最初の実装案FLEDGEから、最近「Protected Audience」に名前変更したAPIです。
広告主サイトにアクセスしたユーザをInterest Groupに入れて、ユーザがニュースサイト等の配信面を訪れた時に、Interest Groupに合わせた広告を配信します。ユーザが複数のInterest Groupに入っている場合、ブラウザ側で入札して競います。落札した広告はさらに、PAAPIの外で決められた文脈広告と決勝戦、という流れもOK。名前以外は仕組みが前回から大きく変わっていませんので、詳細は前回の記事まで！ではなく、最新の公式ドキュメント↑まで！
ユーザの趣味趣向に広告を合わせる「Topics」API
FLoC案への指摘・批判を受けて新たに登場した、ユーザのブラウジング履歴を元に趣味趣向を算出し、広告配信面に提示するためのAPIです（FLoC案は没になりました）。
例えばユーザが車と料理と旅行の情報サイトをよく訪れたら、履歴のURLから車・料理・旅行好きとしてブラウザに認識され、初めて訪れたサイトでもTopics APIをコールすれば、ユーザが車・料理・旅行に興味があることがわかります。デフォルトでは一つのAPIコール「document.browsingTopics()」をすればトピックの観察と取得が同時に行われます。
重要な制限としては、観察したことがあるトピックだけ取得できます。そのため、たくさんのサイトでiframeとして埋め込まれたアドテックが有利になります。
ちなみにFLoCではトピックのリストそのままではなく、トピックのリストをもとに生成した番号（コホートID）が付与されて、コホートの意味を各サイトが他の1st-partyデータなどと組み合わせて推測する必要がありました。
ボット判定結果を伝搬する「Private State Tokens」API
Safari PCMのレポート偽造（実際に発生していないクリックとコンバージョンのレポート）対策について少し触れましたが、こちらはクリック（または広告表示）自体が不正（ボットのアクセス）かどうかを判定するためのAPIになっています。
具体的には、ログインやreCAPTCHAなどの結果、サイトAがボットではないと判定されたユーザに対してトークンを発行し、サイトBがトークンをチェックすることで本当のユーザであることを確認できます。トークンを使ってユーザを追跡できないようにPCMと同じBlind Signatureの技術みを使っています。
広告目的以外のAPI
広告配信と計測以外のユースケースのためにも、3rd-party cookieに代わる機能、または3rd-party cookieの限定利用を可能にするブラウザ機能もあります。
3rd-party cookieへのアクセス許可「Storage Access API」
https://privacycg.github.io/storage-access/ より
ブラウザの3rd-party cookie廃止の後も、特殊な条件で3rd-party cookieにアクセスするためのAPIも用意されています。Storage Access APIはその一つで、3rd-partyの埋め込みコンテンツ（iframe）が自サイトのcookie（本来は3rd-party cookie扱い）へのアクセスをユーザから許可をもらう仕組み。3rd-partyコンテンツでもユーザ認証ができるので、以下のようなユースケースが想定されています。
有料（広告なし）プランで埋め込み動画再生
3rd-party支払いサービス
SNSコメントウイジェット
Safariではユーザが直接アクセス・操作したことがないサイトは許可がもらえないのに対し、Chromeでは「関連サイト」であれば、操作なしでも自動的に許可される仕組みになっています。「関連サイト」になるためのAPIは次に紹介します。
関連サイトの3rd-party cookie共有「Related Website Sets」
同じ組織が管理するなどで、関連性が認められた複数ドメイン間でクッキーを共有できる仕組み。最近First-Party Setsから名称を変更。Chrome以外のブラウザは対応する予定ありません。
一つのサイトは一つのセットにしか参加できないので、広告ネットワークやアナリティックベンダーのサイトを自社サイトのセットに入れてcookieを共有することはできません。
セット内の3rd-party cookieにアクセスするためには上述のStorage Access APIを使って許可をもらいます。iframeの中からAPIをコールするパターンと、サイトが画像やscript等の3rd-partyサブリソースの代わりに呼ぶパターンが用意されています。
セットの登録は申請が必要で、githubで管理されています。セットの最新のリストはこちらで確認できます。
3rd-party cookieをサイトごとに隔離する「CHIPS」
CHIPSでは3rd-party cookieを1st-partyサイト（アドレスバーのサイト）ごとに管理するための新しいcookie属性が定義されています。cookieはどのサイトからアクセスされたかによって値が異なるため、クロスサイトトラッキングが不可能です。一つの3rd-partyツールが複数のサイトで同じ名前のcookieを使いたいが、値はサイトごとに違ってもいいという場合に使えます。これを使えば3rd-partyツールがわざわざCNAMEやJavaScriptの1st-party cookieを使わなくても各サイト内でのcookie読み書きができます。
今の所Chromeだけが実装していますが、Firefoxでは3rd-party cookieに対してすでに同じような処理が強制的に施されています。初代ITPでは、２４時間経過後3rd-party cookieが隔離される仕組みになっていましたが、その後ブロックに変わり、Chrome/Firefoxに合わせて隔離の仕組みを復活させるかは不明です。
Federatedログイン用API「FedCM」
クッキーを使わずにSign in with Google/Facebookなどを実現するためのAPI。詳細は公式説明サイトまで！
まとめ
3rd-party cookieは読み書きしておけばサーバ側で自由にユーザ単位の計測やターゲティングができましたが、今後はブラウザに設けられた制限の中でユースケースごとAPIを組み合わせてデータを処理することになります。ブラウザごとにAPIが異なり、同じブラウザで各APIから取得できるデータの粒度も異なるため、取得後のデータ統合や補完、類推が求められます。ブラウザAPIとは別に、広告媒体から提供されている、個人情報等を使ったコンバージョンAPIとの組み合わせも考えられます。
クッキーに比べて難易度は格段に上がりますが、ブラウザAPIに関しては（SafariのPCMを除いて）広告媒体側の配信や計測タグからコールされる想定ので、配信面と広告主サイト側には大きな負担はかからないはずです。