タグマネジメントの基礎（解析ツール視点）

タグマネジメント関連で積極的に情報発信しているアユダンテの新しいタグマネ関連記事。


以下、記事転載。
---------------
結論から言うと、Webサイトへ埋め込む必要のある「アクセス解析ツールなどが生成するHTMLタグ」を「管理（マネジメント）する」ことをタグマネジメントと呼び、そのための機能を持ったツールをタグマネジメントツールと呼びます。分かりやすく言い換えると「（HTML）タグ管理」ですね。
---------------


非常に分かり易い！
ツールへデータを送信するための外部が生成したHTMLタグを管理することがタグマネ。

タグマネの本質は、各種解析タグの取り纏めという事で、広告配信系タグを取り纏めるというのはあまり本質的ではないという感じなのかな。

メディアサイドにとっては、別に広告配信タグ管理しても、あまりメリットはないのかな？
そもそもタグマネのタグをメディアが受け入れるか否かという点からも懐疑的。
でも、javascriptを活用して一つのタグに纏められ、尚且つ配信設定がラクになるという事になれば、需要はあるかも？？

将来的には、配信側もDFP中心に連携強化されて、Googleがやはり覇権を取りそうな予感。

次回以降の記事も要チェックです。

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って考え方は来年以降もっと浸透していきそうな気がする。

JavaScript関連書籍

JavaScript実践入門というタイトルが気になり、書籍を購入。

WEB+DB PRESSは、定期購読すべき書籍だと思う。

まだまだ内容をきちんと理解出来ないが…。

色々と勉強しなければいけないことが盛り沢山だ。

マイクロアドのエンジニアインタビュー記事雑感

gihyoでマイクロアドのエンジニアインタビュー記事が出ていたので雑感を。

RTBのリクエスト処理に5ミリ秒しかかけていないというのが、まずビックリ。

あと、データベースにKyoto Tycoonを利用しているという構成は、以前、Web＋DB PRESSに掲載されていたFreakOutと同様の構成だった、という事は、DSP側のDB構成は、Kyoto Tycoonを利用するのが、一般的なのかな？と思った。

2分間に1回、全キャッシュ更新という頻度は、他のDSPと比較してフレッシュネスなのか、気になるところ。

で、一番ビックリしたのは、サービスのインフラを設計から運用まで3人で実施、という点。
うーん…、これはエンジニア側がちゃんとビジネス構造を完全に理解しているからこそ出来るという事か。

いずれにせよ、マイクロアドのエンジニア側面からの強さが垣間見えた記事だった。

このシリーズは、楽しみ。

JavaScriptの基礎から学ぶ

アドテク関連を色々と勉強していると、まずはJavaScriptをしっかりと勉強しないといけない。

もう、超が付くほどのド素人なので、まずは文字列の種類から勉強。

このブログのエントリがとても参考になった。

以下、エントリから転載。

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

文字列の中では、バックスラッシュ（\）に続く 1 文字は特別な意味を持ちます。これらの文字をエスケープ文字と呼びます。

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

なるほど。全く知らなかった（汗）

￥nだと、改行ってことなのね。

なんか、「￥nsrc=～～」って書いてあって、「なんじゃこりゃ？？」って感じだったのだが、少し理解出来た。

何ていうか、もう日々勉強だな…。

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が本当に実現できるのかは、気になるところ。

データフィード関連の良まとめBlog発見

丁度、データフィード回りを勉強しなければと思っていた矢先に、とても良いBlogエントリを発見。

相変わらずの高クオリティ。さすがATARAですね。

主にGoogleの商品リスト広告の話がメインですが、データフィードに関する内容もばっちりと入っています。
現時点では、データフィードに関して、最も纏まったものかと思われる。

日本でも徐々に浸透しつつある「商品リスト広告」（PLA: Product Listing Ads）には、マーチャントセンターへの登録とそれに伴うデータフィードは必須であると。
大量保有している自社商品データを自動的に広告（検索やリタゲ、アフィリエイト等）クリエイティブに反映させないといけないと強く感じた。

下記抜粋から、特に流行の3PASでのリタゲ（Criteo等）をやるには、データフィードを導入しないと本当の効果は得られないのだろうなと思った。


以下エントリから抜粋
--------------------

リターゲティング広告は、AdWords のリマーケティング広告をはじめ、多くのDSPのメイン機能ということもあり、2010年にGoogle がリマーケティング広告を正式公開して以降は、それまでダイレクトレスポンス重視でディスプレイ広告にあまり積極的に投資してこなかった企業も、（ラストクリックやセッションベースで見ても）短期的なROIが見込めるということで、急速に普及しました。

リターゲティング広告の設計は、ユーザーリストの設計とコンバージョンまでのシナリオづくりに他なりません。リターゲティングの開始当初はサイトの訪問履歴をもとに追いかけ回す、というタイプが少なくなかったものの、Eコマース企業を中心にサイト内の商品閲覧履歴や興味関心をもとに、分割されたユーザーリストに対してパーソナライズされた広告をリターゲティングで表示させることによってROIをさらに引き上げる手法が台頭してきました。その代表格がCriteo です。

Criteo をはじめとしたレコメンドバナーの実装にはデータフィードの概念が必須です。訪問や閲覧履歴をもとにデータフィードから自動的に関連性の高いバナーを表示するのでコンバージョンに非常に近く、これまでのバナー広告と比較しても非常に高いROIを出せるようになってきました。
現在（2012年12月時点）ではまだベータ版ですが、AdWords でもDynamic Display Ads（動的ディスプレイ広告）のリリースが待たれており、データフィードと連携した動的なクリエイティブのバナー広告は、今後ますます注目されていくと思います。
--------------------


最近リタゲといえば、単純に広告主サイト来訪ユーザーを追い掛け回すだけというのがメインですが、Yahoo!のCriteo導入やAdWordsのDynamic Display Adsリリースで、ここら辺の意識も変わっていくのかな。

で、その際に重要になるのが、やはりデータフィードで、いかにして商品データファイルをクローリングして抽出するか（商品DBへのアクセスはあまり許可されないと思われるので）と中間処理のデータ正規化が上手く出来るかが、データフィードプレイヤーの差別化ポイントになる。

ここで1つ疑問。
多分、クローリングからデータ収集した情報なので、データフィードプレイヤーのものになる筈で、
このデータって有効価値はあるのかな？
TAGGYとかは上手く活用していそうな気がする。

ビデオリサーチインタラクティブのOne Reportをチェック

今年の8月にリリースしたビデオリサーチインタラクティブの広告効果測定サービス「One Report(ワンレポート)」についての備忘録メモ。

2012年8月のVRIのリリースはこちら。


最大の目玉は、ヤフーの出稿の効果測定が出来る点。
11月開催のアドテック東京以前にヤフーは既に第三者配信受けているじゃん！って
思ったのだが、結論から言うと誤った認識だった。

昨日実施されたVRフォーラムでは、DFAと同列で第三者配信的な見せ方をしていたが、よくよく見てみると「擬似的第三者配信」となっており、担当者に聞いてみると、『広告配信リクエスト（クリエイティブリクエスト時）のエレメント（多分）に、VRIのトラッキングタグ（リリースによると1×1透過GIF）リクエストが記載されており、このタイミングでVRIのCookieセットすることで、トラッキングが出来る仕組みらしい。
多分クリック時も同様の仕組みでトラッキングしていると推測。

第三者配信ではないので、他メディアに対しては、One Report専用の測定タグを埋め込んでもらわないといけないとの事。

うーむ。これって、微妙じゃないかな。

事実、ヤフートップページで、VRIのクッキーセットは見たことがないし…。
多分あまり使われていないと想定。
ヤフーがBrightTagを受け入れてしまった時点で、このサービスの優位性が一気に薄れた様な感じがする。

陽の目をみないまま、ひっそりとサービス終了する予感…。

Chrome＋Ghosteryで色々とチェック

Chromeのアドレスバー左にある「サイト情報表示」内の「Cookieとサイトデータを表示」とGhosteryでサイト内設置タグを見ていると、勉強になる。

とあるサイトのOpenxのタグの内訳を見ていると、PHPで記載されていて、前の方にrakuten（アフィリエイトっぽい）へのリダイレクト（？）みたいな記述があったり、ドメイン（Cookie用？）がd.href.asiaというもので、何故かrefererがfacebook.comになっていたりしている。
よくわからないが、GoogleのRSSから飛んでいる筈なのに、何故、Facebookが記載さているのだろう？？
Openxとrakutenって、データ連携させてたりするのかな…。

また別のサイトでは、FreakoutのSync用のCookieがSetされていたりして興味深かったサイトもあったり。

ここら辺の記述内容がある程度、読める様に勉強しないとなぁ。

Cookieの勉強会とか、どこかの配信事業者とかやらないのかな。

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が連携されているのか知りたい所ですね。
まだまだ勉強不足なので…。

Googleのタグマネジメントのインパクトを考える

本日のExchangewireJapanの記事から。

昨今、流行のタグマネジメントに関して、老舗のTagmanCEOのコラムが翻訳されていたので、そこから色々と考えてみた。


日本では、先日のAdtechTokyoでYahoo!JapanがBrightTagとの協業で、一気に注目を集めた感じではあるが、大手広告系会社はプロダクトをリリースしている。
タグマネジメントというよりは、ワンタグとしてだが…。

タグマネジメントとワンタグの違いがイマイチ理解できていなかったが、アド論のこの記事を見て、ある程度納得。
違いは、タグマネジメントだとタグ自身がPiggybuckするか否かという事なのかな。

あと、admarketechのこの記事が秀逸。

TagmanのCEOは、大手広告主などは、利用するか否か疑問と記載しているが、多分、利用する気がする。アナリティクスとかと同様にエンタープライズ版とか出るのではと思う訳で。


振り返って、日本ではどうなるのだろうか。

【広告主視点】
広告主がきちんと理解して、有料でタグマネジメントを受け入れるとはあまり思えない。
これまでの商慣習から、広告代理店がある程度身銭を切って、ツール利用するのかな。
そうなった時に自社でタグマネジメントのプロダクトを保有しているかは、利益の観点からは重要な気がする。

【媒体視点】
本当に使うのかな？？という感じ。
そこまで厳密に収益管理している所は大手媒体だろうし、日本でお金を払ってまでして、
やるのかなという肌感。
まずはYahoo!Japanが、ネットワークの媒体へどういう形で提供するのか知りたい。

ただ、この領域は、日本でも、今後ホットスポットになるのだろうな。
ここを押さえて、インプットデータ元としたいDSPやDMPは多そうだなと勝手に妄想。
多分、スケールアウト社のタグマネジメントは標榜していそう。無料だし。。。

Googleがやり始めたという事は、インパクトは大きいと考えるべきだな。
で、次は、データフィードあたりをさくっと無料で出してきそうな予感。

また、アドテク関連で勉強する領域が増えた。

piggybackとcookiesyncの違い？

アトランティス木村社長の昔のツイートから。

piggybuckの意味がまだ理解出来ていない…

piggybuckだけしても意味がないとは？
相手に対してCookieデータを渡しているだけなので、
自らもSyncさせて、オーディエンスデータを保有しなければ
いけんないという事なのかな？

スケールアウトのこのエントリも、ちょっと抽象的過ぎて
あまり具体的なイメージが持てなかった。

タグマネジメントする際に、piggybuckの仕組みは
きちんと勉強しないといけない。

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高速回線と同様の処理が行えるのか？

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