Google Tag Manager

Getting cross-domain tracking right in Google Analytics is difficult. Even if you use Google Tag Manager. There are many known issues when cross-domain tracking iframes, for example.

Google Tag Manager implements the cross-domain tracking plugin quite handily via the Universal Analytics tag template, and often the easiest way to track links and form submits is to use the Auto-Link Domains option, as described in this great series of posts on cross-domain tracking by Bounteous.

However, sometimes you want more precision in decorating the URLs. Perhaps you only want to decorate one specific link rather than all links that share the same hostname. Or perhaps you only want to decorate forms when they are submitted by your actual visitors rather than internal users.

One of the more difficult concepts in Google Tag Manager is the data model. In essence, the data model is what Google Tag Manager uses to populate the Data Layer variable. You might be tempted to think that it’s the same thing as the dataLayer array, but it’s not.

The data model is a representation of the keys and values you push into dataLayer. Whenever you push any key into dataLayer, GTM grabs this key and updates the corresponding key in its data model with the new value, or in the case of objects and arrays merges the old and the new value together.

It’s time for a very simple #GTMTips article (I know, I always write that these are simple tips, but then they escalate into complex behemoths). Today, we’ll cover a nifty trick you can use with the Element Visibility trigger in Google Tag Manager. This tip was inspired by a question from Eugen Potlog in the Google Tag Manager Facebook group.

The use case is that you have an Element Visibility trigger firing for a number of elements all sharing the same CSS selector. In the image below, I want the visibility trigger to fire when any <h2> header element becomes visibile on the screen. However, I also want to know which one of all those headers caused the trigger to fire. In other words, I want the position of the header; If it’s the 5th header from the top, I want to get the number 5 to use in my tags. If it’s the first header, I want it to return 1.

Tag sequencing was introdced to Google Tag Manager in late 2015. Its main purpose was to facilitate the sequential firing of tags that have dependencies with each other. Due to the asynchronous nature of third-party libraries like Google Tag Manager, it’s difficult to establish an order of completion with tags that compete for their chance to fire.

Tag sequencing changed this, as it allows you to establish setup and cleanup tags - the former firing before the main tag, and the latter after.

One of the great ways to leverage Google Tag Manager in your web analytics tracking is to make use of all the possible custom events that the browser has to offer. One such event is beforeunload. It’s dispatched in the browser when the user is about to unload the page. This means, typically, that the user is about to leave the page after clicking a link, or they are about to exit the browser by either closing the tab or the entire window.

A Content Security Policy (CSP) is something you’ll configure your web server with to add an additional layer of protection, especially from harmful scripts loaded from third-party vendors. Once you have a CSP in place, all resources loaded and executed by the web page need to pass the CSP directives. For Google Tag Manager, this is very relevant. If you have a CSP in place, you will need to modify it so that Google Tag Manager functions properly.

Here we are, reunited with customTask. This time, we’ll put this wonderful mechanism to work for a very, very good cause. One of the lesser known “features” of Google Analytics is that when the payload size (the request body that is actually sent to Google Analytics with each request) goes past a certain limit, specifically 8192 bytes, the hit is aborted without warning. This can come as a surprise, because there’s no indication anywhere in Google Analytics that you are missing hits because of this.

After writing yet another customTask article on how to respect client-side opt-out using Google Analytics and Google Tag Manager, the analytics.js core library was enhanced with a new field that makes it all a lot easier to do. The field, allowAdFeatures, lets you either allow or block the request to DoubleClick that is initiated when Advertising Features have been enabled.

In this very short article, I’ll quickly show you what the field does and why it’s useful.

One of my favorite (and most popular) articles in my blog is Improve Data Collection With Four Custom Dimensions. In that article, I show how you can improve the quality and granularity of your Google Analytics data set with just four Custom Dimensions. The reason I chose the four dimensions (Hit Timestamp, Session ID, Client ID, and User ID) is because I firmly believe that they should be in Google Analytics’ standard set of dimensions, but for some inexplicable reason they aren’t.

I’ve spent a considerable amount of time talking and writing about how to improve the granularity of your Google Analytics data, especially when using Google Tag Manager. I’ve also gone on and on and on (and on) about customTask, which makes adding metadata to the Google Analytics hits dispatched from your website a breeze.

In this article, I’ll introduce a simple way to add yet another level of detail to your GA hits, using customTask as the method of choice. The piece of data we’ll add is the hit type of the hit (e.g. pageview, event, and timing) which, for some ludicrous reason, is not a default dimension available in Google Analytics reports.