はじめに
RTB HouseでHead of Salesを務めています、高橋です。私はリクルートやCriteoなどを経て2018年1月にRTB House Japanに入社し、日本法人の立ち上げから参画しています。
本連載では、約1年半後に迫ったChromeの3rdParty規制への対応策について、公開された資料や各事業者への取材を通じて明らかにしていきます。もちろんGDPRやCCPA、日本での個人情報保護に関する法律の解釈や対応方法は、これから詳細に検討される必要がありますが、先に結論を申し上げますと視界は良好だと思っています。
第1回となる今回は、主にCookieを軸に配信をしていたグローバル企業たちの動きからまとめます。具体的には、GoogleやCriteoといった事業者が推奨する対策方法とその詳細です。なお、これから説明する内容は主にGitHubで議論されているものになります。現時点で日本語での公式アナウンスがされていない情報は、各事業者間でPoC（概念検証）をしているフェーズであり、寄稿執筆時（2020年8月5日現在）以降、情報がアップデートされている可能性があります。気になる方は是非アクセスしてみてください。
そしてプライバシー問題に関する公式な議論はどこで行われているかというと、W3C会議というところです。その議論の中で、これまでの1:1のターゲティングから、1:同じ特徴を共有するユーザーのグループ、つまりユーザーリストに変更することでプライバシーを強化しようと動いています。
Googleらが推奨するTurtledoveとは
本記事で主に紹介する対応方法は、主にGoogleやFacebook、私が勤務しているRTB Houseといった事業者が推奨している「Turtledove」という対応策になります（参照URLはこちら）。Turtledoveとは“Two Uncorrelated Requests, Then Locally-Executed Decision On Victory”の略で、一文でまとめると、「コンテキストデータと個人を特定できる情報（PII）を分離するブラウザAPIソリューション」です。Googleをはじめとする事業者は、入札オークションをサーバーからブラウザ（デバイス）に移行させることを提案しています。これにより、サーバーからブラウザに移行させることでターゲティング精度やプライバシー問題を守ることができるようになります。
このソリューションでは、広告主はユーザーが興味を持っていると思うものに基づいて広告を表示することができますが、ユーザーの閲覧行動に結びつけることはできません。ブラウザは、コンテキストに基づいた広告リクエストと広告主が特定した興味のあるリクエストの2つを互いに分離して送信します。広告ネットワークは、これらの要求に基づいて最終的な入札を行い、ブラウザ内コードを介してユーザーに広告を配信します。
Githubでの議論を読み進めていくと、Turtledoveによる広告配信の仕組みが見えてきます。
