GoogleアナリティクスのAMP対応を利用する際に注意すべきたった一つのこと
ずいぶん前になってしまったが、前回GoogleアナリティクスのAMP対応について紹介した。
実装自体は JSON 形式で計測したいデータ項目を記述していくだけなのでそんなに難しくないけど、デベロッパーガイドをよく読むと少し注意が必要なようだ・・・
そもそも AMP って?
Acceralated Mobile Pages の略で、ものすごく端折って言うと余計な JavaScriptの動作を封じたり画像読み込みを最適化することで、スマホですごく早くページが表示されるようになったよ、という取り組み。
詳しくは、GA の AMP 対応の話とともに、過去記事ご覧ください。↓
GAのAMP対応の落とし穴って何・・・?
デベロッパーガイドに Client ID in AMP pagesなる記事がありこれが要必読。
英語だし長いので重要な部分をかいつまんでピックアップする。
Client ID に関する挙動が変わるよ
上記デベロッパーガイドのリンクによると、冒頭に次のような記述がある。
For non-AMP pages Google Analytics uses a single, first-party cookie named _ga to store the client ID (on the publisher domain).
For AMP pages, things are a bit different. Pages can be viewed via a browser in multiple ways causing client ID generation and management to vary.
AMP じゃない普通の html ではファーストパーティ cookie に Client ID という ID を格納して、それでユーザー(厳密にはブラウザってことになるかな?)を識別しているよ。でもそれは AMP だとちょっと事情が違って、様々な理由により Client ID の生成に関して違いが出てくるよ、ってとこか。後半をよく読むと分かるが、Client ID がユニークにならないケースがあって、ユーザーの判別が通常の html と変わってくることがあるということらしい。
AMP 対応した場合に考えられるシナリオ
GA のデベロッパーガイドによると次のようなパターンを考慮する必要があるとのこと。
- Google Search: AMP page is accessed via a Google Search result.(検索結果から AMP ページを訪れた場合)
- Proxy/Cache: AMP page is accessed from a proxy/cache.(キャッシュやプロキシから AMP へアクセスした場合)
- Direct: AMP page is directly visited on publisher domain.(サイトのドメイン内の AMP に直接アクセスした場合)
- Non-AMP: non-AMP page is accessed on publisher domain.(サイトのドメイン内 AMP 以外のページへアクセスした場合)
検索結果から AMP ページを訪れた場合
- この場合、google.com の検索結果に IFRAME で 自分のサイトのページが表示される。
- しかも、IFRAME 内のページは cdn.ampproject.org ドメインにホストされている。
- Client ID は、google.com に対してまず発行される。
- ちなみに、一番発生しやすいシナリオだろう、とのこと。
キャッシュやプロキシから AMP へアクセスした場合
- cdn.ampproject.org ドメインにホストされてるページにダイレクトにアクセスするケース。
- そうそう無いよね、このシナリオ(だってさ)
- この場合の Client ID は cdn.ampproject.org の 1st party cookie に格納される
- cdn.ampproject.org を直接指定してアクセスしている限りは、同じ cookie = 同じ Client ID になる
サイトのドメイン内の AMP に直接アクセスした場合
- 前述のキャッシュやプロキシから・・・ってやつとほぼ同じ、ただ、cdn.ampproject.org ドメインってとこが 自ドメインになる。
- この場合の Client ID は、自ドメインの「AMP_ECID_GOOGLE」という cookie に格納される
AMP 以外のページにアクセスした場合
- この場合の Client ID は、自ドメインの「_ga」という cookie に格納される
何が問題なのか?
一言で言えば、上記4つのシナリオで発行される Client ID は全てバラバラになる、ということ。
つまり、たとえ実際には同じ人だったとしても、別々の人として認識されてしまう、ということが起こりうる。
・・・ってことは、新規ユーザーとかユーザー数とか、セッションとか、の数値が、これまでの普通の html だけで構成されたサイトとは変わるよね、という話。
でも、そりゃドメインが違ったり cookie が違ったりするんだから、当たり前だよね、って話。
ってかこれ GAの問題じゃないじゃん。。cookie や Local Storage が同じドメインしかアクセスできない仕様として、w3c(?だよね、多分)が定めてるんだから。
解決方法は?
AMP 対応を発表した GA の公式ブログでは、この問題に対し混乱を避けるために、AMPの計測を行うプロパティは従来のものと別にするのがいいよ、と推奨している。
a single user that visits an AMP version of a page and a HTML version of a page can end up being treated as two distinct users. Using a separate Google Analytics property to measure AMP pages makes it easier to handle these issues.
あとは、サーバーサイドでIDを発行して、それを URL とかにくっつけて都度取得して Client ID に設定するかな。
AMP project のリポジトリ見てると、amp-analytics のフィールドの中に clientId ってのがあるので、ここにそのIDを設定すればなんとかなりそうな感じ。
Googleアナリティクス 関係のその他のコンテンツ
datalove.hatenadiary.jp
datalove.hatenadiary.jp
datalove.hatenadiary.jp
参考:
Analytics Blog: Announcing GA Support for Accelerated Mobile Pages (AMP) Analytics(英語)
Adding Analytics to your AMP pages | Analytics for AMP Pages | Google Developers(英語)
amphtml/analytics-vars.md at master · ampproject/amphtml · GitHub(英語)