PrivacySandboxとは
3rdPartyCookieを使わないウェブマーケ
3rdPartyCookieが規制されることにより以下のようなウェブマーケティング手法が使われるようになった。
-
ファーストパーティデータの利用
自社内でしか使えない -
プラットフォームの利用
Google,Amazon・・・などプラットフォーム内でしか使えない -
コンテキストマッチの利用
見ているページから、興味・関心や意図といったコンテキストを抽出し、最適な広告配信する方法
サイト内コンテキストはっきりしないと使えない -
他の識別子を利用する
メールアドレス、フィンガープリントなどを利用する。ユーザーの同意が必要
GoogleからはPrivacySandboxが発表されている。
狙いは、ユーザーのオンラインでのプライバシーを保護しながら、
デジタルビジネスの成功につながるツールを企業や開発者に提供すること
PrivacySandboxの経緯
-
2019年8月22日
Cookieが当初の設計を超えて利用されているが、Cookieをブロックしてしまうと代替手段としてよりフィンガープリントのようなより邪悪な方法が利用されてしまう。
広告エコシステムを守りながらプライバシーを向上させたい。 -
2020年1月14日
PrivacySandboxでは、ユーザー、パブリッシャー、広告主のニーズに対応しつつ、
回避策となるツールを開発次第、Chromeの3rdPartyCookieサポートを段階的に廃止する。
PrivacySandboxは2023年のQ4（10月）から段階的に適用し、
2024年9月に3rdPartyCookieを全面廃止予定。
3PCとPrivacySandboxの違い
3PC
広告配信事業者にCookieを送信することで、サーバ側でデータ処理・分析する
PrivacySandbox
ブラウザ側でデータ処理・分析して、ブラウザが結果を広告配信事業者に送信する
PrivacySandboxの主な機能について
TopicsAPI
ブラウザが行動履歴を分析し、ブラウザに興味関心（Topic）を割り当てる。
広告事業者にブラウザからTopicを送信し、広告事業者はTopicをもとに広告配信する。
※デモグラフィック（属性）系のTopicは存在しない。
※W3Cで仕様策定中（ブラウザの標準になるかどうか検討中）。
Topic利用の流れ
- ブラウザベンダーが分類モデルを作成
モデルでは、以下を分類する。
・ドメインをどのTopicに分類するか
・ブラウザをどのTopicに分類するか - ブラウザベンダーがブラウザ（ユーザー）に分類モデルを送信
- 過去1週間の訪問履歴（ドメインのみ）を用いて、分類モデルが毎週5つのTopicIDを割り当て
※個人を特定できてしまう可能性があるため、母数の少ないTopicは割り当てない、としているらしいが詳細は不明。
TopicsAPIを利用した広告配信
- ユーザがサイトにアクセス
- サイトで広告タグ（TopicsAPIを利用してTopicID送信するJS）が発火
- 広告配信事業者にTopicID送信
- 広告配信事業者はTopicIDに合わせた広告選択し、広告配信
TopicsAPIでは、ユーザーを特定できてしまうので
- 最大3つのTopicIDを返す
- 5％nの確率でランダムにTopicを返す
※すべての広告配信事業者がブラウザに割り当てられたすべてのTopicIDを取得できるわけではない
ユーザー側でTopicのブロック、Topic送信のオフができる
ドメインのTopicも確認できる
ProtectedAudienceAPI
リタゲ広告の代替となる
ブラウザにInterestGroup名と広告情報を保存
- ユーザーがアクセス
- 広告タグ（配信事業者へURLなどを送信）発火
- 広告配信事業者DSPがInterestGroupを選択
- ブラウザにInterestGroupが保存される
- ユーザーがサイトにアクセス
- InterestGroupをもとに広告配信
リアルタイムな問い合わせはKey/Value serviceと呼ばれるトラッキングをしないと信頼のあるサーバに行う
今後必要なPrivacySandboxへの準備
- 広告主
自社サイトで誰がどのようにInterestGroupの作成・運用しているか確認。 - メディア
自社サイトがどのTopicになるか確認。
現在は間違っていても修正はできない。今後議論されそう。 - 共通
PrivacySandboxで発生する外部送信は、
電気通信事業法の外部送信に当てはまるため対応は必要。
ユーザに対する、Topic、InterestGroupの許諾も必要になってくる。