How to Use the AMP Client ID API for Consistent User Tracking in Google Analytics

by Peter Adamson

Recently a number of our partners have begun porting their content to Accelerated Mobile Pages (AMP) –  a Google-led open source project that facilitates super-fast-loading mobile content.

AMP enforces strict limitations on developers and content to ensure code is optimized for speed. Part of this optimization is the requirement to use lighter versions of Google Analytics and Google Tag Manager for AMP. These tools are quite restricted too in terms of features and configuration options and, in many ways, are incompatible with the standard website JS versions.

Just for clarity, below is an example of AMP. If you’ve Googled something on a mobile device in the last year or so, AMP content is marked by a little lighting bolt in a circle icon. 

While it is possible to self-host AMP content on your domain, the most common use case is people viewing AMP content directly within Google search results.

The AMP content that appears in Google search is a copy of your self-hosted AMP that is automatically uploaded to the Google AMP Cache, which is part of the overall AMP project and provides fast and reliable hosting. To further complicate things, the AMP Cache version displayed in Google search is actually within an <IFRAME>, referred to as the ‘Google AMP Viewer’, and this version too has a different URL that the AMP Cache version might link to directly.

The Problems with Google Analytics and AMP

The AMP project has created a rather unusual flow for users compared to the well established path of users searching for things and then clicking into your site. The experience feels relatively intuitive on the surface, but underneath the path from search to AMP to website crosses a couple 3rd and 1st party hosts and technologies.

For Google Analytics, this creates the following problems:

  • AMP GA does not currently offer many of the configuration options of Universal Analytics: ecommerce, cross-domain tracking, and content groups for example.
  • AMP GA stores client ID differently from Universal Analytics for website, and Google-hosted AMP will not share that client ID with your self-hosted content, or even with AMP Cache-hosted content not viewed in a Google search viewer <IFRAME>. Meaning, out-of-the-box, GA will not recognize the same user crossing from AMP in a Google search who then clicks through to your site.
  • AMP GA data can cause havoc with user and session metrics if AMP and website data is combined in the same property. However, if AMP is tracked to a separate property, it also introduces a gap in GA data between search and site. Search gets credit in the AMP property, and the same user appears as a referral from the AMP Cache in website data in this case.

Tracking Option 1: Default AMP-GA Tracking

To help illustrate the complications AMP introduces to Google Analytics data, here is a chart showing some typical paths users might follow across AMP and website pages, and how GA will processes this normally:

Tracking Option 2: Setting Up Your Own Client ID API

Some time ago, two titans of GA and GTM communities Simo Ahava and Dan Wilkerson provided a possible solution, allowing a single client ID to be shared by all AMP and website content thus solving the biggest issue for Google Analytics and AMP.

This approach does require a significant amount of server-side development work to set up an API on your site to serve the site’s client ID to Google-hosted AMP. This remains the most complete solution available, and the results in GA data would appear like this:

This remains the best and most complete solution for tracking AMP and website content in the same property. In GA all AMP content effectively becomes an extension of the website.

Google’s AMP Client ID API

In September, Google released the AMP Client ID API in an effort to address the concerns many have voiced about the problems with AMP tracking in GA.

Functionally this API works very much like creating your own client ID API, with a few important differences; instead of pulling a client ID from your site, your site pulls a client ID from the AMP platform. Curiously, the AMP Client ID API only covers the case of a user viewing AMP content in a Google search viewer, and then navigating to your hosted website and AMP content, and does not work on content hosted on the AMP Cache not presented in a Google search.

This illustrates what the AMP Client ID API does for data processing in GA:

Again, compared to setting up your own API, this option incomplete. But it has the benefit of being easy to implement, and does cover the most common use case: AMP content being viewed in a Google search and leading to your self-hosted content.

As long as you avoid linking to Cache-hosted AMP, this solution actually covers all potential paths presented to your users.

Setting Up the AMP Client ID API

When implementing the AMP Client ID API through GTM, there are a few important things to keep in mind:

  • There is a usage policy associated with the AMP Client ID API. Before it can be implemented, the site’s privacy policy will likely need to be revised, and compliance with Google’s EU user consent policy is a requirement for sites with any European visitors.
  • The site’s GA will pull a client ID from AMP, and not the other way around.
    In practice. The AMP GA client ID will supercede the site’s GA client ID the first time a user visits Google-hosted AMP from search results after this configuration is setup. A returning site visitor will become a new user at this time, as their client ID in historic GA data is replaced by the AMP client ID, and only after will AMP-GA and website-GA recognize the same user across both. This makes the user count somewhat less reliable.
  • There are a number of places/tools this feature needs to be implemented/configured in order to work: in the AMP-HTML, field configurations of the GA tag and referral exclusion in the GA admin.
  • Your content should only link to AMP content on your domain, and not the AMP Cache, as this API is not available to GA. 
  • Testing/verifying this is a little cumbersome, and GTM preview mode for AMP does not have the nice debugging tools you get with GTM for web.

Modify the AMP HTML

In the AMP content HTML, you need to add this tag into the <head>. I’ve tested this with both GA directly in the AMP HTML, and GA through AMP-GTM. It will work with either deployment method.

<meta name=amp-google-client-id-api content=googleanalytics“>

Modify the GA Tag on Your Site

The next part is to add the ‘useAmpClientId’=true field to Universal Analytics tagging on your website.

For direct deploy snippets, this means modifying the ‘create’ line for the snippet:

<!– Google Analytics –>
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
})(window,document,script’,‘’,‘ga);ga(create’, ‘UA-XXXXX-Y’, ‘auto, {‘useAmpClientId’: true});
ga(send’, ‘pageview);
<!– End Google Analytics –>

If you are using GTM, you’ll want to add this additional field on all Universal Analytics tags:

You will probably want to add to the referral exclusion list of the GA property where you intend to track AMP and website data so sessions do not get reset when users cross from Google search to your website.

After configuring everything in all the places you need to, you’re done. Visitors viewing your AMP content in Google searches and on your domain will appear as the same visitor.

Verifying this all works correctly is where things get a little tedious. Remember that in order for the AMP Client ID API to kick-in, the user path must begin with AMP content in a Google search.

If you use structured data in your AMP-HTML, as you should, you can use the Structured Data Testing Tool to simulate how your AMP content will behave when served up in a Google search.

View your AMP content via this test search, and check the client ID sent to GA in the network calls:

Now click through to your website, and again check that the GA client ID is the same as before:

So that’s it, you are now the same user in the GA data. If you then go to the Cache-hosted version of this same AMP content, you may notice that the Client will be different:

Again, as long as you do not include AMP Cache-hosted content in the flow, this should suit most needs to connect everything together in Google Analytics.

Peter Adamson

Implementation Specialist, and Google Tag Manager Practice Lead

Peter is an Implementation Specialist and Practice Lead for Google Tag Manager. He partners with our enterprise client development stakeholders to help guide them through and assure the quality of their most sophisticated analytics infrastructure requirements.

See more posts from Peter