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

モバイルサイト側で標準ブラウザってどれだけ使っている人がいるんだろう…。
そんな疑問をもって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 でデータがちゃんと抽出される

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

ウェブテスト前後のデータ比較をするならそこまで問題は発生しないかもしれませんが。
シーケンスで設定しなければならない点も含め、なんでこんな動きしてるんだろう…と1日に2度驚いた…という話でした。

[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
    FROM
      `xxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxga_sessions_2017092*`,
      unNEST(customDimensions) cd,
      unNEST(hits) hits
    WHERE
      cd.index = 1
      AND cd.value IS NOT NULL
      AND hits.page.searchKeyword IS NOT NULL
    GROUP BY
      cd.value,
      hits.page.searchKeyword) t2 ) t1

WITHIN RECORDを使うやり方やFLATTENを使うやり方、UNNESTを使うやり方などもあり、FLATTEN/UNNESTはRECORDタイプをフラット化して取り扱うやり方ですね。
結構customDimensionsをBQから抜いてる人は多そうですがネット上にはあまり情報が無いなという印象。普段からQueryを書き慣れている人からするとRECORDタイプとかもそんなに苦もなく処理できるんですかね。

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't hurt.
の部分です。 4時間より以前のものに関しては保証されないというヤツですね。再送信可能と書かれているものの `保証されない` だけで二重にカウントされるのも嫌ですしね。
IndexedDBから送信された分だけ消えるのかとか、その辺りも確認が必要かもしれないですね。

autotrackのプラグインで遊ぶ

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

autotrack.js はGAの新しいツールというわけではないのですが、元々GAの設定をカスタマイズするのは面倒だ…という場合にプラグインを使って簡単にキレイなデータ取得をしてしまおうと始まったと記憶しています。しかし今月バージョンが1.0に上がるタイミングで新しいプラグインが追加されたことによって、特にChromeを中心に新しく実装されたWeb APIを使った解析を体験出来るようになりました。

例えば…

これは「Intersection Observer API」を利用したもので、例えばページを開いたタイミングでは見えない特定のバナーや特定の領域がスクロール操作によって表示されたら、そのタイミングでイベントを飛ばすというもの。

テストではページの下の方にボタンを設置しておき、スクロール操作によってボタンが表示されたタイミングでイベントが飛びました。


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


この辺、凄く面白いですよね。
タブが非アクティブになったタイミングでセッションを一回切っても良いなと最近感じていました。

autotrack.js が登場した当時からあったプラグインではありますが、URLをキレイにしてGAにデータを飛ばすというもの。
今回はURLにパラメータが付いていたら全て消してページビューとして集計するという設定。


URLのパラメータによって、同一ページなのにURLが大量に発生してしまい解析が面倒臭くなる…そんな事が無くなりますね。

GTMが出てきた時から設定する人が多かった、自社サイトから他社サイトへのアウトバウンドリンクを踏んで出ていくイベントを取得するプラグインですね。

特定のページからどれだけ外に出ていってしまうのか等、アウトバウンドリンクを計測するサイトも最近は多いのかなという印象。



クリックイベントも毎回onClickやら設定するのは面倒だという場合にはこのプラグインを使えばイベントもサクッと取得出来ます。(ソーシャルインタラクションなどイベント以外も利用可)

イベントカテゴリ「Video」に対するクリックイベントアクション「play」も。



他にもmedia queriesを利用してレスポンシブ・ウェブデザインを実装されているサイトでは「mediaQueryTracker」が、より解析の役に立ちますし、1ページ内でpushStateなどを利用してURLが変わる場合は「urlChangeTracker」が利用できるでしょう。

今回は全てデフォルト値で試しました。

セグメント機能で1条件と2条件に分ける基準は何でしょう…

何度か書いているような気はしますが、セグメント機能はGoogle Analyticsだけではなく「分析」の側面でとても重要だということは言うまでもありませんが、同時に鬼門といっても過言ではないほど難しいポイントではないかとずっと感じております。

衣袋さんのメルマガをチラ見して、セグメント機能に関する電子本を出されるということで大いに期待しております(笑

セグメント機能に対して凄く単純な話、この2つの違いは分かるでしょうか?



未だにちゃんとテストはしていないのですが、かなり大規模なサイトの場合この2つのセグメント結果は微妙に異なります。
超大規模サイトの場合は値が変わることなんて様々な要因で日常茶飯事ではありますが。

で、現状は一応以下のように解釈しております。

  • 2つは対象母集団の絞り方の違いでしか無い
  • 2つ目のパターンの場合は、まずChromeユーザを絞ってからその中から更に市区町村でセグメントがかかる動きをする。
即ち基数制限まわりの問題なのではないかと。

他にもシーケンスにするか単純条件とするか。結果はほぼイコールになったりする場合がありますし、毎日のようにセグメントを書いていてもちゃんと理解できていないなと思う事が多すぎて、非常に残念に感じてしまいます…

API側の場合は更にカオスになります。GUI側がちゃんと理解できていなければ間違えることは言うまでもありませんが、複数シーケンスで且つその中に条件が入り込む例などをGoogleヘルプでは見ることができますし、"その指定は必要?"という疑問も湧いてくるレベル。


閑話休題

様々な施策で事前に仮説立てをすると思いますが、それ以外にも調査をすることもあると思います。最近はメンバーに「とにかく思いつく疑問・質問を出せ」と言っています。
だいたい普通に思いつく疑問はサイトへの仕込み方やGAへのデータの食わせ方にも寄りますが、GA一つで数値は出せるかなと思っています。普段からGAを使いこなしている方の場合は、それ以外に出すことが難しいもの、出した後にデータをこねくり回さなくてはならず非常に面倒なものにぶち当たるかもしれません。

例えば最近あった個人的な課題としては
  • ある特定セッション期間中に特定ページを●回以上見ている~
みたいな問題です。
2回とか3回ならデータを出せなくはないなーとか、データの取得方法を変更すれば取れるけど過去のデータはキツイなーとか、素直に別のツールをーとか。色々感じる単純問題。

まぁただ、「思いつく疑問・質問」として出てきたもので出せないものが出てきたことはないので、個人的な調査でぶち当たる壁くらいしかないのかなと思ったりします。