2013-03-10

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

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

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

はじめに

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

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

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

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

やり方

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

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

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

解説

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

注意点

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

おしまい

追記

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

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

2011-10-26

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

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

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

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

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

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

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

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

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

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

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

それは本当だろうか?

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

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

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

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

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

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

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

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

(おしまい)

2011-04-11

RailsとCで広告システムを作って起業した話

4/10清澄白河で開催された大江戸ruby会議01で
「RailsとCで広告システムを作って起業した話」と題して話をしてきた。

speakerdeck.com

詳細はスライドに書いてあるが、弊社は全く後ろ盾などないスタートアップにもかかわらず、異様なまでに濃いrubyistを集めることができていて、発表後「どうやってそんなすごい人を集めることができたのか？」という質問をうけた。

実はこれも秘密はなく、「彼らは当時たまたま求職中であったり、転職したがってることをRails勉強会の後の飲み会で聞いたりしたので即スカウトした」というのが実際の所で、ぶっちゃけたところ運がよかったとしか言えない。
せいぜい教訓めいたことを言うならば「恋愛と同じく、振られた直後に隣にいるというのは割と重要だ」あたりだろうか。

大江戸Ruby会議01はとてもよい会議でした。ほんとはエンジニアを集めるのに札束が踊りまくっている昨今、いかに人を集めるかとかそういう話をしようかと思ったのですが、あまりに生々しすぎるのでそれは次の機会にでもしようと思います。

最後になりますが、スタッフの皆さん、asakusa.rbのみなさんお疲れ様でした!

(おしまい)