「0.1秒で行われるリアルタイムトレード マイクロアド」雑感

gihyoにWeb広告配信のインフラを探るという記事の第1回を見つけたので雑感。

またまたマイクロアド。最近エンジニア獲得のプロモーションに力を入れているなぁ。
以前のマイクロアドエンジニアインタビューをより深耕した感じかも。
（この記事に関するエントリ「マイクロアドのエンジニアインタビュー記事雑感」はこちら）

データベースに関する部分を備忘録をメモ。


------
同社ではもともとデータストアとしてMySQLを使っていましたが，それが処理上のボトルネックになることが少なくなかったと言います。そこで導入されたのがKVSで，現在はMySQLとKVSであるKyoto Tycoonが使い分けられている。
⇒
ふむ。KVSは処理が速いのか。


「リレーショナルである必要のないもので，かつ高速に参照したいものをKyoto Tycoonに入れています。具体的には，Webサイトを閲覧するユーザの属性情報などですね。
一方MySQLは，MicroAd BLADEを使って広告配信を行っている企業が設定した情報などの記録に利用しています（元井氏）」
つまり，パフォーマンスが求められるデータはKyoto Tycoon，信頼性が重要であるものはMySQLと，両者の特性に合わせて使い分けているわけです。
⇒
何か、ここらへんのDB構成は、どのDSPでも基本同じなのかな？
以前のエントリでも書いた様に、フリークアウトも同じだった気がするので。

レプリケーションできないデータ量を扱うものは，フロントサーバからリクエストを受ける必要があります。これを実現するために導入されたのがKVSであるKyoto TycoonやFusion-ioのioDriveだったというわけです。
⇒
このインフラ構成もフリークアウトと似た様な感じだった気がする。

MicroAd BLADEでは，ネットユーザの性別や居住地域，年代といったデモグラフィック情報や，広告主サイトへの興味の度合い，あるいは広告と各Webページの相性などの情報を利用し，RTBの入札内容を決定している
⇒
広告とWebページの相性って重要な要素だよな。
色々とヒアリングしていると、メディア側ってあまりここを考慮していない気がする。

膨大な情報の集計に使われているのがHadoopで，そこで解析した結果をKyoto Tycoonに取り込み，配信プログラムから参照しています。その具体例の1つにリターゲティング広告と呼ばれるものがあります。
収集したログをHadoopで1～2時間ごとに解析しています。ユーザの行動ごとに配信方法を選べ，たとえばWebサイトのトップページにアクセスした人全員に広告を配信，あるいは詳細ページに3回以上アクセスしたが商品購入はしていない人に広告を配信するといった，広告主の希望に応じたリターゲティング広告を実現しています。
⇒
配信プログラムっていうのが各DSPの差別化ポイントなんだな。
ていうか、Hadoopで1～2時間毎の解析してるんだ。
ここのデータ呼び出しとかの時間のボトルネック解消の為に上記の様なインフラ構成なのかな。
------


なかなか勉強になった。
インフラまわりもきちんと情報収集しないといかんなぁ。

「RTBがデジタル広告の主役になるためには何が必要なのか？」雑感

admarketechのRTB関連エントリを読んだので、雑感。

日本が2014年にはイギリスを超えて、世界2位のRTB市場になるとの推測は、少し眉唾な気がする。
現状、殆どのDSPがリタゲメインでRTBを利用している中、どこまできちんとオーディエンスターゲの環境が整うのかな？

昨年、DSPプレイヤーは出揃ったと思うので、今年はいよいよ実運用の年になり、本エントリ最後でも書かれている様にどこに頼むのではなく、だれに頼むかという流れになるかと。

ただ、そうなった時にいかにユニークなオーディエンスデータを保有しているかが、競争優位性になるんだよね？
そうなると、楽天やリクルートみたいなプラットフォーマーがいよいよ本格的に自社のデータを活用したRTBに力を入れてくる気がする。

プラットフォーマーがDSPをリリースして、プライベートエクスチェンジなエコシステムを構築してくる可能性もあるわけで、そうなると代理店とか大変になるんだろうな。

あと、キモはやはりSSP側がどの様に対応するのかとDMPプレイヤーがきちんと出てくるかという事かな。

今のSSPって、本当のイールドマネジメントが出来ていない気がするので、RTBだけじゃなく、純広告もきちんと対応してくれれば、もっとメディアもアドテク領域に出てくるのかなと思う。

あとはDMP。これがUSみたいにきちんと機能すれば、もっとオーディエンスターゲ市場は活性化してくるはず、現状は各DSPのデータ保有量が競争優位性となっているが、解析で差別化されてくると、ベンチャーとかももっと出てきてUSみたいなカオスになって活性化される気がする。
（ただし、今のUSのカオスマップ的なセグメントは決して良いとも思えないが…）

で、エントリにも書かれているスマホ。これが最も厄介な気がする。
アプリがコンバージョンポイントになるから、スマホのRTBは正直マネタイズするには厳しい気がするんだよな～。

AdStir RTB Exchange APIに関する記事

モーションビートのAdStir RTB Exchangeに関して、興味深い記事を発見。

APIを構築することで、これまでRTB実装に1～2か月程かかっていた仕様合わせ等の工数を減少せる事が出来るとの事。

以下は勉強になった箇所と図を抜粋

-------------

bidリクエストに関しても、基本はOpen RTBに準拠していますが、DSPごとに独自の情報が追加されるなど、拡張されていることが多いため、それに伴う改修、連携テストに時間が掛かります。転送量も、接続対象のDSPを増やすたびにbidリクエストを送信する対象が増えるので、単純計算でトラフィック量が比例して増加します。

Open RTBの仕様ではbidリクエストごとに配信除外対象を送るようになっていますが、日本のDSPの場合、配信対象の情報を毎時などの頻度で事前にやり取りすることが多いです。粒度はDSPによってカテゴリ単位やキャンペーン単位、原稿単位と異なっており、やり取りするデータ構造も異なっています。カテゴリはDSPごとに種類が異なるため、お互いが使用しているカテゴリをマッピングさせる必要があります。

図：DSPを増やすたびに配信毎のトラフィックが増える

-------------

このマッピングが凄い大変な作業なんだよなぁ…。

SSP側では膨大に増えるトラフィックを裁くという観点からインフラは特に重要なのだが、現状の市場ではその投資に見合うだけの取引が無い（特にスマホ）は推測される。

（なので、モーションビートは大赤字なのだろう。）

あと、「複数のDSPと接続している場合、各DSPからのbidレスポンスを一定時間（AdStirでは120ms）待つ必要がある」というのは、業界標準なのかな？

確か、RTBreq/resは100msだった気がする

（マイクロアドやフリークアウトに0.1秒以内にRTB処理されると謳っていたと記憶）

※12/26追記
スケールアウト上野氏によると、オークション期間は200msとのこと

（参照記事こちら）
なので、DSP側のリクエスト～入札完了（勝者決定）までが100msかと推測。

このAPIって考え方は来年以降もっと浸透していきそうな気がする。

CookieSyncに関する学習

CookieSyncについて日々勉強している所、またまた勉強になりそうなBlogエントリを発見。

特にDMP-DSP間、DSP-SSP間、各々のCookieSyncに関して、詳細が記載されており、とても参考になった。


以下、エントリ引用。
---------------------

Quoraの説明では、DSP-SSP間について「プロセスは大体同じだけどServer間のやりとりができない場合について説明されている。
全部ピクセル呼び出しとクエリストリングで行われる。」と言って以下のリンクを進めている。
Server間のやりとりを行うことで、レイテンシを下げられて、ピクセル利用時のデータロスも制限できるとか。

最初の入札において、

・SSPがCookie ID(SSPcookieXYZ)を含まない場合、DSP456はuser123であることがわからないので広告が出せない

・最初の入札が終わった後、SSP123はJSを実行し、各入札者へのリダイレクトにはクエリパラメータとしてSSPのCookie ID(SSPcookieXYZ)が付与される

・DSP456はCookie IDの紐づけを保存(DSPcookie789=SSPcookieXYZ)

レイテンシとUXの問題(Cookie IDとの紐づけ処理などを待っていられない)で最初の入札時にSSPはCookie IDを送らないと言っている。

これは各社仕様が異なるのだろうか？

メジャーなSSPがpiggyback scriptを実行するためのHTMLが紹介されている。

Pubmatic : vcodeというクエリパラメータでCookie IDを送信

Rubicon Project : Cookie IDはnid?ちょっとよくわからない

Admeldは別のソリューション やはり、SSP側の実装はバラバラということなのだろうか。対応コストとか考えるとちょっと嫌だな。

---------------------

以前の自分のエントリで、概念的な部分はほぼ同じという事が改めて認識出来た。

最初の入札の段階では、入札出来ない（敗者）DSPとなるので、入札終了後、「SSP自身でCookieSetさせて、SSPCookieIDをクエリストリングにふった敗者DSPCookieリクエストをリダイレクトさせる」という事でCookieSyncさせるという事なんだろうな。

いずれにしても各SSPによって、実装方法はバラバラというのは正しいのだろう。

あと、やはりスマホでPCと同様のRTBが本当に実現できるのかは、気になるところ。

FacebookExchangeに関する考察

先日リリースされたFBXに関して、techcrunchのこの記事以外のエントリを発見。

こちらのエントリによると、FBが追跡IDを管理する方法が有力な考えとの事。

以下、エントリから転載
----------
・広告主は、ページ中にFBXのサーバへのリクエストを埋め込んで3rdpartyクッキーを設定してもらう＋専用のIDを入手する。これはFB側で生成された専用の匿名ID。
（外部スクリプトタグで匿名IDをcookieにセット、同時に表示元ページにもjsonで渡す、とか方法はいろいろ考えられる）
・広告主は（広告主の管理する個人情報データベース上の）ユーザーにこのIDを紐付けておき、ユーザが広告対象として価値がありそうなら、そのIDに入札する。
・FacebookではFBX用のIDをcookieから取得し、対応するIDに広告主の入札があれば広告領域に表示する。
----------

なるほど。
でも、FB上でまだ3rdpartyCookieがセットされているのを確認したことが無いので、確かめたいな。
このCookieのクエリストリングに暗号化されたFBX用のIDがセットされて、DSPにリダイレクトされるということかな。
この処理でRTBってモバイル（スマホ）でも実装可能なのかな？

実際どの様な形で、DSPとFBXが連携されているのか知りたい所ですね。
まだまだ勉強不足なので…。

RTBにおけるCookieSyncの仕組み

概念的だが、備忘録として記載。


----------------------------------
1.　クライアントからSSPへCookie送信

2.　SSPからクライアントへCookie付与

3..　SSPから各DSPにSSPCookieIDがクエリストリングにふってあるビッドリクエスト送信

4.　各DSPは、CookieSyncしていれば、アルゴリズムが入札価格をはじき出し、ビッドレスポンス

5.　SSPは勝者DSPの広告タグをクライアントに送信
　　※この時に、広告タグの中に、img src"勝者DSP"以外に、CookieSync用のimg src"SSP
   　　リダイレクト敗者DSP1" img src"SSPリダイレクト敗者DSP2"が含まれている？

6-1.　勝者DSPのアドサーバーへクリエイティブリクエスト、レスポンス
　   　表示された時点で、勝者DSPのCookieがクライアントにSetされる
     　（クライアントとDSPサーバーで通信が発生する為、CookieのSetが可能）

6-2.　敗者DSPに対しては、SSP自身でCookieSetさせて、SSPCookieIDを
      　クエリストリングにふった敗者DSPCookieリクエストをリダイレクトさせる

6-2-1.　敗者DSPは、クエリストリングのSSPCookieIDと自分のCookieIDが
　　　　  手元に来るのでCookieSync出来る

6-2-2.　敗者DSPのCookieもクライアントにSetされる
----------------------------------



結論
RTBを受け入れた時点で、入札の勝ち負けに関係無く、入札DSPのCookieは
クライアントにSetされるということか。

このあたりは、SSPによって仕様が異なる筈なので、確認が必要。

cookieSync備忘録

RTBを行う際の必須機能のCookieSyncに関するエントリ。
とても分かり易い。この位の知識レベルは、最低限把握すべき内容。


あとはスケールアウトのこの記事。


スマートフォンでも同様の挙動となっているかは要確認。

果たしてスマホの通信速度で、PC高速回線と同様の処理が行えるのか？

実際に事業者として、きちんと入札処理が出来ているのかは、確認。