読者です 読者をやめる 読者になる 読者になる

GoogleアナリティクスのAMP対応を利用する際に注意すべきたった一つのこと

google GA Google Analytics SEO AMP

ずいぶん前になってしまったが、前回GoogleアナリティクスのAMP対応について紹介した。
実装自体は JSON 形式で計測したいデータ項目を記述していくだけなのでそんなに難しくないけど、デベロッパーガイドをよく読むと少し注意が必要なようだ・・・

GoogleアナリティクスのAMP対応を利用する際に注意すべきたった一つのこと

そもそも AMP って?

Acceralated Mobile Pages の略で、ものすごく端折って言うと余計な JavaScriptの動作を封じたり画像読み込みを最適化することで、スマホですごく早くページが表示されるようになったよ、という取り組み。
詳しくは、GA の AMP 対応の話とともに、過去記事ご覧ください。↓

datalove.hatenadiary.jp

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 のデベロッパーガイドによると次のようなパターンを考慮する必要があるとのこと。

  1. Google Search: AMP page is accessed via a Google Search result.(検索結果から AMP ページを訪れた場合)
  2. Proxy/Cache: AMP page is accessed from a proxy/cache.(キャッシュやプロキシから AMP へアクセスした場合)
  3. Direct: AMP page is directly visited on publisher domain.(サイトのドメイン内の AMP に直接アクセスした場合)
  4. 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(英語)