Google AnalyticsのMeasurement ProtocolはHTTP送信とレポート反映を分けて確認する
公開日： 執筆：佐藤
Measurement Protocolを使うと、ブラウザのJavaScriptを通さず、HTTPリクエストでGoogle Analyticsへhitを送れます。ただし、送信先から2xxの応答を受け取っても、そのpayloadが正しく処理されたとは限りません。
実装では、payloadの組み立て、HTTP送信、レポートへの反映を別の工程として確認します。送信プログラムが正常終了したことと、計測に使えるデータが入ったことを同じ結果にしないのが要点です。
最初に一件のhitを四つの必須値で組み立てる
Measurement Protocolの公式リファレンスは、すべてのhitに次の四つを求めています。
| 値 | parameter | 役割 |
|---|---|---|
| Protocol Version | v |
使用するprotocolの版を示す。値は1 |
| Tracking ID | tid |
送信先のGoogle Analyticsプロパティを示す |
| Client ID | cid |
利用者を区別するIDを示す |
| Hit Type | t |
pageviewやeventなど、送る操作の種類を示す |
説明用に、一つのpageviewを送るpayloadを組み立てると、次のようになります。
v=1&tid=UA-123456-1&cid=5555&t=pageview&dp=%2Fmeasurement-test
UA-123456-1、5555、/measurement-testは仮の値です。実装時は、確認用プロパティのTracking ID、同じ利用者を同じものとして扱うためのClient ID、計測対象を識別できるpage pathへ置き換えます。
四つの必須値がそろっていても、値の意味が合っているとは限りません。たとえば、別のプロパティのtidを指定すれば、HTTP送信に成功しても目的のレポートには入りません。parameterの有無と、値の対応を分けて確認します。
POSTとGETはpayloadの長さとキャッシュを見て選ぶ
送信先はhttp://www.google-analytics.com/collectです。SSLを使う場合はhttps://ssl.google-analytics.com/collectへ送ります。公式リファレンスはPOSTとGETの両方を示し、より大きなpayloadを扱えるPOSTを勧めています。
GETでは、payloadをURI escapeしたquery parameterとしてURLへ含めます。encode後のURL全体は2000 bytes以内です。また、GETリクエストがキャッシュされる環境では、同じURLへの後続送信がGoogle Analyticsへ届かない場合があります。公式リファレンスには、乱数を入れるz parameterがcache busting用として用意されています。
サーバーから継続して送る処理なら、まずPOSTを選びます。GETしか使えない環境では、encode後のURL長とキャッシュの有無まで送信条件に含めます。方式を選んだら、送信先、HTTP method、payload、送信時刻、応答statusを確認できる記録を残します。
2xxはHTTPリクエストを受け取った結果として読む
Measurement Protocolは、HTTPリクエストを受け取ると2xxのstatus codeを返します。一方、payloadの形式が誤っている場合や、値が正しくない場合、Google Analyticsで処理されなかった場合にも、error codeを返さないことがあります。
したがって、2xxを「計測成功」の印にしません。2xxで確認できるのは、まずHTTP送信の段階です。次に、送ったhitと同じ条件でGoogle Analyticsのレポートを確認します。
2xx以外の応答を受け取った場合は、自動で同じrequestを繰り返す前に、endpoint、method、requestの形式を直します。誤ったpageviewやeventを無条件に再送すると、原因を残したまま重複だけを増やすためです。
確認用プロパティで送信と反映を照合する
公開中の集計へいきなり試験データを入れず、確認用のウェブプロパティを用意します。そこで、一件のhitを次の順に照合します。
- 送信する
tid、cid、tと、pageviewならdpを記録する - encode後のpayloadを確認する
- 一度だけHTTPリクエストを送る
- 応答のstatus codeと送信時刻を記録する
- リアルタイムレポートで、指定したpage pathを探す
- 通常のレポートでも同じpage pathを確認する
リアルタイムレポートは、公開直後の計測確認に使えます。ただし、表示があったことだけで実装を完了にしません。送信したhit type、page path、eventの値が、集計後のレポートでも目的どおりに扱われるかを確認します。
表示されない場合は、tid、cid、t、hit固有のparameter、encode、送信先の順に戻ります。通信処理とGoogle Analyticsの画面を行き来して推測するより、一件のpayloadと一件の表示を対応させた方が原因を絞れます。
送信処理と計測設計の担当を分けない
Measurement Protocolの送信プログラムだけを外部へ依頼すると、HTTP statusまでは確認できても、何を一件のhitとして扱ったかが事業者側に残らない場合があります。納品時には、parameterの対応表、送信する条件、送信しない条件、確認用プロパティ、送信記録、再送の判断を受け取ります。
Google Analyticsアカウントとプロパティの管理権限も、送信プログラムとは別に確認します。プログラムを直せる担当者がいても、送信先のtidやレポートを事業者が確認できなければ、実装結果を判定できません。
最初の一手は、確認用プロパティへ一件のpageviewを送り、HTTP応答とレポート表示を同じ記録へ残すことです。一件を説明できてから、eventやサーバー処理へ対象を広げます。
関連記事
