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 former LunaMetrician and contributor to our blog.

  • 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

  • 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.

      • 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:

  • 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”

    • Dan Wilkerson

      Duplicate the requests/vars for each account ID; you can’t have the same key twice, though.

  • Hi Dan,

    I just implemented amp analytics via google tag manager on my WordPress blog.
    I created a GTM AMP container and I managed to put the “_ga” cookie value in an AMP variable by echo-ing the $_COOKIE[‘_ga’] into the “vars” array.

    See code:

    I could successfully pass it over as a custom dimension in my pageview hit, but I was hoping that I could use it also as a field to override the AMP client ID, which doesn’t seem to work.

    See GTM Config =>

    And the generated hit =>

    Is there any way to override the client id like this via GTM or am I loosing time? I read the post by Simo Ahava regarding the json proxy but got stuck in implementing it. Any pointer?

    Cheers and thanks for the good posts!

    • Dan Wilkerson

      Hi Andrea,

      First of all, I have some bad news – echoing data into the HTML of the page is a non-starter, unfortunately. This is because the HTML will be cached by 3rd parties (Google, mainly), which will result in all users being sent the same client ID. You have to use the remote config file, as I detailed a little in my post under Client ID Reflection. I was guilty of the same mistake until suzukik chimed in below (this was pretty early in the AMP game, in my defense).

      Per your second question, currently Fields to Set don’t seem to work. You’ll need to manually replace it in the JSON GTM returns as part of your proxy. More on that soon!


      • Hi Dan, auch! I didn’t think about it, good point..
        In that case I’ll wait for your next article, would be great if you could share your solution for the json proxy. I am half way through, but kind of stuck… 😉

  • Kemen Paulos Plaza

    Hi, one year has passed and this has not a good solution, so looking for the workaround i found this interesting article, nice Dan! thanks you for this. I’ve implemented this but in my case, this always return a new _ga value (this over PHP wordpress ). For any reason the browser is not able to retrieve the cookie on the page hosted on the google side (the cached ones).

    This is the compacted part of what i’m doing

    public function retrieveGA()
    echo $_COOKIE[“_ga”];
    echo newCookie();


    For me makes sense to be unreachable, because your’re not loading the page on the API sop the cookie value is not there, the cookie is stored on the local computer, and on the call you dont load the page. I’m not sure if i explained well.

    As a good news, this works on your own domain calling to the api hosted on your own domain. Any ideas?


    • Dan Wilkerson

      Hi Kemen,

      This post I co-authored with Simo Ahava might offer greater detail and clear up any questions you’ve got:


      • Kemen Paulos Plaza

        Thanks you for reply, yes this is very interesting topic, thanks both to write about it. I already saw that and works as inspiration. but in my case, this kind of implementation can violate some browser privacy policy and due that sometimes the cookie is not readed(even if this exist), returning always a new client id, it was difficult to figure out because the data seems ok, but in a general terms this is was a very good solution excepting from that cases. but this only happens with some browser and technologies (because the json document is partial loaded) and combined with the CDN. Now we are migrating this “proxy” to another server/tech to see if the accuracy is improved. Again, thanks you!

  • Ned

    Hi Dan,
    I’m a bit lost with this, where I should put the code get it work? i need set the crossdomain client id

Contact Us.

Follow Us



We'll get back to you
in ONE business day.
Our Locations
THE FOUNDRY [map] LunaMetrics

24 S. 18th Street
Suite 100

Pittsburgh, PA 15203


4115 N. Ravenswood
Suite 101
Chicago, IL 60613


2100 Manchester Rd.
Building C, Suite 1750
Wheaton, IL 60187