Posts

Over the last couple of posts I’ve mainly been doing proof-of-concept (POC) tests with Google Tag Manager. The great thing about a POC is that you don’t really need to have any viable results or insight-driving technological innovations. The point is to showcase some feature of the platform on which the experiment was conducted.

In this post, I’ll take a care-free step into the world of POCs again. My goal is to do a simple split test in order to identify which variant of a landing page (or key element thereof) produces the most conversions.

Let’s say you want to set up a rudimentary email alert system in your Google Tag Manager implementation. Say, for example, you want to receive an email every time an uncaught error occurs on your website. It’s not a very good use case, since a large website can spawn hundreds of uncaught exceptions in a short period of time, but let’s just pretend for now.

If you know your JavaScript, you’ll know that you can’t send mail using client-side code. That’s a browser security thing, and I completely understand it. However, a vast majority of websites are created using a CMS which might provide some mail function or hook for you to use. And even if you don’t have a cooperative web server (or there’s no way you can persuade your developers to help), you could use any one of the online email APIs that are out there.

In this post, I’ll walk you through a tutorial on how to create a Google Tag Manager extension. This extension will be a new listener, whose sole job is to listen for changes in the HTML and CSS markup on the page.

The reason I’m teaching you how to create a DOM listener is simple. Ever so often I come across people asking for help, but they are unable to touch on-page code. Usually the problem is magnified with form handlers, since the developers might have installed some custom jQuery form manager, for instance, which simply refuses to cooperate with GTM’s form listeners. That is why you might want to fire a GTM event when a certain message pops up on the screen, for example.

If you know your Google Tag Manager, you know that GTM pushes three data layer events into the queue when any page with the container snippet is rendered. Each of these three events signals a specific stage in the page load process. Here are the events (be sure to read my guide on GTM rules to understand further what these events do):

• gtm.js - This is pushed into the data layer as soon as GTM is initialized and the container is loaded. This is also the default event for all rules without an explicit event macro rule as a condition. Basically, if you want something to happen at the earliest possible moment, you need to have {{event}} equals gtm.js as the rule

  Read More…

There is a new, updated version of this article for the new version of Google Tag Manager. I strongly suggest you read that as well!

I really enjoy the ad hoc Q&A sessions my blog posts have inspired. I haven’t said this enough, but I am really, REALLY grateful to people who take their time to comment on my posts, even if it’s just say a quick “Hi!”. The main reason I enjoy getting blog comments is because they often turn into blog posts. Seriously, if you’re a blogger suffering from writer’s block, take a look at your comments. There’s a wealth of content ideas right there.

(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 wouldn’t let a complete stranger come to your house and paint your walls without permission, would you? So why copy-paste some code that you have no idea what it does? Because Google told you to?

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.