Simo Ahava's blog

A while ago, the Google Tag Manager team published one of my favorite feature releases in the history of GTM: Workspaces. I was so thrilled by this release that I went ahead and published a guide on how to implement and leverage this new feature.

Workspaces is a very comprehensive feature in Google Tag Manager. This is because it changed the entire underlying data model. We no longer work directly with a single container draft. Instead, our work is done in a cordoned section of the container, protected from changes made to other workspaces until such a time that we choose to sync the latest container version to our workspace, or vice versa.

A while ago, the Google Tag Manager team published one of my favorite feature releases in the history of GTM: Workspaces. I was so thrilled by this release that I went ahead and published a guide on how to implement and leverage this new feature.

Workspaces is a very comprehensive feature in Google Tag Manager. This is because it changed the entire underlying data model. We no longer work directly with a single container draft. Instead, our work is done in a cordoned section of the container, protected from changes made to other workspaces until such a time that we choose to sync the latest container version to our workspace, or vice versa.

READ THIS (26 Aug 2019)!! Unfortunately, the update I made in 2016 contained code that was incomplete and broken. I nevert noticed this until it was pointed out to me almost three years later. At this point, I don’t have a working backup of the solution, so unless some internet archive / cache service manages to surface the code, this article is basically lost.

UPDATE 20 December 2016: I made some fixes to the solution - be sure to grab the latest code snippet from below!

This article is a collaboration between Simo and Dan Wilkerson. Dan’s one of the smartest analytics developers out there, and he’s already contributed a great #GTMTips guest post. It’s great to have him back here sharing his insight on working with Accelerated Mobile Pages (AMP).

So, we’re back on AMP! Simo wrote a long, sprawling AMP for Google Tag Manager guide a while ago, and Dan has also contributed to the space with his guide for AMP and Google Analytics. Both of these guides touched upon a subject that might be one of the reasons to stay away from AMP for now: Client ID matching across AMP, your regular website, and any caches or CDNs that serve the AMP version.

Google Tag Manager recently published support for Accelerated Mobile Pages (AMP). This support comes in the form of a new Container type in Google Tag Manager.

When you create an AMP container in GTM, you are actually setting up an external configuration for AMP, which leverages AMP’s own analytics module. As befits Google Tag Manager, creating the configuration is done in the familiar Google Tag Manager user interface, and you have (almost) all the tools of regular Google Tag Manager at your disposal.

Single-page sites (or single-page apps) typically have just one page load. When navigating the site, subsequent content is either uncovered from the DOM, where it’s been in a hidden state, or loaded from the server using HTTP requests that do not invoke a new page refresh. This behavior, however, has some implications for Google Analytics tracking, especially when configured via Google Tag Manager.

The crux of the problem is this: When you create a Google Analytics tracker, the URL of the page (without a possible #hash) from when the tracker was created is sent as the value of the Document Location field with every hit that uses this tracker. This is used for a number of things, most significantly attributing the session to the campaign specified by URL parameters such as gclid (AdWords) or utm_source, utm_medium.

Google Analytics’ Site Speed reports are pretty darn great. They report automatically on various milestones in the process the browser undertakes when rendering content. These reports leverage the Navigation Timing API of the web browser, and they are (typically) collected on the first Page View hit of a page.

And this is all fine. As I said, it’s a great feature of Google Analytics, and lends itself handily to spotting issues in the quite complex client-server negotiation that goes on when your web browser requests content from the web server.

What better way to celebrate the 50th #GTMTips article than, well, a really useful Google Tag Manager tip?! This tip is so useful and simple; it encapsulates everything that I had in mind when starting this series. The tip is about restricting scope of Custom HTML Tags. This is an important concept, because it’s possible that you’re stuffing your page’s global JavaScript namespace with all sorts of junk, and thus inadvertently causing conflicts.

This is a guest post by Stephen Harris from Seer Interactive . He was kind enough to share his awesome solution in this blog, so I’m very grateful indeed for his contribution.

If Google Tag Manager is loaded as the primary instrument for tracking on a webpage (as it should be), then all webpage tracking could and should be configurable via GTM. But we don’t always control the circumstances, and it’s not uncommon to face hardcoded Google Analytics tracking outside of GTM.

Google Tag Manager can be quite the hierarchical mess. You have accounts which comprise containers. Containers are split into container versions, and you use workspaces to create new versions. Phew! Trying to keep tabs on all the activity within these layers can be quite the chore.

In this #GTMTips article, I’ll do a quick walkthrough of (almost) all the places where you can review changes made in your Google Tag Manager account and container.

I’ve already written extensively about JavaScript in web analytics implementation. Suffice to say, understanding at least the basics is absolutely necessary to survive in the technical medium of the web browser.

This article expands on a conference talk I gave at MeasureCamp IX, London a short while ago. I’ve always been quite single-minded about the importance of JavaScript in web analytics development, and it was a pleasure for me to get some of that off my chest. So I want to go over the ten concepts introduced in my conference talk with a little more detail, especially in the context of Google Tag Manager.