How To Implement Google Analytics Using AMP


AMP, or the Accelerated Mobile Pages Project, is an open-source project pioneered by Google aimed at increasing the speed of the mobile web. In essence, publishers trade configurability and custom “look-ma-no-hands” features for a predefined set of components. In return, they get super-snappy page load times, generous 3rd-party caching, and prominent placement in mobile SERPs.

AMP does support the addition of web analytics, albeit in a stripped down fashion. In order to get started, you’ll need to include the web analytics component in your AMP pages. Add the following snippet in the head of your AMP template, before the snippet for the AMP JS library.


The analytics component offers a wealth of configuration options. These options make it easy to extend AMP to handle your specific tracking needs. Because the project is continuing to evolve, we’ll skip going into the specifics and instead point you to the Google Analytics and AMP documentation for the component. Ultimately, your configuration snippet should look something like this:

One additional feature to be aware of is the ability to specify a configuration file. This file is not cached by AMP, and can be used to supply user-, session-, or hit-specific information. You can even deliver on-the-fly triggers and hit customizations using this file; they will overrule existing configurations in the HTML of the AMP page. To use a configuration file, you must set the config attribute on the AMP component.

For a deep dive into configuration files, check out the official documentation.

Best Practices

A few recommendations I would like to share for those of you setting out to integrate your Google Analytics with your AMP HTML pages.

Property Selection

The current recommendation from Google is to use a separate property ID for measuring AMP-specific activity. This recommendation stems from the fact that AMP analytics will measure things differently than analytics.js. This is especially true of Client IDs, which AMP will endeavor to create on your behalf and store in a totally different pattern than the typical tracking code.

Using the same property as you use for your normal, everyday reporting can cause some problematic data to appear when running reports. For now, we would recommend creating a new, AMP-specific property for your reporting needs. For roll-up reporting, use a Premium Rollup Property or BigQuery and join together user data based on the Client ID (more on this in a second). If you’re not a Google Analytics 360 (née Premium) user, you’ll have to decide if complete data is more important than tracking users across your AMP pages, or you’ll need to create a manual rollup property and duplicate your hits.

Client IDs

As mentioned in the above, by default, AMP will take it upon itself to generate a Client ID, even if one exists in an _ga cookie on the host the content is being served from (this can be overridden, though). However, we’d like to use the same Client ID for a visitor for our AMP-generated hits and our normal website. This is desirable because a user may visit a non-AMP page and already be assigned a Client ID in Google Analytics. An easy way to accomplish this is to reflect any stored Client ID into the configuration JSON file that we set on the config attribute of the analytics component. This can be retrieved from the Cookie header of the request the browser generates for that configuration file.

Update: If you’d like to generate your own client IDs in the same format as analytics.js, here’s a helpful snippet I wrote that will do just that. The amp-analytics vendor configuration for Google Analytics now supports overriding CIDs, too, by setting the clientId var. The snippet above has been updated to reflect this.

As always, we recommend storing the Client ID in a Custom Dimension for easier mixing and matching with other data sets. This approach ensures consistent user identification, even if the user is visiting a cached version of our AMP page on a 3rd party domain (like in the Google search results).

Additional Dimensions

AMP will try and detect most of the dimensions we expect with our Google Analytics hits, including things like our Page Title and Page URL. For best results, you may want to hardcode the Page Title and desired reporting URL in your configuration file. You may also want to set additional pieces of information with your AMP hit, like Content Groupings or Custom Dimensions. Spend some time examining the data you currently send for your content on your desktop site and try and emulate as many of those values as possible.

Dan Wilkerson is a Software Engineer at LunaMetrics. He is passionate about web technology, measurement, and analysis. Dan is the winner of the 1999 Forge Road Elementary School Science Fair for his groundbreaking report on how magnets work. (ICP, take note.) Dan has worked at LunaMetrics in social media, as our marketing manager, and now in our analytics department.

  • Anton Shulke

    What is LunaMetrics? I mean any good speaker to do a webinar on the metrics itself?

  • suzukik

    Malte Ubl from Google says this approach won’t work.

  • John Peterson

    Thanks for covering AMP in the details, but the sentence about the hitcounters are those for one related to standalone ones? Cuz I have used gostats and the analytics it offers is enterprise class

  • FHR News

    The key thing people will need to remember when it comes to the Client ID is that Google is building systems to cache the HTML for these pages, so whatever you put in this field is likely to be used from locations all over the world and can’t be relied on for accuracy.

    This will be a big surprise for some people when they roll it out.

    • Dan Wilkerson

      Hm, I’m not sure about that – the docs make it seem like the $CLIENT_ID value will be user/domain scoped. I’d have to test it to find out for sure.

      • FHR News

        Ah! I completely missed that page. This will help make it all work, and still be cacheable.

        This stuff has changed quite a lot since October. Hopefully it won’t change too much before it goes live in February.

  • Stephen M. Harris

    There is now a amp-analytics component, which makes this considerably simpler:

  • Tom Conte

    Is there any benefit to creating a new property specifically for AMP content? Right now, we currently use the same property ID to track both AMP and non-AMP performance.

    • Dan Wilkerson

      Hi Tom,

      Hm, sort of. You could wind up with two different Client IDs in your account for the same device, if they access both the full- and AMP-versions of your site. There is a way around this, of course…


  • luisfrancojustia

    Is there a way to have multiple tracking accounts? Something like

    “vars”: {
    “account”: “UA-XXXXX-Y”,
    “account”: “UA-XXXXX-Z”

Contact Us.


24 S. 18th Street, Suite 100,
Pittsburgh, PA 15203

Follow Us



We'll get back to you
in ONE business day.