モチベーション
Google Tag Managerを利用してGoogle Analyticsのタグを配信するということ自体はGoogleの公式ドキュメントはじめ、解説ドキュメントも多く実装すること自体で問題が発生することは少ないと思います。1サイトだけではなく複数のウェブサイトを運営している場合のGoogle Analyticsの設定には多少コツがあるのではないかと感じていますので、多少なりとも個人的な実装ポイントをまとめてみようと思います。実装ポイント
似たようなタグを複数作成しないこと(極力管理できる量のタグに整理しておく)複数ヶ所修正する部分が発生し、修正漏れが起こることを防ぐこと
Google Analyticsでの計測をキレイにし、分析しやすい環境を最初から意識して整えること
前提条件
運営サイトはA( foo.example.com )とB( bar.example.com )の2サイトを別プロパティで計測する。目次
- 単純実装パターン
単純実装パターン(ヘルプや本、各ブログ等で解説されるもの)
設定項目
- Google Analyticsのタグ設定
- トリガー設定
1. Google Analyticsのタグ設定
まずGoogle Analyticsの「タグ」を作ります。初回はGoogle Analyticsのトラッキングコードを登録する必要があるため新規に「変数」を登録します
自分のトラッキングコードを入力して登録します。
2. トリガー設定
次にGoogle Analyticsの「タグ」の発火条件を登録します。以下では「All Pages」ということで全てのウェブサイトで発火する登録となっていますが、実際にはAサイトだけで発火させるかBサイトだけで発火させるかという一部の条件でのみ発火するようにします。
問題点
単純に設定しただけじゃ、そりゃ問題はあるでしょ と思うかもしれませんが、ここでの問題は以下の問題が挙げられます- Google Analyticsの計測タグが複数発生する (似たようなタグが複数生成される)
- 新規サービスの立ち上げ等に伴い、各ウェブサイトごとの設定が発生するなどの拡張に耐えられない (タグ・変数・トリガーが溢れ管理が煩雑となる)
改善案
- Google AnalyticsのトラッキングコードをLookup変数化する
- 毎回ドメインを書いていくフローを止める
- カスタムディメンションもIDごとにLookup変数化する
- タグ設定でのOverrideは極力やめる
- テンプレートを利用したイベントタグ数の最小化
改善案1. Google AnalyticsのトラッキングコードをLookup変数化
改善の第一歩は、ウェブサイトのドメインとトラッキングコードの紐付け部分です。ドメインとトラッキングコードが仮にこのような関係となっていたと仮定します。■Page Hostname - Tracking Code
foo.example.com : UA-XXXXXX-01
bar.example.com : UA-XXXXXX-02
bar.example.com : UA-XXXXXX-02
その場合Google Analyticsのトラッキングコード用変数がドメインごとではなく、1つGoogle Analytics変数とトラッキングコード判定を行うLookup変数が1つの、2つの変数による組み合わせに変化します。つまりtracking codeをドメインを見て動的に変化させるようにするということです。
実際の設定としてはどうなるかというと、まずLookup変数を作ります。デフォルト値としてどちらか片方のドメインを登録するのも良いかもしれません。
そこで作ったLookup変数を最初に作ったGoogle Analyticsの変数、トラッキングコード入力欄に入れます。
★tips
実際の設定としてはどうなるかというと、まずLookup変数を作ります。デフォルト値としてどちらか片方のドメインを登録するのも良いかもしれません。
そこで作ったLookup変数を最初に作ったGoogle Analyticsの変数、トラッキングコード入力欄に入れます。
★tips
Lookup変数のPage Hostnameの部分を定数変数として新規に作成しておくのも良いと思います。
改善案2. ドメインの都度記述の停止
■次に考えるべき「変数」や「トリガー」で大量に記述してく問題新規にトリガーを書くたびに完全一致や正規表現でドメインを書いていると更新漏れも発生しやすく事故の元となります。できればドメインの管理は1箇所で行っておきたいところです。
タグ配信の優先度としてGoogle Analyticsのようなトラッキング系タグを優先的に発火させ、広告タグは後で発火させるような設定とした方が良い気がしておりますが、以下のような手段が考えられます。(Optimizeを利用している場合はトラッキングタグの前)
■手段
- トラッキングコードLookupで管理
- ドメインを定数で管理
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
例えばカスタムディメンションを以下のようにキーを設定したいとします。
■UA-XXXXXX-01
cd1 : dim_foo1
cd2 : dim_bar1
■UA-XXXXXX-02
cd1 : dim_bar2
この場合、以下のLookup変数を用意します。
つまり4つの変数を用意することになります。
- カスタムディメンション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は以下のように作ります。
★tips
次にカスタムディメンション2のKeyを作りたいのですが、カスタムディメンション2は UA-XXXXXX-02 しか設定されていないのでカスタムディメンション2のKeyは以下のように作ります。
ValueのLookup変数設定
KeyのLookup設定が出来てしまえばValueも同じ要領で作るだけです。以下はカスタムディメンション1のValueとして適当なValueを出力しています。★tips
この後、Google Analyticsのタグ側にLookup変数を入れていくのでLookup変数名称はパット見て分かりやすいものにしましょう
このように設定することでカスタムディメンションが設定されているトラッキングコードのみに適用することが出来ます。もう少し良い管理方法があればなと思いますが、Google Analyticsの変数内のカスタムディメンション設定欄がidごとに入力する必要がある事が重荷になっており、配列等で渡すことが出来ないということが大きな要因になっています。(Googleに伝わるかは分かりませんが要望は出してみました)
このOverride設定とは何かというと、トラッキングコードを設定した「変数」での設定内容を上書きするものです。これを利用するということはトラッキングごとの個別設定が発生してしまっているということを意味しますので、「変数」側で対処できることは「変数」にもっていき「タグ」としてのGoogle Analyticsトラッキングはなるべく1つに抑えましょう。(イベントタグで2つ以上に拡大する可能性はありますが、トラッキングのタグとしては少数化)
まずはテンプレートをインストールします。
イベントのカテゴリ、アクション、ラベル等入れる値をそれぞれ If Else If テンプレートを使って作っていきます。注意点としては上から順番に評価される点です。
あとはGoogle Analyticsでイベントタグを作りカテゴリ、アクション、ラベルにそれぞれ作成した If Else If テンプレートを当てていきます。トリガーは各イベントごとのトリガーをORで複数設定していきます。
このやり方がキレイかどうかは分かりませんが、今まで何十個かあったイベントタグをまとめながら管理しやすいタグの数まで抑えるのにこのテンプレートはとても役に立ちました。
パラメータ系はカスタムディメンションだったり他の箱に入れましょう。またカスタムディメンションにフルURLを入れておくとなお安心です。
★tips
Google Analyticsのプロパティでドメインも表示するように設定をしている場合は パス を設定するのではなくfieldsに location を設定し、ドメインも含めたURLを渡す必要があります。各種パラメータは自分で事前に変数を作っておく必要があります。
変数は {{Page Hostname}}{{Page Path}} と組み合わせるとキレイなURLが出来ます。
URLのパスだけをキレイに集計する場合、各種パラメータがなくなってしまいます。その場合パラメータの値をカスタムディメンションなどに入れるのではなく、この方法でキャンペーンとして格納しておくと集計が楽になる事があります。
analytics.js の各種Fieldパラメータは公式のヘルプを参考にしてください。
★tips (参考)Analytics.js Field Reference
どのように変数に格納し、どのようにLookupし解決していくか。その組み合わせにより処理が遅くなる場合もあります。結果として (not set) が溢れる場合もあります。更新し忘れや管理できない量のタグであふれかえる事はなくなりますが処理が重くなっては元も子もありません。当たり前ですがリリースしたら結果をGoogle Analyticsの「リアルタイム」等で確認しながら作業しましょう。
海外情報はちゃんと調べていないので分からないのですがGoogle Tag Managerの応用事例や最適化事例がネットではあまり無い気がしています。基本ケースは良いのですが応用ケースについて、もう少し情報が出てくると良いなぁ。
最後に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設定を紹介しておこうと思います。- URLのパスまたはフルURLをTag Managerで渡す
- 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の応用事例や最適化事例がネットではあまり無い気がしています。基本ケースは良いのですが応用ケースについて、もう少し情報が出てくると良いなぁ。
0 コメント:
コメントを投稿