by Doug


Internet Marketing

Google Tag Manager Auto Event Tracking – Deeper dive (update 9 Oct)


Google Tag Manager (GTM) Auto Event Tracking was announced recently. At first glance the new functionality is very exciting. I’ve read a few articles on the subject already, here are two really good intros to bring you up to speed in case you’ve been in a cave:

Both articles are good but we need to explore deeper to understand how the new functionality can/should be used (sorry Justin, it’s not quite bye bye JavaScript yet!), what to be aware of when using the tool and (hopefully) where the tool will go in the future.

The basic idea is that you can use the GTM front end to track clicks on your pages. In a utopian world where markup is perfect and developers are proper experts we would all happily enjoy sunshine and happiness without a care. Based on a wide variety of experiences we’ve found the utopian existence to be sadly mythical. The reality is a bit more ‘thorny’. You need to be careful where you tread.


Assuming you’ve read the articles above and you’ve got some background knowledge you may well be wondering:

  • Which listener should I use and when?
  • How do I target a specific DOM element (or elements)?
  • How does the GTM auto event tracking behaviour cater for links with javascript?
  • How does the GTM auto event tracking behaviour cater for forms with javascript?
  • I don’t know what a DOM is and I don’t want to start poking around elements using Firebug – is this for me?

We can say without a doubt that you no longer have to rely on a JavaScript framework such as jQuery to make click tracking easier. That semi-dependency has gone which is a good step towards a simpler world.


How do you determine which click on a link or button is going to fire the event? You need to know the tag and hopefully a class or Id on the tag. You can use Firebug or Chrome Dev tools to inspect elements but unless you’re at least semi fluent in HTML and CSS this seemingly simple task can be quite overwhelming.

I offer a visual solution in the form of Trackify 2.0 Trackify is a chunk of javascript that you install in your browser as a bookmarklet. Take the line below and add it as a bookmark:


Having installed Trackify (prototypical software may not be fit for production – no guarantees!), head to your web page of interest and hit the Trackify bookmarklet. I’m going to use trackifytest.html as an example page to show how easy life can be whilst also answering the other questions above and making you aware of potential gotchas.


So, You’ve set up the bookmarklet, you’ve hit my test page and you’ve concluded I’m no web designer – correct and well done:

Now click the Trackify bookmarklet and hover over the first link in Div 1 – see how the elements are highlighted? The DOM elements that Trackify is aware of are:

  • div
  • input
  • a
  • img
  • h1
  • h2
  • h3
  • h4
  • span
  • form

Lovely. Now we can highlight elements we want to track…don’t worry if you’re colours differ from mine – they’re chosen randomly…Anyway, now with the link you’re interested in highlighted, hit Ctrl&d:

See that the element details are displayed? Yes, this is the same info you can get from the dataLayer or from inspecting the element using an inspection tool. I maintain this is often too hard for many folks who can’t or don’t want to get into that level of detail. This is the level of sophistication that the GTM auto event tracker should offer to deliver the ‘anyone can use this to track clicks’ promise.

So, you can see the element (tag type), the classes and the ID. You can use these pieces of info to track clicks on one or more elements of a certain tag type or class.

You can also see the target (_blank to open a new tab in this case), the URL of the page to open and the ‘onclick’ behaviour if there is inline javascript in use (evil!).

The icing on the cake is the suggested GTM listener type – a Link Click Listener in this case and the rule to use in your event tag.

Hit the ‘X’ in the bottom left hand corner of the overlay and try another link. Try the ‘Link to With onclick’:

Ah, now Trackify has recognised a few more things – we have an external link (track these differently as ‘site exit events’) and we have some inline ‘onclick’ javascript.

Gotcha 1:

Testing this particular instance of inline javascript shows that the GTM fired event doesn’t fire until the alert box has been cleared. Bear this behaviour in mind when using inline javascript…

Gotcha 2:

There is worse yet to come. What if a link is constructed such that the behaviour of the link is dictated totally by javascript? WTF? Yes – this happens and it’s just not good for many reasons. It’s evil and it’s demonstrated by the ‘Link to With EVIL onclick’ link. Highlight and Ctrl+d to see Trackify alerting us to the horrors we are contending with:

  • gtm.elementUrl: “#”
    WARNING!This is an anchor link: Check onclick value
  • gtm.elementSrc: ” ”
  • onClick: “document.location=’’ ”

See how we are alerted to potential (actual!) nastiness here? The gotcha prevents the GTM event from firing. Not good.


The two forms on Divs 2 and 3 demonstrate a simple classic form and one that is ‘molested’ with JavaScript like the link above. The good news is that even though the form action is messed with using javascript via onsubmit, the form still posts and the tracking still fires – good!

So far so good…

Okay, I’ve given you a little help via the Trackify tool to help you find the technical details regarding the DOM elements you want to track.

We’ve seen that form tracking is pretty robust despite our attempts to disrupt the status quo using JavaScript.

We’ve seen that we can cause issues by being STUPID with javascript.

Be aware that poor markup will use javascript to do evil things and may ruin your whole day when you try to track clicks with events using GTM.

GTM Config hints

I suggest it is a sound idea to setup a listener of each type whether or not you’re going to use them immediately. Name your listeners sensibly so you can find them easily in the GTM UI:

Similarly, setup macros to extract DOM ID, name, class, action (for forms) and href attributes.

Gotcha 3

The DOM attributes are extracted using an auto-event variable macro type:

It would be really nice if these were extensible so more element meta data could be extracted – rel attributes for example.

Now, track your link clicks such that the event data contains meta data to tell you what sort of link was clicked:

  • External link – does the element href contain document.domain?
  • Internal link – does the element href contain document.domain?
  • Downloads – does the element href contain pdf (document download)?

Add rules to make sure other clicks don’t fire when link clicks fire:

Use the element ID attribute macro in the rule to fire events when tracking clicks on one thing on your page.

Use the element attribute (tag type) macro or the element class attribute macro in the rule to fire events when tracking clicks on multiple similar things on your page.

My final advice is to use the publish and preview in combination with GA Real Time analytics event tracking – see the events firing as you test your pages.

Yes, TEST! For the love of quality test!


Well, it’s good but it isn’t finished and nor did we expect it to be. This is a great step forward (along with the SLA details) for the product but it’s naive to think this is the end of the story or a final solution to fit all needs. Nope. Not by some way but you can now make even more huge strides forwards in your use of GA tracking through GTM.

Nice one Google….don’t stop now.

Update 9 Sept

You can access more meta data from the markup.


Try this in a console first.
Go to
Click on the first link to – the one with the meta data added.
Look at dataLayer;
Look at the last object in the dataLayer.
For me this looks like: dataLayer[4];
See all that juicy data?
You can access it like this: dataLayer[4][‘gtm.element’];
And then like this dataLayer[4][‘gtm.element’][‘rel’];
And so on until you find the treasure you need (don’t dig too far – the further you dig the more brittle it will become in the long run)
Now you need to translate this into a macro in GTM.

Specify the new macro Type as a Data Layer Variable. We’re accessing the dataLayer – not the Auth-Event Variable.
Use dataLayer v2!
Here’s my dataLayer Variable name:
See how that fits together?
Now go do your own.
You’re welcome.


Leave a comment

Your email address will not be published.

ConversionWorks is now Media.MonksVisit us at