Google Tag Manager offers us some nice built-in triggers so that we can automatically listen for specific user interactions on the website, reacting to them however we wish, though typically it would be to fire a tag. The tricky thing especially with the click triggers and form submission tracking is that the page has a nasty habit of redirecting you to the link or form target page before letting you see the respective data in Google Tag Manager’s excellent preview mode.
One of the coolest features of Google Analytics and, as a consequence, Google Tag Manager is customTask. It’s a method you can use to add and execute code as the hit to Google Analytics is being generated. I’ve written A LOT about customTask, and much of the feedback I’ve received has been around the question of how to combine all these different tricks into one customTask script. The problem is, you see, that a tag or hit can only have one customTask script attached to it, so the code within must combine all the different tricks I’ve been writing about over the past months.
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 LunaMetrics.
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.
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.
- OLDER POSTS
- page 1 of 13