ポストサードパーティcookie時代のトラッキング技術とプライバシー

Googleは2023年第3四半期のChromeのサードパーティcookie廃止に向けて動いている。これは当初の2022年の廃止予定から延期されたわけだがサードパーティcookieの廃止が決まっているということは揺らぎない。サードパーティcookieを使えなくするだけでは単に不便になるだけ、特に広告配信などが立ちいかなくなることから、Googleはプライバシーを考慮したうえでこれまでと同様のことを実現するさまざまな技術をChromeに搭載しようとしている。

この取り組みを総称してPrivacy Sandboxという。Privacy Sandboxを構成する各技術要素へのリンクは以下のページにある。

https://developer.chrome.com/docs/privacy-sandbox/

Privacy Sandboxで何ができるの?

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

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

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

アドフラウド検知:Trust Token API

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

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

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

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

この機能はOrigin Trialsで検証中。

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

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

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

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

https://github.com/jkarlin/topics/blob/main/taxonomy_v1.md

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

Topicsの挙動としては過去3週間の履歴に基づいて毎週1個(合計3個)ずつそれっぽいカテゴリを選択して返してくるが、5%はランダムなトピックを返す。直近3週間で当該トピックに関するサイトをそのユーザが訪問したことを観測した呼び出し元だけがトピック情報を受け取れる。分類の際にはURLのフルパスではなくホスト名だけが使われる。

https://github.com/jkarlin/topics/

オーディエンスリストを作って入札を行う:FLEDGE

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

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

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

インタレストグループ

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

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

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

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

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

ユーザが広告主サイトを訪問すると、広告主が使っているDSPまたは広告主自身のスクリプトによって、ブラウザでインタレストグループを追加する処理が行われる。

ユーザが広告を表示する媒体サイトを訪問すると、媒体サイトが使っているSSPかまたは媒体サイト自身のスクリプトによって、ブラウザ内で広告のオークションが行われる。オークションはそのブラウザが持つすべてのインタレストグループに対して行われる。

オークション中には、FLEDGE仕様で信頼されたサーバを通じて媒体と広告主の間で広告の表示可否を決めるのに必要なリアルタイムのデータ(クリエイティブ情報や予算など)のやり取りが行われる。

広告が表示され、オークション結果がレポートに送られる。クリックが発生したらクリック情報がレポートに送られる

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

https://developer.chrome.com/blog/fledge-api/

現時点ではfeature flagsで有効化した場合にこのAPIを使える。Origin Trialsでのリリースの時期は未定。

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

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

Attribution Reporting APIはcookieを使わずに広告のクリックや表示の成果を計測するAPI。大きく4つの機能が含まれる

  • イベントレベルレポート
  • 集計可能レポート
  • アプリでの広告接触からウェブに遷移して発生したコンバージョンのレポート
  • クロスデバイスコンバージョンレポート

イベントレベルレポート

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

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

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

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

広告主サイト側でコンバージョンピクセルのタグに先と同様の属性(attributionstc)にコンバージョン計測用のメタデータをやり取りするサーバの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

イベントレベルレポートと集計レポートは現在開発中(一時期リリースされた関連APIは古いもので、現在変更開発中)で、後半2つはまだ構想段階。

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では現在広告の表示と成果計測が不完全なデータになっており、今後もそれが続く可能性が高いのである。

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

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

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

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

Chromeではファーストパーティcookieの挙動は制限していないが、WebKitでは一部のファーストパーティcookieの挙動を制限する。

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

JavaScriptで生成された、つまりクライアントサイドで生成されたcookieではダメということで、これらを回避するためにWebサーバ側からcookieを生成する対策方法を考える。しかしそのサーバのドメインがCNAMEレコードで割り当てられたもので、そのサイトとは別の親ドメインのものである場合(CNAMEクローキング)にはファーストパーティcookieの有効期限が7日になる。localStorageなど他のストレージの有効期限も同様に7日間になる。

詳細はITPのページを参照

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

ChromeとSafariのプライバシー/トラッキング対策まとめ

大きく2種類のブラウザがあり、3種類のトラッキング技術がある。これらをまとめると以下の図になる。

FPC=ファーストパーティcookie/TPC=サードパーティcookie

ITP、Privacy Sandboxというキーワードの位置づけはここになる。これを並べ替えてトラッキング技術ごとにまとめたのがこちら。サードパーティcookieが軒並み×になっているのがわかるだろう。

対策はそれぞれについて考える必要がある。

[公開日:2021年3月1日] [更新日:2022年2月4日]

計測実装 の記事一覧