{"id":124426,"date":"2025-03-10T15:29:44","date_gmt":"2025-03-10T15:29:44","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/google-analytics-client-id-in-amp-pages\/"},"modified":"2025-03-10T15:29:44","modified_gmt":"2025-03-10T15:29:44","slug":"google-analytics-client-id-in-amp-pages","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=124426","title":{"rendered":"Google Analytics Client ID In AMP Pages"},"content":{"rendered":"


\n<\/p>\n

\n

This article is a collaboration between Simo and Dan Wilkerson<\/a>. Dan\u2019s one of the smartest analytics developers out there, and he\u2019s already contributed a great #GTMTips guest post<\/a>. It\u2019s great to have him back here sharing his insight on working with Accelerated Mobile Pages<\/a> (AMP).<\/p>\n

So, we\u2019re back on AMP! Simo wrote a long, sprawling AMP for Google Tag Manager guide<\/a> a while ago, and Dan has also contributed to the space with his guide for AMP and Google Analytics<\/a>. Both of these guides touched upon a subject that might be one of the reasons to stay away from AMP for now: Client ID matching across AMP, your regular website, and any caches or CDNs that serve the AMP version.<\/p>\n

\n

<\/p>\n

\"AMP<\/p>\n

<\/a><\/p>\n<\/div>\n

Not only does AMP have its own, unique syntax for the Client ID, it also stores it in different ways. For example, in the AMP Cache<\/a> (and thus via Google search, too), it\u2019s stored in localStorage<\/code>. If someone visits your site directly and accesses AMP pages, the Client ID is stored in the AMP_ECID_GOOGLE<\/code> cookie. And then if someone visits a regular page on your site, the Client ID can be found in the _ga<\/code> cookie.<\/p>\n

In this article, Dan and Simo tackle this issue by showing how to serve the Client ID consistently<\/em> from the _ga<\/code> cookie written on your website\u2019s actual domain. This way, AMP pages will use the same Client ID that regular Google Analytics uses, and you will be able to identify customer journeys that may pass through both your regular site as well as your AMP content.<\/p>\n

The examples are provided in NodeJS and PHP (WordPress), but the methodology is universal and quite simple to do with any web server software.<\/p>\n


\n X<\/span><\/p>\n

\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n

\n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n

<\/span><\/p>\n

Overview<\/h2>\n

To recap, Google Analytics<\/a> stores a unique identifier for every user who visits your site within a first-party cookie<\/a>. This value, in GA parlance, is called the Client ID<\/strong>, and the name of the cookie is _ga<\/code><\/a>. Here\u2019s what the entire cookie string looks like, with the actual Client ID bolded.<\/p>\n

GA1.2.1789536866.1471440764<\/strong><\/p>\n

The GA1<\/strong> value denotes this is version 1 of the _ga<\/code> cookie. The 2<\/strong> denotes the number of dot-separated components in the URL the cookie is stored at. For example, if GA were instructed to store the cookie at shop.example.com<\/strong>, the number would be 3, instead.<\/p>\n

Because AMP pages can be cached and served on many different domains, users who might have had a single Client ID could wind up being split into several users instead.<\/p>\n

\n

<\/p>\n

\"AMP<\/p>\n

<\/a><\/p>\n<\/div>\n

This appears to be at least part of the reason behind why Google Analytics officially recommends using a separate GA Property for AMP data<\/a>.<\/p>\n

However, there\u2019s a way to use only<\/em> the _ga<\/code> cookie for all sources that serve your web content. To do this, we\u2019ll need to customize our amp-analytics<\/code> component.<\/p>\n

Custom AMP configuration<\/h4>\n

amp-analytics<\/code> is the component that AMP uses for tracking user interactions. If you\u2019d like to learn more about all the features it supports, check out the AMP for GTM guide in this blog<\/a>; it should have all the information you need.<\/p>\n

For our purposes, let\u2019s focus on the config<\/code> attribute. It\u2019s an optional attribute that we can use to tell AMP: \u201cHey, we\u2019ve got some additional configurations that we need to you fetch from this location\u201d<\/em>. This attribute should be set to a URL where additional analytics configurations should be retrieved from. In other words, you need to specify an HTTP request endpoint which returns a valid, AMP-compliant JSON<\/a> configuration file.<\/p>\n

\n
amp-analytics config<\/span>=\"\/\/example.com\/analytics.config.json\"<\/span>>amp-analytics<\/span>><\/code><\/pre>\n<\/div>\n
Once the browser has loaded the AMP page, and the page is visible in the browser window, AMP will fetch this external configuration file and use it to supplement any configurations that might already be established on the page. Unlike other resources in your content, your amp-analytics<\/code> config will always point to your server and the result isn\u2019t automatically cached. When the request to your server comes in, it will include all of the cookies set on the user\u2019s browser on your domain.<\/p>\n
NOTE!<\/strong> If, and when, your content is served through the Google AMP Cache, any external configuration must be downloaded from an HTTPS source<\/strong>. Thus if your web server is behind HTTP, you\u2019ll need to either only serve your custom configuration when visitors are on your domain OR use just the default configuration template instead. Or, you know, switch to HTTPS as soon as possible.<\/p>\n
Grabbing the _ga<\/code> cookie<\/h4>\n
When the request for the custom AMP config is received by your web server, you can check the cookies in the HTTP request to see if a _ga<\/code> cookie is already set for the user on the website domain. This would be the case if the user has visited your content before (and hasn\u2019t flushed cookies). If the cookie is found, you can use a specific HTTP header (see below) in the response to pass this cookie to the domain where the request originated from, e.g. Google\u2019s AMP cache.<\/p>\n
If the cookie is not<\/em> found, you can generate a new _ga<\/code> cookie, following the same pattern analytics.js<\/strong> uses – a random unsigned 32-bit integer coupled with a timestamp rounded to the nearest second, like this:<\/p>\n
1789536866.1471440764<\/strong><\/p>\n
You can then leverage the Set-Cookie<\/code><\/a> header in the HTTP Response, and instruct the browser to store the new Client ID in a _ga<\/code> cookie, making sure to set the domain, path, and expiration date to match the domain the request originated from (e.g. cdn.ampproject.org<\/code>), just like analytics.js does. You\u2019ll need to add the same GA1.X.<\/strong> prefix that GA uses, too. Furthermore, you\u2019ll need to do this on every single<\/em> request, so that the lifetime of the _ga<\/code> cookie continues to be extended on each page load. The Set-Cookie<\/code> should end up looking something like this:<\/p>\n
Set-Cookie:<\/code> _ga=GA1.1.18347199128.1478727498; Domain=example.com; Path=\/; Expires=Sat, 10 Nov 2018 21:06:48 GMT;<\/p>\n
Finally, you can return the Client ID in the JSON response as a custom AMP variable for use with our AMP requests:<\/p>\n
\n
{\n  \"vars\"<\/span>: {\n    \"clientId\"<\/span>: \"18347199128.1478727498\"<\/span>\n  }\n}<\/code><\/pre>\n<\/div>\n
Checklist for setting up the request handler<\/h4>\n
Of course, it\u2019s not quite that simple. In addition to transposing our Client ID and setting it as a cookie, we need to ensure that we\u2019ve dotted a few i\u2019s. Here\u2019s a handy checklist of the configuration steps that need to be taken to ensure everything works in the wild.<\/p>\n