adtech周辺に興味がある人の四方山話

adtech, marketing, data analysis, etc...

第1回渋谷アドテク勉強会を開催します

タイトルの通り、アドテクノロジー/デジタルマーケティングの勉強会を開催します。

僕自身はアドテクどっぷりなお仕事をしているわけではないですが、このブログではアドテクノロジーやデジタルマーケティング面白いなーと追いかけてきた記録を残していました。 で、最近、僕の隣の席とか向かいの席にDSP案件に関わっている方が増えてきて、いよいよ弊社もアドテクノロジーですね、ということで「乗るしかない、このビッグウェーブに！」状態に突入したため、勢い余って勉強会を開催しようと思います。

ちょっとだけそれらしいことを言う

僕はエンジニアなので、アドテク界隈のプレスリリースでドヤ！という感じ対して、裏側ってどうやって実現しているんだろうなーという気持ちでいっぱいでした。多くのエンジニアも「謎」の部分が多いのが広告のシステムで、最近妙に盛り上がってる分野だ、くらいのノリな気がします。すごい面白そうなんですけどね。一方で、web広告の企画・営業の方と話す機会も最近増えてきていて、そういう方は技術の部分は興味があるけどなかなか勉強する機会がない、という感じの方が多い印象です。

個人的な意見なのですが、アドテクノロジー/デジタルマーケティングは、技術と企画/営業が一体になれるとすごく力を発揮できる分野だと思うんですよね。開発者が売り方まで考えて作るとか、営業がこういうことしたいからこういうシステムできないの、とか、そういう関係です。

そういうことをモヤモヤと思ってて、Facebookにつぶやいたら、予想以上に反応を頂いたので、ああ、これは勉強会やるしかないなー、と思いました。さらに、AmoAdの加藤さんに色々と相談させてもらって、幸いにも2名の方にお話頂くことを了承いただき、なんとか開催の目処が立ちました。

というわけで

第1回渋谷アドテク勉強会を開催します。新卒研修とドンピシャにかぶってしまって、大きな会場は確保できませんでしたが、まずは参加者の反応等も見るという点で50人規模の勉強会としてスタートします。

今後の方向性は不明ですが、RTBよろしく、みなさんの反応を見つつPDCAサイクルを回して、参加者の皆さんにとって有益な勉強会になればいいなぁと思っています。アドテクの勉強会だから食べ物/飲み物/会場を協賛してくださった会社には広告タイムを用意するとか、それらしいことを考えましたが、今回は時間切れということでまた次回以降になんか企画しようと思います。

あと、得てして勉強会はスピーカーが不足するという鉄則もあり（今回も後1枠を調整中）、で、何か喋りたいという方は、僕にお声がけをお願いします！

QuoraでのDMPに関する質問をあさってみた

DMPの仕組みについてはだいたい妄想と気合で補完できるようになってきたのでだいたい一段落してきましたが、一方でビジネスモデルについては依然としてはっきりしていません。なので、深夜のテンションにまかせてQuoraを漁りまくったところ、色々と情報が見つかったのでまとめてみます。

DMPってそもそもなによ？的な質問

  • What is the market size for Data Management Platform
    • 具体的な数字が出てくるわけではない
    • Adobe, Krux, Bluekai, Lotameなど本当のDMPは数少ない
    • AudienceScienceなどのみせかけのDMP(DMP専業じゃないってこと？)もいくつかあり、DSPやタグマネジメントなどが主たる事業となっている
    • 月間100万ユーザーに満たなくてもデータをDMPに売ればコストが発生せずに価値が生まれるので、企業がためらう理由がなくどんどん進んでいくだろうね

Audience Targetingの平均的なCPMってどれくらいよ？的な質問

LotameとかeXelateなんかのDMPのコストはおいくらよ？的な質問

  • How much does a DMP like Lotame or Exelate cost? Assuming I’m a 10M unique visitor per month website editor
    • Lotameのディレクターが答えている
    • DMPを使って作られたオーディエンスをターゲットとするimpressionはCPMベースのプライシングである。Webサイトのボリュームによるが最低$5000のコストでいける。
    • Lotameのディレクターとは別の人が答えていて、よくあるのは媒体がデータをDMPやDataExcahngeに提供した時には50%のレベシェア
      • DMPからデータを買った広告主に対するデータのコストはCPMの20%

DMP使ったことある人は各社のいいとこ悪いところを教えてよ？という質問

Bluekaiのお値段っていくらよ？的な質問

  • How does Bluekai price its data?
    • Bluekaiは”stamps”かCPM毎の値段のプライシング
    • stampの値段は様々どんなデータかで変わる。典型的にはトータルのCPMの15%～20%
    • Ad Exchangeでは固定CPMでデータを提供している。

Bluekaiの競合はどこよ？的な質問

marketplaceというデータ売り買いするビジネスモデルってどんなんよ？的な質問

BluekaiとかeXelateのビジネスモデルってどんなんよ？的な質問

上記の質問をみていて補足的に調べた事

Bluekaiのstampについて

Bluekaiについての日本語の記事

パーソナルデータに関するビジネスモデルの話（おまけ）

Quoraもいいけど、IABのDMP白書もね(おまけ2)

まとめ

記事の間を補完すると、媒体がデータ提供して、DMPがDSPとかにデータ売るときのビジネスモデルが想像出来そうな感じがしますね。Quora++。ただ、個人的には、経産省のスライドが一番おもしろかったです。一読の価値ありですね。

データビジネスの今後について考えてみた

4月に入ってから各社がDMPに関係するプレスリリースラッシュとなっていて、個人的には一気にDMPを始めとするデジタルマーケティング業界が盛り上がってきている感じがあります。

各社まさに、乗るしかない！このビッグウェーブに！！状態な感じが伺えます。

少しタイミングはズレていますがFacebookもCustom Audienceという外部オーディエンスをFacebookに取り込むサービスや、Lookalike Audienceという取り込んだオーディエンスを拡張するようなサービスを提供しています。

2013年はDMP始動の年だ、という予言がまさに実現に近づきつつあるのでしょうか？

そして、先日、このDMPラッシュの集大成とも言えそうな大変濃密かつ重厚な対談記事が出ました。この記事、めちゃくちゃおもしろい。DSP/DMPの本を書き、業界関係者必読ブログを書いてらっしゃるような、まさに業界のトップとも言える人が、先進的な事を発信し続けているのは大変素晴らしいし、ワクワクするなぁと思っています。

なのですが。。。やはり今の流れでは、本当の意味でのデータビジネスは広がりにくいのかなぁと考えています。とはいえ、明確にこうだ、というのがあるわけではなく、なんとなくモヤモヤしている状態です。 先日、同僚であるところの@ritouさんと話していて少し腹落ちできた部分もあるので、つらつらと書いてみます。

はじめに

僕は、いわゆるIdentity系と言われる、広告業界の方から見ると声が大きいと感じてしまう人たちと関わることもあれば、広告のお仕事をする機会も多いです。広告系の方は炎上が起きるかもしれないことを「なんとなく」恐れていますし、一方でIdentity系の人は「なんとなく」広告系は好きじゃない(はっきりとした理由があることも多いです)、という構図ができています。

それぞれの「なんとなく」を明確にするために、私見ですが考え方をまとめてみました。

広告系の人たち

  • もちろんプライバシーや個人情報にはしっかり配慮したい
  • が、実際にその辺の線引がよく分からない。明確なルールがない
  • 個人に紐づくID的なものをマスクしていれば個人情報にあたらないよね？だからその範囲で使えるデータはどんどん使っていきたい
  • アドテク/デジタルマーケティングの時代が来る。もっとデータを使ったビジネスを展開していきたい
  • でも、炎上は怖い。そして、Identity系の人には何かやるとすぐ怒られて一気に炎上しちゃうイメージ

Identity系の人たち

  • 個人の情報は個人の意思で適切に管理されるべき
  • データ保持者の同意のもと、同意した範囲の情報が他システムに適切なルールで提供されるのは問題ない
  • 適切なルールと仕組みのもとであれば、むしろそういったデータ連携の動きは積極的に進めてもいいのではないか
  • 広告系の人が何をやっているのかよく分からない

溝は深そうですね

双方の考えは真逆です。ただ、0か1かという議論は建設的ではなく、その間の落とし所を真剣に考えるべきなんじゃないかと思うのです。

まず、データの第三者提供に関しては、法律的な問題はクリアしているとしても、個人の感情的な部分はクリアされていない場合が多いと思います。例えば、ユーザーが同意したとしてもそれが本当に理解した上での同意なのか？、データの収集はどこまで行われているのか？、集めたデータをどう使われているのか？ etc…です。

この問題は個人の信条などにも関わってくるので、万人が納得するような答えはないと思いますが、最低限「どんなデータを収集していて」、「どのようにデータを使っている/どのようなデータを流通させているのか」をユーザーにわかりやすい形で明示するのが必要と思います。プライバシーポリシーを読めば分かる、といえばそうかもしれないのですが、大半の人はプライバシーポリシーからデータに関して思いを馳せる、なんてことはしなさそうです。

落とし所を仕組み化する

前置きが長くなりましたが、次のようなデータ収集/提供の仕組みであれば比較的納得感があるのではないでしょうか？ ここで言うDMPとは、ファーストパーティの情報を扱うだけでなく、サードパーティへのデータ提供、サードパーティからのデータ取得も扱うことを前提とした広義のDMPになります。 妄想している機能としては以下のものです。（本当は図に落とした方がいいのですが、眠いしうまく絵にできる気がしない。。。）

  • これまで通りCookieSyncなりなんなりでIDを交換してシステム間で連携
    • あとはお互いのプライバシーポリシーや利用規約に反しない範囲で適切にデータを交換します
  • (New)DMPはユーザーに収集している情報を提示するサービスを提供します
    • 具体的には、来訪したユーザーに対して「当システムにおけるID○○のあなたについては、我々は今こんなデータを保有しています」「ID○○さんに関して保有しているデータは、このような形式で第三者に提供しています」というのを可視化するサービスです
    • ユーザーはその情報を見た上で、そのように情報を収集してほしくない/情報を第三者に提供してほしくない(オプトアウト)ということを選べます
    • さらにユーザーが望めば、より精緻な情報を取得/精緻な形で情報を第三者に提供(オプトイン)を行えます。その場合は、ユーザーには何らかのメリットを与える必要があるでしょう。例えばポイントなど。
    • ただし、大半のユーザーはオプトインもオプトアウトも選ばない可能性が高いので、デフォルトでは、一定レベル以上のの匿名化/統計化した情報を第三者に提供する、という形にします

ユーザーにデータの取得/流通についてのコントロール権を与えつつ、最低限のレベルではデータ活用/流通を行える気がします。また、望むユーザーに関しては自分のデータを対価にすることでより詳細な情報の活用/提供が可能になります。DMPはシステムの後ろにいるのではなく、積極的に前に出てくることも必要なのではないでしょうか。

類似したポイントサービスはすでに多く存在すると思いますが、どんなデータが取られていて、どの粒度でデータ提供されているのか、を明示しているサービスはないと思います。このスキームがうまくいくなら、場合によっては望んだユーザーの購買履歴や決済情報などのよりクリティカルな流通させることができるかもしれませんね。それはそれでまた別の問題も発生してきそうですが。。。

まとめ

なんとなく問題意識として持っていることに関してつらつらと書いただけなのですが

  • 法律的には大丈夫かもしれないが、感情的な部分をケアするようなものが仕組みに含まれいたほうがいい
  • もっとデータ活用している企業は前に出て来た方がいい
  • アーキテクチャや制度も含めて、もっといろんなところを巻き込んで議論していった方がいい

というのを痛烈に感じています。よく分からないしきキモいし怖い、という論調が大きくなりデータ活用が盛り上がらないのが一番悲しいですね。

今の営業的というかマーケティング的な方面ドリブンでデータを活用していってやろうというのもすごく重要なのですが、割と重要なところを議論せずにどんどん進んでいる気がしてなりません。もちろん、真剣に議論していくとなかなか大変そうですが、その中から現状を突き破るようなデータビジネスのイノベーションがあるような気がしています。

とはいえ、この文章も半分勢いで書いているのでうまく言いたいことが言えてない気がしますし、自分自身まだまだ考えが足りてないところだらけなので、たっぷり議論したいですね。twitterやFacebookで適当に声をかけてもらえるとうれしいです。

余談

ここまで書いてきて、ああ、これって前に行った勉強会で聞いて考えたことの続きだなーと思いました。

「インタレストターゲティングリニューアルの裏側」の裏側〜または2012年の振り返り〜

先日、「インタレストターゲティング」リニューアルの裏側という記事を弊社エンジニアブログに書きました。エンジニアブログという制約上語れなかった話などをおりまぜて今年のまとめ的な話をしてみたいと思います。

今年は、年明け早々はいわゆるソーシャルグラフな話に取り組んでいましたが、途中からはインタレストターゲティング色が濃ゆくなり、後半にアドテクに出会ったという新しい興味に出会った一年でした。

インタレストターゲティングに出会う

今年の少し暖かくなったころにインタレストターゲティングのリニューアル案件に出会いました。正直、この案件の話があった時には広告自体に興味はなかったたので、まあそういう案件か、くらいのノリでした。

データマイニング要素なくしました

実は記事をよく読んでもらえると分かるのですが、実は僕達の取り組みは、クラスタリングというブラックボックスを取り払っているので、データマイニング要素を無くしているのです。

  • データマイニングというブラックボックス要素を排除することで柔軟に商品作成が可能になる
  • オペレーターが作成した広告商品はすぐに販売可能にする

の２点に注力した改修でした。クラスタリングを排除した理由としては、関連するものを集めるという処理は変わらないので効果は変わらないはずで、人間が細かくチューニング出来る要素を残したほうがむしろ効果は上がるのではないかという仮説にしたがったものでした。

商品作成の手間が従来よりも多少かかってしまうという課題が残りましたが（のちに@kimurasさんによる商品半自動作成機能を追加することで大幅に改善された）、今までなかった機能を追加したりしています（想定impression算出機能など）ので、それを補って余りあるのではないかなと思っています。

プロジェクト自体は途中で主要メンバーが抜けたり、クライアントテストの実施の際にバグが見つかったりと紆余曲折を経ましたが無事に終わったと思います。今の会社に入って、がっつりとゼロから機能を作ってリリースするのは初めてだったので、システム開発としてすごく勉強になりました。また、何より、Hiveを活用した機能を作れたのは自分の中で大きかったです。Hive（というかHadoop)むずかしいですねぇ。この辺の話はまたエンジニアブログに書くと思います。

アドテクに出会う

もはや記憶は定かではないのですが、夏ごろに「RTB」という言葉に出会ったと思います。やけに三文字のアルファベットを連発してきて頭に入りにくいし、前職で広告関連のトラブルに巻き込まれることが多かったために、そもそもWeb広告にいい印象を持っていなかったために、第一印象はふーん、な感じでした。が、その頃、もはやこれもきっかけは忘れましたが@8makiと話すことが多くなり（FreakOutと昔オフィスが一緒だった関係なのか、@8makiはRTBまわりに詳しかった）、Web + DB PRESS Vol.70にアドテクの記事があったりと、徐々にRTBの知識をつけていくに至ります。

秋になっても流れが続きます。9月に前職の同僚がなんとFreakOutに入社!、10月にad:tech tokyoに参加して色々見て回って意識が高まりました。そして、この頃にDMPという概念に出会います。

DMP

DMP、すごく興味深いなぁと思っています。自分が興味を持って勉強していく過程などは過去記事を見ていただければ。これとかこれとか。

なんとも言えないのですが、昔からデータを活用して何かできるといいなぁと思っていたことのどんぴしゃな感じがたまりません。データを提供してマネタイズしたところとデータを欲しているところが確実に存在しており、市場原理的にはもっと盛り上がっても良さそうなのに、実際はそうなっていない裏側には、非常にセンシティブな割にルールが曖昧だということがあるのでしょう。幸運なことに、今所属しているグループにはセキュリティとidentityに大変詳しい方がいらっしゃるので、勉強の機会には事欠きません。今後どうなっていくのかは引き続き追いかけたいと思います。

RTBとインタレストターゲティング

（ここから先は僕個人が思うところで、会社の動きとは関係ありません。あしからず。メディアに身を置くものが考えてみました、的なノリですね。）

で、ぐるっとまわってインタレストターゲティングに戻ってきます。インタレストターゲティング単体だったら、それはまあひとつの広告商品で終わりなんですが、さらに何か活用できないかなーと思っています。

今のRTBの流れは（自分が知るかぎりでは）、3rd partyのデータをいかに1st partyと組み合わせて活用するか、という点に重きが置かれている部分が強いのかな、と思っています。と、なると1st partyのデータの重みは必然的に小さくなるなぁと感じています。大量のデータをかき集めればこれまで分からなかったことがわかったり、できなかったことができるはず、という、いわゆるビッグデータ時代的な観点では間違ってない流れなんでしょうが、どうもメディアという観点ではこの流れにただ乗っかるのはどうなんだろうと思っていました。

Facebook Exchange

で、そのようなことを悶々と思っている時に、やっぱりやってくれました。Facebookさんです。Facebook Exchangeで効果が高かったよ、という話がありました。FacebookのCookie情報を軸として外部のCookie情報を集めて「Facebook内の広告」に活用する。ああ、これはうまいし、やっぱり効果が出るんだなぁと思いました。メディア側もクリエイティブの強化に加えて、RTBの仕組みの中でうまく自分たちの集客性やユーザー特性を利用した仕組みを作ることでまだまだ可能性があると思わせてくれた事例だと思います。

そんなこんなで

なんとなく始まった案件をきっかけに、すごく勉強になった一年でした。来年も広告に関わるかは正直わかりませんが、どんなことでもまあ楽しくやれそうな気がします。もともとスタートアップとかが好きな人間なので、まだ成熟していない分野を色々調べて妄想するのはとても楽しいですね。

グループの勉強会での資料を公開します

あらまし

僕が所属しているグループでは週に一度持ち回りで最近の取り組んでいるタスクの話や今興味のあることなどを20分ほど話す勉強会があります。

昨日が僕のターンで、最近もっぱらDMPに興味があって一日の1/3くらいはDMPの事を考えているので、DMPについてこれまで調べたこと＋最近考えていることなどをまとめました。機密情報でもないし、せっかくなので資料を公開しておきます。

仰々しいタイトルになっていますが、中身はいたってカジュアルな感じです。

スライドの最後に書いていますが、実際に仕事として携わっていない中、独力で「調査」を進めるのはそろそろ限界かなーという感じです。これからは、調べたことを元に要素技術で色々遊んでいこうと思います。

CookieSync

CookieSync自体の是非はともかく、発想は非常に面白いなーと思っています。セキュリティやidentity系では昔からこの手の話題はつきないようで、自分は今までそこまでidentityに興味はありませんでしたが、最近、徐々に興味を持って勉強するようになっています。理解を深めるために、一度サンプルくらいは実装してみる必要があるなと感じています。

プライバシー保護データマイニング

こういう学問があるのは知っていましたが、実際に利用するシーンが思いつかず手付かずになっていた分野です。DMPについて調べれば調べるほど、今後重要になっていく気がしてならないのは僕だけでしょうか？せっかくの機会なのでコツコツやって行きたいと思います。

着手したいことがたくさんあって楽しい限りの今日この頃です。

CookieSyncを試してみる

ここまでDMPに関して、特にデータの収集面に関しての概要をまとめてきました。

ここまで来るとだんだん自分でも実装したくなってきます。実装方法は色々あるとは思いますが、CookieSyncを実際に試してみたいと思ったので、ものすごくシンプルな構成でCookieSyncを実装してみました。

構成とシナリオ

構成というほど大したものでは無いですが、以下の構成及びユーザーの動きを想定しました。

構成

  • siteA：DMPとCookieSyncを行いたいWebサイト
  • ユーザー
  • DMP：siteAのCookieSync相手

シナリオ

  1. siteAにはCookieSync用の1x1pixelの画像を仕込む
  2. ユーザーがsiteAに来訪
  3. ユーザーにはsiteAのCookieがセットされる
  4. siteAからDMPに画像のリクエスト
  5. DMP側ではリクエストからsiteAのCookieIDを取得してユーザーにDMP側のCookieを発行しつつ、1x1の画像を返す

siteA側

  • cidというCookieでユーザーにIDを振る(1000までの乱数)
  • DMP.comに対して、/DMP/${cid}.gifという画像をリクエスト
  • echoしてる部分はCookieの状態を見るためだけなので適宜無視してください
siteAのページ (index.php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

<?php
if(!isset($_COOKIE["cid"])) {
        echo "このサイトのCookieを保有していない<br /><br />";
        echo "Cookieの生成<br />";
        $cid = mt_rand(1,1000);
        setcookie("cid", $cid);
        echo "保有しているCookie : cid = " . $cid . "<br /><br />";

        echo "DMP用のクエリストリング生成<br />";
        $query_string = $cid;
        echo "生成されたクエリストリング : " . $query_string;
} else {
        echo "このサイトのCookieを保有している<br />";
        echo "保有しているCookie : cid = " . $_COOKIE["cid"] . "<br /><br />";

        echo "DMP用のクエリストリング生成<br />";
        $query_string = $_COOKIE["cid"];
        echo "生成されたクエリストリング : " . $query_string;
}

?>

<!DOCTYPE html>
<html>

<head>
<meta charset="UTF-8">
<title>Cookie Syncのテスト</title>
</head>

<body>
        <h1>Cookie Syncのテスト</h1>

        <p>1x1ピクセルのダミー画像を呼ぶ例
     <img src="http://DMP.com/DMP/<?php echo htmlspecialchars($query_string, ENT_NOQUOTES, 'utf-8') ?>.gif" alt="" width="1" heigth="1"></p>
</body>

</html>

DMP側

単純にphpに対してクエリストリング付与して呼び出したり、画像にクエリストリング付与して呼び出すのでもいいのですが、それっぽい感じにするために.htaccessを使います。

  • /DMP/にて展開しています
  • 画像の置いているディレクトリに.htaccess設置
  • 同じ階層に1x1.phpという画像を返すphpを設置
  • ${cid}.gifへのリクエストを1x1.php?cid=${cid}にRewrite
  • 1x1.phpでは、DMPのCookieの発行(dmpid：1000までの乱数)と、クエリストリングを受け取りマッチング処理
.htaccess
1
2
3

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)\.gif$ /DMP/1x1.php?cid=$1
${cid}.gifによって実行されるphpプログラム(1x1.php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
// まだDMP側のIDが振られていないユーザーにCookieを発行
if (!isset($_COOKIE["dmpid"])) {
        $dmpid = mt_rand(1, 1000);
        setcookie("dmpid", $dmpid);
}

// ここでcidとdmpidをマッチングする処理
// if (isset($_COOKIE["cid"])) {
//      hogehoge;
// }
// DBに格納するとか

// 1x1pixelの画像としてのレスポンスを返す
header('Content-Type: image/gif');
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Pragma: no-cache');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
echo base64_decode('R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==');
?>

実際に動かしてみる

VM2台立ち上げて実験してみました。

  • 192.168.80.140 : siteA
  • 192.168.80.142 : DMP

に対応しています。

CookieSync前

  • 前の処理のCookieIDが画面には残っていますが、ブラウザはCookieを所有していません。

CookieSync後

  • siteA(192.168.80.140, cid)とDMP(192.168.80.142, dmpid)の双方のCookie情報がブラウザに存在していることが確認できます。
  • DMP側にはcidとdmpidの双方が渡っています。dmpidを持ってCookieSyncを行なってきたユーザーは特定済みなので、その他の提携サイトからdmpidが振られているユーザーが訪れることで、データのカバー率がどんどん向上していきます。

まとめ

非常にシンプルな形ですが、CookieSyncが実現できることを確認しました。実際は大量のリクエストを捌くためのサーバーチューニングや、データの保持に関するアーキテクチャの検討が必要だと思いますが、とりあえず1x1ピクセルの画像を利用すればいいということの確認ができました。

実利用にはJavascriptのタグを置く形で実現することが多いと思いますが、こちらもまた別の機会に試してみたいと思います。

というわけで、しばらく重めの話が続いたので、少し軽めのお話でした。

参考

以下のサイトを参考にしました。

Ad:tech Tokyoに行って来た話

ad:tech tokyo

少し前の話になりますが、ad:tech tokyoに行って来ました。去年はそいういうイベントがあるらしいくらいの認識でしたが、今年は最新のアドテクの話を聞きたい、と参加させてもらいました。（諸般の事情によりビジターパスでの参加でしたが・・・）人間、興味は変われば変わるもんですね。

RTBとかDMPとか

すでに盛り上がってると言えばそうなのですが、いよいよ本格的にRTB時代が到来しそうな感じを受けました。RTBそのものもすごくおもしろそうそうなのですが、個人的にはアドテクの発展に端を発するマーケティング業界の変化に興味があったりします。直接的に広告業務に関わっている人間ではなく、最近アドテクを通じて業界全般に興味を持ち始めたところなので、今後どういう発展をしていくんだろうなーと思っています。まあ、まだ傍観者ですねw

このブログとか

はてなでちょろちょろ書いてたんですが、そろそろ飽きてきたので、こっちで色々綴っていこうかと。主に自分主に自分が調べたアドテクの話やデータ分析の話など、技術とその応用まわりの話を書いていけたらなと思っています。まあたいした内容ではないかもしれないですが、適当にお付き合い下さいませ。