サイト構造とサイト内検索機能、そして自らウェブサイトの解析をしにくくする人達

ウェブサイトの設計、データ設計、SEO、広告、解析。このあたりは基本的に切っても切り離せない関係にあるという事は恐らく大部分の人に納得いただける漠然とした共通理解だと思います。でも実際にはページやサイト、部署が別れていたり依頼するベンダーが別れていたりして、全く意思疎通がとれていないパターンがあります。

ウェブサイトの構造は様々ですが、よくあるパターンが左のようなTOPページからのツリー構造。

この構造を構築する場合、サイトの構造とユーザの理想となる動きは一致している必要があります。
よく言われる「カスタマージャーニー」とは異なるので以下の図は不適切かもしれませんが、ウェブサイト構造が末広がりのツリー構造となっている場合、ユーザストーリーに合わせてサイトの構造を作る必要があります。


サイト構造とユーザのストーリーを一致させようとウェブ担当者は頑張ってファセットの文言を調整したりナビゲーションを調整したり、UIの変更を計画していく訳ですが、新規にサイトを構築する、ページを構築する時に考えるのが「予期的UX」だったりします。


予期的UXを利用しつつサイトを構築していく過程でアクセス解析側の視点では、この予期的UXから構築されたウェブサイト構造の各導線の数値を計測し次の予期的UX側へのフィードバックをするか、また別の構造を検討したりページを追加する等の施策に繋げていきます。


更にこの一つ一つの計測数値(metrics)に対し、「アルゴリズム」という軸を掛け合わせていくと「パーソナライズ」という新しい側面が発生します。metricsパターンはパターン同士が交差する場合もあると思いますが、そのパターンから協調フィルタリングやらルールベースやらが発生したりします。


話は少し変わり、ウェブサイト構築後の集客という視点で見ると1ページあたりのアクセス数としては、サイト名・ブランド名でランディングするトップページや、カテゴリ名や分類名などでヒットするミドルワードでアクセスされやすい2階層目、3階層目ページのアクセス数はサイトの中でも1ページあたりの集客力は高めになり、逆にコンバージョンに繋がりやすいけどピンポイントで商品名や1サービス名でランディングするような末端ページは1ページあたりのアクセス数は少なくなる。そんな平行四辺形の構造ができあがります。


サイトページ群ごとにターゲットとするキーワードや逆にランディングさせたくないキーワード群というものを設定していると、さらにウェブサイト構造を「サイト内検索」機能によって最適化・補助する事が可能となります。


理想としてはサイト構造のみで、どのページにランディングしても適切にその下層へ導ける状態が良いのですが、そのページにランディングした時のユーザ側のモチベーション、そのモーメントにおけるコンテキストはバラけるため、metricsで見る向上にはある程度の上限を意識せざるを得ません。

そのmetrics部分はGoogle Analyticsでも見れますが特定のページまたはページ群からどういうユーザの動きをしているかによって判断するなど、全体を俯瞰して判断すれば良いと思います。

(画像はGoogle結果ですが、本来は運営ウェブサイトの各ページ群)

能動的な行動ではありますが一般的に軽視されがちな「サイト内検索」は、この部分にアプローチする1手段となりえます。



「サイト内検索」のクエリからランディングする階層を紐付けてあげてユーザを導いてあげることでランディングした人を適切なページへ誘導する事が可能となるだけでなく、ウェブ運営側の想定とOff-Page側、特にGoogle頼みな部分との差を埋める1機能として位置づける事ができます。

サイト内検索に関しては計測と改善は可能なのですが、非常に軽視される部分なんだなと最近は凄く感じるようになりました。

こう考えてみると、集客としてページ内のターゲティングワードを考えるという行為とサイト内検索を紐付けて、より「サイト内検索」機能自体が意味のあるものとなるだけでなく、ウェブサイト内のショートカットとしての機能が発生してくるという事が何となく分かるのではないかと思います。

サイト内検索はよく末端ページを探す道具、あとは絞込やソートで頑張るUIを検討しがちですが、そうではなくキーワードによってサイト内でランディングすべき階層を意識する事が一つの重要なキーとなります。

そんなサイト構造や機能、集客について考えつつウェブサイトを設計・構築していく訳ですが、最近気づいたのが自らサイトの解析をしにくくする人達が多少なりともいるのではないかという点です。
よくSEO界隈だとGoogleの「検索エンジン最適化スターターガイド」に書かれているこの部分で重複コンテンツの対策で301やらcanonicalやらを設定する訳です。


が、これと同じ問題を解析側もかかえる事があります。全く同じコンテンツなのにそのページに様々なURLが発生してしまっているというパターンですね。
もちろんフィルタやグルーピング、URLのrewriteを解析ツール側で設定して同一ページ複数URL問題を解決したり、不要なパラメータを登録したりすることで解決は出来ます。

しかしながらサイトを運営していると、よく分からないパラメータが知らず知らずのうちに付与されていて、いざ解析しようとした時にそれらにマッチングするように正規表現を書いて~と解析を始めるまでに何故かデータのクレンジング処理と言いますか、前処理が必要となることが発生する事が往々にしてあるのです。

あまりに面倒すぎて、バーチャルURLで全部解決してしまえ!というのは流石にやり過ぎな気がしますが、canonicalを設定するんだったらcanonical URLをバーチャルURLとして登録しても良いんじゃないか?と時々ふと思うのです。
なんでSEOは頑張ろうとするけど解析側は放置なんだろうか…と。

更にはサイト構造を見ればちゃんと解析しているかどうか分かるんじゃないか?という考えもあります。解析コストなんてそんなに気にする額でもないというサイトもあるでしょうし、特段議題としてあげる必要も無いのかもしれません。

近々ウェブ解析はAIで自動だという記事もポツポツ出てきていますので、気にする必要が無くなる事を期待しつつw
そしてAIで解析~という系のものに関しては自然言語でバシバシ質問を投げて解析結果が返ってくる、または解析segment情報や計算式を提案してくれるWatson系が一番イイなぁと思います。私自身、毎日見ているmetrics以外のspot分析をする場合はまず疑問から入る事が多いので。(余談)
その一部は月1回とか毎日とかのデータ分析に組み込む事がありますのでschedule機能も。

駄文失礼しました。

コメント

このブログの人気の投稿

ウェブサイトユーザビリティ評価のためのSUS(System Usability Scale)

離脱改善指標に関するメモ

Google Analytics v4用measurement protocol(alpha版)追加