2020年5月のGoogle AnalyticsとSearch Consoleドキュメント系アップデート

以前は毎月アップデートを見ていたのですが、ここ何年も全く見ていなかったので再度。Google Analytics等のGoogleツールに関する気になった仕様変更やドキュメントの変更等をまずは2020年5月分で見ていこうと思います。

Google Analyticsドキュメントの2020年5月変更

アナリティクス360のサンプリング閾値が100万セッションから1億セッションへ

有料の360版は選択した期間でビュー単位のセッション数が1億件以上へ変更されたようです。従来の100万から100倍増加しましたがPCのメモリ増加やChrome等ブラウザ側が多少は大きなデータでも落ちたりせず安定化しているからかもしれません。

参考

GDPR等個人情報に関するデータのアップデート

データに関してはいくつかアップデートがあったようです。

  • 広告パーソナライズ設定でAdwordsとリンクしAnalyticsデータを用いたオーディエンスターゲティングに関しパーソナライズを無効化できるようです。
  • 「管理者間のデータ保護に関する条項」が追加。Google Analyticsの場合はGoogleがデータの処理者としての立ち位置で整理されていますが、「Googleのプロダクトとサービス」で各種Googleサービスとデータを共有した場合、処理者ではなく管理者という立場になるようです。この部分はちょっと気になるところ。社内法務に一旦軽く確認したほうが良さそうな、そんな気がしました。

参考

その他Google Analyticsのドキュメントに関して新設のページ等もありましたが、大きな変更はなさそうでした。

Google Search Consoleドキュメントの2020年5月変更

解決可能なURLに関するアナウンス

クローラーがクロールする際、アンカーリンクで辿ることが出来るか出来ないかという説明は書かれていましたが、アンカーリンクでもjavascriptを用いた遷移は辿ることが出来ないという記述が増えました。

# に関しては意図がイマイチ分かりませんが、単純に # だけだとページTOPに戻るだけになるので、それを辿らせる意味もイマイチ分からないなぁと思います。とはいえページトップに飛ばしたい場合はちゃんとidを指定して上に飛ばすのが良いということなんでしょうかね。

参考

Web Vitalsまわりはドキュメントも大きく変更

5月といえばWeb Vitalsなんでしょうね。

ドキュメントを見ると以前はFCPとFIDに関して書かれていたのですが、このタイミングでFIDとLCP、CLSの3指標に切り替わっています。ユーザにとって快適なウェブを提供するという意味ではどれも重要な指標です。

参考

Google Analyticsのビューレベルフィルタ - 「検索して置換」の正規表現について

Google Analyticsのビューで設定できるフィルタですが、ここに「検索して置換」という項目があります。

この「検索して置換」の検索側は正規表現が利用できますが、あくまで検索でヒットしたものを文字列に置換するだけなので書き換えではありません。先日検索側に正規表現を書き正規表現でヒットした文字列を置換側に引き継ごうと $1 のようなものを書いていたのですが、見事に文字列 $1 という文字列が大量に発生するだけとなりました。

リネームというか検索でヒットしたものを整形して書き換える場合は「詳細」側を利用しましょう。。

普段は「詳細」ばかり利用していたのですが、「検索して置換」のほうが事故が少ないかなと思い利用してみたら事故になったという個人的な事案の共有です 😥

(参考)アナリティクスヘルプ - 検索と置換フィルタ

Custom Dimensionsにデフォルト値は存在しない

Google AnlayticsのCustom Dimensionsに入っている値をを引っ張ると所謂 (not set) は存在しませんが、これはCustom Dimensionsにはデフォルト値が存在しないということです。解決策としては

  1. Google Tag Managerでデフォルト値を埋める
  2. 別々に取得して後でマッピングする
  3. 有料版はBigQueryから取り出す

あたりでしょうか。いざ自分で分析用途ではなく業務フローに組み込むとなると、色々考える部分が出てくるなと思った次第。

ちなみに私の場合は無料版のGoogle Analyticsを利用しているため、2の別々に取得するパターンを選びました。Scopeがユーザである必要があった事と値を埋めるタイミングが少ないためです。Google Tag Managerで出来れば埋めたいけど、色々考えた結果ちょっと難しそうでしたので。

(参考)Google Tag Managerのテンプレートを利用してCustom Dimensionを作る

Google Analyticsで新規にプロパティを作成した際は設定を一応全部見ておくこと

今年に入ってから気づきましたが、Google Analyticsで新規にプロパティを作成した際にデフォルトで 参照元除外リスト として、作成したウェブサイトのサブドメインを含まないドメイン部分がデフォルトで登録されています。

例えばPropertyとして https://foo.example.com というURLについて作成したとすると、デフォルトで example.com が設定されます。通常これはあまり問題ではないのかもしれませんが、大企業におけるウェブサイトの運営等でサブドメインごとに運営会社やサービスが異なるような場合は要注意かもしれません。

参照元除外リスト自体はGoogle Analyticsの設定時に毎回見る部分ではあったのですが、今まではデフォルトで 何も登録されていないだろう という気持ちだったので、登録があったときの衝撃といったらなかったです。規模が大きい会社と付き合いがあったので、ちょっとヒヤッとしますね。。。

Google Tag Managerを用いたGoogle Analytics設定の改善手法例

モチベーション

Google Tag Managerを利用してGoogle Analyticsのタグを配信するということ自体はGoogleの公式ドキュメントはじめ、解説ドキュメントも多く実装すること自体で問題が発生することは少ないと思います。1サイトだけではなく複数のウェブサイトを運営している場合のGoogle Analyticsの設定には多少コツがあるのではないかと感じていますので、多少なりとも個人的な実装ポイントをまとめてみようと思います。

実装ポイント

似たようなタグを複数作成しないこと(極力管理できる量のタグに整理しておく)
複数ヶ所修正する部分が発生し、修正漏れが起こることを防ぐこと
Google Analyticsでの計測をキレイにし、分析しやすい環境を最初から意識して整えること

前提条件

運営サイトはA( foo.example.com )とB( bar.example.com )の2サイトを別プロパティで計測する。

目次

  1. 単純実装パターン

単純実装パターン(ヘルプや本、各ブログ等で解説されるもの)

設定項目

  1. Google Analyticsのタグ設定
  2. トリガー設定

1. Google Analyticsのタグ設定

まずGoogle Analyticsの「タグ」を作ります。初回はGoogle Analyticsのトラッキングコードを登録する必要があるため新規に「変数」を登録します



自分のトラッキングコードを入力して登録します。


2. トリガー設定

次にGoogle Analyticsの「タグ」の発火条件を登録します。以下では「All Pages」ということで全てのウェブサイトで発火する登録となっていますが、実際にはAサイトだけで発火させるかBサイトだけで発火させるかという一部の条件でのみ発火するようにします。


問題点

単純に設定しただけじゃ、そりゃ問題はあるでしょ と思うかもしれませんが、ここでの問題は以下の問題が挙げられます
  • Google Analyticsの計測タグが複数発生する (似たようなタグが複数生成される)
  • 新規サービスの立ち上げ等に伴い、各ウェブサイトごとの設定が発生するなどの拡張に耐えられない (タグ・変数・トリガーが溢れ管理が煩雑となる)
このパターンは単純なGoogle Analyticsのタグという箱に対し、Google Analyticsのトラッキングコードを登録した「変数」と、このタグ自体の発火条件としての「トリガー」が組み合わされている状態となっています。


改善案

  1. Google AnalyticsのトラッキングコードをLookup変数化する
  2. 毎回ドメインを書いていくフローを止める
  3. カスタムディメンションもIDごとにLookup変数化する
  4. タグ設定でのOverrideは極力やめる
  5. テンプレートを利用したイベントタグ数の最小化

改善案1. Google AnalyticsのトラッキングコードをLookup変数化

改善の第一歩は、ウェブサイトのドメインとトラッキングコードの紐付け部分です。ドメインとトラッキングコードが仮にこのような関係となっていたと仮定します。

■Page Hostname - Tracking Code
foo.example.com : UA-XXXXXX-01
bar.example.com : UA-XXXXXX-02

その場合Google Analyticsのトラッキングコード用変数がドメインごとではなく、1つGoogle Analytics変数とトラッキングコード判定を行うLookup変数が1つの、2つの変数による組み合わせに変化します。つまりtracking codeをドメインを見て動的に変化させるようにするということです。



実際の設定としてはどうなるかというと、まずLookup変数を作ります。デフォルト値としてどちらか片方のドメインを登録するのも良いかもしれません。



そこで作ったLookup変数を最初に作ったGoogle Analyticsの変数、トラッキングコード入力欄に入れます。



★tips
Lookup変数のPage Hostnameの部分を定数変数として新規に作成しておくのも良いと思います。

改善案2. ドメインの都度記述の停止

■次に考えるべき「変数」や「トリガー」で大量に記述してく問題
新規にトリガーを書くたびに完全一致や正規表現でドメインを書いていると更新漏れも発生しやすく事故の元となります。できればドメインの管理は1箇所で行っておきたいところです。

タグ配信の優先度としてGoogle Analyticsのようなトラッキング系タグを優先的に発火させ、広告タグは後で発火させるような設定とした方が良い気がしておりますが、以下のような手段が考えられます。(Optimizeを利用している場合はトラッキングタグの前)

■手段
  1. トラッキングコードLookupで管理
  2. ドメインを定数で管理

2-1. トラッキングコードLookupで管理

改善案1 でトラッキングコードLookupを作成し、そこにPage Hostnameをベタ書きした場合はこちらの手法で良いと思いますが、各ドメインごとに別の変数処理をしたい場合や個別ドメインでトリガーを発動させたい場合は例えば Lookup変数がUA-XXXXXX-01だったら という処理に切り替えます。正規表現もとても書きやすく楽です。

★tips
定数は一箇所で管理しLookupで更新し忘れの事故がないようにする場合、一番気をつけたいのはタグの発火・実行される順番です。順番を指定しなかった場合、一部計測が落ちる可能性があります。

2-2. ドメインを定数で管理

改善提案1 でトラッキングコードLookupを作成した際、Page Hostnameをベタ書きではなく、別の定数変数を作った場合はその定数変数を利用する方法です。こちらはとても直感的です。

今現在私はこちらを採用しておらずLookup変数にトラッキングコードをベタ書きしていて、全ての参照はトラッキングコードを起点としていますが、その理由は以下のようなものがあります。
  • 管理しているドメインが随時増えており都度変数を作るのが面倒
  • ステージング環境 / 本番環境 という2パターンで処理する事が多いので変数やトリガーがあふれる可能性がある

ここはサイトの特性と管理方法に合わせて対応すれば良いと思います。

改善案3. カスタムディメンションもIDごとにLookup変数化する

1例としてカスタムディメンションをあげましたが、プロパティごとに個別の値が生まれてタグの数が爆発しやすい原因の一つがカスタムディメンションなどのプロパティ値です。

この処理もっと良い処理の仕方は無いものかといつも考えている悩みの種ではあるのですが、現在カスタムディメンションIDごとにKeyとValueそれぞれのLookup変数を作る方法を採用しています。

例えばカスタムディメンションを以下のようにキーを設定したいとします。

■UA-XXXXXX-01
cd1 : dim_foo1
cd2 : dim_bar1

■UA-XXXXXX-02
cd1 : dim_bar2

この場合、以下のLookup変数を用意します。
  • カスタムディメンション1のKey、カスタムディメンション2のKeyのLookupをそれぞれ作成する
  • カスタムディメンション1のValue、カスタムディメンション2のValueのLookupをそれぞれ作成する

つまり4つの変数を用意することになります。

KeyのLookup変数設定

まずKeyの変数を作ります。ここで確認するポイントは どのトラッキングコードでどのidが払い出されているか です。

今回は両方のトラッキングコードでカスタムディメンション1は設定されているので、カスタムディメンション1のKeyを次のように作成します。デフォルト値の設定メニューを利用するのも良いでしょう。私は本番環境は個別にLookup変数を組みテスト環境はデフォルト値として定義しているといったものも作っています。



次にカスタムディメンション2のKeyを作りたいのですが、カスタムディメンション2は UA-XXXXXX-02 しか設定されていないのでカスタムディメンション2のKeyは以下のように作ります。


ValueのLookup変数設定

KeyのLookup設定が出来てしまえばValueも同じ要領で作るだけです。以下はカスタムディメンション1のValueとして適当なValueを出力しています。



★tips
この後、Google Analyticsのタグ側にLookup変数を入れていくのでLookup変数名称はパット見て分かりやすいものにしましょう

最後にGoogle Analytics変数への組み込み

KeyとValueのLookup変数を作り終えたら最後にGoogle Analytics変数に組み込みます。組み込み方としては詳細設定メニューの中にカスタムディメンション設定欄がありますので、ここに作った変数をそれぞれ埋めます。



このように設定することでカスタムディメンションが設定されているトラッキングコードのみに適用することが出来ます。もう少し良い管理方法があればなと思いますが、Google Analyticsの変数内のカスタムディメンション設定欄がidごとに入力する必要がある事が重荷になっており、配列等で渡すことが出来ないということが大きな要因になっています。(Googleに伝わるかは分かりませんが要望は出してみました)

改善案4. タグ設定でのOverrideは極力やめる

カスタムディメンションを変数化できたことで、だいぶトラッキングコードごとの個別設定は減ってきたと思いますが、Google Analyticsの「タグ」側でOverrideを利用していては元も子もありません。この青チェックボックスの事です。



このOverride設定とは何かというと、トラッキングコードを設定した「変数」での設定内容を上書きするものです。これを利用するということはトラッキングごとの個別設定が発生してしまっているということを意味しますので、「変数」側で対処できることは「変数」にもっていき「タグ」としてのGoogle Analyticsトラッキングはなるべく1つに抑えましょう。(イベントタグで2つ以上に拡大する可能性はありますが、トラッキングのタグとしては少数化)

改善案5. テンプレートを利用したイベントタグ数の最小化

Google Analytics関連のタグでトラッキングタグも増える原因ではあるのですが、もう一つ増えるタグが イベントトラッキング のタグ。色んなタイプのイベントトラッキングタグを出来るだけ一つのタグに統合するためにTemplateギャラリー(変数)から If Else If を使って統合します。(Googleが提供するテンプレートではないので必要に応じてアップデート等を行ってください)

まずはテンプレートをインストールします。



イベントのカテゴリ、アクション、ラベル等入れる値をそれぞれ If Else If テンプレートを使って作っていきます。注意点としては上から順番に評価される点です。



あとはGoogle Analyticsでイベントタグを作りカテゴリ、アクション、ラベルにそれぞれ作成した If Else If テンプレートを当てていきます。トリガーは各イベントごとのトリガーをORで複数設定していきます。



このやり方がキレイかどうかは分かりませんが、今まで何十個かあったイベントタグをまとめながら管理しやすいタグの数まで抑えるのにこのテンプレートはとても役に立ちました。

Google Analyticsでの計測をより快適にするための改善案

次にGoogle Analyticsを運用する上で個人的に設定しておいた方が良いGoogle Tag Manager設定を紹介しておこうと思います。
  1. URLのパスまたはフルURLをTag Managerで渡す
  2. utm以外のパラメータをutmと同様のキャンペーンとして渡す場合はFieldへ入れる

1. URLのパスまたはフルURLをTag Managerで渡す

Google Analyticsを使っていて一番問題になりやすいのは1ページに複数のURLが発生してしまうことがあるという点です。主にパラメータだったりハッシュ値だったり様々な条件で解析時にURLをフィルタで絞り込み、メトリクスを足し合わせたり平均をとったりしなければなりません。なのでFieldsとして page フィールドにURLのパスだけを渡すことで1ページ1URLとして集計することができます。



パラメータ系はカスタムディメンションだったり他の箱に入れましょう。またカスタムディメンションにフルURLを入れておくとなお安心です。

★tips
Google Analyticsのプロパティでドメインも表示するように設定をしている場合は パス を設定するのではなくfieldsに location を設定し、ドメインも含めたURLを渡す必要があります。各種パラメータは自分で事前に変数を作っておく必要があります。

変数は {{Page Hostname}}{{Page Path}} と組み合わせるとキレイなURLが出来ます。

2. utm以外のパラメータをutmと同様のキャンペーンとして渡す場合はFieldへ入れる

utmコードを用いてキャンペーンをトラッキングしている場合はGoogle Analyticsのキャンペーンとしてちゃんと集計されますが、様々なツールだったり過去からのルールなどによりutm以外のパラメータで流入するものもutmと同じ箱に格納してしまいましょう。同様にutmコードを使いたくないという場合も同じ手法でutmの箱に格納することが可能となります。



URLのパスだけをキレイに集計する場合、各種パラメータがなくなってしまいます。その場合パラメータの値をカスタムディメンションなどに入れるのではなく、この方法でキャンペーンとして格納しておくと集計が楽になる事があります。

analytics.js の各種Fieldパラメータは公式のヘルプを参考にしてください。

★tips (参考)Analytics.js Field Reference

どのように変数に格納し、どのようにLookupし解決していくか。その組み合わせにより処理が遅くなる場合もあります。結果として (not set) が溢れる場合もあります。更新し忘れや管理できない量のタグであふれかえる事はなくなりますが処理が重くなっては元も子もありません。当たり前ですがリリースしたら結果をGoogle Analyticsの「リアルタイム」等で確認しながら作業しましょう。

海外情報はちゃんと調べていないので分からないのですがGoogle Tag Managerの応用事例や最適化事例がネットではあまり無い気がしています。基本ケースは良いのですが応用ケースについて、もう少し情報が出てくると良いなぁ。

lighthouse-batchを利用したURLリストに対するlighthouse実行メモ

Google Lighthouseはウェブサイト・ウェブアプリの品質向上に役立つツールで、ページスピードやSEO、PWAなど実装について計測、評価、アドバイスをもらうことができます。

ページ単体の評価であればChromeの拡張を利用したり、Chrome Devtoolsのauditを利用することで評価結果を見ることができますが、特定のURLリストについて片っ端に調べるとなると骨が折れます。

今回はnpmのlighthouse-batchを利用してみました。
lighthouse-batchを利用することでnpmのページにあるこれで一発で取得可能です。

lighthouse-batch -f sites.txt

sites.txtに改行区切りでURLのリストを入れておくだけで、あとは自動的に順番にチェックが走っていきます。
デフォルトでは出力データはjsonになります。
ファイルは report > lighthouse あたりに置かれていく事になるでしょう。
.
├── readme.md
├── report
│   └── lighthouse
│       └── __URL__.report.json
└── sites.txt

jsonファイルは各指定したURLに対応するものとは別に summary.json が出力されます。
summaryには全URLのスコアデータのみが載っており詳細は個別のjsonファイルを見ることとなりますが、summaryをBigQueryへ格納する場合のschemaはこんな感じで良いかと。雑ですがdetailだけ繰り返し無しのrecordで。

[
          {
            "name": "url",
            "type": "string"
          },
          {
            "name": "name",
            "type": "string"
          },
          {
            "name": "file",
            "type": "string"
          },
          {
            "name": "score",
            "type": "float"
          },
          {
            "name": "detail",
            "type": "record",
            "fields": [
              {
                "name": "performance",
                "type": "float"
              },
              {
                "name": "accessibility",
                "type": "float"
              },
              {
                "name": "best_practices",
                "type": "float"
              },
              {
                "name": "seo",
                "type": "float"
              },
              {
                "name": "pwa",
                "type": "float"
              }
            ]
          }
]

summary.jsonは1行1URLとなるように少し修正して、こんなフォーマットへ変換。

{"url":"https://www.google.com/","name":"www_google_com_","file":"www_google_com_.report.json","score":"0.70","detail":{"performance":0.47,"accessibility":0.93,"best_practices":0.79,"seo":0.99,"pwa":0.3}}
{"url":"https://www.google.com/","name":"www_google_com_","file":"www_google_com_.report.json","score":"0.70","detail":{"performance":0.47,"accessibility":0.93,"best_practices":0.79,"seo":0.99,"pwa":0.3}}

URL等はダミーです。1行1レコードになるので改行区切りで。カンマとか不要なものは取り除きます。もっと簡単なimportも可能なんだろうとは思いますが｡
そのままbq loadします。

bq load --source_format=NEWLINE_DELIMITED_JSON mydataset.mytable summary.json

でsummaryのimportは終わりです。( mydataset.mytable の部分はBigqueryに用意したテーブルへ変換が必要)

今は個別のjsonは一旦GCSへ格納してしまっているのでsummaryでスコアを見て気になったページのレポートをGCSへ見に行くという行動をしているのですが、個別のjsonもBigqueryのテーブルに突っ込むというのもありなんだろうと思います。(summary.jsonのfileというのが詳細レポートのファイル名になっています)

ちなみにローカルにあるlighthouseレポートのjsonはviewerが用意されているので、ここで見るのが一番良さそう。

Lighthouse Report Viewer

たまにウェブサイトの健康診断の意味でも主要ページはlighthouseで確認をしたいところですね。

Dimensions & Metrics Explorerページの”Google Analytics Demos and Tools”移管

Google AnalyticsのCore Reporting APIでDimension名やMetric名を調べる際に調べるDimensions & Metrics Explorerページですが、今後Google Analytics Demos and Tools側に移管されるようです。


Notice: The Dimensions and metrics explorer is moving to Google Analytics Demos and Tools, and will be turned down in the coming weeks. Please try out the new site and report any issues you run into on the Issue Tracker.
他の開発側ページだとこの案内はなさそうに見えますがGoogle AnalyticsのAPI、コードまわりは一部developersから移管されていくのかもしれません。
Bookmarkしている場合はとりあえず変更しておくと良いかもです。