サードパーティーCookieに代わる広告の仕組みとして開発が進められているGoogleのAPI「FLoC」は、OracleやVivaldi、電子フロンティア財団などからその内容が批判されています。なぜGoogleがFLoCを開発しようとしているのかや、実際にFLoCはどのような技術なのかという、その仕組みをエンジニアの大津繁樹氏が解説しています。
◆なぜFLoCが開発されているのか？
FLoCは、規制対象となっているサードパーティーCookieの代わりとなる、新しい広告の仕組みの1つをいいます。
既存のデジタル広告は、インターネットにおけるユーザーの行動を広範に追跡し、ブラウジング履歴などから属性・所在地・興味・関心を割り出して、それらの情報を基に広告を表示する「行動ターゲティング」という手法を用いています。この行動ターゲティングを行う上で必要不可欠なのが、サードパーティーCookieです。
しかし、上記のような手法はユーザーのプライバシーを侵害することから、近年、サードパーティーCookieは規制対象となっています。このため、世界最大の広告企業としてサードパーティーCookieを中心に据えた広告システムを構築してきたGoogleは、新たに、サードパーティーCookieを利用しない仕組みを構築する必要性に迫られました。
この新しい広告の仕組みを提案・開発・実験しているのが、プライバシーサンドボックスです。プライバシーサンドボックスでGoogleは、サードパーティーCookieを利用しないことに加え、フィンガープリントといった個人の特定につながる技術を利用したり、個人の追跡を行ったりしないことを明言しています。
プライバシーサンドボックスではこれまでに複数の提案が行われてきましたが、FLoCは新しい仕組みとして有望なAPIだと考えられ、Chrome 89からテストが行われています。
◆FLoCとは？
FLoCはFederated Learning of Cohorts(連合学習のコホート)の略ですが、Chrome 89のオリジントライアルの中では、連合学習は利用されていないとのこと
2021年5月時点ではChrome 2.1版のFLoCでテストが行われていますが、このFLoCについての技術は以下の通り。なお、FLoCはまだ開発中であり、今後、これらの技術は変更されていく可能性があるとのことです。
◆FLoCの技術の詳細はこんな感じ
簡単に説明すると、FLoCはユーザーを数千人単位のグループ(コホート)にわけて、コホートIDを割り当てるというもの。一般的に、デジタル広告は以下3つの情報を組み合わせて表示されますが、FLoCは(2)のために利用されます。
(1)ファーストパーティーCookieおよびコンテンツの情報
(2)何に興味を持つ人が広告を見るかといった一般的な情報
(3)ユーザーの取った特定の行動
サードパーティーCookieを利用したデジタル広告の場合、ユーザー個人の行動や情報を第三者企業が知り、分析やターゲティングに利用することができます。しかし、FLoCではユーザーの閲覧行動をブラウザ内の処理で数値化し、それを数千人単位のグループにまとめた状態で行動ターゲティングに利用するため、第三者企業がユーザー個人の情報にアクセスすることはありません。この方法であれば、今よりもユーザーのプライバシーに配慮し、かつ既存のシステムと同様に行動ターゲティングの効果を上げることができると考えられています。
大津氏はChromeのFLoCアルゴリズムをGoに移植したFLoC Simulatorを作成。FLoCの処理を以下のようにまとめています。
FLoCとはなにか – ぼちぼち日記
https://jovi0608.hatenablog.com/entry/2021/05/06/160046
GitHub – shigeki/floc_simulator: FLoC Simulator
https://github.com/shigeki/floc_simulator
FLoCの処理は大きく分けて、以下の4つから構成されているとのこと。
1．navigation時にFLoC対象のページ履歴にフラグを付ける
2．7日間に一回、履歴からSimHashを計算し、Chrome SyncでGoogle側に送る
3．(FLoCバージョンで1回実施) Google側でユーザのSimHashをまとめ上げてクラスター化する。ブロックするCohort Idを特定し、クラスターファイルを生成し、全Chromeユーザーへ配布する
4．サイトのFLoC APIの実行に伴い、SimHashとクラスターデータから Cohort Id を計算し、出力する
図にするとこんな感じ。
1：navigation時にFLoC対象のページ履歴にフラグを付ける
FLoCはユーザーが訪れた全てのウェブページをもとにユーザーコホートを作成するわけではなく、ウェブページが以下3つの条件すべてを満たした場合に、ユーザーの閲覧履歴にあるウェブページにフラグをつけて計算対象にします。
1．navigation の IP がPublicルーティング可能であること
2．メインドキュメントの permission policy がFLoCを許可していること
3．広告が表示されているページ、又は FLoC API (document.interestCohort()) が実行されているページであること
特に「1」は、プライベートIPを持つ内部Proxyを経由してインターネットアクセスがあった場合、FLoCの対象外となる可能性があることを示しています。また、GitHubやWordPressといったウェブサービスはFLoCをブロックすることを表明しており、全てのウェブサイトにおいて行動ターゲティングが可能になるわけではない模様。
そして、フラグがつけられたウェブページのドメインが、 SimHash値に変換されます。
2： 7日間に一回、履歴からSimHashを計算し、Chrome SyncでGoogle側に送る
SimHashは、似ているデータを近いハッシュ値に変換するLSHの一種です。SimHashを使うと、ブラウザの閲覧履歴に並ぶドメイン情報がランダムな数字に変換され、かつ傾向の近いドメイン群は近似値になります。またSimHashは膨大なユーザーデータを一定の小さなサイズに変換できるというメリットも持ちます。
さらに細かくいうと、SimHashはいくつかのランダムなベクトルを用意し、ユーザーデータとランダムベクトルとの角度の関連性から、データの類似性を導きだし、低ベクトルにサイズを減らします。
例えば以下の場合、左図ではUserAもUserBも赤い波線上部のエリア(1のエリア)に位置するのでSimHash=1となります。中央図では、UserA・UserBともに赤い波線における1のエリアかつ緑の波線の0のエリアに位置するのでSimHash=10、右図ではUserA・UserBともに赤い波線と緑の波線における位置は同じですが、青い波線に対してはそれぞれ0・1という異なる位置にあるため、UserAはSimHash=100、UserBはSimHash=101となるわけです。このように表現することで、ユーザーの閲覧履歴という情報を、1～3bitという小さいサイズで表示することが可能になります。
FLoCでは、50個のランダムベクターを使い、ユーザ履歴の情報を50bitのSimHashに変換させるとのこと。
ユーザー履歴の情報をSimHashに変換したとしても、同じSimHashを持つユーザーが少ない場合、個人が特定される恐れがあります。また、センシティブなカテゴリーの割合が多いユーザー履歴では、センシティブな情報に偏ったコホートIDが生成されてしまうという問題もあります。
このためFLoCでは、ユーザ履歴やプロファイルなどをGoogleアカウントと一緒に同期するChrome Syncの仕組みを利用して、SimHash値をGoogleサーバーに送り、グループ化(クラスター化)させます。
3： Google側でユーザのSimHashをまとめ上げてクラスター化する
グループ化 の際、Google側の処理は、以下2つに分けられるとのこと。
1．ユーザから送られたSimHash値をソートし、2000人以上のユーザを含むようにSimHash群に分割する。SimHashの分割群に対して小さい順にIdを割り振りCohort Idとする。
2．Cohort Id 内に含まれるドメインを洗い出し、「経済状況」や「アイデンティティ」といったセンシティブなカテゴリーを含む割合が平均より10%以上大きければそのCohort Idに対して blocked のフラグを付ける。
つまり、記事作成時点ではSimHashを集めてソートして分割しているだけなので、機械学習(教師あり学習)を利用していません。このためFLoCは「Federated Learning of Cohorts」の略称ではあるものの、「Federated Learning(連合学習)」は行われていないという理解になります。
そしてGoogleが以下のように、ソート・分割したSimHash群と、コホートIDの対応表を作成し、このデータがクラスターファイルとして全Chromeユーザーへ配布されます。
4：サイトのFLoC APIの実行に伴い、SimHashとクラスターデータから Cohort Id を計算し、出力する
クラスターファイルを配布されたユーザーのブラウザは、自身のSimHash値と上記の対応表を照らし合わせて、コホートIDを計算します。そして広告が表示されるウェブサイトでFLoC APIが実行されると、ブラウザのコホートIDを提供します。
コホートIDは上記の通りユーザーの閲覧履歴に基づく興味・関心をベースとしているので、コホートIDに基づいて表示される広告は、ウェブサイトのコンテンツそのものとの関連性ではなく、過去に訪れたウェブサイトとの関連性が高くなり、広告パフォーマンスを高めることができると考えられているわけです。
以下の広告媒体資料のパスワードを入手するにはここをクリック分かりづらい広告・アドテク・マーケティング用語の解説ページはここから
