GoogleAnalytics イベントトラッキング: onClick vs onMouseDown

GAカスタマイズでよく使われるonClick

Google Analytics でページ内のPDFファイルへのリンクやボタンのクリックなど、標準のトラッキングコードでは収集されないデータを収集するためには、イベントトラッキングかバーチャルページビューを使います。

普通よくやるのは、対象のエレメントのclickイベントハンドラからtrackEvent/trackPageviewメソッドを呼ぶ手法で、実際に下記のようなコードがあちこちで使われています。

<a href="/path/to/pdf.pdf" onclick="_gaq.push(['_trackEvent', 'PDFLink', 'Click', this.href]);">PDFへのリンク</a>

このコード、実はやや問題があって、リンク先のPDFの読み込みが速いと、ビーコンをGoogleに送る前にリンク先のPDFが開いてしまい、ビーコンを送信していた元のページがunloadされ、結果としてイベント/PVがカウントされないことがあります。
よくわからない図を描いてしまったので貼っておきますね。

この問題を避けるために、trackEvent/trackPageviewメソッドを_gaq(非同期実行キュー)に入れずに、_gat(トラッカーオブジェクト)を直接呼び出したり、trackEvent/trackPageviewメソッド呼び出し後に数十ミリ秒ウェイトさせたりと、ちょっと不細工な工夫をすることもよくあります。普通のリンクじゃなくて、別のウィンドウで開くなら(target="_blank"が付いていれば)こんな問題は起きないのですが…。

本当にonClickでいいのか?

ところで、「リンクがクリックされた」ことを検知するのはonClickでほんとにいいんだっけ?という議論が本題です。onClickの他にも、よくよく考えるとonMouseDownというイベントがあります。

onClick

マウスのボタンを押して離した後に発生するイベント

onMouseDown

マウスのボタンが押された瞬間に発生するイベント

ほとんど変わりないのですが、onMouseDownのほうが先に発生するので、上記のような「どこかへのリンクのクリックをイベントとして記録する」ような使い方ならどう考えてもこちらが有利な気がしますね。

Cardinal Pathが実際のサイトで実験してみたらしく、恐ろしい結果が…

• onMouseDownで計測したイベント数: 205
• Onclickで計測したイベント数: 122

実際のページビューと比較しても、onMouseDownのほうが正確だと言えるようです。いままでonClickで実装したあのサイトやあのサイトは大丈夫だろうか…と心配になってしまう結果ですね。

実際に同様のコードでビーコンの飛ぶタイミングを見てみました。

トラックパッドのタップでクリックしたので、mousedown -> mouseupまでの間隔はかなり短いですが(11msec)、たしかにビーコンのリクエストが発生したタイミングが12msecほど違います。

ただし、Cardinal Pathの筆者も計測方法に正しいとか間違ってるっていうのはないと記載しています。確かに、その指標がどうやって計測されているか理解していれば、正しく解釈できますからね。

また、実験で使用したコードを見たところ、onMouseDownとonClickを両方設定しているので、この実験のonClickの数値は若干少なめに出るような気がします。
(1つイベント処理してビーコン送るより2つ送るほうが時間かかってonClickのビーコンが飛ぶ前にunloadされるんじゃないかと; ビーコンは非同期・並列でリクエストされるから関係ないかも)

あと、めったに無いですが、リンクをドラッグしたとき(リンクをメールに貼り付けるときや、クリックしようとしてやめたとき)もonMouseDownイベントは発生するような気がしますね…

結論

いずれにせよ、この実験から分かるのは、

• Google Analyticsでクリックイベントを取るなら、onMouseDownのほうが確からしい数値が取れる
• どんな方法で計測・分析するにしても、指標の正確な定義は忘れないこと

という2点でした。

さて、いままでにやった実装を見なおさないと…

エンジニアから見た、Google Analyticsでできること

GWで暇だったので、いろいろ記録しておくべきことを書こうと思い、ブログを始めました。

日頃の業務でGoogle Analyticsをメインに、クライアントのWebサイトのアクセス解析導入・解析・報告を行なっていますが、エンジニアから見たGoogle Analyticsについて、ここでまとめておきたいと思います。

具体的には、Google Analyticsって何をどこまで出来るのか、ということです。

一般的な説明はオフィシャルサイトにまとめてありますが、「どういうふうに解析できるか」の視点で書かれています。

エンジニアなら、どんなデータを収集できて、どんなふうにカスタマイズできるの?ってところに興味がありますよね? ありませんか…

Google Analyticsの開発者向けドキュメントは、https://developers.google.com/analytics/ にあります。ただし、日本語版のドキュメントはどうしても古いので、必ず英語版を参照します。

開発者ガイドには、下記のトピックが載っています。

• Collection
• Webサイトのトラッキング
• Androidアプリのトラッキング(!)
• iOSアプリのトラッキング(!)
• Configuration
• Management API: 設定情報へのアクセスAPI
• Reporting
• Core Reporting API: レポートデータへのアクセスAPI
• Social Data Hub: ソーシャルメディアのオーナー向け。SNSデータをGAに統合できます。

「Webサイト以外にも、Android・iOSのネイティブアプリのトラッキングまでできます。設定情報とレポートデータはAPIからアクセスできます。あと、SNS持ってたらデータを統合できるよ。」とのことです。さすがGoogle、エンジニアが気にしそう、興味持ちそうなことはわかってます。

Android・iOSアプリのトラッキングやAPI、Social Data Hubの件はちょっと置いといて、Webサイトのトラッキングについて、何ができるか見てみましょう。

標準トラッキングコードで収集できるデータ

特にカスタマイズせずに、各ページにトラッキングコードを挿入すると、下記のデータは自動的に収集されます。

• ユーザ関連の情報
• 地理的位置・使用言語
• ブラウザ情報
• ページロード時間
• 流入経路
• Referrer・検索キーワード
• 閲覧コンテンツ・遷移

ちゃんと設定できていれば、下記のデータも取れます。

• ゴール達成: 申し込み完了などの目標が達成されたか
• サイト内検索
• AdSenseの収益

(ちょっと)カスタマイズしないとまずいケース

標準トラッキングコードのままだとちょっとまずい、代表的なケースを下記にあげます。

• サイトが複数のドメイン・サブドメインにまたがっている場合
• Cookieの有効ドメインの問題で、クロスドメインな遷移をすると、GAのセッションは別としてカウントされます。xxx.jp -> xxx.comみたいな遷移をするときは、リンク元ページで_linkメソッドを使ってセッション情報をGETパラメータで渡し、遷移先ページで_setAllowLinkerメソッドをつけて、セッション情報を受け取りましょう。
• サブドメインが違うだけなら、_setDomainNameメソッドでCookieのDomainを設定しましょう
• 動的サイトで、違うコンテンツを表示するのにURLが一緒になる場合
• 例えば申し込みシステムで、入力フォームと確認画面と完了画面のURLが全部一緒なんていうこともありますよね。GAはURLを基準にページを識別するので、ちょっと工夫が必要です。_trackPageViewメソッドに仮想URLを追加して、別URLにしてあげましょう。

カスタマイズしないと収集できないデータ

普通のサイトで、普通の使い方をするなら標準トラッキングコードで十分ですが、それでは満足しないなら、カスタマイズしましょう。

• キャンペーントラッキング: 流入元のキャンペーン(広告・媒体)を区別するのに使います。
• AdWordsキャンペーンは、Auto-TaggingをONにすると自動的にトラッキングされます。
• Yahoo!リスティングなど、AdWords以外のメディアや、メールマガジンなどで集客していて、その効果をトラッキングしたいなら、ターゲットURLにパラメータを追加します。Campaign URL Builderを使うと、日本語のエンコードまでやってくれます。
• カスタム変数: カスタマイズできる機能の中で多分もっとも複雑です。トラッキングデータに任意のメタデータを付加できます。とにかくガイドをしっかり読んで使いましょう。
• Page-Levelカスタム変数: ページのカテゴリや、動的コンテンツに何を出力したのかを記録するのに使います。
• Session-Levelカスタム変数: ログインしたユーザ/していないセッションを区別したり、キャンペーン告知Aを見たセッションだけを区別したりするために使います。
• Visitor-Levelカスタム変数: セッションが終わっても、Cookieにデータを記録して、次回のセッションでもデータを送ります。ユーザの性別・年代なんかを記録して、ユーザ層別の傾向を見たりするのに使います。
• Eコマーストラッキング: ECサイトの売上データをトラッキングします。カート機能の注文完了画面にECトラッキング用のコードを挿入してデータを飛ばします。
• _addItem: トランザクションに含まれる商品の情報を追加します。
• _trackTrans: トランザクションに関する情報(合計金額・顧客の地域 etc.)を追加します。
• イベントトラッキング: なんでも任意のイベントの発生を記録します。
• JSで取れるイベントであれば、ハンドラに_trackEventメソッドの呼び出しを書けば、発生したページと、_trackEventメソッドのパラメータに指定した、イベントカテゴリ・ラベル・値を記録してくれます。
• 検索エンジンの設定
• GAはReferrerを見て大体の検索エンジンからの流入を自動識別してくれますが、日本のマイナー検索エンジン(nifty searchなど)を検索エンジンからの流入として認識させたければ、_addOrganicメソッドを呼んで追加しておきます
• ソーシャルインタラクション: ページ上の「いいね」・「ツイートする」などのSNSボタンの使用をトラッキングします。
• Google+ ボタンは勝手にトラッキングしてくれるはずです。
• AddThisを使っているなら、AddThisのヘルプに書いているように、GAのアカウント番号を設定すれば、自動的にビーコンが飛びます。
• そうでなければ、ボタンのクリックイベントか、ソーシャルプラグインの書き込み完了イベントのハンドラで、_trackSocialメソッドを呼び出します。
• ユーザタイミング: ページロード時間は標準トラッキングコードで収集してますが、任意のリソースのロード時間なんかを収集することもできます。
• 非同期JSのロードで、ロード完了イベントのハンドラで_trackTimingメソッドを呼び出したりして使う。

DevGuideに書いてる機能は以上です。GAはJSビーコン型なので、Javascriptでどうにかなることなら、大体のデータは取得してGAに飛ばせます。後は、飛ばしたデータをGAがどう処理して、どういうレポートに反映してくれるかの問題かと思います。

書いてみて思いましたが、いろいろ出来過ぎですね。

それぞれの機能に絞って書いたほうが良かったかも…。