With Intelligent Tracking Prevention, the Safari browser is on a crusade against cross-site tracking. One of the most obvious and long-standing ways to battle cross-site tracking has been to block third-party cookies in the web browser, and this is exactly what Safari does by default. However, Google Tag Manager's Preview mode relies on a third-party cookies, so that it can serve you the draft version of the container while serving the regular, live container to your site visitors.
When Custom Templates were released in Google Tag Manager, many of us active in the GTM communities started doing two things: 1) creating our own custom templates, and 2) waiting patiently for Google to release a “gallery” or “library” for distributing these community contributions. While I have full faith in the latter happening some time in the future, I thought it would be fun to create something similar to a library, and then open-sourcing it for the community to help out with or to download locally for their own purposes.
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.
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. It's going to be much more ambitious than the simple walkthrough I explored in the main guide.
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.