Google Analytics API V4をいじる

Google Analytics APIがV4が出て数ヶ月が経ちました。少しずつ各種ツールもV3がV4に切り替わりつつあるような気がしています。今まで別々にデータを出力してからローカルでデータを集計したり、それを補うように以前は1ユーザあたりセッション数などを出力できるAPIが用意されて、直ぐに廃止されたりと色々な動きがありました。 またコホートなどV4でしか利用出来ないmetricやdimensionが出始めましたが、かなり柔軟で有用な代わりに多機能でV4用に覚えなおさないといけないという印象です。サポートツールも出始めているので、自分で細かく指定しなくても良くなりそうですが。 ちなみにReporting...

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

ウェブサイトの設計、データ設計、SEO、広告、解析。このあたりは基本的に切っても切り離せない関係にあるという事は恐らく大部分の人に納得いただける漠然とした共通理解だと思います。でも実際にはページやサイト、部署が別れていたり依頼するベンダーが別れていたりして、全く意思疎通がとれていないパターンがあります。 ウェブサイトの構造は様々ですが、よくあるパターンが左のようなTOPページからのツリー構造。 この構造を構築する場合、サイトの構造とユーザの理想となる動きは一致している必要があります。 よく言われる「カスタマージャーニー」とは異なるので以下の図は不適切かもしれませんが、ウェブサイト構造が末広がりのツリー構造となっている場合、ユーザストーリーに合わせてサイトの構造を作る必要があります。 サイト構造とユーザのストーリーを一致させようとウェブ担当者は頑張ってファセットの文言を調整したりナビゲーションを調整したり、UIの変更を計画していく訳ですが、新規にサイトを構築する、ページを構築する時に考えるのが「予期的UX」だったりします。 予期的UXを利用しつつサイトを構築していく過程でアクセス解析側の視点では、この予期的UXから構築されたウェブサイト構造の各導線の数値を計測し次の予期的UX側へのフィードバックをするか、また別の構造を検討したりページを追加する等の施策に繋げていきます。 更にこの一つ一つの計測数値(metrics)に対し、「アルゴリズム」という軸を掛け合わせていくと「パーソナライズ」という新しい側面が発生します。metricsパターンはパターン同士が交差する場合もあると思いますが、そのパターンから協調フィルタリングやらルールベースやらが発生したりします。 話は少し変わり、ウェブサイト構築後の集客という視点で見ると1ページあたりのアクセス数としては、サイト名・ブランド名でランディングするトップページや、カテゴリ名や分類名などでヒットするミドルワードでアクセスされやすい2階層目、3階層目ページのアクセス数はサイトの中でも1ページあたりの集客力は高めになり、逆にコンバージョンに繋がりやすいけどピンポイントで商品名や1サービス名でランディングするような末端ページは1ページあたりのアクセス数は少なくなる。そんな平行四辺形の構造ができあがります。 サイトページ群ごとにターゲットとするキーワードや逆にランディングさせたくないキーワード群というものを設定していると、さらにウェブサイト構造を「サイト内検索」機能によって最適化・補助する事が可能となります。 理想としてはサイト構造のみで、どのページにランディングしても適切にその下層へ導ける状態が良いのですが、そのページにランディングした時のユーザ側のモチベーション、そのモーメントにおけるコンテキストはバラけるため、metricsで見る向上にはある程度の上限を意識せざるを得ません。 そのmetrics部分はGoogle...