Google AMP Project is a very hot topic in these days.

Today I’m going to show you how to implement Google Analytics (or “AMP Analytics”) in your website, and how to install it through Google Tag Manager.

Before we get started, here is a list of topics we will be discussing:

1. What is AMP

2. Setting up AMP on a WordPress site

3. Google Analytics for AMP websites

4. Implementing AMP Analytics through Google Tag Manager

Part #1: What is AMP?

A lot of content already published about this subject, and I’m not going to be reinventing the wheel here, but a short overview is in order to make sure everyone is on the same page:

AMP is an open-source project, spearheaded by Google. The initial goal of AMP was to shorten the load time of news sites viewed on mobile devices.

However, the project has grown and gained momentum. Consider, for example, that Google recently added AMP to its search results pages, which comes together nicely with the new prioritization of mobile sites, as announced by Google in April of 2015 (note that priority is not yet being given to AMP pages, at least not officially, but this will certainly happen soon).

The reason that Google initiated this project to begin with is due the growing trend of site traffic seeping from the desktop to mobile devices, however most site owners have not yet adapted their site to be properly mobile-friendly (and probably will never do that properly…).

So yes, “mobile friendly”, “adapted” and “responsive” websites are terms we are already tiring of hearing, but they don’t actually solve the most significant factor on mobile sites – i.e., loading times.

Speed critically affects user experience. For example, KISSmetrics’ study found that 40% of a site’s visitors will leave if the loading time is greater than 3 seconds. If that doesn’t scare you straight, consider another research finding that every second of delay when you website loaded, reduces your conversion rate by 3.5%.

It’s a lot!

In a funny Google video, they explained this issue in a rather amusing way by showing that the most problematic contributors to lag are the numerous advertising networks and analytics systems installed on the page.

So okay, AdBlocker can solve the problem on the user’s end – but then we’re looking at a serious loss of ROI for the big publishers. This appears to be one of the reasons that Google got involved, to find a solution that will address everyone’s interest.

There are Three Parts in an AMP Website

AMP is made up of three central elements:

1. AMP HTML – a list of custom tags and a whole lot of restrictions (and a few additions that enable rich content). So, for example, replacing the <img> tag with the <amp-img> tag enables the page to render the images only as the user sees it on his screen – instead of loading together with all the page’s elements, which would harm the user experience.

2. AMP JS – only specific tags can be used in AMP pages, one of the main goals of AMP JS being to turn anything that contains Javascript into an asynchronous element. Loading Javascript in parallel to the page’s other elements – instead of upfront, avoids additional load time, which again, would harm the user experience.

3. Google AMP Cache – Google’s proxy server saves the pages, and optimizes their display to the user, which of course includes faster loading times.

So, after our quick introduction, let’s go to the technical part:

Part #2: Setting up AMP on a WordPress Site

First you need to install this AMP Plugin by Automattic with the following link: https://wordpress.org/plugins/amp

[side note]

Since AMP creates a leaner version of your internet site, it is likely that you won’t like some of the design changes, and you may wish to play a little with the CSS. In order to do so, use a custom action addition to WordPress, as explained here.

[/end side note]

That’s pretty much it. From now on, the plugin will create an AMP version for every post or page you have on your site. In order to see it, simply add /amp/ after the post’s original URL (and if that doesn’t work, try additing /?amp=1).

Doesn’t this cause redundant content?

No, because the plugin adds a canonical tag to the AMP pages that leads to the original content.

How does Google know to index the AMP pages?

The plugin adds a special tag with rel=”amphtml” attribute, which leads to the AMP version of your page. So, when Google’s crawler indexes the original page, it will see that it also has an AMP version.

This is how this tag works: <link rel=”amphtml” href=”https://www.example.com/url/amp”>

Part #3: Google Analytics in AMP Sites

Before we get to talk about Tag Manager, let’s consider why do we need a different Google Analytics for our AMP site? Why can’t we just add them to our regular property?

That’s an excellent question, and the answer is simple:

The whole idea of AMP is to speed up mobile pages, but because Javascript can often significantly slow down its rendering time (particularly if it is loaded synchronously), the AMP technology doesn’t allow you to simply embed JS in your page. Instead, it requires you to use a special tag that has been pre-tested and approved by the AMP team.

The AMP team has created tags for the a number of leading analytics systems. You simply add in the desired vendor under the “type” attribute (which, as we already said, have been pre-tested and approved):

<amp-analytics type="XYZ"> ... </amp-analytics>

Amongst the leading systems already approved by AMP you can find Adobe, Segments, Chartbeat, Yandex and of course Google Analytics.

(Despite all of the above, you can still embed any JS through an iframe, but because we need the Google Analytics code to sit directly within the page, and not be loaded via an external iframe, this isn’t a solution).

Should I split them up into two properties, or measure it all under one property?

This is a good question, and it depends on the structure of your site. Google recommends opening a separate property.

As these are fundamentally two different kinds of sites, I would recommend including your AMP pages under the regular property, as well as setting up an additional property specifically for AMP, but since AMP uses a different format for tracking the clientId – you must read Simo Ahava‘s post first.

We need to suppose that the user will also be viewing pages that aren’t AMP alongside the AMP pages – so that if you track them across these different pages with separate properties, you may get a cutoff session and lose a lot of information about your visitor.

Part #4: Installing AMP Analytics using Google Tag Manager

Here comes the interesting part.

First of all, we need to open a separate container for our AMP website.

Yes, that’s right – you can’t just use your regular container. As I explained above, AMP was created to speed your site up, so you can’t use the regular container since it uses a non-adjusted JavaScript.

Besides which, AMP’s HTML is also customized, so you also can’t use the Triggers available in the standard container. So, we’ll open a new container, select AMP, and get the code to embed in our site:

Before we move on, make sure that you are using a child-theme, as we are going to change the template’s function.php file. Otherwise, if and when you decide to upgrade the template, this file will be replaced and you will find yourself without any tracking at all…

Another possibility is to do this using a plugin (like this one), but because the combination AMP <> Google Tag Manager is fresh off the press, there is not yet any plugin that enables you to do this without getting your hands a little dirty with code (at the time of this writing).

In any case, I always like to have things hard coded, as this allows me to control what’s going on, and because I believe that the more plugins you have, the heavier and lower is your website.

After all, AMP was designed to streamline your site’s rendering, and therefore, we don’t want to go about slowing it down with a lot of redundant plugins…

So, after you’ve created your child template, take the first part of the code and embed it as follows in your function.php file:

After that, take the second part of the code and embed it as follows:

Please note! If you’re not highly familiar with code, it is better to give the embedding instructions to an experienced developer. While this is not a complicated setup, the smallest mistake can cause your site to fall.

Please note #2: Don’t forget to change the number in GTM-XXXXXX according to your container id.

And… that’s it! Tag Manager is now embedded in your site. Now let’s see how to configure it.

Tag Manager for AMP website includes some really interesting triggers and variables that don’t come built-in with the regular Tag Manager, but before we discuss them, let’s create our first tag – Google Analytics.

And that’s it. There aren’t any special tricks here, and it works here exactly as we’ve done it up until now with the regular Tag Manager

Let’s move on to the more interesting topics:

Variables in Tag Manager for AMP

As you surely already know, the Tag Manager’s variables are actually “functions” that return certain values.

The Page URL variable returns the URL of the page, Data Layer Variable returns values from the data layer, and so on.

As in the regular Tag Manager, we can find built-in variables such as Page URL, Page Hostname, Event, Click Classes, Click ID, Click URL, Form Classes, Form ID, etc. (click here for the full list).

As well, we can also create additional variables manually:

 

In Google Tag Manager for AMP sites, however, we can find interesting and even downright cool values, such as user’s time zone, screen width/height, number of pixels the user scrolled, Total Engaged Time (the number of seconds the user was active on the page), page’s loading time and more (link to the full list).

All of these variables are available for use automatically, and all that’s left to do is to put them into tags, as we will see shortly.

Triggers in Tag Manager For AMP

Google Tag Manager for websites gives us triggers that can track page views, clicks on a certain element, sending a form and custom events that we can send to the data layer (there are of course others, but these are the main ones).

In the AMP container, we will find slightly different triggers, and it is interesting to see that Google also included triggers for scrolling and page visibility:

Sending an Event with Tag Manager For AMP

We saw the Page View trigger in action with the Analytics tag. Let’s demonstrate tracking the user’s scrolling actions, and send this event to Google Analytics when the user reaches 25%, 50% and 100% of the page.

All you need to do is to create a new tag called Universal Analytics, enter the number of the property (UA-XXXXXXX-Y format, or by using the Constant variable that we created earlier which contains this number), and enter the desired values under Category/Action/Label/Value.

In my case, I entered a constant value “Scroll” under Category, and under Action I put in a variable called {{Scroll Top}}, which returns the number of pixels the user has scrolled down from the top of the page. Under Label, I put in {{Scroll Height}} that will return the height of the page in pixels (both are built-in variables):

After this, I’ll create the trigger that is supposed to send this event, and under Vertical percentages I will enter the percentage points at which I wish to send the event. It is possible to enter a list of more than one area, by using commas:

Usually, I debug my events using Google Analytics Debugger, but it (as yet) does not support events that are sent by AMP pages.

As a bit of a shortcut, I will simply use the Network section in Chrome, and there I will be able to see all of the requests that the browser sends to the Google Analytics servers.

Of course, it is also possible to see the events sent to Analytics via the real-time report, but I just think it’s redundant to keep switching between the windows…

Tracking Clicks in AMP Pages Using Google Tag Manager

Tracking scrolling actions is nice, but let’s see how I track users that have left my AMP pages after clicking on Leave a Comment. Supposedly, they have left the site, but I want to know whether they have actually left my site, or just gone to my regular mobile site, which is being measured under a different property than that of the AMP property, which starts another session.

This is also exceedingly simple. All I need to do is to create a new Event tag for Universal Analytics, but this time I will use a different built-in variable, called {{Total Engaged Time}}. This will give me the number of seconds that the user was active on the page, giving me an indication of how much time it took the user to read the article and then leave a comment.

Afterwards, I will be able to compare this to other actions made by other visitors, and extract my insights about the ideal amount of time the user should be on my page in order to leave a comment.

The trigger for this tag should be Click event, then CSS Selector and then I will add “.amp-wp-comments-link a”.

Please note that in this case, we are talking about an a element which is inside a div element (which holds the class), and therefore I entered both elements, dividing between them using a comma. You can never know in advance which element the tag manager will decide to identify as the clicked element, and so it is always worthwhile to put in both the main element as well as any sub elements – just to be on the safe side.

Important: As the AMP completely changes the structure of your site, note that the selectors that we will want to use are completely different from the selectors that you are familiar with from your regular site.

Let’s debug this – we’ll click on the button and see whether the event was sent:

Indeed it has, it has been sent, but with a small bug. You may have noticed what appears under Event Label is the main domain, without the path, despite I used {{Page URL}} variable. I am working on this with Google to figure out why this happens, and will update this post once I have an answer.

Conclusion

Contrary to what you (might have) thought at the beginning, setting up Google Analytics via Tag Manager in AMP sites (and using Tag Manager in AMP sites generally) is much more simple than Tag Manager for regular web sites.

In light of the simplicity with which we can enable WordPress sites to support AMP, and in light of the fact that Google is pushing this so hard – it is very likely to become a standard in the near future. I think that every website manager and owner should make this change, and the quicker – the better.

And let’s not forget the improvement to user experience. This was the main reason that Google got into AMP, so no matter how you look at it, I believe it’s very worth your while to start planning this changeover today, and of course, to set up your tracking properly.