3rd-party cookieもIDFAもないアドテックに向けた動きまとめ 各機能紹介編

Privacy Sandbox等のクッキーレスアドテックに関する前回の記事から１年が経とうとしています。１年間様々なベンダーから提案が公開され、議論も進化のペースが激しく、しばらくまとめを断念していました。今年に入ってからもGoogle (ChromeとAds）やAppleからクッキーレス、IDレスアドテックについて発表が相次ぎましたが、主要提案の開発とリリーススケジュールが明らかになり、発散から収束フェーズに入ったと思われるので、一度状況まとめておきます。

振り返り

Privacy SandboxはGoogle Chromeの開発チームが提案する、3rd-party cookieとフィンガープリンティングの代替技術（サイトを跨いだ計測とターゲティング機能、アドフラウド防止機能）およびサイトを跨いだユーザ単位のトラッキング防止機能の総称です。3rd-party cookieの段階的な廃止自体もSandboxに含まれています。各技術の仕様策定はW3CのWeb Platform Incubator Community Group (WICG)で行われていますが、なぜか業界関係者への説明や議論はW3Cの別のグループ「Improving Web Advertising Business Group」 (IWABG)の会議で毎週実施されています（去年から議事録が公開されるようになりました）。最近は各提案の細かい議論のためにWICGの会議が増えてきています。ということでいろんなところで口頭で議論が行われていますが、重要な課題は全てGitHub上の各機能のレポジトリのissueで明文化されています。

Appleが進めている代替技術の総称はありませんが、W3CのPrivacy Community Group（Privacy CG）で標準化が進んでいます。2020年4月にChromeもPrivacyCGにジョインして、そこでSandboxの提案の一つだけ（複数のドメインを一つの1st partyとして見なすFirst-Party Sets）がWICGから移っています。
標準化は当然Webに限定した話で、iOSアプリに関してはAppleが独断で仕様を決めます。

代替技術はブラウザやOSの機能として実装し、一部はJavaScript APIとして利用できるようになります。

今回は計測とターゲティング機能を中心に紹介します。IPアドレス隠蔽機能、ブラウザ（UA）情報の取得制限、サイトごとのユーザID分割機能等、トラッキング防止系は別の機会で。

コンバージョン計測

まずは比較的コンセンサスが取れている計測機能開発の状況です。

ChromeのConversion Measurement API（仮）

CMAPIは広告クリックとコンバージョン（CV）を紐づけるための機能で、Chrome 87（2020年6月）から実装済です。Chrome 91までOrigin Trialとして利用可能になっている一番実用化が進んでいるAPIの一つです。
機能の名前にAPIが付いていますが、htmlとトラッキングピクセルで構成されています。

計測の流れは、
1. 広告がクリックされた時に、クリックを識別するためのID（64ビット）をブラウザ側で記録し、
2. クリックから30日以内に広告主（クリックの遷移先）のドメインでCVが発生したら、
3. クリックIDとCVデータ（0~7までの値）のペアをレポートとして、広告のレポート送信先に（ブラウザから）送る。

レポート送信先は基本的に広告の配信ネットワークが指定される想定ですが、指定がなければ広告配信面のドメインになります。
ブラウザがCVの発生を検知するために、レポート送信先ドメイン（例えばhttps://ad-network.example/）に対して、トラッキングピクセルを発火させ、発火先サーバ側で規定のレポーティング専用URL（https://ad-network.example/.well-known/attribution-reporting/trigger-attribution）にリダイレクトさせます。パスが「.well-known/attribution-reporting/trigger-attribution」になっているURLへのリダイレクトのみ、ブラウザがCVとして認識します。

クリックID（"attribution source event id"）やLP/CVドメイン（"attribution destination"）、レポート送信先（"attribution report to"）は、次のように広告表示時にアドサーバが生成した広告のHTMLタグに埋め込む必要があります。 ​

<a attributiondestination="advertiser.example" attributionsourceeventid=123456789 attributionexpiry=... attributionreportto="ad-network.example">

Safariの「Private Click Measurement」

WebKit/Safariでは同様の計測機能Private Click Measurement（PCM）がChromeよりも前に提案と実装がされています。リリース間もないiOS14.5とSafari 14.1に標準搭載予定です。ChromeのCMAPIとの仕様共通化の議論（主にネーミング）が進んでいますが、根本的な違いの解消目処が立っていません。

まず、クリックIDの長さ問題です。CMAPIの64ビットだと特定のクリックを識別できるのに対し、PCMの8ビットでは256種類のクリックしか識別できないので、特定のユーザの追跡が不可能です。PCMは基本的にキャンペーンという粗いレベルでの追跡だけ可能です（256人ユーザしかない配信面なら個人の追跡は可能ですが）。このためSafariはChromeがPrivateではないと批判し続けてきました。そしてChrome仕様の方が、EUのGDPR/ePrivacyに規定されている同意が必要になる可能性が高いと思われます。

もう一つの違いとして、PCMはSafariらしくブラウザから第三者（Service Provider / 委託先であっても）へのデータ送信も許しません。ブラウザからはユーザが見えないドメインへのデータ提供をしない、連携したければサーバ側でどうぞ、というスタンスです。現状ではクロスサイトiframe内の広告クリックにも対応しておらず、実質Google SearchやFacebook内広告（配信面自体が広告ネットワーク）のような1st-party広告の計測しかできません。Braveブラウザが1st-party広告や1st-party（自社運用）analyticsだけブロックしないスタンスに近いです。
PCMから第三者にはデータを送らないものの、広告主には送信できるように対応を進めています（CMAPIのクリックIDだと生成したアドネットワークしかIDの意味がわかりませんが、PCMの静的なIDの値は255までなので広告主と配信面で共有しやすいメリットを活用）。

他に色々細かい違いがありますので以下表にまとめます。が、その前に、アプリ計測の話。

iOSアプリ内コンバージョン計測の「SKAdNetwork」

CMAPIとPCMはWeb上のCVにだけ対応しています。アプリ内CVを計測するために、iOSの計測機能SKAdNetwork (SKAN)を使う必要があります（Androidには同様の機能の話がまだ上がっていません）。詳細は省略しますが、PCMと同様に粗い粒度（キャンペーン単位）での計測になります。PCMとの大きな違いはアトリビューションレポートが配信面ではなく広告ネットワークに送信される点です（Safariは第三者へのデータ提供を許しませんがiOSでは許容されます）。

それでは約束のCMAPIとPCM（とSKAN）の比較表です。

iOSのApp Tracking Transparency (ATT) Framework

iOS14.5から適用されるアプリのトラッキング規制「ATT」の話は既に詳細な記事が出ているので割愛します。非常に重要な点だけ引用します。

改めて、非常に重要な点になりますが、ATT はユーザーに対してトラッキングを行うことへの同意取得であり、IDFA の利用はあくまで一部であることを認識する必要があります。

IDFAだけが規制対象ではないので、アプリ内のユーザデータとアプリの外のユーザデータの紐付けができるような独自のユーザIDの利用もNGです。このためGoogle AdsはGoogleアプリからクリック遷移先URLへのクリック ID（gclid）の付与をやめて、キャンペーン単位の新しいパラメータを導入することを案内しています。ただしGoogleアプリ以外は引き続きgclidが付与されます。Googleアプリでなければgclidを使ってアプリ内ユーザデータと広告主サイト上のユーザデータの紐付けができないからと思われます。
（AppleはATTについて以下のようにトラッキングを定義しています。 ）

Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.

Facebookもユーザ単位からPCMのような集計単位での計測に切り替えると宣言しています。

計測機能のフラウド対策

偽アトリビューションレポートを送るだけでCV偽造できてしまいますので、現状以上にフラウド対策の仕組みが重要になります。PCMではすでにblind signatureを使った対策の実装を進めています。Chrome側は検討中の段階です（64ビットに比べて8ビットのキャンペーンIDの偽造が安易にできるためPCMの方の対策が優先度高く思われます）。

ビュースルー計測への拡張

ビュースルー計測に関してはChromeもSafariも未対応ですが、どちら側も前向きに検討されています。ただ、クリック以上に計測の粒度が落ちる可能性が高く、WebKitのITPエンジニアが興味を示しているFacebookからの提案では、キャンペーンすら区別せずに、広告主の広告（どれかは不明）を見たかどうかの情報だけをレポートに載せる仕組みになっています。

実際は誰が使う？

Chromeはまだcookieが全然制限されていないのでCMAPIを使う理由が今のところ特にありません。cookieの制限が多いSafariですら、PCMの方が制限が多いため今のところ使うインセンティブがほとんとありません。広告のリンク先にキャンペーンIDなどのパラメータを付与して、CVポイントまでJavaScriptのcookieやLocalStorage、CNAMEな1st-party cookie、純粋な1st-party cookieなどを使ってキャンペーンIDを保持した方が自由度高く計測ができるのです。Apple自身、検索広告およびアフィリエイトプログラムのCV計測（1日以内のCVのみ）を「afid=abc&cid=123」のようなURLパラメータと1st-party cookieを組み合わせて計測していると思われますが、 今後PCMにどう対応していくかが注目ですね（広告主だけでなく媒体の対応も必要です）。

All links from your site to Apple contain your unique partner ID. Every time a customer visits apple.com via your site and makes a purchase, we’ll credit your account. To make sure that all purchases are tracked accurately, use only links from our partner, Impact.

SKAdNetworkだけ状況が異なり、ユーザがトラッキングを同意しない限り他に計測する方法がないためアドテックが積極的に導入しています。

ターゲティング

次にサイトを跨いだ行動ターゲティング機能の話です。今回は簡単な方（Safari）から。

行動ターゲティングをサポートしないSafari

ブラウザはユーザ思考を操作するためのターゲティング機能を提供するべきではない、広告はサイト内のユーザ行動や配信面の文脈（コンテキスト）情報を元にターゲティングすればいいと言う考え方の元、ブラウザ側にターゲティング機能を提供する予定はありません。

We are currently only interested in supporting the measurement case —
we don't want a browser technology to support reasoning about users across sites, even at a group level.

行動ターゲティングを見直すChrome

2019年に、3rd-party cookieを廃止した場合のパブリッシャー（配信面）の収入が52%減るという調査結果を発表して以来、3rd-party cookieに代わってサイトを跨いだ行動ターゲティングの技術開発が必要だと主張してきました。2020年に素案が公開され、現在も開発中のFLoCとTURTLEDOVEはこのユースケースをカーバするための機能です。基本的には現在アドテックのサーバ側で行われているユーザの無制限な情報収集とユーザ情報に合った広告の選択を、制限付きでブラウザ側（砂箱？）に移す仕組みです。

ブラウザ側でユーザをセグメント化するFLoC

同じ趣味趣向を持つであろうユーザに同じ番号（コホートID）を振るための技術です。3rd-party cookieがまだ使える世界では、ユーザにIDを振って、ユーザのブラウジング履歴を収集してユーザプロファイルを作る（らしい）のですが、FLoCではブラウザ側がブラウジング履歴を元にユーザをグルーピングします。
具体的に、最初のバージョンでは直近一週間にアクセスしたドメイン（URLのサブドメインやパスは無視）をハッシュ化して細かくグルーピングした後に、グループが小さすぎてユーザの特定ができないように、履歴が近い（=ハッシュ値が近い）グループを統合し、最終的なコホートIDを決めます。コホートIDはJavaScriptから取得できます。ハッシュ化はSimHashアルゴリズム、グループの統合はSortingLSHアルゴリズムを使います。ちなみに統合処理ではグループの参加人数把握が必要になるので、他のChromeブラウザから集めてまとめた情報をGoogleのサーバからダウンロードするので、完全なオンデバイス処理ではありません。

cookieだとサイトに情報収集のタグ（html）を配置したサイトで、タグ配置したサービスしか追跡ができないので、サービスが普及しているほどユーザ情報を収集しやすい性質がありますが、FLoCだと全てのサービスが（Chromeが生成した）同じコホートIDを参照するので、インターネット上にタグをばらまくほどトラッキングしやすくなるネットワーク効果問題が解消されます。
ただ、Chromeが生成したコホートIDの意味はChromeも誰も教えてくれないので、他のデータと照合して意味を推測する必要があります。例えば、「このコホートのユーザはこの商品カテゴリをよく見ている」（ので関連する商品の広告を積極的に表示しよう）。1st-partyデータを多く保有していた方が推測が安易にできます。また、たくさんのサイトでのFLoC IDを観察できればIDからブラウザ履歴を逆算できる可能性がありそうです。
こういったFLoCのプライバシー関連の課題について、W3CのPINGとTAGによって絶賛レビュー中です。

FLoCの検証はChrome 89のOrigin Trialとして間もなく開始され、3rd-party cookieをブロックしていないユーザの中から、数パーセント（5%?）のChromeユーザで有効になる予定です。最初はブラウジング履歴はドメインまでしか使わないので、サイト（ドメイン）の分野が狭いほど、FLoCへの貢献が大きくなります。例えばYoutubeとGoogleとヤフーにアクセスしたユーザのコホートより、ilovecats.exampleとilovesportscar.exampleとilovefrance.exampleのアクセスからできたコホートの方が価値があります（コホートIDから実際はどのサイトを見たか逆算できませんが）。

ユーザ行動情報と文脈情報を分けるTURTLEDOVE

FLoCではブラウザがユーザに一つのラベルを振っているだけでラベルをどう使うかは自由なのに対し、TURTLEDOVEではサイトAがユーザにラベルを付与し、ラベルが付いたユーザのグループ（インタレストグループ、以下「IG」）に対してサイトBがターゲティングし、広告を表示するところまで規定されています。

頭の「TUR」はTwo Uncorrelated Requestsの略で、文脈広告のリクエストとパーソナライズ（インタレスト）広告のリクエストの送信タイミングを分けることによって、ユーザのプライバシーが守られるという考え方です。具体的にはユーザが現在見ているサイトは文脈広告のリクエストしか見られず、過去のユーザ行動を反映したIGは見られません。ブラウザしかIGがわかりません。（ただし文脈広告リクエストにはIGの情報が含まれませんが、入札の時に文脈情報は参照できます。ブラウザからは出ないのでセーフ）

ユーザ行動情報と文脈情報は本当に分けないとダメ？

ブラウザしかコンテキストとIGの両方を把握していないので、ブラウザが入札処理まで担当しなければならず、サーバ側で行われている既存の入札（RTB）の仕組みから大きく離れます。そこで「変わりすぎて大変！」、「コンテキストとIGの情報を混ぜてユーザが特定できないように（k-anonymityの条件を満たすまで）加工して一緒にサーバに送ればいい」と、発表されたのはMicrosoftのPARAKEETカウンター案です。Sandbox担当エンジニアのKleberさんはこの方法も検討しましたが非現実的だと判断し断念したと説明しています。具体的には文脈とインタレストを混ぜるために文脈情報の粒度を落とさなければならず（ページURLすら送らない）、1st-partyデータでのターゲティングまで精度を落とす必要があるといった課題があります。
以上余談です。TURTLEDOVEに戻ります。

TURTLEDOVEの進化版「FLEDGE」

2020年、TURTLEDOVEの仕様が公開された後すぐにCriteo、NextRoll、RTBHouse、Prebid、Google Adsから色々な鳥の名前が付いたカウンター案や拡張案が発表され、今年の2月にそれらの案からいいところを取り入れて発表されたのはFLEDGE（TURTLEDOVEファミリーの最初のプロトタイプとしても紹介されています）。
以下、雰囲気が伝わればと思いFLEDGEの仕様書のハイライトです。

まずTURTLEDOVEからの変更点は？

1. IGメタデータの拡充（入札パラメータ、日次更新URL、広告情報URL等）
2. IGの人数下限の撤廃（クリエイティブ等には閾値が残る）
3. ブラウザの負荷軽減のためのTrustedサーバの導入
4. Seller（パブリッシャーかSSP）とBuyer（広告主かDSP）の役割分担

想定されているユースケースは？

1. 広告主サイトで、特定の商品カテゴリなどを見たユーザのグループを作る（リターゲティング）
2. パブリッシャー（ニュースサイト等）サイトで、特定のカテゴリの記事を読んだ人のグループを作って、他のサイトでこのグループに対してターゲティングできるようにする。パブリッシャーはターゲティングする権利を売って収入を得る。

グループへの追加方法は？

JavaScriptでIGの属性を設定し、navigator.joinAdInterestGroup()という関数に渡します。離脱関数も用意されています（ユーザが広告の右クリックで離脱できるようになる想定）。広告主もパブリッシャーも自前で直接ユーザをIGに追加してもいいし、第三者（アドテックベンダー）に任せてもいい。第三者が（クロスドメインのiframe内で）ユーザをIGに追加するためにファーストパーティ（ユーザが見ているサイト）の許可が必要です。

Buyer（広告主・DSP）の役割は？

1. 入札に参加するかどうかを決める
2. 入札のパラメータやIGに合わせて広告を選んで、Sellerにビッド（入札価格）とメタデータを返すビッド生成ロジック（IGの属性にあるURLから取得したJavaScript）
3. 入札後のレポーティング

Seller（パブリッシャーかSSP）の役割は？

1. パブリッシャーのルールに従い、どのIGオーナー（Buyer）が入札に参加できるか、Buyerのどのビッドを検討するかを決める。Buyerはブラウザが参加しているIGのリストのオーナーから選択。
2. 各Buyerからのビッドの価格とグループのメタデータを元にビッドを評価する入札ロジックの実装と提供。スコアの一番高いビッドが落札。ロジックはJavaScriptとしてSellerのドメインからダウンロード。
3. 入札後のレポーティング（落札したビッドの情報等）

Trustedサーバの役割は？

初代TURTLEDOVE案では入札に必要な情報を一回ダウンロードしておいて、入札までブラウザ側で保持する仕組みだったのですが、ブラウザの負荷が高くなる為、FLEDGEでは随時Trustedサーバから情報を取得できるように変わっています。Trustedサーバから情報がリークしないようにトラストをどう担保するかが大きな課題になりますが、その課題解決は後回しになっています。
サーバから取得するデータは例えば、
Buyer：入札時、ビッドを提示する前に予算消化率等、キャンペーンの最新情報の取得。
Seller：入札時に、ビッドを検討するためのクリエイティブの審査結果取得。

FLEDGEの仕様書ハイライトは以上です。TURTLEDOVEと違って文脈広告のリクエストとインタレスト広告の競争（入札）についてほとんど記載がないのですが、文脈広告のビッドとインタレスト広告のビッドを比較するTURTLEDOVEの基本的な仕組みは変わっていないと思われます。そしてまだまだ絶賛議論・進化中です。

FLoCとTURTLEDOVEの組み合わせは？

初代TURTLEDOVEの仕様書の最後には３つ目の広告リクエスト（Three Uncorrelated Requests -> ThURTLEDOVE）としてFLoCベースターゲティング広告を使うことも考えられると記載されていますが、「あとで考える」状態です。

keeping FLoC as an independent effort for now seems prudent.

ブラウザとOS以外の取り組み

最後に、制限をかけるためにデバイス側に制御を寄せようとしているChromeとAppleの動きに対してアドテック業界がどう対応しようとしているかについて、主要プレイヤーの動きを紹介します。

Google広告の取り組み

Sandboxに対するGoogle広告の動きは
1. Sandbox（主にFLEDGE?）への要望出し、
2. 独自のTURTLEDOVE系の機能「DOVEKEY」の提案、
3. FLoCとTURTLEDOVEを擬似的にアドサーバ側で実装してDSPが検証できるように準備を進めています。

また、1月に3rd-party cookieに代わるクロスサイトなユーザID（ハッシュ化したメールアドレス等）の開発をしないことも宣言しました。ただし、パブリッシャーが持っている1st-partyデータと広告主が持っているデータを接続できるような機能もその翌週に発表し、業界を若干混乱させました。
Google Ad ManagerではパブリッシャーごとのユーザID「Publisher Provided Identifiers (PPIDs)」でのターゲティング機能の拡充も発表しています（1st-partyデータ系なのでTURTLEDOVEで言う文脈広告リクエストのほうで利用する想定です）。

Google広告のユーザ単位のデータと広告主のデータをユーザID単位で結合して、50人以上の単位で結果を返すデータクリーンルームAds Data Hubも2017年からβ版として提供されていますが。ただ、Googleと広告主データを結合するためのキーとして3rd-party cookie（sync）、IDFA/AAID、URLパラメターやLiveRamp IdentityLink IDs（暗号化したメールアドレス）を使う必要があり、従来のユーザIDに依存している状況です。

Facebook広告の取り組み

表ではATTの同意義務化をめぐってAppleと戦いながら、裏ではFacebookのエンジニアが積極的にSandboxとWebKitの提案作業に参加しています。両陣営の会議に必ず参加しており、ファシリテーターのような役割を担いつつあります。独自の提案（クロスデバイス計測、リフト計測）もいくつか出していますが、議論や採用が進まず。Criteoと一緒に、アトリビューションよりもインクリメンタル・リフト計測の重要性を訴え続けています。

IABの取り組み

（Appleのような率直な同意の取り方に反対しながら）同意さえ取れたら個人単位のクロスサイトトラッキングは問題ないという考えの元、クロスサイトなユーザID（ハッシュ化または暗号化したメールアドレス等）の開発を進めています。特に2020年10月以降The Trade Deskが主導しているUnifiedID 2.0への新たな企業参画の発表が相次いでいます。

メールアドレスを使ったIDは、導入しているサイトにログインしただけでユーザがあまり意識せずにデータIDがベンダーに流れる印象ですが、Unified ID2.0ではユーザが意図的にUnified ID2.0を使ってログインできるようなシングルサインオンやポータル機能まで提供する構想になっています。（ポータルでは過去に見た商品や放置したカートを確認できるようになるのでしょうかね。）

Criteo は User-Centric Ad ID ソリューションの主要な要素を Unified ID 2.0 へ 導入します。(...) User-Centric Ad ID には、消費者が自分のプライ バシープロフィールにアクセスし、Web ブラウザおよびアプリをまたいで広告ターゲティングの設定を更新できるポータルが含まれています。

「Sign-in with Apple」と同様に、Privacy Sandboxにもサイトごとにメールアドレスを自動生成する提案（WebID）も含まれているので、クロスサイトユーザIDを守るためには確かに独自のログインシステムを作った方が安全そうです。

Privacy Sandboxへの対応については、議論に積極的に参加しているサービスやベンダー（Facebook、Criteo、NextRoll、RTB House、Scibids、 Magnite、Salesforce、ヤフー）と横で観察または激しく批判するベンダーで分かれています。

まとめ

Googleは主に個人単位のクロスサイトトラッキングや行動（マイクロ）ターゲティングをプライバシー問題として定義し、集団単位のトラッキングとターゲティングに移行しようとしています（ただし計測機能は個人単位でCVの有無をトラッキングすることまで可能です。。）

一方、Appleは（例え集団単位で行ったとしても）行動ターゲティングまで問題視しており、Webでは計測目的以外のクロスサイトトラッキングを認めず、計測も個人単位の追跡ができないように機能設計しています。アプリではユーザの同意が取れた場合のみクロスサイトトラッキングを許容します。

アドテックベンダーは3rd-party cookieのプライバシー課題として、主にユーザがコントロールできない点を挙げており、個人単位のクロスサイトトラッキングと行動ターゲティングの課題認識は特に持っていないようです。このために3rd-party cookieに代わるクロスサイトなユーザIDの普及を目指しています。

アドエビスの対応

アドエビスは2017年のITP1.0の発表をきっかけに広告クリックのコンバージョン計測を3rd-party cookieから、1st-party cookieを使ったドメインごとの計測への切り替えを進め、クロスサイトトラッキングへの依存度を下げてきました。

直近では、マーテック研究会はSandboxの議論に参加したり（CMAで計測ベンダーもアトリビューションを受け取れる方法について提案）、トラッキング防止機能の不具合の報告（ITPでlocalstorageが7利用日で削除されない不具合をWebKitに報告）を実施してプライバシー保護強化の取り組みを支援しています。今後もアドエビスとしてプラットフォームが提供する技術を活用しプライバシーが保護された新しいエコシステム構築に貢献していきたいと考えています。