Contents Delivery Managementという考え方

地震速報の話

Iさん:ヤフーの全ページに一気に情報を反映させる仕組みってないかな?
yamaz:  広告サーバはどうですかね?設備はもうあるし、クリックや表示カウントもできますよ。

 


1秒間に数万アクセス――地震発生時にYahoo! JAPANトップに現れる“あの枠”の裏側 - Yahoo!ニュース スタッフブログ

 

当時ヤフーの全ページに一気にデータを反映させる仕組みは広告サーバしかなかったので、地震速報の実装は広告サーバをベースに行われた。もう10年ほど前の話だ。
 

Contents Delivery Managementという考え方

 
弊社はいわゆる広告システムを作っている会社だけど、広告システムを9年前に作ろうと思ったときに「広告システムって結局のところなんなのだろう?」というのを非常に考えた。いわゆる「バナー配信システム」を作ることはもちろんすぐできたけれど、今後ありとあらゆるインターネットの広告配信ニーズに応えようと思ったときに単なるバナー配信システムという作りではいつか行き詰まるだろうとも思っていた。
 
前の地震速報の実装を広告サーバベースで行った経験から、インターネットにおいて表示すべきコンテンツはマークアップ言語で全て記述できるので、結局のところ
 
その瞬間の状況に応じた最適なコンテンツ(= Markup Languageで記述された小さなテキスト片)を超柔軟かつ超高速に選択し、配信し、集計できる仕組み
 
こそが広告配信システムの本質だという考えに行き着いた。
 
なので広告システムを作るにあたっては、まず超汎用的なコンテンツ配信システム(Contents Delivery Management System)を構築し、その上の1アプリケーションとして汎用の広告システムを乗せるという構成を取ることにした。SSP/DSP/3PASなどは上記の考え方に沿うと広告システム上の1アプリにすぎないので、さらにその上に実装するという形を取った。
 
 
 f:id:yamaz:20150313193134p:plain
 
 
# 余談だけど弊社広告サービスの画像サーバの配信ホスト名である
# i.socdm.comはScaleOut Contents Delivery Managementの略
 

その瞬間の状況に応じた最適なコンテンツってなんだ?

 

さて「その瞬間の状況に応じた最適なコンテンツ」とはいったい何だろう?

 

1. 手元にあるコンテンツのうちで

2. その瞬間に出してOKなもののうち

3. その瞬間において一番優先度が高いもの

 

がその答えになる。コードだとこんな感じ

 

class ContentsDeliveryController < ApplicationController

   def lookup
      Contents.all.grep(:can_delivered?).max(:priority).to_html

   end

end

 

この考え方は比較的いろんなところに応用が利く。

 

1. インターネット全部のコンテンツを対象に、ワードに応じた結果を表示
2. あちこちの記事のうち、ユーザに応じて優先度が高い順番に表示
→キュレーションサービス
3. 各ランキングを順番に出す
→ランキングページ
 
また配信コントロールもいろいろできて
 
1. n回見せたら止める
2. ある日時を過ぎたら配信開始・停止
3. 特定の条件になったら配信
 
などは最も得意とするところで、いわゆるマイクロサービスと呼ばれるものもこの考え方に従って実装すれば比較的はかどると思う。
 

最後に絶賛エンジニア採用中

 
現在弊社の広告システムはContents Delivery Managementという考え方を元に実装されていて、月間数千億アクセスであってもいまのところうまくいってます。そんなシステム中身を見てみたい!俺がもっとすげーの作ってやるぜ!という方、是非弊社に応募ください。
 
採用情報 : ScaleOut
 
 
特に機械学習方面の応募をお待ちしておりますので、どうぞよろしくお願いいたします。
 
(おしまい)

あわせて読みたい

30分でわかる広告エンジンの作り方 from Daisuke Yamazaki

 

TLを汚すことなくGunosyに自分好みの記事を紹介して貰う方法

時間がない人用、三行要約

  1. Gunosyで「自分の興味があるジャンルのワード site:gunosy.com」 で検索し、その先のページでリンクを幾つかクリックして1日待てば良い感じになってるよ(例: 「レシピ site:gunosy.com」)
  2. アルゴリズム変えてくるかもしれないから一時的な技だよ
  3. 自分好みになったページはデフォルトで公開設定になってるので、非公開にするか趣味に走り過ぎないよう気をつけてね

はじめに

Gunosyと過ごした4週間〜1か月で推薦記事はどう変わったか

Gunosyで自分好みの記事を紹介してくれないのに不満を持っている方がいる。


Gunosyはとても優秀なキュレーションサービスで、TwitterもしくはFacebookと連携させると自分のソーシャルグラフを分析して自分にあったニュース記事を紹介してくれる。そのキュレーションはとても優秀で、「なぜこれを?」と思うこともしばしばだ。


またGunosyには今のところTLのペルソナを強化する方向の記事しか紹介してくれないという欠点があって、「このキュレーション能力で他ジャンルの記事を紹介してくれよ」と思うことがしばしばあった。
また「Twitter的にはxxxxな俺だけど、俺が知りたいのはyyyy系なんだ」ということをしようと思うとTLにキュレーションしてほしいジャンルを書いたり、そのジャンルを紹介してくれるユーザをフォローしたりする必要があって、結構めんどくさい。


TLや自分のソーシャルグラフは汚したくないけど、とは言えGunosyのキュレーション能力はとても優秀なので、そこだけなんとか拝借できないかと色々やってみたところ、下記の方法でうまくいったので紹介する。

やり方

  1. 「自分の興味があるジャンルのワード site:gunosy.com」 で検索する。例: 「レシピ site:gunosy.com
  2. ググッた結果ページのいくつかを辿ってそこにある記事のリンクをいくつかクリックする
  3. 1日待つ


ちなみに下記が上記方法を試した結果。「ビジネス、プログラム、ゲーム」だったキュレーションが
一夜にして「グルメ、子育て、ゲーム、映画、サッカー」に変わったのがわかると思う。

術前
http://gunosy.com/yamaz/2013/03/07
術後
http://gunosy.com/yamaz/2013/03/08

解説

めんどくさいので省略。簡単に言うとGunosyは今のところGunosy経由でTLに流れた記事に対する反応に対して高い得点がつくようなアルゴリズムを採用しているっぽいので、それを利用させてもらった。

注意点

  1. この手法は運営側がアルゴリズムを変えてくるかもしれないから一時的なものです。また時々この方法をとってあげないと元のキュレーションにだんだん戻っていきます(多分)
  2. Gunosyでは自分のページはデフォルトで公開です。なので、調子乗ってカスタマイズし過ぎると他人に見られて困るケースがあったりするかもなので、非公開にするか程々にしましょう。

おしまい

追記

まさかの公式からのお墨付きがw

http://gunosy.tumblr.com/post/45245906565/rss-gunosy

RTB用のADサーバこそ最強である必要がある件

明日はアドテック東京というデジタルマーケティングのカンファレンスが行われる。


最近広告配信周りでRTB(RealTimeBidding)というシステムがはやりつつあるが、RTB用のADサーバこそ最強である必要があるということを述べてみたいと思う。



RTBの仕組みというのは簡単に言うと下記のような感じになる。


1. 広告サーバ(SSP)に問い合わせがあった場合、バックに接続されたRTBの広告サーバ(以下RTBサーバ)に対して問い合わせをオークション形式で行う



2. RTBサーバは来たリクエストに対していくらで購入ができるかを返し、SSPは最も高い単価をつけた広告をユーザに返し、表示する(CPMというのは広告単価だと思えばいい)




上記の処理を1つの広告表示のたびに行うので、Real Time Bidding(RTB)というわけだ。RTBのエコシステムにおいては自分の都合のよいユーザのアクセスの時にだけ高い単価をつけて在庫を買い付ければよいため、結果として

  1. 広告主にとっては在庫を安く仕入れることができる
  2. メディア側は高いインプレッション単価で在庫が売れる

ということが可能になり、理想的には広告主・メディアともに都合よいシステムだといわれている。


ではこの実装について考えてみよう。オークションを開催する広告サーバの実装は比較的簡単だ。単に広告リクエストを非同期に各RTBサーバに投げ、戻ってきたリクエストをオークションして結果を返せばよい。


ではRTBサーバ側の実装はどうだろう?単純に広告サーバからリクエストが来たらその条件にあった最適な広告を妥当な価格で返せばいいので、こちらも一見簡単そうに見える。


それは本当だろうか?


RTBサーバは広告サーバに接続されるRTBの事業者が増えるほど広告を出せるチャンスが少なくなっていくという特徴がある。つまりこういうことだ。


RTB業者が3社しかいない場合、1業者が勝つ確率は単純計算で1/3になる。




RTBが9社に増えた場合、1業者が勝つ確率は1/9になる。



例えばオークションの開催側のアクセスが月間100億impあるようなケースでは下記のようなことになる。

  1. 全オークションに参加しようと思うと月間100億impを捌く能力の持った広告サーバが必要である
  2. RTB業者の数が増えると勝つ確率が単純に下がっていく。
  3. 例えば上記の例のようにRTB業者が3社から9社に増えるとサーバコストは変わらないのに売上が1/3になる。


RTBのサーバはオーディエンスターゲティングなど1ユーザごとのターゲティングでもって単価を上げるという手法をとるケースが多いため、高度な機能を持たせる必要があるが、それに加えてアクセス自体も相当に安く捌けるシステムでないと接続業者の増加に伴って割に合わなくなる。


よってRTB用の広告サーバは今までにもまして強力なサーバソフトウェアである必要があるというのが今回の主張だ。


このあたりのことを半年ほど前にRTBをやってらっしゃる業者さんに聞いてみたところ、「実際RTBに参入するのは4,5社くらいだから大丈夫じゃないですか?」という話だった。しかし実際はもうすでにRTBに参入している業者は5社以上になっていて今後も増加傾向なので、ほんとに大変な時代に突入したなと思う。


(おしまい)