DMPはどのようにCookieデータを収集しているか（オフラインデータ編）

ここまで

これまで２回に渡って、DMPの情報収集のコアであるCookieSyncの紹介と、CookieSyncを使っていかにオンラインデータを収集するかについて見てきました。

さらに突っ込んでオフラインのデータをいかにオンラインに持ち込むか、という点についてみていこうと思います。今回もいつものブログの記事Data Management Part IV: Syncing Offline Data To Your DMPをベースに話を進めていきます。

オンラインデータとオフラインデータの比較

  • オンラインデータは収集が容易な一方で、データの信頼性が乏しい。必ず正しい情報を登録しているわけではない。
  • Cookieをキーにするという性質上、正確にはユーザー情報ではなくブラウザ情報になっている。一つのブラウザを複数の人が利用している可能性や、１人の人が複数のデバイスやブラウザを利用して情報が断片化している可能性もある。また、ユーザーはブラウザのCookieを削除することができるし、Cookieの利用を禁止することも可能である。
  • 一方、商品の購入履歴、ポイントカードの履歴、ホテルや空港の予約履歴、位置情報など、オフラインの情報は信頼性が非常に高い。そのため、オフラインのデータは非常に価値が高いと言われている。

オフラインデータは、データソースとしての信頼性がオンラインデータよりもはるかに高いということですね。

オフラインデータの価値

  • オンラインとオフラインのシステムは異なる仕組みで動いているので単純にマッチングを行うことは困難である。
  • オンライン企業の大半は、プライバシーに対する懸念から明示的には個人を識別可能な情報(Personal-Identifiable Information(PII))を収集しておらず、これは実際の「人」のかわりにCookieを代替している点が表している。
  • オフラインデータの場合「人」を特定した状態のデータのため、オンラインデータで起きる１つのデバイスを複数人で利用しているかもしれない問題はクリアされる。それは、たとえば同じ住所に住んでいても特定の人に対して郵便を送れるようなものである。

つまり、ここではオフラインデータ = 「人」のデータ = PII(Personal-Identifiable Information)、ということでしょう。信頼性の高いデータであるPIIは、マーケターを始めとして書くプレイヤーが喉から手がでるほど欲しいデータの一つだと思います。

で、もう少し話を進めます。結局、いかにしてオフラインの信頼性の高いデータをオンラインでも扱うことを可能にするのか。結論から言うと、ここでもCookieSyncが使われます。オフラインデータをオンラインデータに変換する接点を用意することで、「人」のデータを「Cookie」のデータに変換することが可能になるということです。

オフラインデータをオンラインデータに持ち込むために

  • オンラインとオフラインの接点（PIIを持っていて、CookieSync可能であるポイント）が必要である
  • オンラインデータのCookieIDのように、オフラインデータを統合するためのキーにはemailアドレスが使われることが多い
  • オフラインデータをオンラインデータに移動することはcookieをマッチングすることである

CookieSyncが可能なポイントでCookieSyncを行なっていおいて、データを統合する時にCookieをkeyとしてPIIの情報がわたっていくということですね。また、オフライン同士のデータ統合のkeyにはemailアドレスが使えるというのようです。恐らく氏名や住所、電話番号はdata providerの外部に持ち出せないため、暗号化されたメールアドレスをキーとして利用するのでしょう。

eBayの例

Data Management Part IV: Syncing Offline Data To Your DMPでは、eBayがとあるサービスを終了させるまでは典型的なproviderだったと書いて説明しています。ポイントは２点で、ebayがオンラインサービスと注文管理のシステムの２つがあったため、オフラインデータをオンラインデータに結びつけることが可能であったということです。

  • ebayはオンラインサービスを行なっているのでユーザーにCookieをセットすることができた。
  • ebayは注文管理システムも保有しているので、購入ユーザーに対して氏名や住所といったPIIの登録を求めることが可能であった。
  • 上記２点からCookieに紐付くemailを保有数することが可能だった。
  • Cookieとemailの組みを保有することで、オンラインオフラインを問わずデータの統合が可能になる。
  • Cookie情報はないがPIIを保有しているオフライン企業は、ebayのCookieID/PIIに自社のPIIを紐付けることで、CookieIDを持つことができる。

で、実際ebayはサービスを終了させたわけで、現在データどこがかつてのebayのようなことを行なっているのか、という点に関して、ブログの筆者は以下のように類推しています。

They’re out of the market, but plenty of other companies have the same data
 – any large site with user registration pretty much qualifies. 
I have no idea who is a current source of match data, but I would imagine 
the airline booking sites, large eCommerce sites, and even banks could provide 
the necessary information.

飛行機の予約サイト、大手のeコマースや銀行だと予想しているとのこと。どこもPIIとして信頼度の高いデータを保有しているものですし、納得ですね。他には、Web明細の普及によって、クレジットカード会社や、携帯電話の会社なんかも対象になるのでしょう。

実際にどうやってデータの統合を行うか

ここまで、概論をだらだらと見てきましたが、現実はかなりシンプルなようです。

f:id:rindai87:20140622231108p:plain

登場人物

  • マッチサービス：オフラインデータをオンラインデータに紐付ける。カオスマップで言うところのdata aggregatorやDMPが担う役割と思われる。
  • データプロバイダー：信頼性の高いPII(オフラインデータ)を保有している企業
  • クライアント：データプロバイダほどの信頼性はないが、オフラインデータを保有している企業。オフラインデータのマネタイズを行うためにマッチサービスを利用する
  • ユーザー：データプロバイダーが行なっているサービス(飛行機やホテルの予約、銀行のオンライン取引、ネットショッピング）を利用する人

処理の流れ

  1. マッチサービスとデータプロバイダは契約し、データプロバイダーは、ユーザーがよく訪れるページにマッチサービスのピクセルデータを置く
  2. ユーザーがデータプロバイダーのページを訪れると、マッチサービスへのリクエストが発生。ここで、データプロバイダーとマッチサービス間でCookieの交換を実施
  3. 後ほど、データプロバイダーはPIIの情報を自システム内のCookieIDとともにマッチサービスに送信する。
  4. このデータ提供によって、データプロバイダは収入を得る。
  5. CookieSyncとPIIの収集プロセスを複数のデータプロバイダに対して実施し、ユーザーのPIIを統合させる
  6. マッチサービスは収集したPIIをもとに、多数のクライアントと同様にCookieSyncをベースにしたデータ交換を行う。多数のクライントの情報が集まれば集まるほど、マッチサービスにはよりカバー率の大きなデータができてくる。

この後の流れはCookieSyncと同じです。あるユーザーがすでにマッチサービス側のCookieIDを割り振られている状態でCookieSyncを行うと、どんどん複数のデータソースをつなぎ合わせることができるようになるため、よりユーザーの情報を精緻に見ることが可能にります。かつ、ここでのデータはいわゆるオフラインデータです。また、オフラインデータのキーになるメールアドレスも保有しているため、オフライン側のデータも紐付けようと思えば紐付けられそうですね。あとは、マッチサービスとDMPの間で同様にCookieSyncが行われていれば、DMPまでオフラインデータがたどり着きます。

どのくらいうまくマッチングできているのか

Unfortunately, the overlap between sources tends to be small, 
typically 30 – 40% of the total offline records on a good day.

上記のような記述がある通り、よくて30%-40%ということなので、実際は10%-20%くらいが使い物になるデータのような気がします。adtechの何かのセッションでもCookieデータは全体の20%くらいしか取得できていない、という話もあったので、オーディエンスデータとして整理できているのは全体の約20%程度、実際に解析した結果、使いのものになるのが10%程度、というのが妥当なラインのような気がします。オーディエンスデータといいつつ、あくまでCookieをもとにしているために「人」ではなく「ブラウザ」の情報ですので、この辺が限界なのかもしれません。

まとめ

CookieSyncを利用すれば、オフラインのデータがオンライン(DMP)に持ち込むことが可能だということが分かりました。また、カオスマップで言うところの、data providerやdata aggregatorの役割も具体的に見えてきました。毎度の繰り返しの主張になりますが、技術的に実現可能で、そのデータを欲している、お金にできる、という状況になっているので、やはりこの流れは止めにくい状況でしょう。なかなか裏側は見えてきませんが、セキュアにデータを受け渡すところや、意図せぬところでユーザーが識別されてしまわない配慮など、検討しなければならないことは多岐に渡りそうです。また、個人的には、DMPやマッチサービスがマルチデータソースをシングルデータソースにして扱っていそうなところが、名寄の問題などで一番気になります。プライバシーデータ保護マイニングのようなアプローチが裏で行われているのかどうか、気になりますね。

というわけで、割と駆け足で見てきたDMPがどのようにデータを収集しているかという点ですが、まだこのようにまとまった日本語の記事は世の中に出まわってないと思いますので、是非議論の叩きにしていただければと思います。あと、DMPやdata aggregatorに関する良い感じの情報をお持ちの方は、ぜひ教えていただけるとうれしいですね。

まあここまで来ると「ぼくのかんがえたさいきょうのDMP」とか、「DMP作ったけど何か質問ある？」とか言うエントリを書きたくなるのがエンジニアの性だったりするので、こっそりひっそり何か始めたいなと思う今日この頃です。