ブログ

google-universal-analytics

【保存版】Google Analytics(UA版)のトラッキングコードカスタマイズ5選+組み合わせ例4選

はじめに

本エントリーでご紹介するトラッキングコードはUniversal Analytics(以下UA)のコードです。

従来のGoogle Analytics(以下GA)のトラッキングコードについての記述はありません。
WEBサイト用のコードで、モバイルアプリ用のコードについての記述もありません。

また、コードの一節一節に関する詳細な説明はあえて書きません。
書くと文字がいっぱいになって書くほうも読むほうも大変なので。
詳細は公式のヘルプ等をご参照ください。

 

目次

0.カスタマイズ無し
1.ディスプレイ広告
2.拡張リンクアトリビューション
3.クロスドメイン
4.マルチトラッキング
5.eコマース
6.ディスプレイ広告+拡張リンクアトリビューション+クロスドメイン
7.ディスプレイ広告+拡張リンクアトリビューション+マルチトラッキング
8.ディスプレイ広告+拡張リンクアトリビューション+マルチトラッキング+クロスドメイン
9.ディスプレイ広告+拡張リンクアトリビューション+マルチトラッキング+クロスドメイン+eコマース

 

0.カスタマイズ無し

カスタマイズ無し

 
最初に管理画面で「これ貼ってね」と言われるコードです。
「UA-12345678-9」は適当なプロパティIDなので、実装の際はご自身のIDに変更するのをお忘れなく。

 
以降カスタマイズについて書きますが、上記コードの1~5行目と最後の行は固定で、”その間”にカスタマイズ用のコードが入る感じです。
カスタマイズ無しのコードはココが2行(7,8行目)です。

 

1.ディスプレイ広告

ディスプレイ広告に対応させる=GAのデータを元にGoogle Adworsでリマーケティングを実施する際と、性年代/興味関心のレポートを有効化するのに必要なカスタマイズです。
 
ディスプレイ広告対応

 
※以降コードは、カスタマイズ無しをベースに、追加/変更のあった行を青くハイライトするようにします。
上記でいう8行目です。

 
併せて管理画面から「ユーザー属性とインタレスト カテゴリに関するレポートの有効化」をオンにするのもお忘れなく↓
 

ディスプレイ広告対応1

 
性年代/興味関心のレポートを有効化するために、レポート画面から「有効化」するのもお忘れなく↓
 

ディスプレイ広告対応2

 

2.拡張リンクアトリビューション

GAレポート画面内、「行動」>「ページ解析」という”ページ内にあるリンクのクリック数や率”を表示してくれるレポートの中で、同一ページ内にある”URLが同じリンク”を別々に認識し数値を出してくれるようになるカスタマイズです。
このカスタマイズが無いと飛び先が同じURLにはすべて同じ数値が表示されます。
リンクのクリックをカウントしているのではなく、遷移先のURL単位で回数をカウントしているため。
 
拡張リンクアトリビューション対応

 
併せて管理画面から「拡張リンク アトリビューションを使用する」をオンにするのもお忘れなく↓
 

拡張リンクアトリビューション

 

3.クロスドメイン

ドメインは異なるが、同一サイトとして1つのプロパティで計測したい場合のカスタマイズです。
例えば、商品のブランドサイトがあって、その商品をクリックすると、購入できるECサイト(別ドメイン)に遷移するなど、流入からコンバージョンまでにドメインをまたぐような場合。
 
クロスドメイン対応

 
上記コードを両サイトに実装します。まったく同じものでOKです。

 
また、GAレポート画面内、「行動」>「サイトコンテンツ」では、ページURLのドメイン以下のみが表示されます。
クロスドメイン計測を行っていると複数サイトのページURLが表示されることになりますが、ドメインが表示されていないとどのサイトのページか分からなかったりするので、ページURLをドメインから表示させるよう、「フィルタ」の設定もお忘れなく↓
※引用の部分は「(.*)」と入力してあります。
 

フィルタ設定

 
あと、クロスドメイン計測を行っているサイトからの流入を”参照元”としてレポートに表示させないよう、「参照元除外」の設定もお忘れなく↓
 

参照元除外設定

 

4.マルチトラッキング

1つのサイトから、2つ(複数)のプロパティにデータを飛ばすためのカスタマイズです。
基本的に「従来のGAのコード」と「UAのコード」は共存できますが、UAのコード2つは共存できないため、このようなカスタマイズをします。
 
マルチトラッキング対応

 
また、マルチトラッキングで各プロパティへリンクのクリック数等をイベントトラッキングで計測する場合、通常のイベントトラッキングコードは以下ですが、
 

 
2つ目のトラッカー(プロパティ)に対するコードは、
 

 
と、「send」の前に「secondTracker.」を付けます。

具体的に、本ブログの右側にあるRSSの画像リンクのクリック数を計測する場合、通常だと、
 

 
こうなりますが、2つ目のプロパティに飛ばすためのコードは、
 

 
こうなり、両方のプロパティに飛ばしたいので、結果、
 

 
と、「;」でコードを繋ぎ、両方へ飛ばします。
※コードを改行し、すべて表示させるにはコード改行ボタンをクリックしてください。

 

5.eコマース

ECサイトで、購入された商品、購入金額などを計測し、レポート表示させるためのカスタマイズです。
以下は購入完了ページへ実装するコードです。
※購入完了ページ以外のページには、11~30行目が無いコードを実装します。
 
eコマース対応

 
併せて管理画面から「eコマースの設定」をオンにするのもお忘れなく↓
※拡張eコマースは未経験のため、説明無しです、すみません。
 

eコマース設定

 

6.ディスプレイ広告+拡張リンクアトリビューション+クロスドメイン

以降は組み合わせです。
各種、前述した管理画面やレポート画面からの設定は割愛しますが、実装の際はくれぐれもお忘れなく。
 
ディスプレイ広告+拡張リンクアトリビューション+クロスドメイン対応

 

7.ディスプレイ広告+拡張リンクアトリビューション+マルチトラッキング

そのままなので説明割愛。
 
ディスプレイ広告+拡張リンクアトリビューション+マルチトラッキング対応

 

8.ディスプレイ広告+拡張リンクアトリビューション+マルチトラッキング+クロスドメイン

クロスドメインとマルチトラッキングがセットになるとちょっと面倒くさくなってきます。
いくつかパターンがあるかと思いますが、まずは以下の図のパターンでAAA.comに実装するコードです。
 
ディスプレイ広告+拡張リンクアトリビューション+クロスドメイン+マルチトラッキング対応

 
7~10行目はAAA.com単独での計測用プロパティに飛ばし、12~17行目はBBB.comとのクロスドメイン計測をしているプロパティに飛ばしています。
一応ですが、以下はBBB.comに実装するコードです。
違いは7行目のプロパティIDだけです。
BBB.comを単独で計測しているプロパティIDになっています。
 

ディスプレイ広告+拡張リンクアトリビューション+クロスドメイン+マルチトラッキング対応

 
また、以下のようなパターンで、BBB.comに実装するコードはこのようになります。
 

ディスプレイ広告+拡張リンクアトリビューション+クロスドメイン+マルチトラッキング対応

 
7~14行目はAAA.comとのクロスドメイン計測でプロパティID「UA-12345678-9」へ飛ばしていて、14~19行目はCCC.comとのクロスドメイン計測でプロパティID「UA-98765432-1」に飛ばしています。
 

9.ディスプレイ広告+拡張リンクアトリビューション+マルチトラッキング+クロスドメイン+eコマース

だいぶカオスなコードになってきました。これで最後です。
8番目のコードにeコマースを追加したコードです。
購入完了ページに実装するコードです。
※購入完了ページ以外のページには、20~65行目が無いコードを実装します。
 
ディスプレイ広告+拡張リンクアトリビューション+クロスドメイン+マルチトラッキング+eコマース対応

最後に

地味に疲れましたし、最終的にカオスなコードをご紹介してしまいました。
ちなみに実装は、タグマネージャーを使うか、せめてJSファイルを外部化したほうが運用しやすいと思います。

 
GAは非常に優れたツールです。
サイトにアクセスした人の様々なデータが取得できますし、AdwordsやGoogle Playなどとの連携で、より効果的な施策を打つことができるようになります。

 
ただ「ひとまず最初は取得できるだけ取得できるようにしておいて、活用の仕方はあとで考えよう」といったのはやめたほうが良いと思っています。
あっちのサイトともクロスドメインしておきたい、こっちのサイトはまた別で、、、となったりすると、あれもこれもとなり、実装や運用時の手間が増えたり、あまり良いことないです。
そういうケースに限って、取得後あまり活用できていないことが多いです。

 
大事なことは、サイトのパフォーマンスを上げることです。
サイトの存在意義は?このサイトは何故ある?事業にとってどんな存在か。どんな役割があるのか。
商品を知ってもらうことなのか、買ってもらうことなのか、店舗の場所を知ってもらうことなのか。
ユーザーに何をしてもらいたいのか。

 
これらを明確にすると必然的にどの数字を見なければいけないか、上げなければいけないか、が分かってきます。
つまり、サイトのKGIやKPIは、企業の、事業のKGIから逆引きし設定することができ、設定した指標と関連指標のデータがきちんと取得できるよう、予算や運用体制などを考慮しながらツールを選定し、実装し、運用で試行錯誤しながら量や質を上げていくのが自然な流れなのかなと思っています。
サイトのKPIが上がれば事業のKGIにも遠からず影響する、という仕立てになっているべきかなと。

 
もちろんこれらは理想で、すべてがすべてこのようにガチガチに決めてやるべきとまでは言いませんが、少なくともサイトの存在意義を意識し、サイトの存在を知ってほしい人に知ってもらって、見てくれた人に何かしら有益なモノを提供できたほうが良いのかなと思います。

 
今回、従来のGoogle AnalyticsからUniversal Analyticsへ移行する際にニーズがあるかなと思いこのエントリーを書きましたが、トラッキングコードを変えることができるこのタイミングで、併せて、改めてサイトの存在意義について考え、整理してみるのも良いかもですね。
 

Pocket

コメントを残す

メールアドレスが公開されることはありません。

number inc. / 代表
渋谷 泰一郎
Taiichiro Shibuya
Analytics Director

TwitterFacebook