Google Tag Manager is strictly a tag delivery system, and it’s very careful not to collect any analytics data on its own. This is most likely a deliberate choice, because if GTM was to start collecting data, it would introduce additional barriers to adoption.
Nevertheless, being a tool that consolidates the design, development, deployment, and testing of all the marketing and analytics pixels, code snippets, and utilities running on a website or a mobile app, lacking the necessary features for auditing and monitoring has always seemed like an oversight.
One of my pet peeves about Google Analytics has to do with nomenclature. For example, a User isn’t really a user but a browser instance, and Direct traffic isn’t necessarily “direct” at all, but rather just traffic that has no discernible source. But being so invested in content analytics, my biggest gripe has to do with Pageviews.
A Pageview in Google Analytics is collected when a hit with the hit type pageview is received successfully by the Google Analytics endpoint.
Ah, Safari’s Intelligent Tracking Prevention - the gift that keeps on giving. Having almost milked this cow for all it’s worth, I was sure there would be little need to revisit the topic. Maybe, I thought, it would be better to just sit back and watch the world burn.
But then Mr. Charles Farina, a good friend and so amicable he’s practically Canadian, tempted me into testing out a quick proof-of-concept web service that would give us back our first party cookies.
After the recent release of Custom Templates for Google Tag Manager, my mind has been occupied by very little else. However, I have a nagging feeling that due to how involved the feature set is, there’s still a lot of demystifying that needs to take place before templates are fully embraced by the GTM user base.
In this article, I want to show you a concrete example of template creation.
One of Google Tag Manager’s oldest and most reliable features is that it freezes the state of Data Layer variables to the moment when the trigger event occurred. Thus, any tags firing on this trigger (and any variables resolved on this trigger event) will always have access to the same value of each Data Layer variable.
However, there are situations where this is not a good thing. One is tag sequencing, and the other is a scenario where you want to run some custom code that should access the latest value of the Data Layer variable at a moment in time after the tag has already fired.
Every now and then I’m fortunate enough to be able to publish guest posts by illustrious people in the analytics and digital marketing industries. This time, I get to work with an old colleague of mine who’s a veritable wizard when it comes to building solutions that make our daily work in the digital industry so much smoother.
Erik Grönroos works as an analyst in MarkkinointiAkatemia, a Finnish digital customer acquisition agency.
Some four years ago, Google Tag Manager released a new trigger predicate named matches CSS selector. Slowly but surely, it has evolved into one of the most useful little features in GTM.
Even though I’ve written about CSS selectors many times before, I wanted to compile all the relevant information into a single guide. For an external resource, I recommend bookmarking the w3schools.com CSS Selector Reference. But for your day-to-day use of CSS selectors in GTM, this guide will hopefully prove useful.
Trigger Group is the newest trigger type you can add to a tag in Google Tag Manager. It allows you to establish dependencies between multiple triggers, not firing the tag until every trigger in the group has fired at least once.
This establishes an interesting new paradigm in Google Tag Manager, because until now it wasn’t possible to create triggers that relied on earlier values of a given key (event in this case).