(Last updated June 2014) This post is an attempt at a whole new level of interaction. These words will transcend the barriers of time and space, bridging together the physical world and its digital counterpart. You see, in an undisclosed number of hours after the publishing of this blog post, I will be talking at the MeasureCamp unconference on this very subject. Or, I hope I will. The whole unconference thing is somewhat confusing, and it involves lighting-fast reflexes and street smarts for slot selection; traits which I sadly lack.
First of all, I’m sorry for the wacky title. Sometimes I just want to amuse myself. Nevertheless, this post is about the Google Tag Manager container snippet. There’s nothing secretive about it, but I’m betting many people have no clue what the snippet really does. That’s the revelatory part.
If you’ve never wondered what the snippet does, then shame on you! Remember, you own your page template. It’s yours. Any code that you write there is your responsibility.
You’ve probably come across a number of guides or posts talking about why it’s necessary to block so-called internal traffic from your web analytics reports. The reasons are pretty solid: internal traffic does not emulate normal visitor behavior, it rarely contributes to conversions (skewing up your conversion rate), it inflates page views, and it wreaks havoc on your granular, page-by-page data.
Internal traffic is vaguely described as “your employees”, “people really close to your brand”, “your marketing department”, “your web editors”, and so on.
Because I was bored, I did a quick test to sort out the firing order of competing GTM listeners. If you’ve done your homework (i.e. read my article on GTM listeners), you’ll remember that GTM listeners are set up on the document node of the document object model (DOM). I wanted to test what the firing order is if you have multiple competing listeners on the same page.
I tested with the following listeners (make sure you read up on auto-event tracking if you are completely baffled at this point):
There’s a new listener in town! It’s a few days now since the Google Tag Manager team unleashed the History Listener, and the time has come for me to tell you what this baby can do.
The History Listener is designed to be used on websites where content is loaded dynamically. Typically, these websites make heavy use of AJAX (Asynchronous JavaScript and XML), which is designed for loading content in the background and serving it dynamically without having to reload the page.
There is a new version of this guide for GTM V2 here.
(Last updated April 2014) I see Google Tag Manager’s operational model as an analogy of Montesquieu’s three-branched government theory (don’t leave just yet, I’m getting somewhere with this). We have the legislative power of tags (what should be done), the judiciary power of macros (explore the context and circumstance of each tag), and the executive power of rules (make the tag happen).
Here are a few quotes I found on the web regarding tag management and IT departments:
Relief of IT department bottlenecks – once the Tag Manager is deployed, new tags can be implemented directly by Marketing with no IT department involvement. This is a huge benefit for large websites, where IT is oftentimes a bottleneck. Original text here
IT Issues - when you use a TMS like 'Google Tag Manager' you are bypassing the IT department.