Fringe81の田中社長Blogで、タグマネに関してとてもわかりやすいエントリがあった。
因みに今回雑感の対象は2回目。第1回は、こちら。
かなりポジショントーク入っているが、タグマネに関してここまで整理されたものってなかったのではないだろうか。
個人的には、大分すっきりした。
もし、自分が広告主という立場だったら、すぐに話をききたい!って問い合わせただろうな(笑)
これまでワンタグと何が違うのか?、なぜタグマネが必要なのか??というのが、かなりもやもやしていたが、下記を見て腹落ちした。
以下引用
-----------------
「DSPやソーシャルボタンの普及により、広告主サイトへのタグ導入数が飛躍的に増加し、さらにタグをどのページで起動させるか、ルール設定を行うことで、リターゲティングの効果改善のリターンが大きくなってきた。よって、“タグをマネジメントする必要”が出てきた。」
----------------
ワンタグだけでは、確かにこれは出来ないよな~。
特に「タグのルール設定」や「どの設置タグが要因でエラーになっているのか」とかは、知見がないと対応出来ないだろうし。
で、最後にやはり書いてありました。
「データマネジメントやる!宣言」
過去エントリでも書いていた(Fringeとしては、やはりタグマネから「オーディエンスデータのマネージメント」という根っこの所を握りたいんだろうなぁと改めて思った。)みたいに、タグマネはあくまで入口で最終的には、DMPに行きたいのが本音なんだろうな。
先日、FringeはMBOしたけど、狙うポジションとしはDMP領域で、ソコをコアコンピタンスとして収益を拡大させて、IPOなのかな??
(単なるツールベンダーだけだと確実に淘汰されるし。でもヤフーのBrightTag、グーグルのタグマネとかとの整合性はどうするんだろおう??)
ヤフー!もいよいよ、BrightTagベースのタグマネを広告主向けに無償でリリースしたし、昨年グーグルも自社プロダクト限定だが、グーグルタグマネージャーをリリースしたり、オプトやロックオンもサービス提供し始め、元々ワンタグ提供していたcciやDACも参加してくるはずだし、今年一気にタグマネサービスが浸透しそう。
まさに今年は、タグマネ元年だな。
あと、先日発表になったグーグルのエンハンストキャンペーンが、どの様なインパクトを与えるのかも注視しておく。
あと、今回の記事1回目のタグ界のヒストリーマップは、とても参考になったので、以下転載させて頂く。
<タグ界のヒストリーマップ>
ほんゆら日記
Real time bidding(RTB)、Data Management Platform(DMP)、Tag Management、cookiesync、等々のAdTechnology関連記事を自分なりに解釈した雑感を公開中。
2013年2月28日木曜日
2013年1月29日火曜日
「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時間毎の解析してるんだ。
ここのデータ呼び出しとかの時間のボトルネック解消の為に上記の様なインフラ構成なのかな。
------
なかなか勉強になった。
インフラまわりもきちんと情報収集しないといかんなぁ。
またまたマイクロアド。最近エンジニア獲得のプロモーションに力を入れているなぁ。
以前のマイクロアドエンジニアインタビューをより深耕した感じかも。
(この記事に関するエントリ「マイクロアドのエンジニアインタビュー記事雑感」はこちら)
データベースに関する部分を備忘録をメモ。
------
同社ではもともとデータストアとして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時間毎の解析してるんだ。
ここのデータ呼び出しとかの時間のボトルネック解消の為に上記の様なインフラ構成なのかな。
------
なかなか勉強になった。
インフラまわりもきちんと情報収集しないといかんなぁ。
2013年1月28日月曜日
「ExchangeWireJapan Fringe81タグマネジメントinterview」雑感
ExchangeWireJapanにFringe81のTagKnightに関するインタビューがあったので、読んでみた。
これ、非常に参考になった。
以下、参考になった箇所を引用。
------
一番よくある話が、デジタリスを入れたらページが遅くなったと言われてしまった事ですね。
このような問題が発見されると、広告主様や代理店様は、まず広告のタグを全部取る作業をしなくてはいけません。1個1個タグを入れ直して、どのタグが悪さをしていたのかを検証するわけです。
⇒
これ凄い大変だよな…。
結果として広告配信しても、このタグ調査中はトラッキングデータ取れなくなるわけだし。
死活問題だよな。
現状、お客様のどのページにどのタグを入れるかというルールに関しては、代理店様が設計しているケースが多いのですね。
「ベン図」と言うのですが、どのようなユーザーに対してどのようにユーザーを足すか、引くか、除外するかと言ったルールをイメージして、それを直接URLで数式のように足したり引いたりする必要があるのです。例えばクリテオさんではトップのページのタグ、商品詳細のタグ、申し込みフォームのタグ、コンバージョンページのタグというように幾つかタグを分けて、どのユーザーがどこまで到達したかを判別し、自動的にリコメンドのバナーを配信するというようなことをシステムで行っています。
これらのルールを、日本の国産DSPである「マイクロアドブレード」とか、グーグルの「GDN」など、個別にルールを作っていくのですが、誰に対してリターゲティングを出すかというマーケティングの全体像としてはまったく統一されていないのが現状です。
⇒
Criteoのタグの仕組みって、そうなっていたのね。
ていうか、他も多分、基本は、同じだろうけど。
Fringeとしては、やはりタグマネから「オーディエンスデータのマネージメント」という根っこの所を握りたいんだろうなぁと改めて思った。
いろんなロジックがあるのですが、すごく分かりやすい話で言うと、複数埋め込まれたタグの中で速いほうから読み出すというものがあります。例えばデータセンターが近いと物理的に速かったりするわけです。
それでは10個タグが入っていたうち、1個遅いのがあったときに、そのタグが一番最初に読み込まれてしまうと他のタグの読み込みがすべて遅れてしまうので、速いものを先に読み込ませるということですか?
通常ウェブサイトを上から下まで読むときには、コードは順番に読まれるのですね。ただ、タグというのは順番に読むべきものではなくて、いろんなサーバーに問い合わせがいくものなので、一遍に問い合わせてしまえばいいというのが考え方です。通常Javaスクリプトを順番に貼っていくと順番に組み合わされるので、われわれのコンテナの中に入れたタグを一遍に読み出してしまうというわけです。
⇒
あ。ココ、コンテナタグの事かな。
DMPがデータ収集する際には、タグマネ的なロジックもやっぱり必要なんだろうな~。
------
色々と具体的な事が書いてあり、非常に参考になった。
DMPのデータ収集する際に、タグコンテナを活用するとなると、タグマネの知見も必要そうだな。
そろそろ、今年あたりから、各DSP導入したはいいけど、タグ管理が無理!っていうクライアントが増えていきそうだから、各社リリースしているタグマネサービスの需要は増えそう。
(スケールアウトのこの纏め記事が秀逸)
これ、非常に参考になった。
以下、参考になった箇所を引用。
------
一番よくある話が、デジタリスを入れたらページが遅くなったと言われてしまった事ですね。
このような問題が発見されると、広告主様や代理店様は、まず広告のタグを全部取る作業をしなくてはいけません。1個1個タグを入れ直して、どのタグが悪さをしていたのかを検証するわけです。
⇒
これ凄い大変だよな…。
結果として広告配信しても、このタグ調査中はトラッキングデータ取れなくなるわけだし。
死活問題だよな。
現状、お客様のどのページにどのタグを入れるかというルールに関しては、代理店様が設計しているケースが多いのですね。
「ベン図」と言うのですが、どのようなユーザーに対してどのようにユーザーを足すか、引くか、除外するかと言ったルールをイメージして、それを直接URLで数式のように足したり引いたりする必要があるのです。例えばクリテオさんではトップのページのタグ、商品詳細のタグ、申し込みフォームのタグ、コンバージョンページのタグというように幾つかタグを分けて、どのユーザーがどこまで到達したかを判別し、自動的にリコメンドのバナーを配信するというようなことをシステムで行っています。
これらのルールを、日本の国産DSPである「マイクロアドブレード」とか、グーグルの「GDN」など、個別にルールを作っていくのですが、誰に対してリターゲティングを出すかというマーケティングの全体像としてはまったく統一されていないのが現状です。
⇒
Criteoのタグの仕組みって、そうなっていたのね。
ていうか、他も多分、基本は、同じだろうけど。
Fringeとしては、やはりタグマネから「オーディエンスデータのマネージメント」という根っこの所を握りたいんだろうなぁと改めて思った。
いろんなロジックがあるのですが、すごく分かりやすい話で言うと、複数埋め込まれたタグの中で速いほうから読み出すというものがあります。例えばデータセンターが近いと物理的に速かったりするわけです。
それでは10個タグが入っていたうち、1個遅いのがあったときに、そのタグが一番最初に読み込まれてしまうと他のタグの読み込みがすべて遅れてしまうので、速いものを先に読み込ませるということですか?
通常ウェブサイトを上から下まで読むときには、コードは順番に読まれるのですね。ただ、タグというのは順番に読むべきものではなくて、いろんなサーバーに問い合わせがいくものなので、一遍に問い合わせてしまえばいいというのが考え方です。通常Javaスクリプトを順番に貼っていくと順番に組み合わされるので、われわれのコンテナの中に入れたタグを一遍に読み出してしまうというわけです。
⇒
あ。ココ、コンテナタグの事かな。
DMPがデータ収集する際には、タグマネ的なロジックもやっぱり必要なんだろうな~。
------
色々と具体的な事が書いてあり、非常に参考になった。
DMPのデータ収集する際に、タグコンテナを活用するとなると、タグマネの知見も必要そうだな。
そろそろ、今年あたりから、各DSP導入したはいいけど、タグ管理が無理!っていうクライアントが増えていきそうだから、各社リリースしているタグマネサービスの需要は増えそう。
(スケールアウトのこの纏め記事が秀逸)
ラベル:
Tag Management
2013年1月21日月曜日
BrightTAGのFAQを見てみる
BrightTAGのFAQページを見て、再度学習。
実務で携わらないので、こういうページを見て、定期的に復習。
以下転載。
----------
これ、Javascriptのサンプルコードらしい。
あと、 下記にあるfourth-partyって何だ??
This number doesn’t reflect the high volume of fourth-party/piggybacked tags that are often appended to existing tags already in place.
⇒
(Google翻訳先生より)
この番号は、多くの場合、すでに実施されている既存のタグに追加されfourth-party/piggybackedタグの高いボリュームを反映していません。
データ収集の概念的なフローは分かり易かった
Piggybackは、何となく把握してるつもり
Piggybacking : It is possible for tags to be chained together through a process called “piggybacking.” This enables tags to be appended to existing tags already in place on the website without making any changes to the page code.
⇒
(Google翻訳先生より)
それはタグのためと呼ばれるプロセスを介して連鎖させることが可能ですこれは、タグがページのコードを変更せずに、既にウェブサイト上の所定の位置に既存のタグに追加することを可能にする"便乗"。便乗すると、サイトへのタグの数十を追加し、サイトの所有者が施設内には、意識していないかもしれないというサービスを導入することができます。、タグの歴史についてもっと読むタグのコンテナと"に便乗ここへの道は、弊社ウェブサイトの"ページ。
----------
うーむ、fourth-partyってなんだろ…。
また、知らない単語が出てきた。
Piggybackはコンテナタグと関連しているというのは、何となくイメージつく。
スケールアウトのこのエントリで概念的には理解していたつもり。
コンテナタグの具体的なシーケンスは、以下の図が非常に参考になる。
※引用元はこちら
ここらへんは実際に運用している人にきちんと聞いて、理解したい。
あと、BrightTAGってDMP的なことも出来そうな気がするのだが、しているのかな?
ていうか、そもそもDMPがどうやって収益上げているのか、知りたい。
3rdPartyCookie収集して、そのデータを加工して販売しているというは概念的に解るのだが、どうやって収益をCookie提供社(DataProvider)に按分しているのかな?
確か、国内ではオプトやオーディエンスサイエンスがCookie設置したサイトに按分していると聞いたことあるが、実際の按分比率はどうやって算出しているのだろうか。
実務で携わらないので、こういうページを見て、定期的に復習。
以下転載。
----------
これ、Javascriptのサンプルコードらしい。
あと、 下記にあるfourth-partyって何だ??
This number doesn’t reflect the high volume of fourth-party/piggybacked tags that are often appended to existing tags already in place.
⇒
(Google翻訳先生より)
この番号は、多くの場合、すでに実施されている既存のタグに追加されfourth-party/piggybackedタグの高いボリュームを反映していません。
データ収集の概念的なフローは分かり易かった
Piggybackは、何となく把握してるつもり
Piggybacking : It is possible for tags to be chained together through a process called “piggybacking.” This enables tags to be appended to existing tags already in place on the website without making any changes to the page code.
⇒
(Google翻訳先生より)
それはタグのためと呼ばれるプロセスを介して連鎖させることが可能ですこれは、タグがページのコードを変更せずに、既にウェブサイト上の所定の位置に既存のタグに追加することを可能にする"便乗"。便乗すると、サイトへのタグの数十を追加し、サイトの所有者が施設内には、意識していないかもしれないというサービスを導入することができます。、タグの歴史についてもっと読むタグのコンテナと"に便乗ここへの道は、弊社ウェブサイトの"ページ。
----------
うーむ、fourth-partyってなんだろ…。
また、知らない単語が出てきた。
Piggybackはコンテナタグと関連しているというのは、何となくイメージつく。
スケールアウトのこのエントリで概念的には理解していたつもり。
コンテナタグの具体的なシーケンスは、以下の図が非常に参考になる。
※引用元はこちら
ここらへんは実際に運用している人にきちんと聞いて、理解したい。
あと、BrightTAGってDMP的なことも出来そうな気がするのだが、しているのかな?
ていうか、そもそもDMPがどうやって収益上げているのか、知りたい。
3rdPartyCookie収集して、そのデータを加工して販売しているというは概念的に解るのだが、どうやって収益をCookie提供社(DataProvider)に按分しているのかな?
確か、国内ではオプトやオーディエンスサイエンスがCookie設置したサイトに按分していると聞いたことあるが、実際の按分比率はどうやって算出しているのだろうか。
ラベル:
JavaScript,
Tag Management
2013年1月16日水曜日
「RTBがデジタル広告の主役になるためには何が必要なのか?」雑感
admarketechのRTB関連エントリを読んだので、雑感。
日本が2014年にはイギリスを超えて、世界2位のRTB市場になるとの推測は、少し眉唾な気がする。
現状、殆どのDSPがリタゲメインでRTBを利用している中、どこまできちんとオーディエンスターゲの環境が整うのかな?
昨年、DSPプレイヤーは出揃ったと思うので、今年はいよいよ実運用の年になり、本エントリ最後でも書かれている様にどこに頼むのではなく、だれに頼むかという流れになるかと。
ただ、そうなった時にいかにユニークなオーディエンスデータを保有しているかが、競争優位性になるんだよね?
そうなると、楽天やリクルートみたいなプラットフォーマーがいよいよ本格的に自社のデータを活用したRTBに力を入れてくる気がする。
プラットフォーマーがDSPをリリースして、プライベートエクスチェンジなエコシステムを構築してくる可能性もあるわけで、そうなると代理店とか大変になるんだろうな。
あと、キモはやはりSSP側がどの様に対応するのかとDMPプレイヤーがきちんと出てくるかという事かな。
今のSSPって、本当のイールドマネジメントが出来ていない気がするので、RTBだけじゃなく、純広告もきちんと対応してくれれば、もっとメディアもアドテク領域に出てくるのかなと思う。
あとはDMP。これがUSみたいにきちんと機能すれば、もっとオーディエンスターゲ市場は活性化してくるはず、現状は各DSPのデータ保有量が競争優位性となっているが、解析で差別化されてくると、ベンチャーとかももっと出てきてUSみたいなカオスになって活性化される気がする。
(ただし、今のUSのカオスマップ的なセグメントは決して良いとも思えないが…)
で、エントリにも書かれているスマホ。これが最も厄介な気がする。
アプリがコンバージョンポイントになるから、スマホのRTBは正直マネタイズするには厳しい気がするんだよな~。
日本が2014年にはイギリスを超えて、世界2位のRTB市場になるとの推測は、少し眉唾な気がする。
現状、殆どのDSPがリタゲメインでRTBを利用している中、どこまできちんとオーディエンスターゲの環境が整うのかな?
昨年、DSPプレイヤーは出揃ったと思うので、今年はいよいよ実運用の年になり、本エントリ最後でも書かれている様にどこに頼むのではなく、だれに頼むかという流れになるかと。
ただ、そうなった時にいかにユニークなオーディエンスデータを保有しているかが、競争優位性になるんだよね?
そうなると、楽天やリクルートみたいなプラットフォーマーがいよいよ本格的に自社のデータを活用したRTBに力を入れてくる気がする。
プラットフォーマーがDSPをリリースして、プライベートエクスチェンジなエコシステムを構築してくる可能性もあるわけで、そうなると代理店とか大変になるんだろうな。
あと、キモはやはりSSP側がどの様に対応するのかとDMPプレイヤーがきちんと出てくるかという事かな。
今のSSPって、本当のイールドマネジメントが出来ていない気がするので、RTBだけじゃなく、純広告もきちんと対応してくれれば、もっとメディアもアドテク領域に出てくるのかなと思う。
あとはDMP。これがUSみたいにきちんと機能すれば、もっとオーディエンスターゲ市場は活性化してくるはず、現状は各DSPのデータ保有量が競争優位性となっているが、解析で差別化されてくると、ベンチャーとかももっと出てきてUSみたいなカオスになって活性化される気がする。
(ただし、今のUSのカオスマップ的なセグメントは決して良いとも思えないが…)
で、エントリにも書かれているスマホ。これが最も厄介な気がする。
アプリがコンバージョンポイントになるから、スマホのRTBは正直マネタイズするには厳しい気がするんだよな~。
2013年1月10日木曜日
Fringe81、タグマネジメント「TagKnight」リリース
3PASのdigitaliceを提供しているFringe81がタグマネ「TagKnight」を2/4にリリースするとの事。
ワンタグではなく、タグマネジメントという事で、機能も明確化されている。
以下、リリース抜粋。
-----------
TagKnightで外部広告タグの監視を行うことによる新たな4つのメリット
1.コミュニケーションコストの削減
2.オーディエンス管理の効率化
3.ウェブサイトの高速化
4.第三者配信アドサーバ「digitalice」とのシームレスな連携
-----------
2のオーディエンス管理という所がキモ。
以下リリース内記載「TagKnightは外部広告タグを設定するルール毎にどの程度のユニークユーザーに接触しているかを算出することが可能です。これにより、様々な外部広告タグを登録する前に広告効果のシミュレーションができます。最適な外部広告タグの設定を行うためのPDCAを圧倒的に早く回すことが可能です。」とある様に、タグマネ提供することで、Fringe81に情報が集約されるという事。
ただ、これでどの程度、オーディエンス管理が出来るのかというのはよくわかっていないが…
ティザーサイトに、問い合わせすれば、タグマネ課題・事例集がもらえると書いてあったので、勉強の為に問い合わせしてみようかな?
ワンタグではなく、タグマネジメントという事で、機能も明確化されている。
以下、リリース抜粋。
-----------
TagKnightで外部広告タグの監視を行うことによる新たな4つのメリット
1.コミュニケーションコストの削減
2.オーディエンス管理の効率化
3.ウェブサイトの高速化
4.第三者配信アドサーバ「digitalice」とのシームレスな連携
-----------
2のオーディエンス管理という所がキモ。
以下リリース内記載「TagKnightは外部広告タグを設定するルール毎にどの程度のユニークユーザーに接触しているかを算出することが可能です。これにより、様々な外部広告タグを登録する前に広告効果のシミュレーションができます。最適な外部広告タグの設定を行うためのPDCAを圧倒的に早く回すことが可能です。」とある様に、タグマネ提供することで、Fringe81に情報が集約されるという事。
ただ、これでどの程度、オーディエンス管理が出来るのかというのはよくわかっていないが…
ティザーサイトに、問い合わせすれば、タグマネ課題・事例集がもらえると書いてあったので、勉強の為に問い合わせしてみようかな?
ラベル:
Tag Management
2013年1月7日月曜日
「mixiインタレストターゲティング リニューアルの裏側」エントリ雑感
Blog「adtech周辺に興味がある人の四方山話」の筆者が会社Blogに書かれたエントリが非常に興味深かった。
ターゲティング広告では、一般的とされているクラスタリング生成が、実は更新が非常に困難で、mixiの旧インタレストターゲティングではボトルネックになっているというのは、「へぇ~」という感じだった。
以下、エントリから転載。
--------
クラスタの更新はある時点で停止しており、最新のmixi内の興味関心情報を完全には活用できていない状態(例えば、最近興味関心のボリュームが多そうなAKBやスマートフォンなどといったもの)でした。
比較的最近話題になっている興味関心情報への対応ができていないため、大きな機会損失となっていました。
--------
で、新しいインタレストターゲティングでは、中間データであったクラスタを廃止し、コミュニティを直接組み合わせる形で広告商品を作成するという手法が採用されているとの事。
いくつかのキャンペーンでターゲティングなし、旧インタレストターゲティング、新インタレストターゲティングを同時に配信して効果検証を行い、おおむね新インタレストターゲティングに統計的に有意な効果があることが確認出来たとの事。
最近、PCでオーディエンスターゲのROIがあまり良くないとの話をちらほら聞いたりします。
クラスタリングがフレッシュでないという問題が根本的にあるのかもしれないなぁと思った次第。
行動履歴ベースのターゲティングって、現状だと結構厳しそうだな~。
その点、Googleやヤフー!は、検索クエリというその瞬間のユーザーニーズを把握しているから、大きな強みだよなぁ。
DSPとかも多分、検索クエリがBiddingの値付けに際して、大きな役割を果たしていそうだし。
ターゲティング広告では、一般的とされているクラスタリング生成が、実は更新が非常に困難で、mixiの旧インタレストターゲティングではボトルネックになっているというのは、「へぇ~」という感じだった。
以下、エントリから転載。
--------
クラスタの更新はある時点で停止しており、最新のmixi内の興味関心情報を完全には活用できていない状態(例えば、最近興味関心のボリュームが多そうなAKBやスマートフォンなどといったもの)でした。
比較的最近話題になっている興味関心情報への対応ができていないため、大きな機会損失となっていました。
--------
で、新しいインタレストターゲティングでは、中間データであったクラスタを廃止し、コミュニティを直接組み合わせる形で広告商品を作成するという手法が採用されているとの事。
いくつかのキャンペーンでターゲティングなし、旧インタレストターゲティング、新インタレストターゲティングを同時に配信して効果検証を行い、おおむね新インタレストターゲティングに統計的に有意な効果があることが確認出来たとの事。
最近、PCでオーディエンスターゲのROIがあまり良くないとの話をちらほら聞いたりします。
クラスタリングがフレッシュでないという問題が根本的にあるのかもしれないなぁと思った次第。
行動履歴ベースのターゲティングって、現状だと結構厳しそうだな~。
その点、Googleやヤフー!は、検索クエリというその瞬間のユーザーニーズを把握しているから、大きな強みだよなぁ。
DSPとかも多分、検索クエリがBiddingの値付けに際して、大きな役割を果たしていそうだし。
ラベル:
Targeting
登録:
投稿 (Atom)