Loading Jaywing website
26 October 2016 / Opinion

Google Tag Manager supports AMP

Jason Sanderson / Senior Analytics Consultant

This week, Google announced that the Tag Manager AMP integration is now publicly available. It’s a great addition to the Tag Manager arsenal that enables us to bring some of the dynamic tracking abilities we use daily into an AMP-based environment.

Why is this important?

Firstly, you might need to refresh your understanding on what AMP (Accelerated Mobile Pages) is all about, which you can do with this post.

Accelerated Mobile Pages definitely have their strengths for users, but this lightweight approach to serving content has also come with limitations.

The strict AMP JavaScript library doesn’t allow for any author-written JavaScript to exist in the page itself with all third-party scripts resigned to iframes. Immediately, this puts tag management solutions out of the window, forcing any tracking adjustments to be hard-coded into those pages, often entering a development queue with more immediately high-priority work taking precedence.

There will always be certain limitations on what tracking solutions can be deployed to an AMP supported page. Though now, there is AMP support from Google Tag Manager, deployment and modifications to website tracking has certainly been made far more efficient and ultimately easier.

What’s changed?

Quite a lot! Looking at your already existing Google Tag Manager containers, you’ll see no changes. Architecturally, AMP is vastly different to an average website, so a completely separate container is required to adhere to the specific requirements and reduced functionality.

The changes start to appear when it comes to creating a new container where you will now have the ability to select an AMP-specific variation.

This is where the changes begin to kick in:

Container: AMP GTM containers run as part of the AMP Analytics package. It’s a case of including the Analytics script within the head element of the page and invoking your GTM container settings at the beginning of the body element.

Tags: As expected, there have been a lot of changes to the tags actually available. Mostly from those we’d expect – long gone are those custom HTML tags and others such as Mouseflow’s tracking.

However, support remains for GA, AdWords and DoubleClick; with image pixel tracking a relatively straightforward tracking method to support. A substantial list of supported tags can be found here.

Arguably, the bigger change for tags is the advanced support which has been removed. The nature of AMP means that it is not possible to dictate sequencing/firing priorities or even add ecommerce data to your Analytics tags.

Triggers: The most notable feature here is the inclusion of scroll and visibility trigger types. With these two new triggers, you’re able to fire tags when a user either scrolls to a certain percentage down or across a page or when a user scrolls a specific element into view.

Variables: There have been a lot of alterations to both the in-built and user defined variables compared to a standard website container; see the full in-built list here.

Though, two new sets of variables worthy of a mention are:

  1. Device and Browser: Eight new variables that return data such as screen and scroll dimensions, the client’s time zone and the client’s language.
  2. Timings: A few variables looking at load times for the current content and time user spent engaging with the content.

Of course, whilst these are new features there is no reason in a ‘full’ container you couldn’t achieve the same functionality with a custom JavaScript function – but these custom script functions are not allowed with AMP.

The ‘dataLayer’ itself is not used with AMP, instead the container uses “AMP Variables” which is part of a JSON array that can defined in similar ways to which the dataLayer could be. A technical orientated explanation can be found on the AMP GitHub including details on utilisation of AMP variables.

Why do I need to know?

Having a tag management solution in place for an additional website scenario is definitely a positive. Though it really depends on the adoption of the AMP specification and whether the use of HTTP/2 on an, arguably, more flexible setup will supersede the benefits from AMP outright.

At the least, it should be one less thing to be concerned about when making the decision to create an AMP supported website – knowing the tools will be at your marketing team’s disposal.