ポストサードパーティcookie時代のソリューションとプライバシー

Googleは現時点では廃止自体を諦めたものの、個人のプライバシー尊重の観点からサードパーティcookieを廃止する動きを進めていた。AppleのiOSやSafariではすでにITPによってサードパーティcookieはデフォルトで使えなくなっている。

そんな中サードパーティcookieに代替する技術としてさまざまな技術をGoogle自身も開発し、他のベンダもそういった技術を開発してきた。その結果さまざまな自称「ポストcookie」「cookieレス」ソリューションが出てきているのだが、それらはどれも完全にサードパーティcookieを代替するわけではなく、これまでサードパーティcookieが担ってきた役割を部分的に違う方法で実現しようとしているものにすぎない。ここではソリューションの種類と、それらがサードパーティcookieのどんな機能を代替するのか紹介する。

サードパーティcookieの役割

cookieの役割にはさまざまなものがあるが、サードパーティcookieは主にドメインをまたいでブラウザを識別するために使われてきた。ファーストパーティcookieであれば自社サイトの中だけでの識別になるが、サードパーティcookieでは自社のサイトと他社のサイトで同一人物であることが判明してしまうため、ユーザの許諾なくそれを使うとプライバシーを侵害することになる。そこでサードパーティcookieを使う場合はユーザの許諾を得ることを必須にする（デフォルトでは無効化する）というのがサードパーティcookie無効化の流れである。

ブラウザを識別することによって

広告のリマーケティング／リターゲティング
広告配信や分析のためにオーディエンスリストを作る
コンバージョン計測（ビュースルー、クリックスルー）

一部分析用途もあるが、ほとんどは広告配信のために使われてきた。

これら個別の用途を実現するためにさまざまなソリューションが提案されることがあるが、主に以下に分類される。

Privacy Sandbox
Google広告の拡張コンバージョン、Facebook広告のコンバージョンAPI
共通IDサービス
データクリーンルーム

これらはいずれも「ポストcookie」「cookieレス」ソリューションと称されることがあるが、それぞれ別のものなので、用途に応じて選択する必要がある。

サードパーティcookieに対する各ブラウザベンダの姿勢

サードパーティcookieに対して各ブラウザベンダはどのようにサポートしていくのか、Google（Chrome）とApple（Safari）のアップデートに見える方針を読み解いていく。

Appleの方針

ITPによってサードパーティcookieが無効化されると広告の行動ターゲティングができなくなるが、それについては特にフォローすることを考えていないようである。

またサードパーティcookieが無効化されたり、広告媒体サイトからの流入時にcookieの有効期限が著しく短くなったりすると、広告のコンバージョン計測ができなくなるが、こちらについては広告配信の成果のカウントを個人の行動がわからない形で許容している。

広告が表示されているサイトのHTMLと広告の成果が発生するサイト（自社）のHTMLとサーバ両方に細工をすることで、キャンペーン×成果地点ごとに集計されたレポートが送られてくるようになる。集計されているので、個人は特定できない。これをPrivate Click Measurementという。ウェブサイト／Safariだけでなく、iOSのアプリでも類似の実装（SKAdNetwork）が用意されている。

Googleの方針

ユーザの同意なきトラッキングが悪であって、広告配信は必要。そのための技術はサポートするという方針のようである。広告配信のための機能としてはこれまで触れてきたターゲティングや効果測定に加え、不正対策などがある。サードパーティcookieに代わってプライバシーを保護した形でこれらを実現するための機能を開発してきたのだが、機能不十分ということでサードパーティcookieの廃止を諦めた。ただし代替技術自体はChromeに残されたままで、これらの技術をプライバシーサンドボックスといい、詳細は次の項で説明する。

Privacy Sandbox（プライバシーサンドボックス）

Googleをはじめとするアドテク事業者が、サードパーティcookieに記録された識別子とともにユーザの行動履歴を受け取り、配信の制御を行ってきた。つまりアドテク事業者のサーバで集中管理をしていたわけだが、その過程でアドテク事業者が個人のサイトをまたいだ行動履歴を取得する（トラッキングする）ため、プライバシーの侵害と指摘されるようになった。

そこでサーバが個人の行動履歴を受け取らない形で広告配信に必要な機能を実現する。具体的にはこれまでサーバが行ってきた処理の一部をブラウザに任せ、ブラウザからは履歴情報そのものを送らないようにしつつ、それでもターゲティングや効果測定、不正対策を実現するという取り組みを始めた。これがプライバシーサンドボックスである。プライバシーサンドボックスはあくまでChrome（iOSのChromeは対象外）だけを対象にしたものであり、macのSafariやiOSのブラウザはすべて対象外である。

プライバシーサンドボックスを構成する各技術要素へのリンクは以下のページにある。

https://privacysandbox.com/intl/ja_jp/open-web/

これまで広告配信においてサードパーティcookieが担ってきた役割には主に以下のものがある。

アドフラウド検知
インタレストに基づいた広告
オーディエンスリスト、リマーケティングリストを作る
コンバージョン計測

これをそれぞれ置き換える技術を紹介する。

アドフラウド検知：Private State Tokens API（旧Trust Token API）

メディアサイトでは、ボットからのアクセスに対して広告を表示させたくない。人間であることを検証することが必要となる。以前はボットでない情報を共有するためにサードパーティcookieが使われてきたが、今後はPrivate State Tokensというものを使う。

ユーザがあるウェブサイトAに訪問し、reCAPTCHAなどの入力など人間でないとできない行動をすると、ボットでないことを証明するトークンが発行される。そのトークンはブラウザに保存される。

そのユーザが広告を表示すべき媒体側のサイトB（このサイトはそのユーザがボットでないことを確認したい）に訪問すると、サイトBがあらかじめ信頼したサイト（これがAに該当する）が発行したトークンをブラウザが持っているかどうかをブラウザ上で検索する。もし照合したら、サイトBはサイトAに照合したというリクエストを送り、サイトAから照合したことを証明するレコードを受け取る。

サイトBは広告プラットフォームに対してそのレコードを付けたリクエストを送ると、広告プラットフォームから広告表示に必要なデータが返される。そしてサイトBで広告が表示され広告インプレッションがカウントされる。

https://developers.google.com/privacy-sandbox/protections/private-state-tokens

インタレストに基づいた広告：Topics

従来インタレストベースの広告では複数のサイトの閲覧履歴から訪問者の興味を推定していた。そこではサードパーティcookieをキーにサーバにウェブ閲覧履歴を送り、そのデータに基づいて類似の興味を持つ人たちをクラスタリングしていたわけである。

その置き換え技術としてブラウザ内でサイト訪問履歴に基づいた匿名のセグメントに分類し、セグメント情報をサーバに送るFLoCという技術が提案されていたが、いろいろアドテク業界の反発を受けるなどして代わりにTopicsという方法が提示された。

Topicsでもブラウザ上でサイト訪問履歴に基づいた興味関心の分類が行われるが、FLoCとは異なりあらかじめ意味の定められたセグメント（トピック）に分類される。その中にはセンシティブなトピックは含まれず、500個弱のトピックが予定されている。

https://github.com/patcg-individual-drafts/topics/blob/main/taxonomy_v2.md

分類モデルがブラウザの中に含まれるので、ブラウザ上でこの分類を拡張した独自の分類モデルも構築できる。

Topicsの挙動としては

週単位で閲覧履歴に基づいて毎週最大5個のトピックが興味関心の候補として抽出される。分類の際にはURLのフルパスではなくホスト名だけが使われる
履歴がある場合は最大で過去3週間までさかのぼって、各週につき上の5個のうち1個（合計3個）のトピックをランダムに返す。ただし5%の確率で全分類からランダムにトピックが選ばれる
2の抽出は広告を表示するサイト（ドメイン）を訪問するたびに行われる

https://developers.google.com/privacy-sandbox/relevance/topics

オーディエンスリストを作って入札を行う：Protected Audience API（旧FLEDGE）

リマーケティングとカスタムオーディエンスを提供するもので、第三者がサイトをまたいだトラッキングに使えないような形で提供される。

従来はブラウザからIDと行動履歴をサーバに送り、サーバで行動履歴からIDのリストを作っていた。このIDの同一性を保つのにcookieが使われていたわけである。

Protected Audience APIではIDと履歴をやり取りするのを廃止し、インタレストグループという単位でやり取りすることになる。ブラウザ内で、各ユーザを、個人を特定できないある程度の人数をもつインタレストグループに分類する。このインタレストグループが従来のオーディエンスリストと同じ役割を果たすのだが、リストの生成がサーバでなくブラウザで行われるところに特徴がある。そしてそのグループ単位で広告の入札が行われるのだが、この入札もブラウザ内で行われる。

インタレストグループ

インタレストグループとは、リマーケティングリストのような共通の興味関心を持つユーザのグループ。さまざまな立場の事業者（インタレストグループのオーナー）がそれぞれの目的で任意に作ることができる。

広告主がグループを作るケース。たとえば通販サイトの場合、自社サイト上でどんな商品を見た人なのかという単位でグループを作れる。リマーケティングリストになる。

パブリッシャー（媒体サイト）がグループを作るケース。たとえばニュースサイトの場合、どんな記事を見ている人なのかという単位でグループを作れる。パブリッシャーのファーストパーティデータを使って広告主サイトの訪問者に合った広告を表示できるし、特定のプレミアムなセグメント作ることもできる。

アドテク事業者がグループを作るケース。たとえばDSPの場合、どんな製品カテゴリに興味を持つ人たちなのかという単位でグループを作れる。特定の製品カテゴリ市場にいるとDSP事業者が推定した人たちのグループを作り、そのカテゴリの製品を売るための広告で使われることがある。

Protected Audience APIを使って広告が表示されるまでの流れ

ユーザが広告主サイトを訪問すると、広告主が使っているDSPまたは広告主自身のスクリプトによって、ブラウザでインタレストグループを追加する処理が行われる。
ユーザが広告を表示する媒体サイトを訪問すると、媒体サイトが使っているSSPかまたは媒体サイト自身のスクリプトによって、ブラウザ内で広告のオークションが行われる。オークションはそのブラウザが持つすべてのインタレストグループに対して行われる。
オークション中には、Protected Audience API仕様で信頼されたサーバを通じて媒体と広告主の間で広告の表示可否を決めるのに必要なリアルタイムのデータ（クリエイティブ情報や予算など）のやり取りが行われる。
広告が表示され、オークション結果がレポートに送られる。クリックが発生したらクリック情報がレポートに送られる

以下のページに広告配信の仕組みの詳細が説明されている

https://developers.google.com/privacy-sandbox/relevance/protected-audience

コンバージョン計測：Attribution Reporting API

従来コンバージョン計測はcookieを使って行われてきた。広告に接触（クリックまたは表示）したブラウザのcookieにIDを発行し、広告主のウェブサイトでコンバージョンが発生したときにそのcookie内のIDを参照することで広告接触情報とコンバージョンを対応させていた。クリックスルーコンバージョン計測はファーストパーティcookieを使えば引き続き実現できるが、ビュースルーコンバージョン計測はサードパーティcookieが使えなくなると実現できなくなる。

Attribution Reporting APIはcookieを使わずに広告のクリックや表示の成果を計測するAPI。大きく2種類のレポートを出力できる

イベントレベルレポート
概要レポート

https://developers.google.com/privacy-sandbox/relevance/attribution-reporting/system-overview

イベントレベルレポート

特定の広告表示やクリックに紐づけたコンバージョンをレポートする。情報は大きく制限されているし、レポートに最大7日間の遅延やノイズが含まれる。

媒体側で広告のタグに新たな属性（attributionsrc）として広告クリック計測用のメタデータをやり取りするサーバのURLを埋め込んでおく。すると広告をクリックするときに、計測サーバからブラウザに

広告クリックの属性（クリックIDなど）
コンバージョンをカウントする対象サイト
カウントする期限

などの情報が送られる。広告のクリックだけでなく表示についても類似の方法で行われる。

広告主サイト側でコンバージョンピクセルのタグに先と同様の属性（attributionsrc）にコンバージョン計測用のメタデータをやり取りするサーバのURLを埋め込んでおく。するとコンバージョン発生時（コンバージョンピクセルの表示時）に、サーバからブラウザに対して特定の値（trigger_data）に紐づけてコンバージョン情報を送るよう、命令を送る。

数日後（最大7日）、ブラウザが計測エンドポイントにノイズを入れてコンバージョン情報

広告主サイト（広告のリンク先サイト）
広告クリックの属性（クリックIDなど）
trigger_data（上で受け取ったデータ。コンバージョン種別など）

を送る（これだけしかレポートしない）。

WebKit(Safari)の提供するPrivate Click Measurement(PCM) APIと似てはいるのだが、Chromeではビュースルー計測ができる、

https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md

概要レポート

イベントレベルレポートでは限られた情報しか扱えなかった。遅延も発生したし、コンバージョン値も扱えなかった。これはよりリッチな情報をやり取りするための機能である。情報はリッチで遅延も小さいが特定の広告表示やクリックに対して紐づけることはできない、キャンペーンなどの単位で集計されたレポートになる。

https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md

Privacy Sandboxはサードパーティcookie対策としては完璧なの？

ブラウザにはChromeとWebKitがある。より正確に言えばブラウザにはChromium（Blinkレンダリングエンジン）とWebKitがあり、ChromiumはGoogle ChromeやEdgeで、WebKitはiOS内のすべてのブラウザとMacのSafariで使われる。さらにはFirefoxなどもあるが、ややこしいのでシェアの大半を占めるChrome（ただしiOS以外）とWebKitと認識しておけばいい。WebKitはSafariだけでなくiOS内のすべてのブラウザ（Chromeを含む）が対象である。

Privacy SandboxはあくまでGoogleが新しいガイドラインとして提案してChromiumに搭載しようとしているだけで、WebKitで採用されるとは限らないし、AppleとGoogleの関係からWebKitがPrivacy Sandboxを採用する可能性は低い。つまり実質Chromeのシェア（日本では半分程度？）に依存するので、完全とは言えない。

また、すでにWebKit、つまりMacのSafariとiOSのすべてのブラウザではデフォルトでサードパーティcookieがブロックされている点も忘れてはならない。つまりiOSでは現在広告の表示と成果計測が不完全なデータになっており、今後もそれが続く可能性が高いのである。

共通ID

共通IDというのはサードパーティcookieに代替してPIIを使って個人を特定することで広告のオーディエンスターゲティングを実現する技術の一つである。PIIとはメールアドレスや電話番号などの個人識別情報。個人情報保護法で定められた個人情報とは別物。

たとえば以下のような使われ方をする。

ユーザが広告枠の設置されているサイトに訪問するとログインを求められる。そしてユーザが共通IDへの参加（ターゲティング広告の表示）に同意すると、登録済みのメールアドレスや電話番号をハッシュ化・暗号化したものが共通IDプラットフォームのサーバに送られる。そしてこのプラットフォームに参加している広告配信プラットフォーム（DSPやSSPなど）と広告枠を設置しているサイト（パブリッシャー）で共有されて利用される。このログイン情報はブラウザ内のファーストパーティcookieに保存される。

複数のウェブサイトと広告配信プラットフォームが同じ共通IDのプラットフォームに参加することで、それらのウェブサイトや広告配信プラットフォーム間でIDが共有される。つまりサイトをまたいだトラッキングが実現されることになる。そしてユーザは同意のうえでそのプラットフォームに自分のメールアドレスなどの情報を提供するわけである。

メールアドレスをユーザが入力（ログイン）するときに、メールアドレスのハッシュ値がサーバに引き渡される。たとえばユーザーAさんがサイトBとサイトCで同じメールアドレスaaa@example.comを使ってログインする。するとサイトBとサイトCではそれぞれaaa@example.comというメールアドレス（のハッシュ化された値）を受け取るので、サイトBとサイトCの間でメールアドレスaaa@example.comという値を使って訪問者の履歴を照合できる。このようにAさんがログインに同じメールアドレスをaaa@example.comを使ったサイト間では、Aさんの同一性を担保してデータを扱うことができるのである。

ログイン時に使ったメールアドレスに対応した会員番号などの識別子はファーストパーティcookieに保存され、cookieが削除（ログイン状態が解除）されても同じメールアドレスを再入力することで同じユーザとして扱われる。

共通IDは識別子をサーバに送らないPvivacy Sandboxとは異なり、ユーザの同意を得たうえで個人の識別子をサーバに送る発想のサービスである。こちらがより具体的な仕組みの一つである（Inified ID 2.0）。

https://miyaichi.medium.com/unified-id-2-0-%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E5%BA%83%E5%91%8A%E3%81%AE%E6%9C%AA%E6%9D%A5%E3%82%92%E5%BD%A2%E4%BD%9C%E3%82%8B%E3%81%AE%E3%81%8B-4b80723972be

同意済みのユーザしか行動履歴や興味関心などのデータを得られないため、広告配信の総量に対する成果の合計を計測することはできない。つまりこれ単体で広告のコンバージョン計測（効果測定）に使うのは難しい。用途としては主に広告のターゲティングになる。サイトをまたいだ行動の分析や興味関心の推測に使うこともできるが、「PIIのデータを他社と共有することに同意をしたユーザ」という、偏った標本になるので、分析の際には気を付ける必要がある。

ポストcookieの文脈で語られることが多いが、cookieを使うため厳密な意味ではcookieレスソリューションではない。主なものにThe Trade Deskが提唱しているUnified ID 2.0やLiveRamp社のRampIDなどがある。

コンバージョンAPI／拡張コンバージョン

Google/Facebook広告はコンバージョン計測でcookieを使っているが、追加的にcookieに依存しないコンバージョン計測の方法も用意している。iOSではITPの影響ですでにcookieを使ったコンバージョン計測が不完全になっている（サードパーティcookieに限らずファーストパーティcookieも広告プラットフォームを狙い撃ちで多くを無効化する）し、そもそもcookieではデバイスをまたいだコンバージョン（スマートフォンで広告を見てPCでコンバージョンなど）は計測できないため、それらを補完する目的のものである。

コンバージョンAPIも拡張コンバージョンも原理は同じで、広告主サイトでコンバージョンしたユーザのメールアドレスや電話番号（PII）をGoogleやFacebookにアップロードすることによって、彼らが持っているメールアドレスや携帯電話番号のリストと突き合わせるものである。ただしアップロード時には生のメールアドレスや電話番号を送ると危険なので、SHA256でハッシュ化した値をアップロードする。

ウェブの行動ではないオフラインコンバージョンでも使用できる。スマートフォンのアプリで広告を見てウェブのブラウザでコンバージョンした場合でも、コンバージョン時に送信したメールアドレスがFacebookに登録されているものであればコンバージョンとしてカウントされる。逆に捨てメアドのように違うメールアドレスで登録した場合はマッチングできず、コンバージョンカウントされない。ただ携帯電話番号は複数持って使い分けることが難しいのと、Google/Facebookではアカウント登録において携帯電話番号は必須としているため、それなりに紐づく可能性がある。

広告プラットフォームによって名称が異なる。Google広告のものを拡張コンバージョンといい、Facebook広告のものは実装方法によって詳細マッチング、あるいはコンバージョンAPIという。以下、媒体公式ヘルプのリンクを交えて要点だけ説明していく。

拡張コンバージョン（Google広告）

メールアドレスや携帯電話番号をアップロードするのに、JavaScriptのタグを使う方法とAPIを使う方法がある。タグを使う方法にはGoogleタグマネージャー（GTM）を使う方法と、Googleタグ（グローバルサイトタグ、gtag.js）を使う方法がある。

https://support.google.com/google-ads/answer/9888656?hl=ja

タグを使う方法はPIIを入力するフォームにタグで細工をし、フォーム送信時に広告主だけでなくGoogleにもその個人情報を送るようにするもの。フォームの実装次第ではサイト改修不要で実現可能である。GTMとgtag.jsのいずれでも設定できる。それぞれ設定方法は以下のページに記載されている。

GTMでの設定方法：https://support.google.com/google-ads/answer/13262500
Googleタグ（グローバルサイトタグ／gtag.js）での設定方法：https://support.google.com/google-ads/answer/13258081

APIを使う方法では広告主のデータベースにあるメールアドレスや携帯電話番号をGoogle広告API経由でアップロードする。Eコマースのシステムなどでは注文時に自動的にメールアドレスをGoogle広告APIに送信する仕組みのものもあるが、このようにコンバージョン連携に対応したツールを使うのでなければ開発が必要になる。この方法ではどのクリックがコンバージョンに結びついたのかを識別するためにgclid、wbraidやgbraidとセットで送る必要がある。

広告のリンクURLに付いているgclidなどのクリック識別子を引き回すのに基本的にはcookieを使うことになる。そのためcookieレスの方法というわけではない（通常はファーストパーティcookieの範囲内で可能）。

https://developers.google.com/google-ads/api/docs/conversions/enhanceconversions?hl=ja

（参考）「拡張コンバージョン」ではないコンバージョン計測

Googleではcookieを補完する拡張コンバージョンの他に、gclid/wbraid/gbraidを直接指定してコンバージョンを取り込む方法がある。これがGoogle広告のコンバージョンデータのインポート機能である。
gclidを紐づけたクリックに起因するコンバージョンであればインポートすることが可能で、手動アップロードやGoogle広告APIから送ることもできる。この機能では日本では利用できないが、電話問い合わせに起因するコンバージョン（専用電話番号が必要）をアップロードすることもできる。

Salesforce/Zapier/HubSpotのような対応したツールでコンバージョンをインポートすることもできる。

紛らわしいが「インポート機能」は「拡張コンバージョン」とは呼び名が異なるので、言葉を使い分けてほしい。またコンバージョンインポート機能はコンバージョン計測の補完的に使うものではなく、成果対象とするすべてのコンバージョンを取り込むケースもある。

Facebook広告

https://www.facebook.com/business/help/611774685654668

詳細マッチング

Google広告の拡張コンバージョンの「タグを使う方法」に対応するものである。自動詳細マッチングと手動詳細マッチングがある。

自動詳細マッチング（業種によっては使えない）：https://www.facebook.com/business/help/1993001664341800
手動詳細マッチング：https://developers.facebook.com/docs/meta-pixel/advanced/advancedmatching

コンバージョンAPI（CAPI）

Google広告の拡張コンバージョンの「APIを使う方法」に対応するものである。実現方法にはGoogleと同様に対応したツールを使うか、コードを使った直接連携、コンバージョンAPIゲートウェイを使う方法がある。

https://www.facebook.com/business/help/2041148702652965

コンバージョンAPIに対応したツールにはShopifyなどのeコマースで注文をコンバージョン情報として送るもの、TealiumのようなCDP、Zapierのようなワークフローエンジンなどがある。またウェブ上のイベントに限らず、Messenger/Instagram/WhatsAppのメッセージアプリ内で発生したメッセージイベントも計測できるものもある。

ウェブイベント計測：https://www.facebook.com/business/help/260370078559247
メッセージイベント計測：https://www.facebook.com/business/help/1050753706106190

コードを使った直接連携ではコンバージョンAPIを呼び出すプログラムを開発する。開発が必要というハードルの高さがあるが、オフラインコンバージョン連携はこの方法でないと実現できない。

https://developers.facebook.com/docs/marketing-api/conversions-api/

コードを使った直接連携だとハードルが高いが、少しインフラの設定をするだけで開発自体は不要なコンバージョンAPIゲートウェイを使う方法がある。DNS設定が必要なのと、AWSかGCPのいずれかのクラウドを使う点がポイントである。GCPはGoogleタグマネージャーのサーバサイドタグを使う。

法律、媒体のポリシーは順守することが大前提

個人情報保護法における個人データまたは個人関連情報（どちらになるかは広告主側で吟味する必要がある）の第三者提供にあたるため、それに応じた扱いが必要である。外国にある第三者への提供（越境移転）にもあたる。海外向けのサイトの場合は、対象の国や地域の法令（GDPRなど）を順守する必要がある。

また国内法だけでなく、媒体の規約も守らなければならない。

共通IDと同様、多くのケースではユーザの同意が必要になるため、これ単体で広告の効果測定をするのは難しい。あくまでcookieを使った従来のコンバージョン計測を補完するものという位置づけである。あくまでコンバージョン計測のための機能であり、ターゲティングやアドフラウド対策に使うものではない。Google/Facebookに限らず大きな広告プラットフォームにはこのような機能を提供しているものがある。

データクリーンルーム

データクリーンルームはプライバシーの問題を解決したうえで他社とデータを共有して分析を行うサービスの総称である。

共通IDサービスや拡張コンバージョンはユーザの同意を得たうえでPIIを他社と共有する（第三者提供する）ことによって広告配信リストの管理（ターゲティング）やコンバージョン計測をするものであった。

これと同様にメールアドレスのような個人を識別できる変数を使って自社データの顧客Aさんと他社データでの顧客Bさんを個人の単位で紐づけるケースもある。またGoogle広告のAds Data Hubでは携帯電話の広告識別子を使って広告主とGoogleとの間でデータのマッチングを行う。フィンガープリンティングのように複数の変数の組み合わせで自社顧客のAさんと他社顧客のBさんを類推して紐づける（「AとBは地域と端末の種類と生年月日が同じだから同一人物だろう」）こともある。紐づけはデータを共有する企業間で個別に決めたルールに基づいて行う。紐づける際には、PIIを使う場合は当然個人の同意を求めることが前提となる。

自社の保持している顧客リストに対して、他社の保持している顧客リストからマッチするレコードだけを紐づけて取得する（INNER JOIN）。データクリーンルームのテーブルの中には、自社だけしかアクセスできないレコードと他社だけしかアクセスできないレコードが存在することになるため、アクセス権設定も重要になる。

データクリーンルームは主に分析用途になる。共通IDサービスのアウトプットは広告配信そのものであったり、コンバージョンAPIのアウトプットはコンバージョンレポートであったりした。つまり決められた用途のものだったのだが、データクリーンルームのアウトプットは個人を紐づけた結果のテーブルや分析結果のデータという、柔軟な形になる。

Googleの持っているデータと連携するデータクリーンルームにはAds Data Hubというソリューションがある。ただデータクリーンルーム自体のツールというのはあまりなく、企業間のデータ連携アライアンスの中で個別に作ることになる。技術的には既存のDWHで2社間のデータJOINすればいいだけなので、その2社間で同じ種類のクラウドDWHを使っていれば比較的容易に実現できる。

サードパーティcookie以外のトラッキングに関する問題

サードパーティcookieはトラッキングに関する技術の一部に過ぎない。ブラウザのトラッキングに使われる技術は主に以下のものがある。

ファーストパーティcookie（1PC）に関するもの
- クリックスルーコンバージョン計測
- Googleアナリティクスなどの自社ウェブ解析
サードパーティcookie（3PC）に関するもの
- オーディエンスターゲティング
- リマーケティング
- ビュースルーコンバージョン計測
リファラ

それぞれについてプライバシー保護の観点からChromeとWebKitで対策をしている。

Chromeではファーストパーティcookieの有効期限が最長400日になる程度の制限しかしていないが、WebKitでは一部のファーストパーティcookieの挙動を制限する。

JavaScriptで生成されたファーストパーティcookieの有効期限が7日間になる。またトラッカー認定されたドメインからクリックIDがついたリンク経由で流入した場合、そのページでJavaScriptが生成したファーストパーティcookieの有効期限が1日になる。

JavaScriptで生成された、つまりクライアントサイドで生成されたcookieではダメということで、これらを回避するためにWebサーバ側からcookieを生成する対策方法を考える。しかしそのサーバのドメインがCNAMEレコードで割り当てられたもので、そのサイトとは別の親ドメイン（別の所有者）のものである場合（CNAMEクローキング）にはファーストパーティcookieの有効期限が7日になる。またAレコードで割り当てられたドメインであったとしても、ウェブサーバとcookie生成サーバがネットワーク的に遠い位置にある場合（IPv4の場合同一16ビットマスクネットワークにない）は別の所有者とみなされ、同様に有効期限が7日になる。localStorageなど他のストレージの有効期限も同様に7日間になる。

詳細はITPのページを参照

リファラ（参照元）はChromeではすでに別ドメインからの流入のリファラはドメイン単位までになっている。Safariでも同様だが、さらにドメインがトラッカー認定されている場合は親ドメイン単位までになる。つまりサイト外からの流入についてはどのページから来たかはわからず、ドメイン単位までしか知ることができない。