TRAINING GA

Google Analytics概要と基礎知識

特徴と概要

ここでは技術的要素ではなく、主に用語や定義の説明を行う。旧アナリティクスには触れず、ユニバーサルアナリティクスを基準とする。

アクセス解析の種類

アクセス解析には大きく分けてログ解析を主とするserver log型と、ブラウザからHTTPリクエストのパラメータに情報を乗せてリクエストを送るbeacon型が存在する。Google Analyticsはbeacon型であり、特徴としては以下が挙げられる。

• ブラウザのイベントをトラッキングできる
• 導入が容易である
• 多数を俯瞰するのに向いている
• 正確ではない

1人のユーザーを深く見ることには適していない。また、正確ではないためデータの母数が少ない場合は参考にならない。複数のデータを掛け合わせる場合はぶれが大きくなるため注意が必要。

基本概念

Google Analyticsではプロパティ毎にトラッキングコードが発行されるが、前後合わせて3つの階層がある。

アカウント

ひとまとまりのサービス群。アカウント毎にデータをフィルタリングできるが、GAのフィルタはそもそもデータを受け取らなくしてしまうので、ここで設定する場合は本当に不要なデータのみにする。あまりそういうケースはない。

プロパティ

Tracking tagが発行される単位。ひとつのWebページに対して2つのPropertyを同時に埋め込むのは非常に手間がかかるため、むやみにわけたりしない。

ビュー

Propertyを分割してデータを表示できる。ここでもフィルタを設定できるので、基本的に何かフィルタリングする場合はViewで行う。

ディメンションと指標

Google Analyticsではディメンションと指標のセットでデータを見る。ディメンションは対象のデータがどんなデータであるか表し、指標はそのデータに対するvalueを表す。

• ディメンション … 集計対象
• 指標 … 集計数値

また、セカンダリーディメンションを使うと、ディメンションを掛け合わせ、分別して表示させることができる。例えば、eventAの集計数を、OS別で表示させるなど。

フィルタとセグメント

セグメントは今あるデータを後から特定の条件で分割したり絞り込んだりするもので、前述したディメンションにあたる機能。フィルタの場合は、そもそもデータを受け付けなくするため、後から設定しても意味はなく、集計前に設定する。よくあるケースとしては、自社IPを弾いたり特定のドメインからの集計を行いたくない場合にドメイン単位で弾いたりする。

下記は、問題発生時に参照することの多いセグメントの例。

• OS (バージョン)
• ブラウザ (バージョン)
• 端末ブランド名
• URL正規表現パターン
• 時間

期間による絞り込み

全てのデータは期間によって絞り込みが可能だが、期間の絞り込みは大元のデータを切り分けるため、過去にデータが存在した場合にも、その期間内でユニークであればそのように扱われる。ユニークユーザー数を見るときには注意が必要。

ユーザー

Google Analyticsでは基本的に1-Cookieを1-Userとして扱うため、Cookieが共通化されない場合は別のユーザーとしてカウントされる。

Cookieの扱い

beacon型のAnalyticsは送信する情報を保持するためにcookieが使用するが、GAでは基本的に1st party cookieをが使用されるため、ドメイン毎のデータとなる。3rd party cookieが利用されるものは、主に広告向けの機能に限定される。

• first party cookie ... サイト内行動に関するデータ
• third party cookie ... 広告に関係するユーザー属性など

Cross domain

Google AnalyticsのCookieはデフォルトで_gaをkeyとした単一の場所にroot domainの'/'に保持することを試みる。仮にサーバー側の設定でCookieが許可されない場合、順々に子のドメインに下る。例として、以下のドメインはデフォルトで等しく.hoge.comに保存されるため、ドメイン間のデータの受け渡しを考えなくても良い。（*1）

• sub.hoge.com
• www.hoge.com
• hoge.com

上記のCookie共通化ができないドメイン間でデータを受け渡す際にはurlのクエリを利用する。それを行わない場合、異なるドメイン間でそれぞれのユーザーは別のユーザーと認識され、セッションも途切れるため、遷移した際に離脱扱いとなる。必要なクエリの付与はanalytics.jsの提供する機能で行うことができる。

(1) 遷移元のページでlinkerと遷移先のドメイン設定を行う

ga('require', 'linker');
ga('linker:autoLink', ['hogehoge.jp']);

(2) 遷移先のページでパラメータの受け取りを許可する為のオプションを設定する

ga('create', 'UA-XXXXXX-X', 'auto', {
  'allowLinker': true
});

うまくいくと、遷移した際のurlにutmから始まるクエリが付与される。Google Analyticsはmousedown, keyup, touchstartのタイミングでa[href]やform[action]の値を書き換えるため、通常の遷移ではなくlocation.hrefなどで遷移させる場合には注意が必要。

UserIDを使ったCookieの共通化

もしWebサービスで、ログインIDなど露出しても問題ないユーザーを表す値が存在する場合は、それを使ってデバイスやドメインを跨いで同一ユーザーとして扱うことができる。

行動 (ページビュー, セッション)

ユーザーの行動データにはいくつか種類がある。

• ページビュー ... ページが表示された回数
• ページ別訪問数 ... ページ毎に重複を除いたページビュー
• セッション ... 一度の訪問

例: pageAに流入し、pageBを閲覧したのち、pageCを閲覧し、pageBに戻った。

セッションは最初に流入したpageAでしかカウントされない。セグメントで直接流入のないページのデータだけを表示すると、異常にセッションが少なく見える。

セッション

セッションはよく見られる重要なデータだが、定義が複雑で間違いやすい。セッションが途切れる条件は以下の通り。

• 30分以上何のデータも送信されなかった
• 流入元クエリが変更された
• 日付が変わった

平均滞在時間の罠

Google Analyticsの滞在時間は、実際に時間を数えているわけではなく、送られたデータの中で最初のデータと最後のデータの時間を見て算出される。そのため、シングルページのLPなどでイベントもなくpageview以外にデータが飛ばなかった場合、滞在時間は0秒になってしまい正確な計測を行うことができない。

参照元

主にリファラーの値を参照することでユーザーがどこから流入してくるのかを特定する。例えば、媒体Aに出向したバナー広告と媒体Bに出向したバナー広告でどちらが効果があったか、また複数のデザインのバナーを出稿した場合に、どのデザインが最も効果的だったかを判定するために使用される。

URLクエリを利用する

クエリに値を設定することで、どこからの流入なのかを判定することができる。使用できる値はutm_campaign, utm_medium, utm_sourceの３つで、前者２つはそれぞれ機能的に大きな違いがあるわけではないため、好きに活用できる。

流入元とセッションの落とし穴

前述の通り流入元のクエリが書きかわると、強制的に新しいセッションになってしまう。極端な話全てのページ内リンクのurlにユニークな値をセットした場合は、全て新規セッションとしてカウントされてしまうため、注意が必要。

逆に、同一のセッション内では最初に流入元がその後の全てのデータで採用される。例えば、bannerAから流入し、30分以内にgoogle検索から流入してきた場合、2回目のアクセスもbannerAからの流入としてカウントされる。