Analytics

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. Basically, it should be a term which covers traffic that does not adequately represent trending visitor behavior on your site. Most often, this is “internal”, in that it is traffic by people who generate the content. It can also be your proof-readers (wives, husbands, best friends), beta testers (wives, husbands, best friends), outreach marketers (wives, husb… you get my drift).

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). Not one of these would work without the others, so checks and balances are in place as well.

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. If anything goes wrong, they can/will put all the blame on you.

Original text here

When push comes to shove, I’m a pretty lazy guy. I enjoy nothing more than just to stretch my legs on a couch, pick up my iPad, and read what’s going on in the world. I skip the news, since they’re just full of depressing stories. Instead, I head over to my favorite Google+ communities to see what’s new in the blogosphere.

This approach has led me to some pretty amazing individuals, whom I follow like a suckerfish. These people have written a bunch of great articles, which have helped countless people with their Google Tag Manager installations. Or they might be really active in the online communities which people turn to for advice.

Ever so often I come across a Google Tag Manager setup where GTM’s own auto-event listeners don’t perform the task they were supposed to. Listener problems seem to be a hot topic in Google+ and the Product Forums as well.

There may be many reasons why your listeners don’t work, but a very common trend is that you have conflicting JavaScript libraries or scripts running on your page.

Let’s explore how listeners work before tackling the problem. You see, when you attach an event listener to an element in your Document Object Model (the collection of all elements on your page), the listener waits for the element to produce the action it is listening for.

I’ve written a new Variable Guide for Google Tag Manager, which covers the new GTM UI. This guide is for the old UI.

You might be vaguely familiar with macros if you’ve ever used a computer. Basically, whenever you perform a complicated task with a simple gesture, or reuse complex code with a simple input mechanism, you’re using macros. Think keyboard shortcuts.

In Google Tag Manager, this is the essence of macros. You can do away with a lot of complexity by resorting to macros, especially if you ever find that you need the same piece of code or the same operation over and over again.

Having just come hot of the press with my latest article on GTM and Content Grouping which, to my delight, Bounteous had written an amazing tutorial on earlier, Brian Kuhn and the amazing Google Tag Manager development team came out with another incredible new feature: The Lookup Table Macro.

In software engineering, a lookup table is an array which takes away a layer of complexity in runtime computation, and replaces it with a simple value assignment based on array indexing. To put it simply, a lookup table looks through an array of source values, and assigns a value to the target depending on what the source value is. Well, maybe it’s easiest to show it in an image:

Content Grouping is a nice new feature from the good folks at Google Analytics. Basically, it allows you to group your content according to a logical structure. You can create up to five Content Groupings, and you can have as many Content Groups within these groupings as you like. The difference between a Content Grouping and Content Group is hierarchy. The second is a member of the first. Read Justin Cutroni’s post on Content Groupings to get you started.