[GTM]SPAで構築されたウェブサイトのハッシュ以下URLトラッキング

## tl;dr

SPAに分類されるウェブサイトでページ読み込みがなく、Google Analytics等のトラッキングができない場合はGTMトリガー「history change」を利用する

## 背景

React等を用いてSPAによるウェブフォームが作成され、それをトラッキングする必要がありました。そんなに多くのSPAを見てきた訳ではない & 自分でSPAのサンプル等を作ったこともなかったのでSPAだから共通して言える事なのかどうかはわかりませんが以下のような特徴がありました

* SPAなので当たり前ですがページ読み込みのない遷移
* ページ遷移後のURLが `#` の後ろにつく
* ウェブ履歴(history)には遷移毎にURLが載ってくる

## 必要な実装

### トラッキングに必要となる要件・要点

1. ページ遷移毎にGoogle Analytics等、トラッキングツールや広告ツールにログを送信すること
2. `#` 以下のURLをバーチャルページビューとしてURLトラッキングできるように実装すること

### ページ遷移毎のログ送信方法

#### 履歴トリガー

SPAでの実装時にブラウザのウェブ履歴にURLが掲載される事がポイント。これはAjaxが出てき5年以上前と全く同じ。SPAでもpushStateが利用されているのか、それともhistory api的ななにかが使われているのかは分かっていないのですが履歴トリガーを使います。

(参考)履歴の変更

### バーチャルページビュー対応

#### Google AnalyticsへのURL送信

Google Analyticsへバーチャルページビューを送信する場合 `Fileds to Set` で `location` を指定するか `page` を指定します。

#### URL整形

この部分は実装方法がサイトごとに異なるかもしれませんが私の場合、こんな感じの実装を行いました。

1. 【変数】 `#` 以降のハッシュ文字列を取得する - URL fragment

2. 【変数】 ハッシュURLを用いてURLを正規化する
こちらは方法は何通りもありますルックアップテーブルを使ってもいいし以下のように正規表現で書き換えても良いと思います。

※input variableや正規表現は適当なのでサイトに合わせて書いてください
※Lookup系テーブルは上から順に評価されることに注意してください

3. Google AnalyticsにURLを送信する
2でパスへ書き換えた場合は `Fields to Set` は `page` で、Step2で書き換えた変数を送信する。フルURLで書き換えた場合は `location` で送れば良いと思います。

## 注意事項

実装で個人的に考慮が漏れた点を1つ注意事項としてあげますが、トラッキング系含めURLにgetパラメータが付いてきた場合の挙動はちゃんと確認するべきでしょう。

最初Lookupテーブルを利用して実装していたのですが、そうすると様々なツールを通してget系パラメータ付で飛んでくるURLのパースがうまくいかない事にリリース直後気づきました。そこで正規表現テーブルへ移行してすぐにリカバリーしたのですがバーチャルURL生成時にちゃんとパラメータ付でも処理されるかは見たほうが良いでしょう。

## 結論

GTMのコードを埋め込んでもらっていれば自由に内部で処理できます。ハッシュ以下のURLも含めてきれいにトラッキング可能ですがツールによってバーチャルページビューをどう投げれば良いかは異なるので調べる必要があります。
ただ個人的にヒートマップツールなんかはバーチャルURLを利用するとデータ取得としては問題ないけれどもヒートマップとしてウェブページの上にレイヤー表示できない部分だけ解決出来ていないので、そういうツール毎に考慮が必要な部分が出てくるかもしれません。

Ajax実装でGTMを触っていたら `ブラウザ履歴を確認してみる` という行動をすると思いますが、全くの初めてだと迷うかもしれませんが、それほど難しい処理を書く必要は無いのではないかと思います。

## どうでもいいこと

GTMの正規表現テーブル、GAのフィルタみたいに `$A1` みたいな変な書き方ないよな？とか勘ぐって `GTM 正規表現テーブル  書き方` みたいなクエリでGoogle検索したのは内緒。

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'}]
}]

出力サンプル

dateRange	ga:browser	ga:sessions
Date range (1)	Android Browser	5
Date range (1)	Chrome	631
Date range (1)	Edge	0
Date range (1)	Firefox	185

…


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'}]
}]

出力サンプル

dateRange	ga:browser	ga:sessions
Date range (0)	Safari	90
Date range (1)	Safari	74
Date range (0)	Safari	90
Date range (1)	Safari	74

…

サンプルでは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'
  }
}]

出力サンプル

dateRange	ga:browser	Formula1
Date range (0)	Android Browser	1
Date range (0)	Chrome	1.146167558
Date range (0)	Edge	1.6
Date range (0)	Firefox	1.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"}]
}]

出力サンプル

dateRange	ga:sessionCount	ga:users
Date range (0)	1-4	939
Date range (0)	5-9	11
Date range (0)	10-14	1
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)」指定はシンプルと言うんですね。

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

Universal Analyticsでアウトバウンドトラッキングにnavigator.sendBeaconを利用するサンプルが追加

Google Analyticsの「アウトバウンド リンクをトラッキングする」ページの英語版にnavigator.sendBeaconを利用する場合のサンプルが追加されました。

var trackOutboundLink = function(url) {
   ga('send', 'event', 'outbound', 'click', url, {
     'transport': 'beacon',
     'hitCallback': function(){document.location = url;}
   });
}

リンクには

<a href="http://www.example.com/" onclick="trackOutboundLink('http://www.example.com'); return false;">Check out example.com</a>

という感じで指定することで、navigator.sendBeaconを利用したアウトバウンドリンクのトラッキングが可能です。
ちゃんとテストをしてみないと何ともですが、非同期でデータを送れるので対応ブラウザに関しては、より精緻にデータの取得が可能になりそうな予感。

今日現在のブラウザ対応状況は以下のとおりです。詳細はこちらを参照してください。

Google AnalyticsのCore Reporting APIにユーザーレベルの指標がいくつか追加

Google AnalyticsのCore Reporting APIを利用されている方であれば、よく参照するであろう「Dimensions & Metrics Reference」。最近AnalyticsではUniversal Analyticsで、かつユーザー単位でデータを取得していることが前提、またはユーザー単位でデータを取得していなければ指標としてのメリットがフルに生かせないと思われる「コホート分析」なども出てきていますが、Core Reporting API側にも少しずつリリースがかかっているようです。

■ECommerce(Metrics)

• ga:transactionsPerUser
• ga:revenuePerUser

ユーザー単位の注文数だったり受注金額という指標ですね。

■USER(Metrics)

• ga:sessionsPerUser

ユーザー単位のセッション数という指標です。

その他、Geo Networkも大幅に追加がかかっています。

■Geo Network(Dimension)

•  ga:cityId
• ga:countryIsoCode
• ga:regionId
• ga:regionIsoCode
• ga:subContinentCode

このGeographical IDというのが、実際にどう活用できるのかがイマイチ分かっていませんが、例えば北ヨーロッパは「UN M.49」というIDだとかサンプルが出ていますので、国別ではなくグローバル企業における北欧マーケット全体のマーケティングプランを考えたりとか、そういったビジネス的視点から導入された指標なのかもしれません。


何はともあれ、ユーザー単位トラッキングについては積極的に導入していく必要がありますね。

Google Universal Analyticsで公式発表は無いものの「navigator.sendBeacon()」に対応

注意 : {useBeacon:true}の利用は非推奨に変わりました。

Googleからの公式発表は無いものの、Universal AnalyticsのJavascript APIにnavigator.sendBeacon()の設定が追加されているようです。

「navigator.sendBeacon()」については、簡単に言うと解析用の小さな通信をブロッキング無しに非同期で行うというものです。
Universal Analyticsの場合、外部へ飛んで行くイベントだったり、PDF等のコンテンツダウンロードのイベントをcallbackを使って取得することが可能でしたが、今回の「navigator.sendBeacon()」への対応によって、callbackが必要無くなります。

実際にちょっとしかけてみました。

仕掛け方は簡単。

ga('send', 'event', 'Clicks', 'Outgoing', 'Google',  {useBeacon: true});

と「useBeacon」のプロパティを持たせてあげればOKです。

実際、Universal AnalyticsのJavascriptを見てみると、確かにパラメータを持っていました。

で、実際にイベントを発生さえた時のGoogle Chromeの「Network」がこちら。

Beacon APIの場合、Responseが返ってこないため「canceled」として表示されるようです。

でも、実際にAnalytics側で見てみると、イベントが飛んできていることが分かります。

デバッグツールによっては、データが見えるものと見えないものが存在しているようです。

この「navigator.sendBeacon()」ですが、現在利用できるブラウザは

Chrome 37以上
Firefox 31以上
IE　非サポート
Opera 24以上
Safari　非サポート

となっているようです。
デジタルアナリティクス的には、データの欠損を防いだり、コンテンツに影響を及ぼさず、逆にコンテンツの影響を受けない状況を作り出す意味では、恐らく他のブラウザもサポートされるのではないかと期待しています。

Google Analyticsという意味では、恐らくON/OFF設定をサイト側に持つのか、Tag Managerのみで設定を開放するのか。そんな流れになるのでしょうね。

HTTPSのBing経由でサイトへアクセスするとGoogle AnalyticsにはDirectとして計測される

日本国内ではあまり利用率は高くないと思いますが、BingのHTTPs対応が完了しているということで、Google Analyticsに渡る値を少しみてみました。

今回はAnalyticsを利用されている「どこどこJP」さんのサイトを検索してみました。

・・・ダブルクォーテーションで囲まないと検索結果にヒットしねぇ(泣)

そしてランディング！

さすが、既にUniversal Analyticsで計測されているわけですが、見ていただきたいのが「utmz」値ですね。

拡大したのがこれ。

Analytics側には完全に「direct」として値が渡されていますね。HTTPsだから当たり前といえば当たり前ですが、利用率が多くなるとチャネル別の分析というのも、ちょっと考えないといけないですね。

Google Analyticsのサイト速度・ページ速度のサンプリングレートを10％以上にあげることも可能

Google AnalyticsにはHTML5のNavigation Timing APIを利用して、ユーザー環境における実際のページ表示速度、サイト全体における表示速度を計測する機能があります。

以前はユーザーのサンプリングレートが10%だったと記憶しているのですが、現在はデフォルトのサンプリングレートが1%に変更されています。

この辺りは情報を追いかけられていなかった自分の失態ですね。

Google 側のヘルプを見ると

setSiteSpeedSampleRate()

の利用を推奨しておりますが、

【非同期版】(サンプリングレートが5%の場合)

_gaq.push(['_setSiteSpeedSampleRate', 5]); 

※trackpageviewの前に書く

【Universal Analytics版】

ga('create', 'UA-XXXX-Y', {'siteSpeedSampleRate': 5}); 

Google Tag Managerの場合は単純に「5」という数字を入れるだけのボックスがありますので、そこでリリースが可能です。

で、このサンプリングレートですが、値のレンジを調べてみるとGoogleの資料には0～100まで指定することが出来ると書かれてありました。

今まではNavigation Timing APIに対応していないSafariなどもありますので、大規模サイトではそれなりにサンプリングデータが取れたとしても、小～中規模サイトではサンプリング数が少なくデータによる上下の振れ幅が大きかったのですが、このサンプリングレートを上げることで中規模サイトぐらいでも安定して数値を取得することができますね。

今は個人的にテスト中なのですが100%のサンプリングでデータをとっています。

Analytics側からサンプル数のカラムが無くなってしまったようなのですが、数値の安定性という面で検証していこうかと思います。

【非同期版】(サンプリングレートが100%の場合)

_gaq.push(['_setSiteSpeedSampleRate', 100]); 

※trackpageviewの前に書く

【Universal Analytics版】

ga('create', 'UA-XXXX-Y', {'siteSpeedSampleRate': 100});