This blog post will dive deeper into what we’ve been doing with the newly released option to use Google Tag Manager on AMP Pages. Also we’ll be sharing parts of The Next Web’s container that we’ve been using.
We’ve been working with Google for a while now to implement Google Tag Manager’s abilities in AMP. It was officially released only yesterday, so we felt like it was time to share some of the insights we gathered from working with it. Because for now, AMP containers will be different from the actual Web containers that you can create, and come with their own sets of pros and cons.
Google Tag Manager and AMP?
Let’s start off with the biggest downside to using Google Tag Manager to manage your setup. The fact that you have to create a specific container for AMP is unfortunate. But also logical as AMP is a completely different set of rules compared to a normal page. That’s why they can’t just run all the tracking you’re used to as well. Further down we’ll go into some of the differences between the Web and AMP version that you want to keep in mind.
Instead of having to deal with the basic Google Analytics integration options by doing it natively, a Tag Manager obviously allows you to add more custom (tracking) code to your site. By using GTM to do this, you’ll be exposed to some new/additional features:
- Scroll tracking: Come on, obviously this was already possible in the Web version by using a custom HTML script like, this one. Based on that you could push data layer events to make sure you could set up custom triggers again who responded on the value (10%, 70%, end of page).
- Page visibility: You want to know what percentage of the page the user is really looking at. This will allow you to do that.
What are the differences with the Web versions?
- AMP Variables v.s. dataLayer: The biggest difference in using custom variables can be immediately found in the use of AMP variables instead of dataLayer attributes. As the dataLayer doesn’t exist within AMP, you can use something similar to it which is called AMP variables. It’s a JSON array with information about the page that you can enter, as well as a variable to use in your tracking.
- Custom HTML: We’ll forget about it for now. As AMP is very strict, the AMP container doesn’t allow for custom HTML yet. Which is unfortunate as it could provide you with great extra functionalities on Web. With the development of AMP itself, I’m assuming this might become available again at some point.
- Click Tracking: With the Web version it could be hard to find the right classes or other IDs to use for click tracking. But the good thing with AMP is that the protocol is so strict that the different elements in the code have their own name. Want to track sharing buttons? The CSS selector for that is just: ‘amp-share’.
Tips & Tricks:
- Use as many built-in variables as possible: To make sure that you can still have access to all your custom back-end variables to use for custom dimensions or custom metrics, you want to make sure that your port them to your AMP set-up as well. Variables work about the same as the values you would usually push to your data layer, with the exception that you can’t trigger events based on them.
- Dealing with Customer IDs: This sucks quite a bit for now, to be honest. As it’s possible to get any information for now from cookies, no cookie variables or custom HTML are available to take care of this. So for now you would be stuck with a back-end solution to take care of this and send this information in the built-in variables to use them within your Google Analytics tags.
- In-Content Link tracking: Very simple, this luckily still works in GTM for AMP. Just define a click trigger with the CSS selector for the clicks in your content. GTM will again pick this up like you’re used to from their Web version and can help you send the events to Google Analytics. It would be very nice to have the same click variables from the Web version in AMP though, for things like sending the click URL to Google Analytics. This is at the moment not possible.
How to get started? The Next Webs AMP Container!
So previously we released our container for Web in Google Tag Manager. But with the newly released AMP, we thought it would be cool to also share the AMP version that we’ve been using. We’ve removed the very specific TNW information from the container to make sure it’s useful for your AMP pages as well.
We’ll keep on supporting our AMP pages with the best available analytics information to make sure that the AMP container we’re using matches our Web version as closely as possible. There’s still a long way to go to accomplish that, but we’re hopeful we can make it happen. What we’re struggling with is custom HTML; It’s something we highly value and often use in our Web container but as it’s missing on AMP it doesn’t allow us to track full referral paths, use A/B Testing, set user IDs, etc.
What we’re hoping for that will be build:
- Scroll Tracking: Please, lovely Google Tag Manager team, please do us a favor and port the scroll functionality feature that we can use in triggers to the Web version.
- Pixels: We know you’re working on this with the actual AMP team, but being able to follow our users across different social networks is important, for both ecommerce and publishers.
- JS Error tracking: This seems almost impossible. If there is a JS error on the page, AMP also shouldn’t be able to load completely properly. So error tracking through the preconfigured variables in their Web version seems far away.
If you missed previous posts in this series, don’t forget to check them out: #1: Heat maps , #2: Deep dive on A/B testing and #3: Learnings from our A/B tests, #4: From Marketing Manager to Recruiter, #5: Running ScreamingFrog in the Cloud, #6 What tools do we use?, #7: We track everything!, #8: Google Tag Manager , #9: A/B Testing with Google Tag Manager, #10: Google Search Console, #11: 500 Million Search Results and #12: How are you engaging with this page?, #13: Supporting Schema.org, #14: Calculated Metrics in Google Analytics, #15 How TNW uses Google Optimize 360