投稿

改めて考えるCore Reporting V4 APIのメリット

イメージ
Core Reporting APIのV3を利用している人でV4になかなか踏み出せないという方も多いのではないかと思います。V4がリリースされて1年ちょっと。V3からV4への移行によるメリットは以下目的に集約されるのではないでしょうかということで、少しまとめてみようと思います。
Table of ContentsAPIリクエスト数の減少とそれに伴う分析時間の短縮2期間のデータ比較積み上げグラフ用(historical bucket)データ抽出V4のみサポートされる機能の利用pivotCohortLTVその他注意点などもsession dateが存在しなそう…V3であったfilterは存在するけど機能分裂欲しい機能 APIリクエスト数の減少とそれに伴う分析時間の短縮 ■2期間のデータ比較 従来2期間、例えば前年比や前週比、その他特定期間同士を比較する場合V3では2期間それぞれでAPIを叩き、その結果を自分たちで比較する必要がありましたが期間を配列で2つ渡すことが可能となったことによって1リクエストで完結することができるようになりました。

[{ startDate = 2017 - 11 - 22, endDate = 2017 - 11 - 22 }, { startDate = 2016 - 11 - 22, endDate = 2016 - 11 - 22 }]
V4では2期間を配列で入れ込みます。期間を複数指定した場合はsortの仕方として2期間の差に対するソートと以前のGoogle Analyticsで存在していた加重平均順が指定できるようになります。例えば2期間のユーザ数の差の降順で表示したい場合のorderBy指定は以下のような指定になります。

{ orderType = DELTA, fieldName = ga: users, sortOrder = DESCENDING }
DELTAは差、SMARTが加重平均となります。
2回投げてからSpreadsheetなどでデータを整形するとなると抽出されたデータが100%データであれば問題ありませんが、filterやデータサイズによって返却されたデータの中でしか分析ができません。この部分が解消された今回の2期間比較は大いに利用する価値があると思います。
■積み上げグラフ用(hist…

標準ブラウザなのかそうじゃないのか、それが問題だ

イメージ
モバイルサイト側で標準ブラウザってどれだけ使っている人がいるんだろう…。
そんな疑問をもってGAのブラウザ分布を見て「Android Browser」を見に行くパターン、それはアウトです…


User-Agent的にも当然ではあるのですが、Chromeに分類されているパターンも非常に多い。Chromeで非常に古いバージョンを利用している人とか気になりません?


バージョンを眺めていると古いバージョンは特定のバージョンに偏って、そのバージョン以外はほとんどセッションが無いという事になるのですが…


ほら…Android標準ブラウザの Chrome/40.2214.89 と一致。
全部のキャリアのUser-Agentを見たわけではありませんが、通常のChromeであれば少なからずどこかで強制アップデートがかかっていて、現状61あたりにはなっているっぽく見えます。

一旦ver.56以上をChromeユーザとみなすとか、そういう感じにしないとGAのChromeが増えてきた = Chromeユーザばっかりではないよ、という事ですね。

GAテストパターンに対するセグメントが意外と厄介

イメージ
Google Analyticsのウェブテスト、このウェブテストのテストパターンに対するセグメントの作成方法を最近ヘルプでの記載を見ました。他の方に指摘されて示された訳ですが、「条件」ではなく「シーケンス」で設定する必要があります。

■Googleヘルプのキャプチャ

これだけでも結構厄介というか想像がついていないわけですが…
なんでシーケンスなのにSTEP1だけ指定するだけのセグメントなの…と。全く理解出来ませんがデータ的にはちゃんと取れていそうなのでまぁこれは覚えれば良い内容ということで整理しましょう。

でも、更に不可解なのがこのウェブテストに対するセグメントが分析期間の指定によりデータが左右されるという事。

普段API側で作業をしているのでAPIとして具体的に説明すると…

■テスト期間
2017-10-01 〜 2017-10-10

■データ抽出1
start-date -> 2017-09-01
end-date -> 2017-09-30
metrics -> ga:users
segment -> users::sequence::ga:experimentId==xxxxxxxx

■データ抽出2
start-date -> 2017-09-01
end-date -> 2017-10-10
metrics -> ga:users
segment -> users::sequence::ga:experimentId==xxxxxxxx

の2パターンでデータを抽出するとします。データ抽出1とデータ抽出2では分析期間のend dateが違うだけです。
通常のcondition(条件)の場合、セグメントに入ってくるセッション開始日やセッション日などの日付とデータ抽出用のstart date、end dateは独立していますが、上の例のsequenceが問題なのかウェブテストが問題なのかはまだ検証が必要ですが、この場合は異なってデータが抽出されてきます。

■結果
データ抽出1 : 0
データ抽出2 : >0 でデータがちゃんと抽出される

つまりユーザレベルでデータを抽出しているにも関わらず解析期間内にウェブテスト期間を含んでいないと正しくデータが抽出されない事になります。
これは結構問題だなと感じますね…。

[BigQuery]Custom Dimensionsに対するQuery

GoogleのhelpでもBigQueryのCookbookとしてCustom Dimensionsに対するQueryの書き方があります。

■ヒットレベル SELECT fullVisitorId, visitId, hits.hitNumber, hits.time, MAX(IF(hits.customDimensions.index=1, hits.customDimensions.value, NULL)) WITHIN hits AS customDimension1, FROM [tableID.ga_sessions_20150305] LIMIT 100
■セッション・Userレベル
SELECT fullVisitorId, visitId, MAX(IF(customDimensions.index=2, customDimensions.value, NULL)) WITHIN RECORD AS customDimension2, FROM [tableID.ga_sessions_20150305] LIMIT 100
カスタムディメンションはBigQueryだとヒットレベル・セッション/ユーザレベル・プロダクトレベルの3つあります。

hit : hits.customDimensions
session/user : customDimensions
product : hits.product.customDimensions

上の例だとcustomDimension2には数値が入りMAXを取得する感じですが入ってる文字列を抜き出してjoinに使いたいとなった場合どう取得すれば良いかと少し悩みました。

パット見て最初わからなかったのは `customDimensions.value` の書き方の部分なのですが。

国内・海外含めコミュニティやブログを参照しつつ色々ためしてみて、一部抜粋&改変でちょっとイマイチな部分がありますが、最終的にこんな感じで書きました。

( SELECT t2.id AS id, t2.query AS query FROM ( SELECT cd.value AS id, hits.page.searchKeyword AS query …

Data Studioの正規表現、エスケープは2バックスラッシュ

イメージ
メモ的な投稿ではありますが、Googleの正規表現だからといってre2ではなく2バックスラッシュを利用しなければなりません。

いつもの事ではありますが日本語のヘルプには書かれていません


英語側のヘルプには記載されています。


最後の2 backslash charactersという部分ですね。
パースエラー、パースエラーと怒られて何でだよ!と検索しつつ試してみたら通って、「なーんだヘルプに書いてあるじゃん」と思ったら日本語側には無いという罠ですね。

PWAによるオフライン時のPVカウント実装 `sw-offline-google-analytics`

イメージ
Googleのオフィシャルで昨年アナウンスのあったnpmモジュール `sw-offline-google-analytics` を利用したオフライン実装は皆さん述べられている通り非常に簡単でしたのでメモ。


# 準備
## localhostにサンプルのPWAサイトを導入

1. node.jsをローカルへインストール
2. localの適当なディレクトリにPWAコンテンツを格納
3. `sw-offline-google-analytics` を導入

`npm install --save-dev sw-offline-google-analytics`

# service-worker.js を変更
## Googleドキュメントの通り service-worker.js に2行追加


※まだ最新版のバージョンは v0.0.25

## 計測が分かりやすいようにGA / GTMを設定
### Google Analytics側はカスタムディメンションを設定



### Google Tag Manager側は navigator.onLine でステータス把握
#### variable


#### tag側はカスタムディメンションにセット



# 実際の動きを確認
## ONLINE
通常どおりGA側にPVが送られている


## OFFLINE
GAへの送信がコケる


同時にIndexedDBへ格納される(4回OFFLINEアクセスをしてコケた時のキャプチャ)


## OFFLINE to ONLINE
まとめて送信される



# まとめ
moduleのバージョンが0.0.25なので今後のUpdateなども行われそうですが実装的には非常に簡単にできそうです。計測も問題はなかったのですが、数秒以内に何度もOFFLINEでアクセスをするといった場合はPVカウントがイマイチな気も少ししました(ネットワーク側の問題かも?)。ここは要検証。

ただ…注意事項としては
You should note that Google Analytics hits older than four hours are not guaranteed to be processed, but resending somewhat older hits "just in case" shouldn…

autotrackのプラグインで遊ぶ

イメージ
Google Analytics開発チームが作っているautotrack.jsで面白そうな拡張が出ているなと思いつつ…今月バージョンが1.0を向かえましたので、少しだけ遊んでみようかと思います。

autotrack.js はGAの新しいツールというわけではないのですが、元々GAの設定をカスタマイズするのは面倒だ…という場合にプラグインを使って簡単にキレイなデータ取得をしてしまおうと始まったと記憶しています。しかし今月バージョンが1.0に上がるタイミングで新しいプラグインが追加されたことによって、特にChromeを中心に新しく実装されたWeb APIを使った解析を体験出来るようになりました。
例えば…
impressionTracker これは「Intersection Observer API」を利用したもので、例えばページを開いたタイミングでは見えない特定のバナーや特定の領域がスクロール操作によって表示されたら、そのタイミングでイベントを飛ばすというもの。
テストではページの下の方にボタンを設置しておき、スクロール操作によってボタンが表示されたタイミングでイベントが飛びました。

pageVisibilityTracker Chromeをはじめタブブラウザを利用しているとウェブサイトを開いたままでもタブは非アクティブな場合がよくありますよね。 この非アクティブ <-> アクティブの変化時にイベントを飛ばすというもの。

この辺、凄く面白いですよね。 タブが非アクティブになったタイミングでセッションを一回切っても良いなと最近感じていました。
cleanUrlTracker autotrack.js が登場した当時からあったプラグインではありますが、URLをキレイにしてGAにデータを飛ばすというもの。 今回はURLにパラメータが付いていたら全て消してページビューとして集計するという設定。

URLのパラメータによって、同一ページなのにURLが大量に発生してしまい解析が面倒臭くなる…そんな事が無くなりますね。
outboundLinkTracker GTMが出てきた時から設定する人が多かった、自社サイトから他社サイトへのアウトバウンドリンクを踏んで出ていくイベントを取得するプラグインですね。
特定のページからどれだけ外に出ていってしまうのか等、アウトバウ…