• Permuto Discoveries » The Ins and Outs of the Abandoned Cart
  ショッピングカートを放棄した際の理由などがキレイなInfographicになっています。コマース系サイトの方は印刷してデスクの壁に貼っておくとヒントになるかも。
• 配置をマスターして「機能するレイアウト」を作る大切なポイント | コリス
  テストを行っていく際にも、そのバナーなどの画像に入る目線などは結果に影響を及ぼすこともあります。細かいケアですが、こういった内容も制作側として押さえておきたいですね。
• Alertbox: スクローリングと注目(2010年03月22日）
  ページスクロールについては賛否両論あるものの、解析をするにあたっては1コンテンツ＝１URLでありたいもの。ページコンテンツ量をいかにうまくコントロールをしていくかも今後の課題なのかもしれません。

また、ある程度レポートを見るのに慣れてきている方であっても、色々なレポートを見続けていると、結局「そのレポートは何で見ていたのか？」といった疑問にあたり、迷子になることもあったりなかったり。

ということで、ウェブ解析のレポートを参照していく上で、「今、こういう目的でレポート見てます」という念頭に置いておくべき、目的を４つに分類してみました。

１：体重測定に利用する

ダイエットするときに体重計にのり、それと理想体重を比較しながら、何kg痩せるかを考えるように、サイトを運営、最適化していくにあたっても体重測定は必要です。いわゆる定点観測といったものです。

毎日どの位の人ら来訪しているのか、どの位のページが見られているのか、どのくらいのコンバージョンが起きているのか？といったサイト全体にまつわる基礎的な数字です。これらは日別に、まさに体重測定のようにトレンドを確認していくことで、サイトの変化を気づけるようにします。

また、月が終わった（レポート的には月初）タイミングでは、前月と合わせて、前年同月と比較することも忘れないようにしましょう。こういったことをきちんと続けていくだけでも、サイト全体の変化を捉えやすくなります。

流入についても、検索エンジン（PPC・無償）、バナー広告、Eメールなどからどのくらいの割合で来ているかを見るようにします。これらは日ごとに変化しにくいので、月別で確認をしていきます。

※以前紹介した Cube Model Beta だとベースの部分にあたります。

２：効果測定に利用する

週末少しハードなスポーツをしたら、それに対してどのくらい体重に反映したかを確認したくなるものです。出来れば疲れず、効果の高いものを続けるようにしたいもの。サイトの運営でも、投資が少なく、効果の大きいキャンペーンは残しておきたいもの。

ということで、キャンペーンごとの効果の測定をします。これらはツールによってコードの記述方法などは変わりますが、基本的には外部に設置したリンクにパラメータを設定することで、そこからの流入やコンバージョン数を確認できるようにします。

スポーツでもダイエットに適した運動と時間があるように、キャンペーンにもサイトや商材に適したものがあったりします。そのため、キャンペーンごとにかかった費用も含めてROI（費用対効果）も計算し、そのキャンペーンの良し悪しを判断できるようにします。

キャンペーン以外にも、サイト内で改善施策を実施したのであれば、その実施効果を確認する必要があります。この際は「〜といった仮説をベースに改善したので、その後こういった効果が期待できるはず」という確認指標を事前に確定しておくことで効果測定しやすくなります。というより決めておかないと分析の分析になり悲惨な状況を招きます。

※以前紹介した Cube Model Beta だと基本は上部のキャンペーン部分にあたりますが、場合によってツールなどのベースになる場合もあります。

３：課題を見つけるのに利用する

サイト内の課題を見つけるのに利用するレポートもあります。サイト内の循環が悪いと、せっかく流入が確保できていても、取りこぼしが多いため、結果サイト全体のROIを下げてしまっていることになります。

サイトの課題を見つける方法は正直沢山あるのですが、まずは下記のようなレポートを参照していくと良いと思います。

• 入口数が高く、直帰率の高いランディングページを特定する
• 線形型のパスの中での離脱箇所を特定する
• サイト内のTOPページや戦略的ページからのパスを確認する
• ページの参照数とコンバージョンへの貢献度を確認する

この時に意識をしていただきたいのは、なるべく大きな視点からブレイクダウンするようにします。その中で、入口数が多い、ページビュー・訪問が多い、コンバージョンに近いなど改善幅の高い部分に狙いを定めて絞り込んでいきます。

ここではまだ課題を１つに固定をする必要はありません。いくつかの候補をだしながら、仮説を見つける作業に入るわけです。

※以前紹介した Cube Model Beta だとベースの部分にあたります。

４：仮説を見つけるのに利用する

ある程度の課題のポイントが見つかったら、そこから具体的な改善策の仮説を見つける作業に入ります。その箇所に合わせて、深堀分析をしながら、仮説を作っていく作業になります。

この部分は「仮説」を作ることなので、必ずしもこのレポートを見たら解決策が見えますよ。ということではありません。あくまで考える上での一助となるものです。とはいえ、色々なデータが取れるウェブ解析ツールでは有用なレポートは多数あります。

ランディングページでは、リファラ情報が取得できるためサイト改善の仮説が立てやすい箇所とも言えます。流入したドメイン、キーワード、キャンペーンコードなどを確認していくと仮説としてみえてくる可能性が高いです。

線形フローでの離脱が多い場合や想定と違うフローが多い場合などは、前後のパスをもう少し詳細に分析をします。１つ前のページから、どのボタン・リンクをクリックすることと遷移しているのか？さらにそのもう１つ前はどんなページなのか？など。

ここは様々な角度から分析をしていくわけです。さらに詳細な分析をしていく場合もありますが、コストがかかり過ぎる場合もあるので、ある程度で見切りを付けることも大事です。ということで、ある程度の仮説がみえてきたらテストの実施にシフトさせてしまうほうが良いでしょう。迷ったらテストです。仮説なのでテストです。

※以前紹介した Cube Model Beta だとベースの部分にあたります。

まとめ

というこでおおざっくりと分析レポートを４つに分けて考えてみました。実際にツールによってレポートの名称であったり、見られるレポートが違う場合もありますが、考え方は全て同じです。

レポートを参照しているときに、なんのためにこのレポートを見ているのか？ということ立ち止まって考えることで、小難しいウェブ解析のレポートも見やすくなると思います。

ということでサイトの構造と指標の味方について少し。あれ、同じような話を書いた気がする…と思ったら書いてたけど、そこから拡張版で書きますっ！（サイトマップ、頭に入ってますか？／　コマースサイトのサイトマップ）

まずはハイレベルサイトマップ

自分がお客様と何かしら分析について話す場合は、なるべくハイレベルサイトマップを作り、最初に確認する用にしています。通常、サイトマップというとサイトに用意しているような、サイト全体のリンク集みたいなものや細かいURLとディレクトリの位置を記述したものを想像される方も多いと思います。

ハイレベルサイトマップとは、そういった詳細なものではなく、もっと、ざっくりとしたサイトマップで、サイト内の主要動線構造や機能の箇所、コンバージョンへのルートを確認するためのものです。

これを整理すると、サイト全体でどのようなルートでユーザーがフローを辿るのかが見やすくなります。

これを整理することでのメリットは

• サイトを俯瞰できるようになる。
• サイトの（マイクロ含む）コンバージョンの箇所が明確になる。
• フローの分析の手がかりになる。

といったことになります。分析する際の勘所がつけやすくなります。そして、何よりサイト全体の理解をするには早いわけです。なんでも細かいところからやってはダメです。大きくいきましょう。

一般的なサイト構造

ハイレベルサイトマップを整理することで見えてくることが多いのですが、サイトのフロー構造はいくつかに分類され、それらの組み合わせによって成り立っています。

メディアサイトやコマースサイトでも商品を探す部分などは、リンク構造が複雑にからみ合ったウェブ・回遊型などと呼ばれるものや、IRサイトや情報系サイトでは多く見られるヒエラルキー（階層）型、予約・購入などのフローで見られるライナー（線形）型などがあります。

さきほどのハイレベルサイトマップを作ると、サイトのどこがサイト構造として成り立っているかを俯瞰することができるようになります。

そしてこのサイト構造の大枠を理解しておくことで、ウェブ解析ツールでさまざまな課題点の分析をしていく際の、評価のポイントが見えてきます。というか、評価を分けなきゃおかしい部分もあったりするわけですよ。

コマースサイトやリード獲得系サイトの場合、ウェブ・回遊型と線形（ライナー）型の組み合わせパターンがほとんどです。ウェブ型で色々な情報を見せ、購買意欲が高まった時点でフォームに流すわけです。そしてフォームについてはライナー型で一直線なフローになってくるわけです。

このような組み合わせを考えた場合に、わかりやすい違いの例でいくと滞在時間や平均ページビュー数があげられます。ウェブ型の部分は、どんどん回遊をして購買意欲を高めてもらいたいわけで、滞在時間や平均ページビュー数の伸びを期待します。

しかし、ライナー型のフォーム部分はその逆です。滞在時間、平均ページビュー数が伸びているということは、何かしら詰まっているわけですよ。入力に手間取っているかもしれないですし、エラーをだしまくりかもしれないわけです。

この場合のライナー型の部分については、滞在時間、平均ページビュー数はある程度ひくくなった方がユーザビリティが向上しているとも言えるわけです。

まとめ

ということで色々とざっくりと、それでいてしつこくなく、まったりとした形でサイト構造について書いてみました。

ウェブ解析ツールの結果として出てくるものは数字です。ただ、これだけ眺めていても答えや課題は見つかりにくいものです。

サイト構造を頭に入れておいたり、実際にサイトと数字を見比べながら分析を行っていくことで、本質的な課題が見つかることが多くあります。

ということで特にハイレベルサイトマップなどはぜひぜひ一度作って頂くと良いと思いますよ！

今回のテーマ

もともとCS5プロモーションも含めて用意された場所でもあり、かつ、事前の申し込みでのデザイナーの方の割合が多かったため、今回は少しデザインのことも考えられるような会にするようなテーマにしたいと思っていました。

ということで実際に出したテーマが下記です。

ウェブ解析をサイトの中心に据える時に、
サイト運営者とサイト制作者は何を考え、どう歩み寄るのか？

実は登壇者に「職業：デザイナー」がいないという中でのテーマ選択だったので、もしかしたら聞いている方はなんとなくデザイナーが歩みよらないと！に聞こえたところもあるかもしれないのですが、そんな事は全くなく、むしろ登壇者達は自分たちが歩み寄らないとと思っている感じで登壇していました。

Twitterの反応の反応

前回の「解析しないと！」でハッシュタグがバズッターにあがったりもありましたが、今回もTwitterをふんだんに利用した展開をさせて頂きました。会場のStation5としてUstreamで配信もしていましたしね。ということで、Twitterの反応の反応などを少ししてみたいと思います。Togetter – まとめ「解析しないと！のTL」

FLASHの動的分析

最近、Flashとか動的なものの解析用データの取得を自前実装する事が多いので、指標の組み方とか数字の読み解き方とか勉強させてもらいたい。（Twitter / daishiro）

情報の取得自体は自前実装出来ても、解析データとして視覚的に表現したり、ドリルダウンや絞り込みしたりが厄介なんだよなぁ…（Twitter / daishiro）

実際にFLASHの場合は自前実装をされているところも多いわけですが、恐らく手間に比べて取得できるデータの内容だったり、後々の視覚表現などは大変だと思います。それだけでも対応している解析ツールを使う意味はあると思っています。

分析のレイヤーで考えると、RIAでの分析の場合は、それだけでサイトが完結していることは少なく、殆どの場合、HTMLで構成されたサイトの一部として機能していることが多いと思います。

そうした場合はRIA内部の計測はもちろんのこと、サイト全体で見たRIAの効果も合わせて検証していく必要があります。そういった場合も分析出来たりするのが、既に用意されたツールの良さなのかなと思ってます。

ハイレベルサイトマップの活用方法

ハイレベルサイトマップってどのように活用すればいいでしょうか？「行動」をみるには。。。？（Twitter / toshihiro miyakawa）

ハイレベルサイトマップ自体は、サイトの構造、動線、コンバージョンのポイントを明確にして、まずはそれを関係者でシェアできるということが最も重要なポイントだと思っています。

その上で主要なポイントにコンバージョンを埋め込むことだと思います。これにより、大枠でどういったファネルになっているかの構造を把握しやすくなります。

ここからはSiteCatalyst独特になってしまうのですが、実際の計測を考えた場合、いくつかのセクションレベルでのパスレポートを実装することを通常推奨しています。これを利用してセクションレベルでのパス分析を多角的に行って行くことで、ハイレベルサイトマップと実際のフローとのギャップ分析を行っていくことが出来るようになります。

テストは個々の最適化のつみあげ？

個々の最適化（バナーのA/Bテストとか細かいレベルのやつ）が、必ず全体の最適化につながるのかな？やっぱりテスト設計も重要になってくるよね。 （Twitter / Koji ISHIMOTO）

個々の最適化を細かく続けていくことである程度のポテンシャルアップにつなげることは可能だと思います。…が場合によっては部分最適だけされて、全体最適がされないことも多々あったりもします。

また、細かく思いつきで実施をしていっても、効果がすごく薄くなってきてしまうので、手当たり次第はあまりおすすめ出来ません。実際にテストを行う際は、ウェブ解析ツールで課題があり、かつ、主動線である部分を見つけ出し、プライオリティを付けながらテストを行っていきます。

自分の場合、テストを推進していくにあたって、アクション２割、計画８割だと思っています。計画の中でいかに効率良く、かつ、成功に結びつけられ、汎用性の高いナレッジを落としやすいものを検討していくかが非常に重要なポイントになるかと思います。

すぐに出来ることは？

大規模サービスサイトが前提で議論が進んでるけど、中小規模でも検討すべき内容だし、発想の枠組みだったり手法の一部だったりは十分実践できる。ので、「明日から使える」的な話題も入れて頂けると…(無理かなぁ) （Twitter / daishiro）

これ当日のパネルであがったんですが、自分はすぐに答えられなかったです。少し考えたのですが、一番やって欲しいことは「制作に携わったデザイナーを含めてローンチして少したってからサイトとデータを見ながら話してもらいたい」です。

こいういったフィードバックとかってあまり普段しないんですよね。でも１回やると面白いですよ。ただ、数字としてこうでしたよとか、これ人気コンテンツなんですよ。意外とここも見られていて。とかフィードバックがあると、デザイナー側も、「あ、そこはこう考えていたので、こうするとより良くなるかもしれないですね。」とかポンポン返ってきます。

資料たち

今回、自分が利用した資料をここにアップしておきます。ちなみに、清水さんの分もご自身のブログに公開されていますので、ここからリンクしておきます。

• 解析しないと！安西資料（PDF：5.0MB）
• 解析しないと！清水さん資料

自分の資料スライドの最後にもご紹介させて頂いたアプローチについては下記で大きいものを取得することが可能です。バージョンが0.2になっているくらいなので、どしどしフィードバックを頂きたいと思っています。

• Site Optimization Approach Ver.0.2 on Flickr – Photo Sharing!

※2010年6月23日追記：Ustreamのアーカイブが見れっるようになったので埋め込みました。途中、製品説明が入りますが、その後もちゃんと続きますので最後まで見てね！

感想！

今回は会場までいらして頂いた方で７０名弱、Ustreamでは最大３００を超える大盛況で終えることが出来ました。解析しないと！については今後も機会を設けて定期的に実施をしていきたいと思っていますので、今後とも宜しくお願いしたいと思います。

参加してくださいった皆様、ありがとうございました。そして、今回、無償で参加を快諾して頂きました楽天清水様とぐるなびウエディング舘田様に改めてお礼を申し上げます。

そして急遽、京都からオープニングのためにいらして頂いたウェブライダーの松尾さんもありがとうございました！

ありがたいことにアップして頂きました解析しないと！の感想を下記にリンクさせて頂きたいと思います。

• 6月7日「Adobe Station5 in 表参道」でミニライブを行いました！！ | 恋のSEO！紅白への道
• 「解析しないと！アドビになったよ第一弾スペシャル」に行ってきたよ！ – 加速する残像
• 解析しないと！ に参加してきました · mizmo.net
• 解析しないとに参加してきました | ログマニアックス
• 『解析しないと！』UST版で「解析を考えたサイト作り」について考える « ECナビUIO戦略室ブログ

すっかり告知が遅くなってしまったのですが、以前に行ったご好評頂いた「私的勉強会　解析しないと！」をまたやることになりました。

前回については「私的」ということで行わせて頂いていたのですが、今回は会社としてやることになりました。おおきいですよ。はい。

ということで今回は「解析しないと！アドビになったよ第一弾スペシャル」ということでお送りする形になりました。いぇい。

イベント詳細

早速ですがイベント詳細です。直近告知ですんません。

• 日程：6月7日
• 時間：Open:18時30分　Start:19時～21時　Openから来ると良いことあるかも
• 場所：表参道　station 5 in 表参道

今回はCS5のイベントスペースを間借りしての開催となるため、いらっしゃるとなんとCS5も触れます！すごいですね！もちろん無料なので、基本的にはぶらっと来て頂きたい限りなのですが、スペースの都合上、登録をして頂く必要があります。ので下記より登録を願いできればと思います。

• セミナー応募フォーム | station 5 in 表参道　ありがたいことに受付終了しました

※当日少し座席があるようなのでもしかしたら立ち見をお願いするかもしれませんが、いらして頂いても大丈夫です。

豪華ゲストっ！

そして今回は豪華ゲストです！！！！！！！！！ありがたいことに弊社のクライアントにもご登壇頂くことになりました！

• 楽天株式会社　清水　誠様
• ジョイジョイ株式会社（ぐるなびウエディング）　舘田　智様

こんな事考えてます

さて、気になる内容ですが、内緒です。嘘です。検討中なだけです。ただSiteCatalystのことも結構話はでますし、CS5とのインテグレーションの話も出す予定です。色々と考えてますが、まぁ、場所柄、「デザイナーと解析」ってテーマを軸に置いていきたいなぁと考えてます。

【ちょっと追記】
ウェブ解析をサイトの中心に据える時に、サイト運営者とサイト制作者は何を考え、どう歩み寄るのか？とかそんな感じです。私も含めゲストの方にも少しずつプレゼンして頂きながら、後半はパネルやる予定です。

清水さんのブログも合わせてご参照ください。
6/7 解析しないと！に出演します :: 実践CMS*IA

Cube Model Beta

下の図がCube Model（Beta）になります。Cube自体がサイト全体というか管理みたいなもので、図の右側から訪問があるイメージです。

Cubeの下側（緑色）にあたる部分は、「サイトのベース（中長期的視点）」にあたる部分です。そしてCubeの上部（黄色）が「キャンペーン／プロモーションなど（短期的視点）」です。

ベース部分

先程、ベース部分は中長期的視点と書いていますが、これはKBR型KPI（KBRが何たるかについてはGoalとKPIに潜むキャズムの乗り越え方 その１あたりから読んでいただけるとよいかと）にあたる部分でもあります。この部分は大きく流入部分（entry）とサイト内部（path flow）に分けています。

サイト流入（entry）については全体バランスや全体予算などを管理する必要があり、これらはキャンペーンの実施などとは別に実施されている必要があります。

また、前々回のエントリで触れた中長期的に向上施策を行う必要がある、自然流入増加などもSEO対策として実施する必要があり、その部分についてもこのベース側のサイト流入での管理となるかと思っています。

またトラフィックの後ろ側にあるのが、サイト内部（path flow）なわけですが、ここでは、一般的なサイトのUIであったり、機能、フォームなど、サイト共通的な部分についてポテンシャルをアップする部分になります。

全体としてサイト全体のコンバージョン率が大きな指標であり、その中でより全体のフローを良くしていくための管理です。

キャンペーン部分

キャンペーン部分はより短期的な視点になります。ベース部分と違い流入に対して縦長に切り分けているのが特徴です。

キャンペーンの場合は、短期的かつ結果へのコミットも非常に重要になってきます。そのため流入だけ確保できました、あとはサイトよろしく！ではなく、きちんと結果についてもコミットしていく必要があります。

特にきちんとセグメントをターゲティングして行うキャンペーンの場合、それらセグメントの良し悪しやターゲティングなども行っていく必要があります。また、サイト外部と内部でキャンペーンをうまく相互活用していく必要があります。

そのため流入部分からサイト内部まできちんとみていくことが必要になり、それが複数本ながれるということで、縦長に分かれている図にしています。

まとめ

このCube Modelは自分の中でかなりしっくり来ている図だったりするのでご紹介しました。KBR型KPIとKGI型KPIとの区分けとしても非常にわかりやすいかと思いますので、何かサイト施策を考える際の一助となれば幸いです。

はい。強気コメントです。でも本当です。自分も数年前は直帰率命みたいないところがあったんですが、色々な経験もあり、今はそうでもないと思っています。

色々な方とお話をさせて頂いたり、LPO関連の記事やブログなどもたまに読ませて頂きますが、結構、直帰率を下げることにやっきになっている方が多いように感じます。でも、なんだか本質を失っている気がしてなりません。

ランディングページは何のために働くのか？

直帰率なんて「改善すべきかもしれないコンテンツを特定」するための指標でしかなく、そんなコンテンツを改善した時の「補助的」な指標でしかないです。これ大事。

最終的にランディングページは直帰率を下げるために働くのではなく、そのサイトのゴール、つまりコンバージョンを達成するために用意されているわけで、あくまで評価すべきはこの部分です。

そしてコンバージョンへの誘導という意味でいけば、（場合と状況によりますが）ランディングページだけでなんとかなることはほとんど無いです。

ちなみに「改善すべきかもしれないコンテンツを特定」ですが、基本は入口数のボリュームと直帰率を見る感じで良いかと。入口数が少ないところみてもしょうがないので入口数のボリュームも合わせて見るわけです。

それらをランディングページのデータでフィルタして、入口数でソートして直帰率が高いところに目星をつけて、目で確認したり、流入広告やキーワードも合わせてみて絞り込んでいくわけです。

コンテンツもきちんと用意する

以前に書いたエントリ「ユーザーがサイトに訪問する目的 」で「既に買う気（コンバージョンする気）になっているユーザー」と「まだ情報収集が目的のユーザー」があると記述しましたが、改善アプローチをするにはこの考え方が必要です。これを意識することがすごく重要です。

情報収集目的のユーザーにCall-To-Action（行動喚起）だけを用意しても、そんなのほとんど意味ないんです。どんなにシンプルにしたってそりゃあ直帰します。きちんと情報を提供する誘導も必要なんです。

個人的にこの情報収集目的のユーザーには１ページ先に進んでもらうということも結構重要だと考えてます。いわゆるフット・イン・ザ・ドアです。情報をランディングに掲載するのではなく、簡単なリンクで１ページ遷移をしていただくんです。

これって２つの大きな意味があって、１つが心理的な要因（フット・イン・ザ・ドア的な）で、もう１つが情報収集目的のユーザーを直帰させずにデータ上でも明確にすることが出来るようになるわけですよ。（ランディングに情報を何もかも掲載すると情報収集ユーザーと目的間違えたユーザーの判別が全くつかない）

ちなみにキーワードなどでセグメントのおおよそのニーズは図ることが出来るものの、同じキーワードでも「既に買う気ユーザー」と「情報収集目的ユーザー」の判別はできないことがほとんです。

まとめ

ということでちょっと勢いで書いてしまったのですが、直帰率なんて参考指標でしかないのです。その上できちんとコンバージョンを見据えた対応をしていくことで、自ずと直帰率も落ちてきます。

ちなみにセグメンテーションとの兼ね合いなどを考えていくと、ランディングページは常に同じものでなくても良いわけです。きちんとニーズ分解を出来るのであれば、１つのものを複数に分割していくこともできますし、その逆もまたしかりです。

もう少し詳細なセグメントとランディングの関係については、また別の機会にでも書き起こしてみたいと思います。

「サイトのポテンシャルを最大限にすること」

ポテンシャルのとらえ方は様々で、現状のトラフィック（集客予算）の中で最大限の効果(コンバージョン）を達成すること、や、現状のコンバージョンを維持しつつ、集客予算をより下げることもあります。

最適化の視点ではポテンシャルの最大化です。しかし、サイト全体で見れば、ポテンシャルを最大化することだけではなく、合わせてトラフィックを確保していくことで、始めて全体的なゴールの最大化を計ることが出来るわけです。

ポテンシャルの最大化を少し分解

ポテンシャルを最大化は深く掘りさげていくと果てしないわけで、まぁ、結局これが自分の仕事のほとんどなわけでして、ほんの少しだけ。

さて、このポテンシャルの最大化ですが、サイトのユーザビリティ強化や機能追加／改善、フォーム最適化などを様々なベースとなる部分を指しています。

また、自分の中では「広告予算を利用しないトラフィック（ブックマークや自然検索流入など）」や「サイトブランド」などもここに含んでいます。

これらが達成できれば、サイトのコンバージョンを減らさずに広告予算を減らしたりもで、かつ、中長期施策の中で行われ、中長期的に効果が持続する可能性が高いものだからです。

だからサイトのベース。これです。

トラフィックの確保を少し分解

トラフィックの確保といっても、上記のような自然検索やブランド力をあげることでトラフィックを増やす中長期的施策もあれば、短期的にはキャンペーンなどによるトラフィック確保があるわけです。

これらは以前に「GoalとKPIに潜むキャズムの乗り越え方 その２」で触れたKBRから直接落とし込んだKPI（KBR型KPI）とKGIから落とし込んだKPI（KGI型KPI）はそれぞれ、これらにも当てはまります。

前者のような中長期的施策については、サイトのベースを向上させる、KBRを直接達成するものに近いという部分でKBR型KPIであり、キャンペーンなどは短期的かつ、直近の目標値を達成するために行われることが多いことから、KGI型KPIと言えると思います。

どこを目標に置いているかで、期間的なものも違いますし、評価や分析の方法もこれらで変わってきます。

まとめ

ちょっと長くなってしまったので、いったんここまでで。ポテンシャルの最大化とトラフィックの確保的な部分は、結構難しくて、場合によっては組織的な部分も考える必要もあったりします。

しかし、これをきちんと捉えておき、自分の施策で何をしているかを意識しておくことで、オンラインマーケティングを行ううえでのとっちらかりは大分押さえられるような気がします。

追記：2010年5月11日

このエントリの続きを「サイト運用と解析の関連をモデル図にしてみた」として書きましたので合わせてご参照頂ければと思います。

この講演では「改めて企業がソーシャルメディアと向き合うには、何を意識したら良いのか？」という部分をベースに、そのアプローチをどう組み立て、計測などにもつなげていくかという部分についてひれました。

このエントリではその最初の部分について触れてみたいと思います。

Social Mediaの特徴

企業がソーシャルメディアと向き合うにあたって、まずはソーシャルメディアがなんたるかを知っておく必要があります。色々と整理をした結果、自分の中では３つのキーワードに絞り込みました。

• 沢山ある
• 繋がる
• ユーザー主体

コンテンツは伝搬する

沢山あるというところですが、一言でソーシャルメディアと言っても、SNS（ソーシャルネットワーキングサービス）やSBM（ソーシャルブックマーク）、ブログ、マイクロブログ（Twitterなど）など多種多様になります。

また、繋がるというのは、ソーシャルメディアなのだから当たり前だろうというところではあるのですが、ここでは２つの意味で使っています。ユーザーとユーザーがつながることはもちろんのこと、ソーシャルメディア同士も繋がり始めています。

システム的統合がされている部分もあれば、RSSで繋がっている場合もあります。また、Twitterでまた使われるようになってきた、デスクトップクライアントによって統合されている場合もあるでしょう。

この「沢山ある」「繋がる」という２つの項目で考えると、それらサービスの上に流れるコンテンツは様々な方法で運ばれ、繋がることで、単一ではなく複数のソーシャルメディアをまたいで伝搬をしていくということになります。

これってすごい重要で、良い方向で動いた場合はTwitterだけを対象にマーケティングしたところで、その他のメディアに流れ、結局そっちからも効果があがるかもしれないですし、ネガティブな情報も同じように伝搬するということです。

同じ目線

さて、もう１つ重要なのが３つ目のユーザー主体ということです。ソーシャルメディアの中では、ユーザーと企業は同じ目線で扱われます。それこそ企業のTwitterアカウントもユーザーのTwitterアカウントも同じように扱われているわけです。

これは企業がユーザーとどのようにコミュニケーションしていくかという部分に大きく関わってきます。今までメガフォンを使っていたのが、それでは全く耳に届かず、きちんと正面を向き合って言葉のキャッチボールをする必要があるわけです。

コンテンツの質も非常に問われてきます。先ほど”繋がっている”というキーワードがあがりましたが、コンテンツ自体、人でフィルタリングがされます。つまり、人で繋がっていて、人がコンテンツの伝搬を左右するんです。

今までコンテンツを運ぶのは旧来のメディアが主導していたのが、そうじゃないんです。つまり、どれだけコミュニケーションしてEngagementを高め、ユーザーが興味のあるコンテンツを提供できて、それを運んでもらえるかなんです。

じゃあ、何をしていけば良いのか？

Enagementもブランドもないところで、いきなりキャンペーンだの広報活動だけしはじめても、ソーシャルメディア上では振り向いてもらえる数は極端に少なくなります。そのためまずは関係（Engagement）作りが非常に重要なポイントだと考えています。

• 対話
• 仕組み化

キャッチボール

Engagementを高めるたみには当たり前ではありますが「対話」が重要です。コミュニケーションです。キャッチボールです。ブランドがある場合は、場合によっては対話せずともEngagementが築けている場合もありますが、それはそれです。

ただ、ブランドがあるから沢山広告的活動をして良いということでもなく、また、無いから全くしちゃいけないかということでは無いと思ってます。

講演後、大前創希さんと話をしてた時に、大前さんがおしゃっていたのが「コミュニケーションと宣伝の割合が７：３な感じ」というのが自分もすごくしっくりくる感じでした。

このぐらいの割合でも良いので、誠意をもってコミュニケーションを行っていくことが非常に重要だと思ってます。

コンテンツ デリバリー

さて、もう１つの「仕組み化」です。これって意外と語られてないところなのですが、個人的にかなり重要な部分だと思っています。この「仕組み化」とは大きくは「コンテンツがデリバリーしやすい形であること」と「必要な情報を集めること」だと思っています。

コンテンツがデリバリーしやすいことって、あまり意識されていない事が多いんですが、１ページ１コンテンツであることや、それらが一意のURL（パーマリンク）であることなどがあります。

また先ほどRSSというのにも触れましたが、企業側が発信している情報が複数手段で提供されているか（サイト、メルマガ、RSS）なども大きく違います。

また、最近では動画配信を行うことも多くなってきました。これら動画についても埋め込みタグを用意していたり、その動画自体を一意のURLで提供できるかどうかでもリーチの幅は大きく変わってきます。

必要な情報を集めることも重要です。ハッシュタグを使うのも１つの情報集めです。きちんとやるなら、きちんとやるなりにハッシュタグをきちんと定義していかないと、使ってもらえません。

また、サイト内でブログの紹介やTwitterの紹介をするなども良いでしょう。TOYOTA USAでは自社キーワードでつぶやかれた内容をまとめるサイトも提供していたりします。（Toyota Conversations: Latest News About Toyota Cars And The Recent Recall）

ソーシャルメディアに拡散した情報は、企業が効果測定が大変なようにユーザーが集めるのもやはり大変な時もあります。そのため、集約できるような仕組みをうまく提供していくことも、企業が担うべき部分になるかもしれません。

まとめ

今回の講演は改めて書き下ろそうと思い、テストとソーシャルメディアの２つの軸に絞っていました。この２つは、先日のOmniture SUMMITに参加をした際に、日本よりも大幅にすすでいると感じた部分でもあります。（Lead the next DIGITAL decade | dIG iT）

ただ、色々と整理をしていると、ソーシャルメディアがあまりにも奥深かったので結局、この内容だけにターゲットを絞り込みをした感じです。自分の中でも今回のまとめの中で、どこにフォーカスをしていけば良いのか、少しクリアになったのでよかったなぁと。

この関係構築をきちんと出来たうえでのキャンペーンを実施すればそれは、効果は果てしなく大きくなると思っています。あとは、それをどのように計測していくかですね。これはまたどこかできちんとまとめたものをアップします。

自社サイトのURLなどがTweetされたのであれば、やはりそれは抑えておきたいところ。ところが140文字しかPOSTできないTwitterということもあり、ここのところ急速に利用が増えているのが短縮URLサービスです。

Twitter Searchを利用することでTweetの中に含まれるブランドワードや製品名などは検索できるものの、短縮サービスに置き換わってしまっているURLまで探すのは難しかったりします。

そんな中、個人的にも好きなサービスのTopsyというサイトがあります。これはTweetを検索できるベータ版サービスです。最近少し機能拡張しているものの、基本はTweetに含まれるURLなどを集計して検索できるものだったりします。

このサービスの素晴らしいところは、先程も触れた短縮URLサービスについてもきちんとトラッキングし、同じURLならまとめて表示できることなんです。これ地味に大きいんです。

メディアサイトなどを運営している場合は、どの記事がどのくらいTweetされていたかというのも気になるところなわけで、そんなのも検索クエリに「site:ドメイン」と入れるだけでOKです。

このTOPSYがAPI実装したら最高なのに〜と思っていたところ、たまたまサイトでAPIの文字を見つけまして、調べてみたらJSON形式ということで早速取り込んでみました。

ということで以下は少しだけテクニカルな部分を書くので、必要のない方は最後の「まとめ」まで飛ばしてしまってください。

TOPSYを実際に実装してみる

そもそもTOPSY自体がベータ版なのでAPIも当たり前のようにベータなわけですが、とはいえきちんとしたドキュメントがあります。（otterapi – Project Hosting on Google Code）

これを見る限りはTOPSYで検索できるような内容のほとんどが出来るように実装されています。上記にあるようなsite:などの説明はないので、そういった部分はTOPSYをいじりながら検索クエリを見るのが良いかと。

あとは実際にリクエストして返答を得るだけなわけですが、JSON形式とJSONP形式と２つが用意されています。（ResponseFormats – otterapi）

通常の検索のリクエストであれば /search.json がJSON形式で /search.js がJSONP形式です。JSONP形式の場合は、通常の検索クエリの他に、引数としてcallbackで返答の関数名を指定します。リクエストの種類については　Resources – otterapi　に書かれています。

自分は実装のしやすさからJSONP形式でやりましたが、この辺りは環境によって合わせる形で良いと思います。ちなみにJSON形式はFirefoxのAddOn入れるとブラウザ上で参照できるので便利です。（JSONView :: Add-ons for Firefox）

http://otter.topsy.com/search.js?q=site:an-k.jp/blog&window=a&callback=TopsyJsonAPI

callback変数と同じ関数と適当に引数を１つ用意して呼び出しもとのページに用意しておくことで、あとはリスト形式を好き放題です。適当にDOMなどを利用して設定を入れてしまいます。それだけ。

ということで１時間もかからずに実装が終了でした。自分はとりあえずブログに入れてみようということで、WordPressのWidgetのHTMLとしてJSを放り込んで、サイドバーに表示をしています。

まとめ

最初にも書きましたが、個人的にTOPSYはかなり興味をもって使っているサイトの１つです。実際にJSONの返答を見ていると、それぞれのURLにはきちんと評価ポイントがついていたりもします。

単純なTweet数だけではないようで、Tweetの伝搬の速さとか考慮されているのかなというイメージです。こういったデータを解析ツールに取り込んでムフフなんてのも面白いかもしれませんね。

また、TOPSYはTwitterのユーザー情報を問い合せることができます。TOPSYではユーザーをInfluence Levelとして10段階評価をしています。このようなデータもSocial Mediaとうまく”対話”をしていくには良い情報かもしれません。

ということで待ち望んでいたTOPSYのAPI実装で興奮しながら書いてみました。