ただ、通常の解析などを話すというものではなく、「スキルアップを考えぬく」というものです。いや、そんな偉そうなキャリアパスじゃないんですが、とはいえ色々なものをやってきたという部分はあったのでそんなところからブレイクダウンなどしてみました。

個人的には過去の自分のパスを振り返る良いタイミングだったかなぁとも思っています。そんなところの後半で触れたのはサイトを因数分解して、そこからサイト価値を拡大させていくことという部分なんですが、スキルという部分で少し遠くなってしまったので、ここで改めて詳しく書いてみたり。

サイトの情報を落として捉える

サイトを顧客と企業をコミュニケーションツールとして捉える場合、サイトの細かい情報を削ぎ落して、大きな枠組みの中でみていくのが良いと思っています。

その１つの方法としてハイレベルサイトマップの考え方があったります。作り方は「ハイレベルサイトマップの作り方」に記載してます。

↓このぐらいの粒度

このサイトマップを作ったうえで、それをベースに「誰に」「何を」伝えていくのか、「どうして欲しいのか」といった部分を考えることで、コミュニケーションを整理しやすくなってくると思います。

整理する

今度はこのハイレベルサイトマップ単位で色々と整理をしていきます。例えばまずはウェブ解析ツールで入口なっているTOP5を入れて頂くと、どこに流入が多いのかといったことが見えてきます。上記のような単位でまとめているとTOPが一番入口が多くなくなったりするので、またそこも新しい発見があると思います。

さらに新規の方、リピートユーザーの方や未購入者と購入者（既存顧客）といった視点でも同様に分類していったりすると、そこでの行動の違いが見えてきます。これによってそれぞれの人達とどうコミュニケーションしていくのか？といったことを考えて行ったりするわけです。

他にも授業の中でも触れたAISCEASを使ったサイト分析 やリスク（ユーザーがサイトに訪問する目的）といった視点でコンテンツや機能を整理し、ハイレベルサイトマップと照らし合わせながら、足りないもの、動線などを確認していったりします。

拡張する

足りない部分や動線だけでも十分色々と次のコミュニケーション設計が出来るようになってくるのですが、ぜひやっていただいきたいのは、競合と思われるサイトでもハイレベルサイトマップを作ってみることです。

ハイレベルサイトマップって実際に作るときは、そのサイトをくまなく回遊して構造を頭に入れていきながら作っていく必要があります。しかし、これをやってみることで実は自分が関わっているサイトと競合サイトなどとで違いも見えてくるんですよね。

もちろん競合だけではなく様々なサイトで行って頂くと良い部分やつまる部分などが見えてきます。そこを自分の関わっているサイトにどんどん反映していくわけです。これはパクリではありません。リスペクトなんです。

ちなみにサイトだけではなく、キャンペーンに特化して行って頂くのも良いと思います。そうするとキャンペーンを行った目的はなんだろう？というところで非常に気づきがある場合が多いです。また、ビジネスに置き換えても同じようなフロー図を作ることが出来ます。その場合はマネタイズのポイントを意識して頂くと非常に色々な発見があると思います。

とにかく、こうやって色々なサイトの情報を必要なものだけに削ぎ落した中で比較することで、見えてくるものは非常に多いです。

まとめ

実は職員室（講師控室）の時間でこれを書いていたので、まだイベント自体が終わったわけではないためイベント自体の感想はまた別に…ということなんですが、サイトを分解・整理・拡張していくことが最適化のアプローチの１つだろうなぁと思っています。

手元では少しづつ型のようなものを整理し始めているので、それがもう整理できたらまたこのネタを拡張して書いてみたいなぁと思います。

運用をする、課題となっている箇所を探す、テストをするなどサイトを最適化するためにも様々なタスクがあります。これらを行っていくにあたり、事前に行っておくと良いことがあったりします。というこでそれらを３つに分けてみたいと思います。

KBR（サイトの戦略）を明確にする。

ビジネスのゴール、サイトの役割など大きな部分については、サイトに関わっていれば意識していることが多くあります。しかし、実際の運用となるとサイトの役割は自分の行っている運用とは少し離れてしまっていることもあります。

そこでこれを埋めるためにKBR（Key Business Requirement）を決めておきます。KBR自体の詳しい記述は「GoalとKPIに潜むキャズムの乗り越え方 その１」が参考になると思います。

KBRはサイトの役割と実際の改善作業の間を埋めるようなもので、実際に課題を洗い出す場合、KBRが定義されていると、分析を行う際の軸が出来るので分析の効率を上げることができるようになります。

ハイレベルサイトマップを作る。

ディレクトリ一覧やリンク構造を明記したものではなく、サイトのポイントと動線をざっくりとマップにしたものがハイレベルサイトマップです。

これがあることでサイトの全体を俯瞰して考えやすくなります。俯瞰して見えるようになることで、解析ツールを使った分析と想定（ハイレベルサイトマップ）とのギャップを見つけることも出来るようになります。

実際の作り方は先日書いた「ハイレベルサイトマップの作り方」を読んでいただくと良いと思います。

プレ分析をする。

以前のエントリで解析ツールのレポートを４つに分けることについて記述しましたが、その中でも体重測定のレポートに近い部分になります。（分析レポートは４つに分けて考える。 ）

おおよそ現状のサイトがどのような状態にあるかを知るためのものです。これらのデータがあるかないかで、その後の仮説が非常にたてやすくなります。

この辺りの見る指標やその切り口などについては「はじめてのサイト分析」のエントリでまとめた内容が役立つと思います。

まとめ

上記の３つを行っておくことで、さまざまなシーンで役立つようになります。そのためこれら３つはサイト関係者に共有できるようにしておくと良いと思います。

例えば運用に入る場合もKBRが明確になっていることで、どのような戦略で集客やサイト改善を行っていくべきかが非常に明確になります。

また、課題発見を行う際も、具体的にどこから分析していけば良いかもわかりやすくなってきます。プレ分析をしておくことでおおよその傾向がつかめてますし。

もちろんテストの時も役立ちます。どのあたりからテストしていくか、また、どんなテストを行っていくべきかも明確になってきます。

ということで３つを上げてみました。もちろん他にもあると良いもは多々あります…がこの３つに関しては絶対的に役立つと思うので一度作ってみてください。

ハイレベルサイトマップは解析とは関係ないようにも感じるかもしれませんが、自分はクライアントのサイトを分析する際は必ずといっていいほど作るものです。というかこれがないと分析の軸がブレやすくなってしまいます。

ただ、このハイレベルサイトマップは慣れていないとちょっと難しい部分もあるので、そもそも何よってところから、作り方まで触れていきたいと思います。

ハイレベルサイトマップとは？

そもそも、ハイレベルサイトマップって？について少し。ハイレベルサイトマップとは通常の詳細なサイトマップとは違い、サイト全体の大枠を知るために利用していきます。おおよそメリットは下記の感じです。

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

サイトの概要、動線を俯瞰できるようにするためにサイトのポイントとなる部分だけを抜き出し、さらに主動線・辿ってほしい動線のみを記述するようにします。また、循環する部分をエリアとして明確にしておくと、全体の動線を想像しやすくなってきます。

さらにサイトのコンバージョンを色分けしておくことで、コンバージョンの箇所が明確になります。マイクロコンバージョン、最終コンバージョンを入れておくと良いです。（コンバージョンの分類については「コンバージョンは３つに分類しよう」に詳しく書いてます）

フロー分析の手がかりですが、上記２つの項目が明確になることはもちろんのこと、回遊部分、線形部分を把握できるようになることで分析のアプローチもしやすくなってきます。（回遊、線形については「サイト構造を考えながら解析しよう！」にも詳しく書いてます。）

また、流入チャネルやコンバージョン率などを記入していくことで、さらに色々と仮説検討のためのベースもできあがってきます。

ということでハイレベルサイトマップがなんとなくわかったら作ってみましょう！

Step１：おおよその型を知る

サイトの構造の種類は大きな視点で考えるとそれほど多くはありません。というかベースは３つです。実際にサイトマップを作るサイトがおおよそどのような構造にかるか、これらの型にあてはめ、そこからカスタマイズすると良いと思います。

コマース・新規獲得型

いわゆるコマースサイトですね。商品を選んで、カートに追加して、チェックアウトプロセスをとおって購入完了となるものです。

商品は複数の場合もあれば１つ選ぶ場合もありますが、おおよその構造は同じなので１つにまとめてしまって問題ありません。とうかハイレベルサイトマップ上はどちらも変わらないです。

また、新規獲得（リードジェネレーション）と呼ばれるいわゆる資料申込や無料体験といった箇所を最終コンバージョンとして提供している場合も構造自体はあまり変わらないのでここになります。

メディア型

メディア型の場合は、広告などを参照してもらう、そもそも記事を読んでもらうなど様々なな理由があれど、基本は記事をたくさん見てもらうことです。

ともあれ基本的に、回遊を中心とする場合はこのメディア型の構造になってきます。

機能提供型

会員へのサービスなどを提供しているものがここに入ってくることが多くなります。わかりやすいところでいけば金融系などはこの部分になってきますね。

オンラインバンキングなど機能を提供して利用してもらう部分などがこの機能提供型の特徴になる部分です。他にもSNSもこれに近い形になります。一見、メディア型に近い部分もあるのですが、会員に機能を提供しているという点ではこちらでも良いと思います。

Step２：自分のサイトに近づける

これらの型をベースに自分のサイトに近づけていきます。下記の要素を使いながら、肉付けをしていきます。

ここでのポイントはポイントとなる部分を大きくくくって考えること、メインの動線だけに線を引き、細かいリンクは気にしないことです。

さて要素ですが下記のようなものを入れていきます。
・　TOPページ
・　ランディングページ
・　商品一覧
・　商品詳細
・　ログイン
・　会員登録
・　会員機能
・　ツール（商品比較機能やシュミレーターなど）
・　サイト内検索
・　買い物かご
・　購入／資料請求プロセス
・　最終コンバージョン
・　特集・キャンペーン

あとはこれらをうまく組み合わせながら作っていくだけです。あと、細かいポイントをいくつか挙げておくと

• 商品検索などで検索方法（軸）が違う場合は別の要素として扱います。たとえば商品の条件で選ぶ場合と商品を写真から選ぶ機能がある場合などは別ものとして扱います。
• 主動線を意識すること。入口として大きくなる箇所、TOPページ、ランディングページ、キャンペーン、商品詳細ページなどから最終コンバージョンに至るための主動線（想定動線）で結んでいきます。
• 最終コンバージョンが複数存在する場合はそれぞれ別のものとして記載します。たとえば、システム的には同じページで処理をしていたとしても無料体験申し込みと資料請求はコンバージョンの種類が違います。こういった場合は別のものとして記述しておくようにします。

まとめ

上記を組み合わせていくことでおおよそハイレベルサイトマップが出来あがるとおもいます。ハイレベルサイトマップを作るときに最も重要なのは「動線を意識すること」と「細部にこだわりすぎない」ことです。

そして「誰でもサイトを俯瞰できるようにすること」が重要です。その上で上記の要素をうまく取り込んでいきます。俯瞰できることが重要なので、場合によっては粒度を荒くする、細かくするなどは行っても問題ありません。

ハイレベルサイトマップが出来たら次は下記のようなことをやってみると良いと思います。

• チーム内にシェアをする
• 解析ツールで分析して流入箇所が多い箇所にメモを入れる

ということでハイレベルサイトマップの作り方でした。

逆に言えば、アクションにつなげやすいサイトは、解析のしやすいサイトであり、それは結果としてサイト構造がしっかりしたものとも言えます。

ということで、サイトを作っていく上で＜解析視点から＞押さえておくと良いポイントをご紹介したいと思います。

USで起きている変化

まずは最初にUSで起きている変化について少し触れてみたいと思います。個々数年、USの上位に評価されているコマースサイトのTOPページなどを見ていくと、実際に＜解析しやすい＞が意識的に作られていると感じています。

下記のキャプチャはBest BuyのTOPページを現在と２００５年１月のものとで比較したものです。
（２００５年版はInternet Archive: Wayback Machineから取得しました）

基本構造は＜メニュー＞＜特集（メイン１つ、サブ２〜３）＞＜フリーワード検索＞の３つを軸にシンプルなものに変化しているのがわかると思います。

これは最低限の要素だけを残すことで、行動のニーズを把握しやすいようにして、サイトの改善はもとより、ターゲティングもしやすいようにしているんです。

日本は…運営社内での陣取り合戦が多いですね。圧縮陳列的になっているわけですね。

これはこれで選択肢を沢山用意しているということではあるものの、＜改善＞という観点から見ると非常に評価しにくい構造だったりします。この辺りが、現状のUSと日本では大きく違うと言えます。

どういう構造を作るのか？

それでは、実際のどような部分に気をつけて作っていくかを考えていきたいと思います。最近、自分の中で整理したポイントは下記です。

• １ページ（URL）＝１コンテンツ
• URL構造はきちんとした階層構造に
• ページ内リンクはメインナビとして利用しない
• ランディングページで動画系は利用しない
• ページ内は要素ごとに入れ替えやすいように

１ページ（URL）＝１コンテンツ

＜解析しやすい＞で最も重要なものと考えているのは１ページ＝１コンテンツに絞り込むことです。ページが見られたこと＝どんな情報が参照されたか？ということがわかれば飛躍的に改善のスピードがあがります。

ここは意外と見落としがちなのですが、これが実現できているかどうかで、改善アクションの検討やアクションの取り方が大きく変わってきます。

ランディングページなどでは、なるべく１ページで色々なコンテンツを見せたいということもあると思いますが、まずは、それぞれのコンテンツに分割することで、改善のアクションが取りやすくなります。

URL構造はきちんとした階層構造に

＜解析しやすい＞の2番目としてURL構造も重要です。ここでのURL構造とは、きちんと階層構造になっていて、かつ意味が推測できることを指しています。

この部分は、以前よりはよくなってきていると感じていますが、まだURL内が意味を全くなさない文字列で造られていることがたまにあったりします。

あと、きちんとしたURL構造を作ることは、コンテンツの階層構造を意識することでもあります。経験上、URL構造がきちんとしているサイトは、コンテンツの整理もきちんとされている傾向があるかなぁと思ってます。

ページ内リンクはナビとして使わない

ページ内リンクは、大量のコンテンツが１つのページに存在する場合は、ナビゲーションとして役立つこともあります。

先程触れたとおり、そもそもコンテンツ内に複数のコンテンツを推奨しないわけですが、ページ内リンクはWeb解析視点からみた場合にも致命的な欠点を抱えています。それは計測されないことです。

もちろん、別途実装等をすればリンククリックを計測することは出来るのですが、基本はページビューとしてカウント出来ないのです。つまり、訪問者がページ内リンクを多用していたとしても、それを解析面から見て取ることが難しいんです。

「ページの先頭に戻る」といったリンクはユーザビリティ的に有用だと思うので良いのですが、メインナビゲーションとしての利用はおすすめ出来ません。

ランディングページで動画系は利用しない

動画をプロモーションとして利用することが多くなってきましたが、ランディングにおいてしまうと、動画だけ見て満足して帰った訪問者は全て＜直帰＞扱いになってしまいます。

せっかく動画が効果をあげていたとしても、これでは評価しづらくなってしまいます。そのためWeb解析からの評価を考えた場合は、ランディングページでの動画はあまりおすすめできません。

Flashも同じで、裏側でリクエストを投げているなどをしていないFlashコンテンツをランディングにでかでかと持ってきてしまうと、解析ツール上はそれで遷移が終了、つまり直帰になってしまうのです。

きちんと効果を上げていることを数字に落とすためにも、こういった部分は制作時に少し意識しておく必要があったりします。

ページ内は要素ごとに入れ替えやすいように

テストを意識するということでいうと、テストできる要素を事前に意識できた作りになっているかも最適化アプローチの中では大きいです。

これは制作側で特に意識をする内容だと思っています。どの単位でテストされるのか？その単位でテストがしやすいか？などが意識できた作りになってると改善アプローチがしやすくなります。

ターゲットセグメントによって、ページ内の要素の位置を入れ替えるだけでもコンバージョンは変化します。セグメントによりコンテンツごとの優先度が違うのでこれをツールでコントロールするわけです。

テストツールは基本はソースの一部を出し分ける作りになっているので、デザインとして要素をある程度入れ替えても崩れないような組み方をしているとこういったテストもしやすくなるわけです。

まとめ

ということで、Web解析ツールを利用して分析を行うという視点から、サイトの作りについて少し触れてみました。サイトをより良くしていくためには、こういうちょこっとした部分ができてるかがポイントになってきます。

「次の改善アクションをどうするか？」と考える時に、手元のデータが使えないデータよりは、仮説が色々と組み立てられるデータのほうが良いですよね。

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

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

自分がお客様と何かしら分析について話す場合は、なるべくハイレベルサイトマップを作り、最初に確認する用にしています。通常、サイトマップというとサイトに用意しているような、サイト全体のリンク集みたいなものや細かい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戦略室ブログ

この別サイトとして展開しているサイト群のことを、マイクロサイトやサテライトサイトと呼ぶのですが、今回はこのマイクロサイトの分析について少し。

まず、このマイクロサイトとは何かについて少しだけ。

マイクロサイトとは？

飲料メーカーなど販売している商品それぞれがブランド化している場合、それぞれ別のドメインにてブランドサイトの展開をしています。また、多くの自動車企業においても、各自動車ブランドごとにサイトを作っていることは多くあります。

他にもコミュニティサイトの運営やプロモーション用サイトとして一時的に別サイトとして運営することも多くあると思います。

１つの企業が運営しているサイトという視点でサイトをみた場合、複数のサイトを運営していることも多くなってきているわけです。実際に、ブランド視点でのマイクロサイト化するメリット、デメリットはコンセントの長谷川さんが書いている記事が参考になると思います。

企業のブランド戦略を促進するWebサイト設計の要点 | Web担当者Forum

全体をみる。

では、実際にサイトをどのように分析していくかなのですが、サイトの目的によっても変わってきます。

このようなサイトを分析する場合は、サイトごとの分析とともに複数のマイクロサイトやメインサイトを束ねた分析も必要になってきます。

前者のサイトごとの分析については、目的によって変わってくるので今回はふれずに、後者の複数サイト全体での分析についてみていきたいと思います。

これらの分析を見るときに重要な視点は３つです。

• それぞれのサイトの流入量
• それぞれのサイトから別サイトへの送出量
• コンバージョンポイントが明確にある場合は、その送出分のコンバージョン

これらを見ることで、サイト間を流動させることによるシナジー効果の分析をしていくことができるようになるわけです。

図はコマースサイト（コンバージョンが明確だったから）とマイクロサイトとの関係を示したものです。

まとめ

細かい実装などはいつも通り省きますが、これらを分析することで、よりサイト全体のフローが見えるようになり、結果、複数サイトを運営することのシナジー効果も見えてくるようになるわけです。

対象範囲が大きくなればなるほど、より大きな視点で分析をする必要になってきます。ページ、セクション、そして、サイト間という分析がどうしても出てきてしまうんですよね。

サイトマップ

Web解析でのサイトマップは、別に詳細なものは全く必要ではありません。そりゃあ、最終的に詳細まで落として行くには必要ですが、概要を把握する段階では皆無といっても良いです。

基本で押さえるべき部分を入れたのが、下記のサイトマップになります。TOPやランディングページから、サイトの内部に入ってきて、サイト内検索や特集ページなどを通って商品詳細につきます。

あとは買い物かごにものを入れる感じです。ここまでの流れをコマースサイトの場合は循環していく感じになります。そして最後に買い物かごから、実際の購入プロセスに移動して購入完了します。これが一連の流れです。

基本的にはこの「ポイント」をうまく押さえて、そこの利用率だったり、そこからのコンバージョンなどを押させて行くことでサイトを大きく捉えることができるようになります。

まとめ

とりあえず一番分かりやすいポイントが多いので、コマースサイトで作ってみました。また、時間をみて他のサイトも作ってみます。

#ちなみに自分が行けるかどうか調整中ですが、次回のWebSig会議では「100人で考える、理想的なサイトマップの形と標準書式」というテーマで行うそうです。ご興味のある方は是非。

IAを学ぶのに一番良いのは良く出来た（IBMとか）のサイトマップを手書きしてみること
by nobsato

というもの。これ、Web解析にも通じる話だったりします。解析ツールで計測された数値を見る場合も、そのサイトを理解しているかどうかで、答えに辿り着く早さが違ったりします。

解析を活用するために理解する場合は、詳細なサイトマップを作っていく必要がなく、逆に重要なポイントだけ押さえたものが頭の中にあれば良い感じです。

TOP → 商品検索結果 → 商品詳細 → 買い物かご → 情報入力 → 購入完了

みたいな。これを会員登録だったらどうなるの？とか、キャンペーンページだったらどうなるの？とか。

ぱーっとサイトの概要を書いてくださいと言われて、結構書けない方って多いようです。

分析している対象サイトの構造を知らないということは、数字だけ追ってしまっている可能性が高いということ。それって、カタログスペックだけ見て評価をしてしまう評論家みたいなものなわけです（謎）。つまり、あれですよ、上辺だけになってしまいがちなわけです。

ということで、サイトマップを頭に入れておくとすごく良いと思いますというお話でした。

サイトマップとは？

今回このサイトマップというお題がだされた時点で感じたのは、「サイトマップ」という定義のあいまいさ。別にモデーレータの方々が悪いとはそういうことではなく、実はサイトマップという単語自体は定義があいまいで、ディレクトリリストみたいな事をさしてしまう事もあれば、動線設計を表す場合もあるわけですよ。

まぁ、定義ありきのものではなく、コミュニケーションありきのツールなので、誰もが模索状態の中できあがったものなんですよね。

個人的にはサイトマップといった場合は「動線を確認する」ためのものとして定義をしておきたいところです。ディレクトリリストは別にあるし、デザインや動的ページの動きは別に定義をするから。

なので、自分が重要視するのは、サイトをきちんとマーケティングに利用していくのであれば、ゴールの設定とともに、仮説としてたてたセグメントに対してどのような動線でコンバージョンに誘導するかも非常に重要だったりします。

動線の表し方

ネットイヤーの坂本さんも今回は参加されていたのですが、坂本さんのグループの発表の際に出ていた。

主要動線と関係性（リンク構造とか）を表す線を混同しないこと

これはサイトマップを作る上では非常に重要な考えだと思うんですよね。モデレータの方がサイトマップを定義するときに、ディレクトリリストを切り離す決断をするのが大変だったそうです。

結構、何も考えずにサイトマップを作るとディレクトリマップに近い関係図になってしまうんですよね。でも、やはり「動線を確認する」という部分で見ると、間違えて捉えてしまう場合もあるわけです。

リンクを全部書こうとすると何がなんの線だかわからなくなる

画面ごとに遷移をみせていこうと考え場合に、リンクをすべて記述してしまおうとすると、ただのスパゲッティ状態になってしまうわけです。

それでは全く意味がない。そう考えても画面間の線は、あくまで主要動線にかぎっていった方が良い感じ。

ちなみに、前職時代にセグメントごとに違う主要動線を表現するために、線をセグメントごとに違う色で表現することをしてたこともあります。

ページの表現

グループ発表をみていると、実際のページの表現についてもいくつかのパターンがありました。Topページをメインページとして捉えて他のページよりも重要度が高いことを強調するものもありました。

自分がこのページ表現のところで重要視したのは、「動線を確認する」上で必要な要素が入っていることです。

今回のWebSig会議の中ではステンシルと呼ばれていた、画面のテンプレートを考えることも今回のテーマの１つでした。自分のグループで盛り込んだのは下記のような要素でした。

• 動的生成ページと静的ページ
• 同系統のページのまとめ表示
• コンテンツページとハブページの分離
• 情報グルーピング
• フォーム画面の可視化

「動的生成ページと静的ページ」についてはどこで区切りを付けるかは微妙なんですが、パラメータによって大きくデータの内容がかわる部分として自分は捉えています。そのため、Wordpressなどでは各記事が毎回動的生成されるわけですが、これはちょっと違うなぁという感じ。

「同系統のページをまとめ表示」については、同じエントリーや似た属性の記事が続くのであれば重ねて表現をしてみようというところですね。

「コンテンツページとハブページの分離」これについては自分が少しこだわった部分でした。普段、コンテンツを「作る」という部分ではあまり意識しない部分かもしれませんが、動線を確認していく中では、読む内容があるコンテンツページなのか、設計上できてしまうリンクをまとめたハブになるページなのかは非常に重要です。

こういった議論がないと、TOPページからこれら記事へトピックとしてリンクを設けましょうなんて話もできないわけですよ。何クリックでどういったページを確認しながら目的のコンテンツに到達できるのか？これをサイトマップで確認していくわけです。

「情報のグルーピング」ですが、これも重要かなと思ってます。動線視点で見た場合は、どういった情報の中に投げ込まれるのかとか、そういったことをまとまり感のある中で見ることができるのが重要で、その辺りのコンテンツが何か？とまとめられることが非常に重要だと思ってます。

「フォーム画面の可視化」ですが、ちょっと他のテンプレ（ステンシル）とは毛色が違うのですが、フォームの入力画面って離脱も多いため非常に重用視すべきものと思っています。また、経験上、フローのどこで入力が発生するかがわかっていないと、後で困ることも多いのがフォーム入力だったりもするので入れています。

まとめ

といった議論の中で生まれた自分のグループのサイトマップが下記のものになります。

グループ分け、通常の動線とともにトピックの動線を表示。あとはフォームの場所がわかるようにとか。そんな感じです。

今回、このグループワークを行って感じたのは、やはり細かい定義はいらないだろいうということ。結局はコミュニケーションツールなので、最終的にコミュニケーションが出来れば良いのだろうなぁと。

あと、頑張って作りすぎて修正が難しいとかは絶対にやめた方が良いと思ってます。サイトマップをベースにコミュニケーションを行うわけなので、そこで修正をお願いしてすぐに出来ないとかあり得ないわけですよ。

WebSig会議が行われているのと並行で、Twitter上でも結構な議論展開がありました。その中で、「コンテンツリストの中から自動に作ってくれれば…」という部分がありました。実際に、解析ツールでもそれに似たようなことをできるツールはあったりもします。しかし、それはあくまでファイル同士のリンク関係を見せてくれるものでしかありません。

コンテンツの意味やセグメント別の主要動線、そんなものが皆無なものになってしまうわけです。何を調整、コミュニケーションするためのものかを改めて前提に考えて作って行くのが良いのだろうなぁと。

ちなみに、出来上がったサイトを分析していくのに細かいサイトマップは使わず、むしろハイレベルサイトマップといったものでポイントが見れれば十分だったりします。以前に書いているエントリがありますのでご興味があれば併せてお読みください。（コマースサイトのサイトマップ ）

あおと、Twitter上で、Jesse James Garrettのjjg.net: a visual vocabulary（日本語版）についても触れられていたのでリンクしておきます。個人的には１つの方向性としてはありだと思いつつ、UMLのように読み取るための学習が必要なため、クライアントとの調整では不向きかなぁと。