AdFraudについて調べてみた話

これは？

なんとなく最近金融のFraudの話に触れる機会が多く、その中でAdFraudという単語が引っかかったので調べてみた話です。参照記事を適当に繋げて意訳しているので、大意としてそもそも違うことになっていたらご指摘ください。

メルセデスベンツ問題

メルセデスベンツによるオンライン広告キャンペーンにおいて、広告が人間以上に自動化されたプログラムに見られていた、ということが報じられて波紋を呼んでいる。

従来から、オンライン広告のFraud(不正表示,不正クリック, etc..)というのは度々問題になっていたが、ナスダックに上場しているRocket Fuelにより実施されたキャンペーンにおいて大規模なFraudが生じていたため、かなりインパクトの大きな問題となっている。

具体的な数値

イギリスのセキュリティー企業Telemetryサンプリングした約365,000のimpressionのうち、57%が自動化されたコンピュータプログラムによる閲覧だった。

なぜ問題が拡大しているのか

  • Ad Fraudの被害額が2014年には$11bnに上る見込みで、これは2013年比で22%の増加であること
  • RTB市場は急速に拡大しており、現在では全ディスプレイ広告の22%を占めており、2018年には76.5%を占める見込みのため

Ad Fraud問題に関しては、Googleも関心が高く、spider.ioというロンドンにあるAd Fraudに特化したスタートアップを買収したことでも有名

AdFraudの各種手法をざっくりと

大別すると、広告表示やクリック効果を偽装することで広告料をだまし取ろうとする行為が多い印象。その行為によって発生するimpressionを買ってしまうことが広告主の不利益に繋がる、というもの。

CrowdSourcing(Cyclops)

依頼され、記事を見て（時には）広告をクリックする集団。ユーザは意識的に不正を行っている認識はない

Incentive Ad Network(Voldemorts)

リワード目当てに広告を閲覧/クリック/コンバージョンする人たち。正しい行為ではないことをうっすらと認識はしている

Click Farms(Zergs)

報酬をもとに広告クリックを行う集団。モバイルデバイスとSIMカードの組み合わせで、様々な偽装をしながらクリックを行う

Computer Malware(VaderBots)

洗練され、見つけるのが困難なMalwareの一種。感染すると、PCにはbot slaveが潜伏し、bot masterと通信を行い、bot masterからの指令に従い、どのサイトでどのようにクリックするかの指示を遂行する。

Sophisticated Fraud (PhantomBots)

一定のアルゴリズムに従って、広告の閲覧、クリックを行う

Retargeting Fraund (DeceptiBots)

例えば、特定のブランドの車を何度も閲覧する、人間のように振る舞うことで、リターゲティングの対象になる。リターゲティングの対象となることで高いCPMを支払う価値あるターゲットと認識させる。

Mobile Simulator (CryptoBots)

PC上で動作し、スマートフォン上のモバイルアプリのように振る舞う。モバイルアプリ内広告の効果を不正に引き上げるために利用される。

Ad Stacking

複数の広告を一つの場所に表示させることで、見えていない広告をカウントさせる

Toolbars

ツールバーによって、ブラウザの動きをコントロールできるため、特定のサーチエンジンを利用するように強制し、ツールバー自身のアンインストールは困難にさせる

Ad Injection

未承認の広告を勝手に注入するソフトウェア

Domain Identity Theft

広告が表示されるドメインを偽る価格で適正価格でのディールが行われないようにする。

こういった問題に関してIABはTraffic of Good Intent Task Force(TOGI)を立ち上げて不正トラフィックへの取り組みを初めている。

メルセデスベンツ問題に対するRocket Fuel側の反論等

メルセデスベンツ側の証言

キャンペーン中、Fraudと疑わしいインプレッションは6%未満だと報告を受けており、RocketFuelからは該当のインプレッション分の払い戻しが行われた。

ここの数値がFinancialTimesの報道と大きく乖離していていたため、大きな注目を集める要因となった。

RocketFuel側の証言

RocketFuel自身も、広告の不正表示に関しては注意を払っており、実績としては平均的に広告表示箇所の約40%がbot判定及びブランドセーフの観点から適切か、という点でリジェクト対象となっている。ということもあり、Telemetryのレポートを100%正しいと核心は持てない、という感じでバチバチやっている。

AdFraud対策の方法論など

と、いうことで、今現在進行形でAdFraudは米国で大きな問題になってきており、この流れで行くと1,2年後には日本にもその流れがやってきそうかな、と。まだ方法論まで踏み込んだところまでキャッチアップできていないですが、例えば、こういった論文も公開されています。

FDMAというAd Fraudに特化したコンペティションが開催されていたようです。

いつもの流れだと1,2年後くらいに流れがやってくるので、今のうちに情報を仕入れておくと差別化要因になるかも？的な感じです。なかなか奥深い。

参考

Ad Engineering Summitというイベントで登壇してきました

f:id:rindai87:20140515182204j:plain

5/15にAESというイベントにて「デジタルマーケティングを支える技術とその未来」というタイトルで発表してきました。当日のスライドの公開などは特に予定していません。

f:id:rindai87:20140518234443j:plain

エンジニアの人も参加しやすいように、と、イベント自体が始まりも終わりも遅い、という少し変わったタイムテーブルで、自分は夜の20:30からのお話してきました。

「Engineering」とイベント名に入ってはいるものの、初回のイベントだったため、オーディエンス層がいまいち掴めず資料作成に苦しんだのはいい思い出です。記憶にあるうちで一番苦しんだかもしれません。とはいえ、登壇後に分かりやすかった、面白かった、などのフィードバックを頂けたので一安心です。

この登壇やイベント参加を通じて、改めて今のアドテクブームやデジタルマーケティングという言葉について考えなおすきっかけになったのが収穫かな、と思っています。「DMP」という言葉はバズワード化しつつも、サービス提供者側はマネタイズ面で苦労していたり、広告主側はうまく活用しきれていなかったり、と理想と現実のギャップはまだまだ大きいな、と感じています。少なくとも広告という文脈だけでデータ活用を行おうとすると結構苦労するんじゃないかなぁ、というのが今の自分の意見だったりします。

情報知財研究会に行ってきた話

何をきっかけに存在を知ったか記憶は定かではないですが、最近の興味関心とばっちりあっている情報通信学会主催の2012年度　第6回情報知財研究会に参加してきました。 大変勉強になったんですが、すんごい眠いし書くのやめようかと思ったけれど、今日書かないと永遠に書かない気がするので、自分への備忘録ということで書き残しておきます。

全体の流れというよりも、自分が勉強になったな、と思った部分をピックアップしてのメモ。なにぶん全然詳しくない分野なので、内容についての正確性は若干あやしいです。

個人情報についての誤解

「個人情報保護法」で言うところの「個人情報」とは、特定個人の識別情報であり、プライバシー情報とは異なる。

まずはこのレベルの認識が曖昧でした。

個人は識別できないが、私生活上の情報や、非公開/公開を望まない情報などがプライバシー情報だということです。PIIくらいの純度の高い個人情報に紐付くIDくらいじゃないと、現行法では個人情報にならないんじゃないかなぁと思って聞いていました。

とはいえ、昨今のO2Oの流れなどがあり、オフラインのPII情報が紐付いて、単にWeb上の情報だけで流通・収集されている段階では個人情報まで行かなくても、オフライン情報（決済情報や住所など）が紐付くことで個人情報になりうる可能性は高そうです。そして、このことをre-identificaitonと表現されていました。

3つの規制

個人情報に関する規制には3つの規制があるそうです。

  • 刑事規制
  • 民事規制
  • 行政規制

刑事規制は秘密漏洩罪、民事規制はプライバシー侵害、行政規制は個人情報保護、という観点での規制となっており、上の方が法的な罪としては重くなっています。

行政規制は、話を聞く限り「注意」、悪くても「罰金」レベルなので、基本的には怒られたら辞める、というスタンスが通用してしまいそうです。

ターゲティング広告やDMPまわりの話なんかはモロにこのあたりの規制対象になりそうですが、実際に広告やマーケティング情報が刑事罰にあたるレベルの情報を扱うことは考えにくいですよね。 民事規制レベルだと、個人が不快に思いそれを訴え出る、というケースがありますが、ターゲティング広告に追いかけまくられたりやDMで狙い撃ちにされて不快に思う人もいますが、よっぱどひどいことにならない限り、なかなか訴えるという手段には出なさそうですし、実情は行政規制のレベルでしか縛りはないのではないかなぁと思いました。

情報の流通に関する個人情報保護法の規制

個人的に今回一番勉強になったな、という部分です。個人を特定可能な情報を持っている企業が、そのデータを第三者に提供するにあたって、個人を特定できない形で渡すことが個人情報保護法の適用範囲かどうかという○☓表が出てきて、それが非常にわかり易かったので再現してみました。

f:id:rindai87:20140713223416p:plain

  • 1番目は明らかにアウト
  • 2番目はCookie情報の提供などがあたりそうですね
  • 3番目がre-identificationに相当する、個人を特定不可能な識別情報が、提供先で他の情報源と組み合わることで個人を特定可能な識別情報になってしまうパターンです。現行法は、こういったことを規制できないようです。
  • 4番目の識別可能情報を識別不可能な状態で提供することは、現在のところ専門家の間でも意見が分かれるところのようです。

やはり気になるのは3番目と4番目の部分で、3番目が感覚的にはグレーなのに大丈夫、というパターンです。 4番目は、一見するとNGにすると厳しくなって産業界的にはよろしくないという印象にもなるけれど、仮にここをOKとしてしまうと、匿名化したデータの漏洩が起こった際に、行政処分の適用範囲としにくくなり、実態の調査などに踏み込めないケースが出てくるとのこと。 積極的にグレーやブラックな方法を選ぶ企業だけが得をしないためにも、一見締め付けに見える規制も必要なんだな、と思いました。

米国、EU、日本の比較

  • 米国は個別規制、プライバシー情報を考慮
  • EUは包括規制、センシティブ情報を考慮
  • 日本は包括規制、特定個人の識別情報のみ考慮

日本は重箱の隅を突っつくように特定個人の識別情報のみに注力してしまい、特にWebの時代では特定個人の識別情報以外にも、UUID、電話番号、ポイントカードのIDなど、特定個人の識別情報ではなくとも取得することで多大な利益を得ることのできる識別情報が多く存在するため、実態とかけ離れた法規制になっているような印象を受けました。

プライバシーインパクト

上で書いてきたことと繋がりますが、結局はこれだな、と。

特定個人を識別できない情報であってもプライバシーの権利を侵害しうることに留意すべき

プライバシーの権利に与える影響を常に意識することが大事だということですね。

まとめ的なものなど

今日の話を聞いて、CCCの問題やトラッキングの問題などに関してなんとなく見えてきたこととしては、感情論と法規制と技術的な部分が混ざり合って「なんかやばそう」感が先行しているんじゃないかなぁと思いました。

  • 法規制としては、そもそもユーザーに同意をとった範囲で色々やるのはOK
  • でも、それがユーザーが真意で同意したかは不明なので、法規制という点と民事的な観点（感情的な部分）はまた別。キモいと思う人にはキモいものだし、コワいと思う人にはコワいもの
  • さらに法規制の範囲で何かやるにしても、そもそも暗号化などの基本的なセキュリティ要件は満たす必要がある

なので、

  • ユーザーには、同意することでどうなるかはっきりと分かるようにする
  • ユーザーの意思で、いつでもデータの収集等を終わらすことができるようにする
  • 平文でデータ送ったりしないとか、基本的なセキュリティ要件はクリアするように心がける。また、セキュリティに配慮していることをユーザーにはっきりと分かるようにする

ということが大事なんじゃないかなと思います。なので、ちゃんと（この辺が微妙なニュアンスになりますが）やれば、DMPやターゲティング広告/O2Oもそこまで問題となるものではない気がしました。現在先行してプロダクトなりサービスをリリースしているところが割とアグレッシブな感じなので、ネガティブな印象がどうしても先にきてしまっている。ここは何とかしたいところですね。

その他

pマークの話や、privacy by designの時代、個人情報保護法2000個問題など盛り沢山で大変勉強になった会でした。

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作ったけど何か質問ある？」とか言うエントリを書きたくなるのがエンジニアの性だったりするので、こっそりひっそり何か始めたいなと思う今日この頃です。

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

CookieSyncとDMP

前回、CookieSyncの技術について簡単に解説しました。CookieSyncを使えば2つの異なるシステム(ドメイン)で発行されるCookie情報を交換することができます。 DMPはこの技術を駆使してCookie情報を収集し、オンラインのデータを次々に紐付けていきます。 今回も前回のブログ記事の続きのこちらとこちらの記事の内容を用いて、DMPがどのようにオンラインのデータを収集しているかを見て行きましょう。

DMPが保有しているデータ

http://www.adopsinsider.com/wp-content/uploads/2011/07/data-management-platform-integration1.jpg

出典：Data Management Part II: Centralize and Synchronize Your User Data

こちらの図が非常に分かりやすいので引用します。図からDMPが2種類のデータを所有していることが分かります。

  1. DMPのCookieIDをkeyにして、他のシステムのCookieIDを管理するマスターテーブル
  2. 他のシステムから送られてくる、そのシステムにおけるCookieIDをkeyにした行動ログや属性情報など

1.Cookieの管理テーブル

CookieSyncを行なって、DMPと他システム間のCookieSyncを繰り返すことで、DMPにはDMPCookieID：OtherSystem1CookieID, DMPCookieID:OtherSystem2CookieIDというデータが集まってきます。なので、後はこれを同一DMPCookieIDでまとめてしまえば、DMPCookieIDをkeyにしたCookieのマスターテーブルのようなものが作れてしまいます。

2.他システムにおけるデータ

Cookieの管理テーブルが用意できていれば、後は別途CookieIDをkeyにしたデータを送ることによって、DMPはDMPのCookieIDでユーザー(ブラウザ)を特定した状態でデータを管理することができます。

3.DMPからのデータの引き方

※この項目は当該ブログ記事に明記されていなかったので推測になります。

DMPと連携しているシステムからは、CookieSync済みのDMPCookieIDをkeyとして問い合わせることで、DMPで収集している様々なデータを取得可能になります。 これによって自システム以外のオンライン上の広大な空間でのユーザー(ブラウザ)の行動情報を取得可能になります。

では実際にどのようにデータを収集しているか

http://www.adopsinsider.com/wp-content/uploads/2011/07/data-management-platform-redirect-process.jpg

出典：Data Management Part III: Syncing Online Data to a Data Management Platform

こちらの図が大変わかり易いので引用して説明します。以下の箇条書きの数字は図の番号と対応しています。

  1. ユーザーがサイトを訪れ、ページのHTMLをリクエストする
  2. コンテンツサーバーはユーザーにページを返す。そのページには、DMPのコンテナタグ含まれている
  3. ページの残りがローディングされている間に、コンテナタグはブラウザに強制的にDMPを呼び出させる
  4. 呼び出されたDMPは管理しているタグを返す。このタイミングでDMPのCookieがユーザーにセットされる。（タグを返すと書いたがイメージで、実際はCookieSyncの技術と同じく1x1pixel画像を利用したリダイレクト）
  5. ユーザーはDMPから返された情報にしたがって、各種システムにリダイレクトさせられる。このタイミングでユーザーには各システムのCookieがセットされる
  6. 各システムのCookieのセットと同時にDMPへのコールバックも行う。そのコールバックには、URLに各システムにおけるCookieID(ブログ記事本文ではUniqueIDと書いているがCookieIDのことでしょう)が付与された状態で行われる。IDは暗号化されているのが望ましい。
  7. DMPはその情報を受け取り、DMPのCookieIDと照合した上で保存する。
  8. CookieIDの交換が完了さえしていれば、後は非同期にCookieIDとそれに紐付くデータをDMPが取得すれば、データベースの構築が完了する

このあと、DMPは独自にデータの分析を行います。どのようなデータを収集しているかと合わせて、この分析がDMP同士の差別化ポイントだったりするのでしょう。それはともかく、このような流れで溜め込まれたデータを、必要に応じてDataExchangeに流通させたり、DSPやアドサーバーに提供していきます。ここがDMPのマネタイズポイントですね。

DMPがタグマネジメント機能を提供することで、様々なシステムとCookieSyncを実現しているのが理解できます。先にシステム間のCookieIDの交換が完了していると、実際のデータは後から任意のタイミングでDMPに投入すれば良さそうです。できるだけユーザー体験を阻害しないような配慮ですね。

Cookie交換のところのセキュリティに関しては、IDの暗号化をエクスキューズにしているようです。この当たりはまた突っ込んで考えていきたいと思います。

まとめ

私は実際のDMPのシステムに触れたことはないので、情報の参照元にしたブログ記事の正確性がどの程度現実に即しているのかは不明ですが、技術的には実現可能そうなので、大きく外れてはいなさそうですね。

DMPについて理解が深まってくると、とにかくユーザーの情報が欲しいマーケッターやターゲティングに活用したい広告業者にとってはぜひ欲しいシステムなんだろうなと納得できます。かつて、Googleを始めとする一部のプラットフォーマー以外が、ここまでの規模でユーザーの情報を取得できたことはないはずなので、やはり様々な業界で大きなパラダイムシフトをもたらしそうな期待感は高まります。一方で、技術者としてはセキュリティ大丈夫なのかなーと思ったりしますし、ユーザーとしてはどこまでどんな情報収集してるのよ、という不安感が出てきたりします。色々とセンシティブな領域ではありますが、技術的にもビジネス的にもチャレンジングかつ面白い分野なので、ビジネスサイドによる需要ドリブンでの盛り上がりだけでなく、多くの人を巻き込んで良い感じに進んで行ってほしいものです。

さて、タイトルから類推できそうですが、次はオフライン編について触れようかと思います。どんどん危険な匂いが増していきますね！

おまけ

CookieSyncやDMPに関しては、今現在、日本語での技術的な情報源が少ないですが、以下のものが非常に良い感じで参考になります。あわせて読むと理解が深まるはずです。

ScaleOutさんの情報発信力はさすがですね。

DMPはどのようにCookieデータを収集しているか（CookieSync編）

DMPがどのようにCookieデータを収集しているかについて、ある程度知識が固まってきたのでまとめようと思います。まずはDMPのデータ収集の肝であるCookieSyncについて数回に分けて書いていこうと思います。

DMPの役割とは

こちらにも書いた通り、DMP自体にはデータを解析するだけでなく様々な役割があります。データの分析/解析だけでなく、データを収集するところにも関わっているということを念頭に置くと理解が深まります。

DMPが集めるデータと収集方法

DMPはブラウザのCookie情報を収集し整理し、利用しやすい形で提供しています。収集にはCookieSyncという技術が用いられています。

CookieSync概要

このあとCookieSyncの実例をあげますが、まずは基本的なCookieSyncの流れの説明をします。CookieSyncは外部のサーバーに対して1pixelの画像のロードを行うことで実現します。

  1. Webサイトにタグを埋め込みます。
  2. Webサイトを訪れたユーザーには、WebサイトのCookieが発行されます。
  3. Webサイトに埋め込まれたタグによって画像をロードしようと外部のサーバーにリクエストを送ります。
  4. そのリクエストは、WebサイトにおけるCookie IDをクエリストリングに付与されています
  5. 外部サーバーはクエリストリングの情報によってWebサイトにおけるあるユーザーのCookie IDを知ることができます。
  6. またそのリクエストに対して、外部サーバーにおけるCookieを発行します。
  7. これによって、2つの異なるシステムにおけるCookie IDを交換することができました。

これは実例があった方が理解が深まりますので、まずはこちらで紹介されているSSP-DSP間のCookieSyncについて見て行きましょう。

SSPとDSP間のCookieSync

こちらに書かれているものをまとめたものになります。ユースケースとして、DSPの出稿主であるあるショッピングサイトが、自社のショッピングサイトで商品をカートに入れるまで進んだユーザーに対してターゲティングを行いたい、という状況です。

登場人物

  • ショッピングサイト：storeABC, DSPを利用している
  • webサイト：awesomesite.com, SSPを利用している
  • ユーザー：user123
  • DSP：DSP456
  • SSP：SSP123

ケーススタディ

文字だけではわかりにくいので簡単な図も書いてみました。

f:id:rindai87:20140622224646p:plain

  1. user123がstoreABCを訪れる。150$の靴をカートに入れるも離脱
  2. user123はカートのページにはDSP456へ1pixelの画像を取得してにいくタグを仕込んでいた。なので、user123はDSP456のCookieID=DSPcookie789が発行されている。
  3. user123はネットサーフィンを行なっていて、awesomesite.comにたどり着く。awesomesite.comはSSPを利用している
  4. awesomesite.comでも、SSPへのリダイレクトを行わせるのでuser123には、SSP123のCookieID=SSPcookiexyzが発行されている。
  5. 今user123は、DSPとSSPの双方のCookie情報を保有している

ここまでで、user123にはSSPとDSPのCookie情報が保存されていることになります。これをどう交換するのか、が次のポイントです。ここでもう一度目的のおさらい、「DSPはいかにしてSSPからのbidリクエストから自分たちの保有しているCookie情報にマッチするユーザーを探すのか」です。 結論から言うと、初めてのbidでは不可能です。SSPだけがユーザーの情報(とSSPで管理するためのCookie情報)を持っています。CookieSyncは競売が終了した後に発生します。

  1. SSP123が競売に勝利するDSPを選択した後、SSP123はuser123をDSPに(DSP456を含む)にユーザーをリダイレクトさせます。クエリストリングにSSP123のCookieID=SSPcookieXYZを付与したリダイレクトです。
  2. なんとここでSSPcookieXYZをクエリストリングに持ってやってきたuser123がDSP456のcookieID=DSPcookie789を持っているではないですか
  3. こうして、SSPCookieXYZ=DSPCookie789は同一ユーザーのものと分かり、DSPはその情報をDBに保存しておきます。
  4. すると次にSSPCookieXYXのbidリクエストがきた時には、user123からのリクエストだということが分かるようになります。

CookieSyncのポイントはオークション終了後に実施することで、UXの低下を防ぐという工夫を行なっています。CookieSyncの実例としてPubmetricなどの主要なSSPが行なっているスクリプト例があげられています。確かにvcodeという名前でCookieIDっぽいものがパラメータとして付与されているっぽいですね。。。

まとめ

クエリストリングにCookieIDを載せてやりとりを行っているあたり、セキュリティ的にどうなんだという気もしますが、現状ではCookieデータの収集にはこのような技術が使われているようです。

DMPについて調べたまとめ（概要編）

個人的にDMPがあってダラダラと調べていて、そろそろまとめておかないと色々と忘れていきそうな危機感を感じたのでまとめます。

3行で語るDMPのお仕事

  • データを収集することで、パブリッシャーの収入源となる
  • データを解析することで、広告主の投資の最適化・投資効果の最適化に寄与する
  • DMPで扱うデータは基本的にCookieデータである

adtechにおける立ち位置

  • 配信を担うアドサーバーやDSPではカバーしきれないオーディエンスデータの整理や、オーディエンスデータの活用など

DMPに必要な要素とか機能とか

  • アドサーバーとの連携。アドサーバー利用者から見ると、外部の機能と言うよりは内部の機能に感じるくらい密接にインテグされている方が望ましい
  • データの収集。1pixelのロードを行なって、DMPにCookieデータを集めてくる。DMP単独でカバーはできない部分もあるため、外部からデータ(Cookieなど何らかのかたちでユーザーを一意に特定できる情報をkeyにした情報)を購入する。
  • データの解析。集めた膨大なCookieデータを分類し、活用しやすい形でクライアント（データ提供元のパブリッシャーや配信業者、広告主）に提供する。

データ解析という意味での仕事

  • ブラウジングの行動履歴ベースでの解析を行なってデータセグメントを作る
  • 各セグメント毎に最適なクリエイティブ調査や、その他情報との重ね合わせによりimpressionやclickに対する理解を推し進めるような解析を行う
  • コンバージョンデータが取得可能であれば、そのコンバージョンに至る経路も含めてデータの解析を行う

データ収集という意味での仕事

  • タグを貼って、ピクセルデータのロードを行うことでリアルタムにデータを収集する
  • cookieIDのsyncだけ先に行なっておいて、ファイルベースで後からデータは結合する方法もある
  • データの結合自体は基本的にCookieベースで行う。一部ハッシュ化されたemailなどを使う場合もあるが、結合できるシーンがそもそも少ない。DMPがどうやってデータを収集しているかはこの辺でまとめられている。

データ収集の仕組みはまた機会があればこちらにまとめるかもしれません。

データ活用という意味での仕事

  • DMP自体は様々なパブリッシャーやアドサーバーと連携しているが、一方でデータ活用自体にはDMP側でパーミッションをコントロールすることもできる
  • 例えばAというパブリッシャーはBというアドサーバーにはデータを提供したくないとか。極論すると、AというパブリッシャーはDMPにデータ解析までしかお願いしたくない場合、どこにもデータを公開しないという道もありそう

まとめ

DMPには、cookie情報の収集・cookie情報の結合・cookie情報の解析・解析情報の提供まで幅広く役割があるみたいですね。本来は配信とは独立しているもののようですが、日本ではいわゆるDMP的なことを単独で事業にしている例はなさそうです。xrostなどのDMP＋配信事業(DSP/SSP等)を行なっている例はありそうです(中身を知っているわけではないので例として適切なのかはわかりませんが...）。 今後日本の市場として、配信とは切り離されたところでのDMPが出てくるかどうかですが、プライバシーやセキュリティに対するルール/感覚が米国とは異なるため、必ずしも同じ形に進化していくわけではないと思われます。米国でも、今のCookie偏重のデータ収集/活用の流れはよろしくないという動きが出てきているようなので、DMP自体がどうなっていくのかも楽しみです。やはり、データ分析/活用に興味のある人間としては、DMPの動向はアドテクの中で一番興味をひかれる分野ですね。