メルマガの開封率も計測できる! ユニバーサルアナリティクスの「Measurement Protocol」とは?
Measurement Protocolとは
Googleアナリティクスの最新バージョンであるユニバーサルアナリティクスでは、データ収集方法が大きく変わった。「実装するトラッキングコードがga.jsからanalytics.jsに変わった」という直接的な影響以外にも大きな変化があった。
それが「Measurement Protocol」(メジャメントプロトコル)と呼ばれるGoogleアナリティクスのサーバーにデータを送るための新しい仕組みだ。これを使うと、WebサイトにGoogleアナリティクスのコードを貼り付ける以外の方法で、データをGoogleアナリティクスで分析できる。
簡単に言ってしまえば、Measurement Protocolを使うと、インターネットに接続しているどのような機器からでもGoogleアナリティクスで集計可能なデータを送ることができる。
IoT(モノのインターネット)と言われるようになったとはいえ、あなたはこう思うのではないだろうか。
別にPOSレジやテレビ、冷蔵庫からデータを送る必要もないし自分には関係ないよね。
しかし、この仕組みのおかげで、あなたが発行しているメルマガの開封率も簡単に計測できるようになったと聞くと、興味をもたないだろうか。
こうした根本の仕組みを理解しておくことは、実は大変に役に立ち、実用的だったりもするのだ。それほど難しくないので最後までお付き合いいただきたい。
グーグルに送られているデータの中身はどうなっている?
Measurement Protocolを理解してもらう前提として、Googleアナリティクスでは、グーグルのサーバーにどのようなデータが送信されているのかということから話を始めよう。
Googleアナリティクスのトラッキングコードが実装されているページを閲覧すると、ブラウザが自動的に次に示すようなリクエストをグーグルのサーバーに送信する。
1つ目が従来のGoogleアナリティクスの非同期ga.js版でのリクエスト、2つ目がユニバーサルアナリティクスのanalytics.js版でのリクエスト例だ。
これらのリクエストを集めて集計した結果が、Googleアナリティクスのレポートになる。
従来の非同期ga.jsのリクエスト
http://www.google-analytics.com/__utm.gif?
utmwv=5.6.7d&
utms=2&
utmn=1756133946&
utmhn=xfusion.jp&
utmcs=UTF-8&
utmsr=1280x1024&
utmvp=1093x750&
utmsc=24-bit&
utmul=ja&
utmje=0&
utmfl=21.0%20r0&
utmdt=GoogleAnalytics&
utmhid=58789550&
utmr=-&
utmp=%2F&
utmht=1458980545845&
utmac=UA-1988149-1&
utmcc=__utma%3D213379805.955633772.1451203407.1458782970.1458980541.21%3B%2B__utmz%3D213379805.1456627167.15.4.utmcsr%3Dgoogle%7Cutmccn%3D(organic)%7Cutmcmd%3Dorganic%7Cutmctr%3D(not%2520provided)%3B&
utmjid=&
utmu=qAAAAAAAAAAAAAAAAAAAAAAE~
analytics.jsのリクエスト
http://www.google-analytics.com/collect?
v=1&
_v=j41d&
a=58789550&
t=pageview&
_s=1&
dl=http%3A%2F%2Fxfusion.jp%2F&
ul=ja&
de=UTF-8&
dt=GoogleAnalytics&
sd=24-bit&
sr=1280x1024&
vp=1093x750&
je=0&
fl=21.0%20r0&
_u=SCCAAEADI~&
jid=&
id=955633772.1451203407&
tid=UA-1988149-2&
z=6659974
どちらも構造は似ていて、リクエスト先のURLに各種パラメータが付いている形式だ。
2つ目のユニバーサルアナリティクスの場合で簡単に説明すると、URLのスキーム(プロトコル)とホスト名とパス名が「http://www.google-analytics.com/collect」で、そのあとのクエリ文字列の部分は下記のようにパラメータと値のセット(x=y)を「&」でつなげて記述している。
v=1
_v=j41d
a=58789550
t=pageview
…
tid=UA-1988149-2
z=6659974
この例では、ヒットタイプを意味するパラメータ「t」の値が「pageview」(赤字部分)なので、このリクエストは1ページビューの閲覧データを飛ばしていることになる。
そして最後から2つ目のパラメータ「tid」(青字部分)がプロパティID(トラッキングID)を意味するので、これによって、どのサイト(プロパティ)のデータなのかを判定できるといった具合だ。
非同期ga.js版は対応するパラメータが異なるが、基本的には同じような構造になっている。
リクエストの裏側の処理が大幅に変化した
このようにリクエストはga.jsでもanalytics.jsでも同様の形式だが、実は裏側で動作しているシステムが、ユニバーサルアナリティクスでは大幅に変わっている。
Measurement Protocol以前は、Googleアナリティクスのリクエストデータを送る際の条件が厳しかったため、「http://www.google-analytics.com/__utm.gif?utmwv=5.6.7d&utms=2……」といったリクエストを直接送ってもグーグルが受け取ってくれず、Googleアナリティクスで計測することはできなかった。
しかし、Measurement Protocol以降は、最低限の形式が満たされているリクエストであればグーグルが受け取ってくれるようになった。そのため、「http://www.google-analytics.com/collect?v=1&_v=j41d……」といったリクエストを送れば、グーグルが受け取ってGoogleアナリティクスで集計してくれるようになったというわけだ。
ブラウザのアドレスバーに直接入力してリクエストを送っても問題ないし、今回の主題であるメルマガの開封率を計測するためにHTMLソースに画像タグを入れ、そのsrc属性としてこのURLを記述しても問題ない。
Measurement Protocol以前と比べて、計測対象のデータをGoogleアナリティクスのサーバーに送信する自由度が大きく広がったといえる。
Measurement Protocolのパラメータを理解する
最低限必要なパラメータは4つ
Measurement Protocolの仕様をもう少し説明しよう。Measurement Protocolで最低限必要なパラメータは次の4つだ。これらが正しく存在していれば、データを受け付けてもらえる。
パラメータ | 意味 | 記述例(上記リクエスト例の場合) |
---|---|---|
v | バージョン | v=1 |
t | ヒットタイプ | t=pageview |
tid | プロパティID | tid=UA-1988149-2 |
cid | クライアントID | cid=955633772.1451203407 |
パラメータ「v」はプロトコルのバージョンを示すもので、現在のバージョンは1なので、「v=1
」と記述する。
パラメータ「t」は前述したがヒットタイプのことで、ページビューやイベントやトランザクション(購入)などのデータの種類を表すもの。ページ閲覧のリクエストなら、値は「pageview」と指定する。
パラメータ「tid」は、トラッキングコードに固有のIDであるプロパティID(トラッキングID)の「UA-XXXXXXXX-Y」を指定する。アナリティクス設定(図1赤枠部分)でプロパティの項目の「プロパティ設定」(図1青枠部分)の画面の上部にある「トラッキングID」(図1緑枠部分)がそれに該当する。
パラメータ「cid」はクライアントIDと呼ばれるもので、計測対象サイト利用者の固有のブラウザを識別するためのIDだ。ランダムに生成され、ブラウザのCookieに保存される。このクライアントIDを利用することで、Googleアナリティクスのユーザーやセッションを識別し集計する。クライアントIDの値は64ビット整数であればよい。Measurement Protocolでは、英数字を含む UUID(バージョン4)を指定できる。
ページビューデータのリクエスト例
ページビューのデータを扱う場合、基本の4パラメータに加えて、さらに3つのパラメータを追加しよう。「ホスト名」「ページ名」「ページタイトル」の3つだ(つまり合計7つのパラメータを送ることになる)。
それぞれ、「ホスト名」(dh)は計測しているサイトのホスト名を、「ページ」(dp)はパス名を、「ページタイトル」(dt)はタイトルタグの値を、通常は割り当てらる。
Measurement Protocolを利用して、ページビュー相当のデータとして扱いたいリクエストはこの3つを追加しておくとよいだろう。
パラメータ | 意味(ディメンション) | 記述例 |
---|---|---|
dh | ホスト名 | dh=example.com |
dp | ページ | dp=%2F |
dt | ページタイトル | dt=toppage |
パラメータ「dp」の値「%2F
」は、「/
」(スラッシュ)をURLエンコードした値だ。この例でのリクエストURL例は次のようになる。
http://www.google-analytics.com/collect?
v=1&
t=pageview&
tid=UA-1988149-2&
cid=955633772.1451203407&
dh=example.com&
dp=%2F&
dt=toppage
イベントトラッキング データのリクエスト例
イベントトラッキングを行う場合、基本の4パラメータに加えて、さらに2つのパラメータを追加しよう。「イベント カテゴリ」と「イベント アクション」の2つだ(つまり合計6つのパラメータを送ることになる)。
これらはイベントトラッキングの必須項目なので、最低限この2つを追加し、場合によってはオプションのイベント ラベル(パラメータ「el」)とイベントの値(パラメータ「ev」)も付与しよう。
またヒットタイプの変数「t」の値は、イベントトラッキングを表す「event」に変更する。
パラメータ | 意味 | 記述例 |
---|---|---|
ec | イベント カテゴリ | ec=email |
ea | イベント アクション | ea=open |
この例でのリクエストURL例は次のようになる。
http://www.google-analytics.com/collect?
v=1&
t=event&
tid=UA-1988149-2&
cid=955633772.1451203407&
ec=email&
ea=open
なお、パラメータを記述する順番は特に決められていないので、順不同でも問題なく動作する。上記の例は、下記のように記述しても同じだ。
http://www.google-analytics.com/collect?
tid=UA-1988149-2&
cid=955633772.1451203407&
v=1&
t=event&
ec=email&
ea=open
なお上記で紹介したパラメータは利用できるものの中のごく一部に過ぎない。興味のある方は開発者向けサイトの「Measurement Protocol のパラメータ リファレンス」のページを参照してほしい。パラメータによっては最大文字数の制限もあるので、気を付けよう。
- Measurement Protocol のパラメータ リファレンス
https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters
メルマガ開封の計測と開封率の計算
以上がMeasurement ProtocolにおけるリクエストURLの作成の仕方だ。実際にHTMLメール内でのメルマガの開封率を計測するためには、たとえば下記のようなタグを、HTMLソースに記述する。
<img src="http://www.google-analytics.com/collect?v=1&t=event&tid=UA-xxxxxxxx-y&cid=123456&ec=email&ea=open">
HTMLメールを受け取った人がメールを開いてHTML内にある画像が表示されると、<img>タグのsrc属性に指定したMeasurement ProtocolのURLにリクエストが発生し、計測されるというわけだ(ちなみに、Googleアナリティクスのサーバーからは実際に1ピクセル×1ピクセルの白色画像が返され、HTMLメール内に表示される)。
上記の例では、誰が開封したのかといった情報は必要なしと判断し、クライアントIDを指定するパラメータである「cid」には固定の値「123456」を一律仕込んでおけばよいとした例だ。
そのような準備を行ったうえで、メルマガ開封率の計算は、メルマガ発行のたびにその後2日間くらいを対象にして、Measurement Protocolで開封数を計測したイベント数÷メール送信数(エラー送信数は除いて)とすればよいだろう。[行動]>[イベント]>[上位のイベント]レポートの該当イベントの「合計イベント数」(図2赤枠部分)の数値を利用すればよい。
メルマガの発行頻度が高く、発行号別に開封率を正確に把握したいのであれば、イベント ラベルのパラメータ「el」にメルマガ発行日を割り当て、集計対象期間もメルマガ発行後1週間程度のように少し長めにするとよいだろう。具体的にはリクエストURLの最後に「&el=20160331
」など日付の情報を付け加えればよい。
また、この例ではクライアントIDを固定化しているので、別の人が開封してもそれが全部延べ数でカウントされてしまう。またセッションあたり500ヒット(データ送信)という制限に引っかかってしまう恐れもあるので、実際はクライアントIDをユーザーごとに変えて実装するなど、もう少し工夫しないといけない。
動作には注意、まずは別プロパティで運用を
開発者向けサイトでは下記のページでメールトラッキング用のMeasurement Protocol使用例を紹介している。
このページの例では、ページ(原文ではドキュメント パスと表現)やページタイトル(原文ではドキュメント タイトルと表現)やキャンペーン(参照元系)のパラメータまで紹介されていたので、実際にページ名をつけてイベントトラッキングのヒットをMeasurement Protocolでリクエストしてみた。
その結果だが、図3のようなカスタム レポートを作成したところ、ページビュー数がゼロ(図3赤枠部分)のページ名が出現(図3青枠部分)した。一方[行動]>[サイト コンテンツ]>[すべてのページ]レポートを見ると、このページ名(図3青枠部分)はレポートに表示されない。
Measurement Protocolでページビューのヒットは飛ばさず、イベントトラッキングのヒットだけを飛ばしたので、なるほどと納得できる。とはいうものの、どのように集計されるのかは実は想像できていなかったというのが正直なところだ。
なお[行動]>[イベント]>[ページ]レポートは通常イベントが発生したページが集計されるレポートだが、ここでは該当のページが表示された(図4赤枠部分)。
さらにMeasurement Protocolでキャンペーン(参照元系)のパラメータを利用した場合や、クライアントIDのパラメータをどのように指定するかで、「ユーザー」や「セッション」の判定や「セッション」数の集計がどのようなになるのかは、確信をもてない。もしセッション判定が変われば、ユーザー数、セッション数、直帰率、ページ/セッション、平均セッション時間、新規セッション率など、多くの基本指標にも多大な影響を及ぼす可能性がある。
メルマガ開封率の計測に限らず、本格的にMeasurement Protocolを利用したいのであれば、通常のウェブサイト利用と絡めてデータを見ないと意味がない場合を除いて、別のプロパティを作成して、そのプロパティIDを使ってMeasurement Protocolを利用したリクエストの運用をすることをおすすめしたい。
つまり、冒頭では「メルマガの開封率も簡単に計測できる」と書いたが、慣れるまでは慎重な利用を心がけよう。
ソーシャルもやってます!