The Page Visibility API for web browsers is pretty sweet. It lets you poll, using some new properties of the document object, whether or not the current page is visible to the user. Visibility is hidden if the page is not open in the current browser tab instance, or if the browser window has been minimized.
In this post, I’ll give an example of how features of the Page Visibility API could be used with Google Tag Manager.
Rules are the cornerstone of Google Tag Manager. As with any critical element in a system, they are easy to get wrong. This tip is just a refresher on how GTM firing and blocking rules work.
Tip 3: Google Tag Manager rules in a nutshell So, let’s go through these points one-by-one.
Every tag requires a firing rule to work - this is a given. Without a firing rule, your tag will not be written in the document object, and it will never be executed.
Here’s a simple way to check what was the source of the visitor’s arrival to the current page. It’s done by utilizing the {{referrer}} macro, which comes out-of-the-box in any GTM setup.
Tip 2: Use {{referrer}} to see where the visitor came from You might want to also explore the Component Types and create new macros for {{referrer path}} and {{referrer host name}} for example:
By default, you see, the {{referrer}} macro returns the entire URL of the previous page.
I wanted to try something new (and, naturally, I’m running out of content ideas), so let me introduce the hashtag #gtmtips. I hope others contribute as well, but I will be adding a new tip as often as possible. I’ve got maybe 20 tips in store right now, and I’m writing new ones all the time. So without further ado, here’s…
Tip 1: Save GATC In A Constant String Macro This is an easy one, and everyone should already be doing this in one way or another.
(Update 19 November 2018: See this article for a more elegant solution.)
If you know your JavaScript, you know that all variables, functions, objects, resources, and data in the document get rewritten with every page load. In other words, every single page refresh builds the page from scratch, and the state of the document before the page refresh is left drifting in the ocean of oblivion.
Google Tag Manager’s dataLayer is also one such entity.
There’s a much easier, native-to-GTM way to do this now: the Matches CSS Selector.
Behind this tragically boring title is a simple solution to many problems with Google Tag Manager’s auto-event tracking. The common denominator to these problems is poor website markup. Selectors are used sparingly, and element hierarchy is messy. This disregard for proper node relationships means you have to resort to Data Layer Variable Macros which look like
(UPDATE 1 Oct 2014 Due to a change in how macros work in Debug Mode, the {{generic event handler}} macro no longer works when testing in Debug Mode. That means that you’ll have to test your custom listener in a live container (I know, ouch!). If you want to test in Debug Mode, you’ll have to skip using the {{generic event handler}} as a macro, and instead copy the inner function into the Custom HTML Tag, give the function a name, and use that as the callback in addEventListener or attachEvent.