
今回、発表されたAMP クライアントID API は、AMPページと通常ページ間のクライアントIDの取り扱い方によるトラッキングの問題に対処するソリューションです。これまでGoogleの検索で表示されるGoogleのキャッシュ上のAMPページのクライアントIDとサイトのドメインで取り扱うクライアントは別々に取り扱われていました。このクライアントIDの個別の取り扱いは、実際のユーザー動向とアナリティクスの指標が(大きく)乖離してしまう弊害を抱えていました。
AMP クライアントID API は、若干のコード変更を行ってオプトインという形で使用します。デフォルトの設定では、これまでと変わりません。AMP クライアントID APIを利用するかどうかの検討や判断するための参考情報として、クライアントIDに関連したAMPのトラッキングとそれに関連したアナリティクスの指標データへの影響について、Google ディベロッパーサイトのアナリティクスのページの説明を元にして以下に紹介します。
目次 - Table of Contents
クライアント ID とは?
Googleアナリティクスは、ユーザーを識別するためにユーザー固有のID(ユーザー識別子)を割り当てます。このユーザー識別子がクライアントIDです。
通常ページ(非AMPページ)では、_gaと言う名の単一、ファースト パーティー クッキーを使用してクライアント IDを格納します。AMPページでは、表示状況が大きく異なります。AMPのコンテンツは、サイト上のドメインだけではなく、Googleのドメインからも表示(配信)されます。ページはブラウザを通じて様々な方法で見ることができます。アクセスする方法(表示されるドメイン)で、クライアント IDのフォーマットや管理も異なります。そのためサイトの指標にも影響を与えます。
クライアント ID の使用・管理について
AMPページは様々な形でアクセスすることがきます。アクセスの仕方によるクライアント IDの取り扱いを以下のような物があります。
- Google 検索: Googleの検索を通して、AMPページにアクセスした場合
- 表示されるページは、Googleのドメイン上にあります。
- クライアント IDは、google.com(グーグルのキャッシュドメイン)にファーストパーティクッキーとして格納されます。
- プロキシ/キャッシュ: プロキシまたはキャッシュからAMPページアクセスした場合
- 表示されるページは、cdn.ampproject.orgのドメイン上です。
- クライアント IDは、cdn.ampproject.orgに格納されます。
- AMPページに直接訪問: サイトのドメイン上のAMPページに直接アクセスした場合
- 表示されるページは、サイトのドメイン上です。
- クライアントIDは、クッキー(_ga)の中に格納されます。このIDは通常のフォーーマットでもAMPフォーマットでも再使用されます。(同一ドメイン上の通常ページとAMPページは、同じクライアントIDを使用するため)
- ユーザーが最初に通常ページではなくAMPを訪問した場合は、AMPフォーマットのクライアントIDとなります。
- 通常ページ(非AMPページ): サイトのドメイン上の通常ページにアクセスした場合
- 表示されるページは、サイトのドメインからになります。(通常のアクセス)
- クライアントIDは、クッキー(_ga)の中に格納されます。このIDは通常のフォーーマットでもAMPフォーマットでも再使用されます。(3と同じです。)
- ユーザーが最初に通常ページを訪問した場合は、通常(これまでどおりの)クライアントIDフォーマットとなります。
同一ユーザーに複数のクライアントIDが付与されるシナリオ
上記のアクセス形態によって、考慮すべきことは以下の通りです。
一人のユーザーに複数のクライアントIDが付与される
上で紹介したアクセス形態で、3と4はクライアントIDを共有していますが、1から3はクライアントIDがそれぞれ異なります。例えば、同じユーザーが同じサイトのコンテントに対して、検索経由でAMPページにアクセス、プロキシ/キャッシュ上のAMPページにアクセス、そして、サイトのAMPページ、通常ページ、または両方にアクセスした場合、Google アナリティクスでは3人のユーザーとして計上(カウント)されます。
ドメイン単位でクライアントIDは管理される
ユーザーが同じサイトのコンテントに様々な形でアクセスした場合のクライアントIDの取り扱いは、アクセスするドメインのローカルストレージにIDが格納されており、他のドメインのアクセスとIDは別で取り扱われます。(共有することはできません。)
同じサイトドメイン上の通常ページとAMPページの場合は、クライアントIDは共有して、ユーザーを識別しています。一人のユーザーを二人の異なるユーザーとしては取り扱いません。これは、2017年5月に行われたアナリティクスのAMPと通常ページのトラッキング統合によるものです。
アクセスの仕方によるクライアントIDの相違が生む実際のアクセスと指標データの乖離
アクセスする仕方によって、それぞれ別途にクライアントIDを取り扱っている場合、ユーザーが検索経由でAMPページ訪問からサイトの通常ページを訪問した場合、異なるユーザーとして取り扱われます。このことは、アナリティクスの他の指標へも影響を与えます。
アナリティクスの指標に与える影響の具体例
説明だけだとあまり具体的な影響に対するイメージが掴みづらいと思うので、例を以下に紹介します。
例: あるユーザーが検索を行い、サイトのAMPページを訪問し1分間滞在後、リンクからオリジナルサイトのページを訪問しました。ユーザーはそのページを1分読んだ後、別のページを見ました。別のページでも1分間滞在して、その後離脱しました。
上記の例のユーザーの動向は、一人のユーザーが最初にGoogleのキャッシュ上のAMPページを訪問後、サイトに移動し、通常ページを2つ閲覧して、サイトから離れた事例となります。各ページには、1分滞在していたと仮定します。
この例でのアナリティクスの指標は次のように記録され、指標としては以下のように取り扱われます。
ユーザー数: 2
セッション数: 2
セッションあたりのページビュー数: 1.5
セッションあたりの滞在時間: 0:30 (30秒)
仮に同じドメイン上であった場合は、指標は以下のようになります。
ユーザー数: 1
セッション数: 1
セッションあたりのページビュー数: 3
セッションあたりの滞在時間: 2:00 (2分)
アナリティクスのヘルプページに、上記事例と同様のAMPのセッション ベースの指標の中で説明があります。
指標算出方法
ユーザーは本来は一人ですが、Googleのドメイン上のAMPからサイトのページに移った場合、ユーザー数は2となります。同様にセッション数も2です。ページビュー数は3のため、セッションあたりのページビュー数は1.5になります。
Googleのキャッシュ上でのAMPページのビュー数は1のため、直帰セッションとなります。直帰の場合は、セッション時間は0分として取り扱われます。離脱時のページの滞在時間も0分となるため、実際には3分滞在していても、アナリティクスに記録される滞在時間は1分のみです。2つのセッションで滞在時間が1分のため、セッションあたりの滞在時間は30秒です。
同じドメイン上の場合、ユーザー数は1、セッション数は1となります。セッションあたりのページビュー数も実際と同じ3です。滞在時間は、離脱したページを除く訪問ページの滞在時間の合計、2分となります。セッションは1つのため、セッションあたりの滞在時間は2分です。
ここでは一人のユーザーのみで例を紹介しました。多くのユーザーが複数のドメイン(GoogleのAMPキャッシュのドメインとサイトのドメイン)を訪問すると、実際のユーザーの動向とアナリティクスに記録される指標データの乖離が非常に大きくなります。
これが今までのAMPページと通常ページのトラッキングを共有できないために発生するAMPページと通常ページのアナリティクスのトラッキングの問題でした。この問題に対処するために新たに登場したのがAMP クライアントID APIです。
クライアントIDの共有
今回発表されたAMP クライアントID APIを利用すると、AMPページと通常ページ(非AMPページ)を同一のクライアントIDで共有、使用することが可能になります。導入すると、Google アナリティクスはGoogleの検索、直接のAMPと通常ページの訪問など、上で紹介した様々なアクセスでのクライアントIDを1つで取り扱うようになります。
クライアントIDは以下のように取り扱われます。
- 新しいユーザーがGoogle 検索でAMPページを訪問した時、AMP クライアント ID が使われ始めます。このユーザーが、続いて本サイトの通常ページを訪問しても、同じクライアントID サービスから同じクライアントIDが引き渡され使用されます。
- AMPと通常ページの両方を訪問したことがあるユーザーが、AMPまたは通常ページを再訪した時、AMP クライアントIDがそのユーザー用として継続して使われます。
- AMPページを訪問したことがないユーザーが、通常ページを再訪した場合は、それまでどおりのanalytics.jpが生成したクライアントIDが引き続き使用されます。
AMPページと通常ページで共有されるクライアントIDは、AMPフォーマットとなるようです。
AMP Client ID API の導入設定方法
以下の記事に当該APIの導入についての手順と留意事項を紹介しています。
コメントを残す(承認後表示されます)