Google Analytics API V4をいじる

Google Analytics APIがV4が出て数ヶ月が経ちました。少しずつ各種ツールもV3がV4に切り替わりつつあるような気がしています。今まで別々にデータを出力してからローカルでデータを集計したり、それを補うように以前は1ユーザあたりセッション数などを出力できるAPIが用意されて、直ぐに廃止されたりと色々な動きがありました。

またコホートなどV4でしか利用出来ないmetricやdimensionが出始めましたが、かなり柔軟で有用な代わりに多機能でV4用に覚えなおさないといけないという印象です。サポートツールも出始めているので、自分で細かく指定しなくても良くなりそうですが。

ちなみにReporting API V4は別APIとして管理されているようです。


  1. 2期間でのデータ比較
  2. metricsの計算結果を返す
  3. pivotを利用してヒストグラムを生成する
  4. コホート分析をする
※以下、VIEW_IDはみたいGAのビューIDを入れている前提となります。
※JSONフォーマットの改行が無い状態で読みにくくなっている点ご了承ください。

1. 2期間でのデータ比較

Reporting API V4では期間を複数指定出来ます。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"},{"startDate":"2015-07-01","endDate":"2015-07-23"}],
  "dimensions":[{"name":"ga:browser"}],
  'metrics': [{'expression': 'ga:sessions'}]
}]

出力サンプル
dateRangega:browserga:sessions
Date range (1)Android Browser5
Date range (1)Chrome631
Date range (1)Edge0
Date range (1)Firefox185
…


Google Analyticsのブラウザ(GUI)上では普通に出来ますが、2期間を指定して比較が可能です。
上記の例はdataRangesを2期間指定して前年比を取得しています。

この場合返ってくるデータはdimensionの昇順で返ってきてしまい、あまり結果としてはイマイチな感じが出てきます。

そこでデータのソートをかけます。セッション数の変化量降順に並び替える時はorderBysを利用します。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"},{"startDate":"2015-07-01","endDate":"2015-07-23"}],
  "dimensions":[{"name":"ga:browser"}],
  "orderBys": [{
    "fieldName": "ga:sessions",
    "orderType": "DELTA",
    "sortOrder": "DESCENDING",
  }],
  'metrics': [{'expression': 'ga:sessions'}]
}]

出力サンプル
dateRangega:browserga:sessions
Date range (0)Safari90
Date range (1)Safari74
Date range (0)Safari90
Date range (1)Safari74
…

サンプルでは2期間を連続して出力しています。

2. metricsの計算結果を返す

metricsは単純にリストで指定するだけでなく所謂「計算指標」を自由に作成することができるようになっています。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"}],
  "dimensions":[{"name":"ga:browser"}],
  "metrics" : {
    'expression': 'ga:sessions/ga:users',
    'formattingType': 'FLOAT',
    'alias': 'Formula1'
  }
}]

出力サンプル
dateRangega:browserFormula1
Date range (0)Android Browser1
Date range (0)Chrome1.146167558
Date range (0)Edge1.6
Date range (0)Firefox1.206521739
…

この場合はmetricsのexpressionでユーザあたりセッション数をブラウザごとに表示します。計算指標化したときのheader名はaliasで指定して、formattingTypeで整数だったりパーセントだったり日付だったりと指定できます。

3. pivotを利用してヒストグラムを生成する

V4ではorderBysのorderTypeでHISTOGRAM_BUCKETを利用して自由にカスタマイズしたヒストグラムを生成することが出来ます。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"}],
  "dimensions":[{"name":"ga:sessionCount" , "histogramBuckets":["1","5","10","15","20"]}],
  "orderBys":[{"fieldName":"ga:sessionCount","orderType":"HISTOGRAM_BUCKET"}],
  "metrics" : [{"expression":"ga:users"}]
}]

出力サンプル
dateRangega:sessionCountga:users
Date range (0)1-4939
Date range (0)5-911
Date range (0)10-141
Date range (0)20+1
…

上の例の場合はdimension(セッション数)に対して1,5,10,15,20という階級を与えています。
返ってくる範囲は

1 -> 1-4
5 -> 5-9

などです。別に等間隔でなくてもデータが返ってきますので自由にカスタムして欲しいデータの範囲を設定して投げられます。ただし該当の階級に値が存在しない場合はその階級のデータは返ってこないようです。

4.コホート分析をする

V4でしか利用出来ないけど使いたいニーズの高いコホート分析。
この場合は全体のdateRange指定は無しでコホートの部分でdateRange指定をする。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dimensions":[{"name": "ga:cohort"},{"name": "ga:cohortNthDay"}],
  "metrics":[{"expression": "ga:cohortActiveUsers"},{"expression": "ga:cohortTotalUsers"}],
  "cohortGroup":{"cohorts":[{"name": "cohort 1","type": "FIRST_VISIT_DATE","dateRange":{"startDate": "2016-06-01","endDate": "2016-06-01"}},
  {"name": "cohort 2","type": "FIRST_VISIT_DATE","dateRange":{"startDate": "2016-07-01","endDate": "2016-07-01"}}]}
}]

ga:cohortNthDayの場合はdateRangeは1日のみ指定。
ga:cohortNthWeekの場合はstartDateは必ず日曜日、endDateは必ず土曜日。
 ga:cohortNthMonthの場合はstartDateは必ず1日、endDateは必ず月末といった感じでの縛りもあるので、自分で何回か書いてみて覚えないといけなそう。


以上ざっくりとしたV4追加機能の部分ですが、もちろんフィルタやセグメントも普通にかけられますし、V3ってこんなに複雑だったっけ？と思う部分もあったりしますが、Googleのドキュメントを見ながら必要なものを揃えれば良いと思います。

中には数字が入る部分も文字列で渡さないといけないとか、以前からのGoogle仕様はV4でも変わらず健在です！(苦笑

現状コホート以外はjavascriptでも提供されていました。
pivotとコホートはAPI側から触れるのは嬉しいですね。あとセグメントで通常の「条件(condition)」指定はシンプルと言うんですね。

ツールや使い方だけでなく、自分が取りたいデータを自由に取得できるようになりましょう！

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

ウェブサイトの設計、データ設計、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機能も。

駄文失礼しました。