hail2u.net

Web Bugをフィードに埋め込む

Posted at 2006-09-05T15:37:00+09:00 in RSS

ひとつ前のエントリで取り上げたように、エントリ内の画像を利用するとエントリの閲覧者数を大雑把に知ることが可能で、リファラを数え上げるなどをすればいろいろなサービス経由での閲覧者数を大雑把に把握することも可能。しかし、フィードの本当の購読者数にはそのまま応用することは出来ない。そこで古くからあるWeb Bug(あるいはWebビーコン)と呼ばれる手法を使ってやってみようとかそんな話。

Web Bugは小さな画像をWebページに埋め込んで、その画像へのアクセス・ログを閲覧してニヤニヤするというある程度正確なページ・ビューを割り出すという類のもの。Webページへのアクセス・ログによる統計と違い、いわゆるグラフィカルなブラウザのアクセスだけを対象にできるので、より価値のあるデータを得ることが出来る。

これをフィードに応用する場合も特に難しいことはなく、適当に各エントリにあたる部分に小さな画像を埋め込むようにしてやれば良いだけ。具体的にMovable TypeのAtom Indexテンプレートを例にすると、

<entry>
  <title><$MTEntryTitle remove_html="1" encode_xml="1"$></title>
  <link rel="alternate" type="text/html" href="<$MTEntryPermalink encode_xml="1"$>" />
  <link rel="service.edit" type="application/atom+xml" href="<$MTCGIPath$><$MTAtomScript$>/weblog/blog_id=<$MTBlogID$>/entry_id=<$MTEntryID$>" title="<$MTEntryTitle encode_html="1"$>" />
  <id><$MTEntryAtomID$></id>

  <published><$MTEntryDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></published>
  <updated><$MTEntryModifiedDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></updated>

  <summary><$MTEntryExcerpt remove_html="1" encode_xml="1"$></summary>
  <author>
    <name><$MTEntryAuthorDisplayName encode_xml="1"$></name>
    <MTIfNonEmpty tag="MTEntryAuthorURL"><uri><$MTEntryAuthorURL encode_xml="1"$></uri></MTIfNonEmpty>
  </author>
  <MTEntryCategories>
    <category term="<$MTCategoryLabel encode_xml="1"$>" />
  </MTEntryCategories>
  <content type="html" xml:lang="<$MTBlogLanguage ietf="1"$>" xml:base="<$MTBlogURL encode_xml="1"$>">
    <$MTEntryBody encode_xml="1"$>
    <$MTEntryMore encode_xml="1"$>
    <div><img src="http://example.com/images/web-bug.png?id=<$MTEntryID$>" alt="Web Bug" width="1" height="1" /></div>
  </content>
</entry>

こんな感じにcontents要素の最後にWeb Bug画像を追加するだけで良い。各エントリ固有のIDをWeb Bug画像のクエリとして追加しておく必要はある。他のblogツールでもこの程度の手間で実現できるはず。あとはWebサーバーのログを閲覧してニヤニヤすればフィードの購読者数を割り出せば良い。このケースでは、フィードのみにWeb Bug画像を追加しているので、Web Bug画像へのアクセス数とフィードの購読者数はほぼ一致するはず。

このサイトのフィードにはまだWeb Bug画像は埋め込んでいない。やろうかなーとかやってみたいなーとは思うけど、Web Bug画像に嫌悪感を抱く人もいるらしいので躊躇。

購読者の内訳

Posted at 2006-08-09T00:15:00+09:00 in RSS

FeedBurnerのsubscriberの円グラフ。11ヶ月前と比べると大幅に内訳が変化。3強がBloglinesとlivedoor Reader、FEEDBRINGER.netとWeb型のフィード・リーダーが占めるように。僕はもう完全にlivedoor Readerユーザーになってる。Live Bookmarksの次にもWeb型のFeedpath。

FirefoxのLive BookmarksやSageはユーザー数にほとんど変化無し。スタンド・アローンのフィード・リーダーは軒並み購読者数は激減している。そこそこユーザーが残っているのはRSSバーくらいで、ブラウザでという人ばかりになったということになりそう。ソーシャル・ブックマーク・サービスとの連携やページをサクサク開けるという点で明らかにブラウザで読めるほうが良いものね。

Bloglinesでの購読者数は、かなりの数のデッド・ユーザーも含んでいると思う。実数はlivedoor Readerとほぼ同じくらいだろうか。

Bloglinesにホットキーが導入

Posted at 2005-10-13T12:24:00+09:00 in RSS

Bloglinesにホットキーがつきました。Newsにはまだ出てないですが、jとsだけで全ての未読を順に見ていける感じ。微妙・・・な感じもしますが、それなりに便利でもあるような(どっちだよ)。「ギザスゴス！」とか言う感じではないことは確か！

パフォーマンス的にも未読管理の観点からも、fよりsで読み進めた方が良さそう。

jで最後の記事まで進んだ状態で、更にjを押した場合は、s相当の挙動になるとかだと、jで全部読み進めることが出来るので楽そう。

FirefoxユーザーはFAYTを「Begin finding when you begin typing」にしているとバッティングしてしまって上手く動かないので、Optionsからオフにすると良いかも。オフにしても/やCtrl+Fなんかでいけるのでオフでもさほど気にはならないような。

設定でON/OFFできるようにはした方が良い気がする。

あと、タイトルに未読記事数の表示とかも付いてる。

Feed History

Posted at 2005-09-23T00:46:00+09:00 in RSS

Feed Historyはフィードの過去ログを機械的に辿ることを可能にするドラフト段階の仕様です。つまり、最近10件のフィードとかだけではなく、一ヶ月前のフィードや一年前のフィードなども取得できるというわけ。多くのフィード購読者にはあまり意味が無さそうな仕様ですが、フィード・アグリゲーター・サービス(Google Blog SearchやBloglines、Feedsterなど)はインデックスの強化を機械的に行えることにつながるので、こういった類の仕様は大歓迎なのではないかとか。

通常の検索エンジンの場合は、リンクを辿ってインデックスというアプローチのため、どこからかリンクが張られてさえいればどんなに古いページでもインデックスすることは可能ですが、フィード・アグリゲーターは巡回を開始した日付以前のフィードの内容をインデックスすることはできません。もしあるフィードがFeed Historyを利用して過去ログを取得できるようにしていたとしたら、古いページを含めてインデックスすることが可能になり、フィード・アグリゲーターはインデックスの強化を、そのユーザーはより良い検索結果を、そしてフィード提供者はより良いヒット率を、とそれぞれ利益を得られることになるわけです。

とはいうものの、巡回する側が面倒な仕組みな気がしないでもない。archives.xmlとかいう予め決めたファイル名で過去ログを全部ぶち込んだフィードを用意しておいて、勝手に拾っていって貰うとかだと簡単そう。転送量で死にそうですが。

フィード向け広告

Posted at 2005-08-09T15:29:00+09:00 in RSS

フィードに広告を！という試みはblogによってフィードがクローズ・アップされた当初から試行錯誤されていました。その走りはMoreover Technologiesが以前(今はもう個人向けにはやってないかも)提供していたニュース記事のフィード配信などでしょうか。Moreover Technologiesは広告専用のitem要素を設けるというアプローチでしたが、最近は記事そのものに横長バナー広告もしくは一行テキスト広告を追加するというアプローチのものが多いようです。

前者の広告記事を設けるというアプローチは、「更新チェックしたら広告だけ未読になった！MK5！」とか死ねる感じの現象がおきたりとかすること(もちろん配信側でそうならないように努力することは可能ですが)など、ユーザー側にストレスを感じさせることがあったりすることから闇に葬られた感じです。そもそもフィードの購読スタイル自体が飛ばし読み中心の人が多そう(私見)なので、広告記事は高確率で飛ばされ広告として効果が期待できないという問題もありそうですね。ただ、能動的ないわゆるメーラー型フィード・リーダー(BloglinesであるとかFeedDemonであるとか)ではなくスクリーン・セーバーやティッカー型向けのフィードとしては、広告をTV CM感覚で流すことが出来るのでなかなか効果が高いアプローチかもしれません。

対して記事そのものに広告を追加するというアプローチの場合は、例え記事と広告の関連性が低いとしても、記事そのものに目が留まる確立が高いためそれなりに広告の効果が高くなるはずです。最近の傾向としてこちらのアプローチにシフトしつつあるのは必然に近いでしょう。ただ、ビジネスから見ると、フル・コンテンツなフィードではフィードへの広告のみにしか期待できないので、自分のサイトの広告も生かすとなると要約主体のフィード、つまりSlashdotや@IT(要約が短すぎで、タイトルとほとんど変わらない情報量しかないため、フィードの広告の効果は期待できなそうな気がしますが)のフィードのような形になりそうです。

とかなんとかGoogle AdSense for Feedsに申し込んでみたり(結果はまだ来てない)しながら考えたことを書いてみたりしましたが、通常のblogではフィード向け広告よりもサイト向けをうまく利用し、フィードは人集めの手段と割り切った方が広告配信側と購読側の双方にバランスが良さそうかなぁという極普通の結論になったりしてます。

というか、広告をフィードで配信するというサービスが出てきて欲しいなと。そうすればどういう形でフィードに広告を潜りこませるかは配信側に自由があるし、フィード・リーダー(はもちろんどんなアプリケーション)をAdware化するのも(しなくて良いけど)簡単！そもそもフィードは配信フォーマットとしては優れていることがキモだと思うので、それに注力した形で広告事業とすり合わせる方が有用なんじゃないかなと思います。この話はフィードにより広告収益を上げるという上述の話とは少し方向性が違う話ですが、フィード向け広告の効果は購読者が使用しているフィード・リーダーの形態に依存する(メーラー型のフィード・リーダーでは広告専用記事は読み飛ばされる可能性が高いし、ティッカー型のフィード・リーダーでは各記事に追加された広告はそもそも表示されない可能性が高い)と思われるので、コンテンツのフィードと広告のフィードを分離し、フィード・リーダー側で適切な形で表示してやるという形だったらどうよ？とかそういう話です。まぁ配信する人間(企業)とフィード・リーダーを作成する人間(企業)は同一人物では無いのでムリなんですけど。

適当に書いているので心底堂(新語)エントリ。正直、最後の段落だけが書きたかったことだったりする。