RSSはどの程度の情報鮮度が必要とされるコンテンツに向いているか?
いつもCRM、ダイレクトマーケティング系のよいコンテンツを送ってくれる電通ワンダーマンさんのメールマガジンが、今回はRSSのネタだった。
CRM的な視点において「RSS」という個人情報が取得できない規格の可能性と限界がわかりやすく説明されており、よい内容だったと思う。
が、RSS屋から見て、一箇所注意が必要だと思う箇所がある。
RSSと情報鮮度についての箇所だ。
ある航空券の販売サイトにおいて、RSSでチケットの最安値情報を配信することで、チケットという時間的に有効期限のある商材を効率的に販売することに効果を発揮したとの事例もある。
情報更新頻度が高く、情報の鮮度に価値のある商材において、RSSはとても有効なコミュニケーション手段になりつつあるのだ。
(メール本文)
同メールマガジンでは、「時間的に有効期限のある商材を効率的に販売」するのに効果があったとしているが、これは現在のRSSの普及状況からすると問題にぶつかる可能性が高い。。
理由は、サーバー型RSSリーダーのクローリングタイムラグ、それからキャッシュの問題だ。
最大1日程度のタイムラグ
現在のサーバー型RSSリーダーのクローリング頻度は、数時間〜1日に一回程度だ。特にシェアの大きいMy Yahoo! やBloglinesがその程度の頻度でくるため、RSSの更新からエンドユーザー側にそれが伝わるまで最大1日程度のタイムラグが発生する可能性がある。
情報の有効期限までにそれ以上の余裕のあるコンテンツであればよいが、数時間以内に有効期限を迎えるコンテンツを工夫なしにRSSで配信しても、サーバー型のRSSリーダー上でエンドユーザがそれを目にするころにはすでに有効期限が切れている、ということがかなりの頻度で起こる。
情報の更新をXML-RPCで相手サーバーに伝える「weblogUpdates.ping」などの仕組みがうまく機能すればよいが、これにしても現時点では伝達の結果情報がクロールされることが必ず保証されるものではないので、やはり限界がある。
(もちろん、リーダー側の事業者も「最新情報が取得できる」ことは謳いたいだろうから、きちんと配信側と受信側が提携できるようになっていけば問題の解決は可能だろう。)
- メモ
- Yasushi IwataさんによるXML-RPC Specification の日本語訳
- いわゆる「更新Ping」として知られるWeblogs.Com のXML-RPC interface
キャッシュされたRSSアイテムの扱いが不統一
さらにこの問題をややこしくするのがキャッシュされたRSSの存在。
サーバー型RSSリーダーの多くは、一度クロールしたRSSの内容をキャッシュする。このため配信側で修正したり、削除したりしたコンテンツがサーバー型のリーダーでは残り続ける可能性があるという問題がある。
冒頭のような利用方法の場合、「このチケットは売り切れました」みたいな状態を伝えたい場合に困る。配信側で情報を削除しても、受信側には情報が残ってしまうからだ。
アイテムの内容変更や、削除されたアイテムをどうするというのは、現在の時系列のRSSという規格では十分に表現できない。RSS側でできるのはサーバーやRSS内のタイムスタンプいじるくらいだと思う(技術に詳しい方の突っ込み希望)けれど、これをリーダー側がどう処理すべきというのは特に統一された仕様にはなっていない気がする。
これらの問題は、RSSに同期関連(特に双方向の同期)の情報を持たせるSSE(Simple Sharing Extention)によって解決できる問題なんじゃないかと考えている。
(SSEでは、アイテムが「<sx:sync>」という要素を持ち、その属性に「version」とか「deleted」とかの情報が含まれるため、これによって同期先でもアイテムの削除や更新を知ることができる。)
- メモ
「んじゃどうすりゃいいんだよ!」にお応えできますかどうか、、。
現時点ではRSSは、そうしたゆるさを許容する規格だと思って使うのが無難だ。とか言いたいけれど、まあそうも言っていられない場合もあるのはわかる。
例えば冒頭のように時間にシビアな用途にRSSを使うのであれば、「特定のRSSについてはメーラー並みの頻度でチェックして、削除等も反映するティッカー的なリーダーとセットで導入する」みたいな工夫をする必要があるだろう。
いずれにしてもRSSは情報の規格でしかない。残念ながら、工夫せずに導入するだけで目覚しい効果が上がるというものではない。「WEBサイト」や「ブログ」みたいな概念と同じようなものだ。こつこつと、「こういうふうに使える」みたいな事例を積み上げていけるとよいなと思う。