An alternative approach to GTM event tracking
27/07/2014 | Written by | Categories: Analytics Set-up

Google Tag Manager feels like it has been around forever and we are now at the stage where I (& many other consultants) will refuse to do a Google Analytics implementation without it (or an equivalent TMS).  But it is still very new, features are evolving and best practices are still being invented.  With that in mind, I wanted to share the approach we use here at L3 Analytics for tracking events in Google Analytics.

I have to say first that we don’t have the developer background or skill-set of many other GTM experts – Phil, Carmen, Doug & of course Simo to name just a few.  As a result, I feel our approach has evolved differently, although we may now use similar ideas.

We aim to create minimal if any custom code within Google Tag Manager.  Instead we insist on our clients creating a Data Layer (on page load and for all visitor interactions) and using that to populate all the GA tracking via GTM.  There are exceptions and I will cover all that another time along with the reasons for this approach. But I want to focus here on event tracking with the information triggered by pushes to the data layer, not via the auto event tracking features in GTM.

The Current Approach

The current approach appears to be to use a naming convention for the variables pushed to the data layer of event, eventAction, eventLabel & eventValue.  Examples below can be found from Phil’s Guide to GTM and from one of the many great blog posts from LunaMetrics.
Code sample via Phil Pearce
Code sample via Lunametrics


The benefit of this approach is that you then only need one set of macros and a single tag for all your event tracking in Google Tag Manager.  Life is easy, job is done and even better, no work is required within GTM for new event tracking – just use the same naming convention.
Event category macroEvent Action macroEvent tag in GTM








However I don’t like this approach, it doesn’t feel right.  What is the point of a tag management tool if it doesn’t do anything except transfer information through to the analytics tool?  You can get the same result by adjusting the code slightly and sending the data directly to GA.

Then what if you want to change anything?  You need to change the code on the website.  This is fine for GTM users with a developer background but not so much for me.  It means all the logic is defined within the website tracking and I want to get away from relying on developers to get business logic right.

Event Tracking in GTM, the L3 Analytics way

So I have taken a different approach.  I wanted to still have a minimal amount of work to add new event tracking but for all the logic to be defined within GTM.  All I wanted from the developers who created the code & the data layer was information about the visitor interaction that occurred.

My approach is to simply record in the data layer all the information about the visitor interaction that occurred.  Obviously the name of the interaction is required but after that, it depends on what the interaction was.  The name alone may tell me everything I need to know or there might be two, three or ten more items of information to be sent through as well.  Great – send them through, I can decide if I want to use them or not.  And how.  And where.

The format of the data layer push is

‘event’: ‘visitor interaction’,
‘interactionName’: ‘<name of visitor interaction>’,
‘<variableName1>’: ‘<variable value 1>’,
‘<variableNameN>’: ‘<variable value N>’

To see that in practice, here are examples of what the push to the data layer would look like for five different visitor interactions.


Click on homepage widget

‘event’: ‘visitor interaction’,
‘interactionName’: ‘homepage widget’,
‘hpWidgetType’: ‘<widget type>’,
‘hpWidgetName’: ‘<widget name>’

[/one_half] [one_half_last]

Apply a filter on a product list page

‘event’: ‘visitor interaction’,
‘interactionName’: ‘product page filter’,
‘filterType’: ‘<type of filter>’,
‘filterValue’: ‘<value of filter>’,
‘numFiltersApplied’: ‘<number of filters previously applied>’


Track completion of a form field

‘event’: ‘visitor interaction’,
‘interactionName’: ‘form field tracking’,
‘fieldFormName’: ‘<name of form>’,
‘fieldFieldName’: ‘<name of field completed>’

[/one_half] [one_half_last]

Submission of a form

‘event’: ‘visitor interaction’,
‘interactionName’: ‘form submission’,
‘submitFormName’: ‘<name of form>’



Scrolling to the bottom of a content page

‘event’: ‘visitor interaction’,
‘interactionName’: ‘content read scroll’

That is a few examples, you will see why in a minute.  First task though is to create a macro for each and every variable you are now recording.  This is more work than for the commonly used approach, I admit that.  Takes about 30 seconds per variable though so not much more work.
Homepage widget name macroInteraction name macro








Now comes the really clever part.  You use Macro Lookup Tables to define all your event tracking logic.  Easier to show you than to explain, look at the macros below defining the event category, action and label for my five examples.  The logic is based on the interaction name variable and the values used can be hard coded or use another item of information that was pushed to the data layer with that visitor interaction.

Event Category lookup table macro

Event action lookup table macro Event label lookup table macro

If there is no Event Label (or Event Value) for a particular visitor interaction, that visitor interaction is not included within the lookup table.

Now, guess what your event tracking tag looks like?  Is this at all familiar?  In case you hadn’t guessed, the rule will be {{event}} equals “visitor interaction”.

Event tag in GTM

So, besides an easy setup, let’s see what the other key benefit of this approach is.  Imagine you want to adjust the event tracking on form submissions so the event category field records “form submission” and the event action field records the name of the form (no event label field required).  With the normal approach, you either need to create a new tag just for this event or have the code changed.  With this approach, it takes less than a minute to adjust the necessary macro look up tables.

The analyst has control over all of the event tracking logic.  It still uses a minimal number of tags and rules, just with a lot more (very simple) macros and three or four lookup tables.  It is a very scalable solution and simple enough for non analysts to learn & be able to modify.  And beyond all of that, it feels like a very elegant solution, using a TMS as it is meant to be used…

What do you think?

L3 Analytics is recruiting.  Please contact us if you want to be part of a team coming up with these sorts of ideas.

10 responses to “An alternative approach to GTM event tracking”

  1. Al Wightman says:

    Hi Peter,

    Great post. I’m a big fan of look up tables.

    I have applied similar techniques in my own GTM setups but where I would differ to your approach is not to use an interaction name but instead have a unique event name for each type of event you want to track. Just as you have used the interaction name to drive the look up tables you could use the unique event names to do the same.

    The benefit of having unique event names is that it is very easy to then fire non-GA/non-UA tags that are event driven rather than page load driven.



    • Peter O'Neill says:

      Thanks Al, I use the same event name for all events so I can set a single rule to work with a single event tag – how do you do this? If I wanted to use this information for other tools, can use the Interaction Name field like you suggest to define the rule so only fires for a single interaction type. But having something in common across all visitor interactions makes life easier with a single tag/rule for events.

      • Al Wightman says:

        I would apply separate rules to the same tag. (Reading some of the forums some analysts are averse to this but I am quite happy to do this if they are discrete events).

        I’m pretty certain you can’t use a variable, on its own as a rule, that has been pushed with the dataLayer.push method. You always need an event to be part of the rule to track an event after page load. That’s why I prefer the unique naming for events.



        • Peter O'Neill says:

          Hi, pretty sure I could use a rule of event equals “visitor interaction” as my generic rule and a rule of event = “visitor interaction” AND interaction name = “form submission” for a more specific tag. Also believe I could just use interaction name = “form submission” and would work fine (although only doing the similar thing here on page load).

  2. Al Wightman says:

    Hi Peter,

    You certainly could use both event and interaction name together but if you are going to do that you might as well just have a unique event name. I suppose it depends on whether you are doing a lot of different tags or just mainly do GA tags through GTM.

    Another reason why I love the different event names is just from a transparency point of view when handing over GTM setups or taking them over.

    As with most things GTM/UA there’s more than one way to skin a cat 🙂



    • Peter O'Neill says:

      Always multiple ways to do anything and it comes down to a personal preference. Which was my point at the start, this approach suits me without a dev background whereas someone else may want to skip a data layer & create custom scripts for all event tracking.

  3. Mickael ROBIN says:

    Thanks for sharing this interesting approach.

    Considering the fact that many events get enriched by custom dimensions (this event will use those custom dimensions and that event those other dimensions…), would you still recommend this approach (as opposed to regular “1tag per event” approach).
    How would you adapt your method?

    • Peter O'Neill says:

      Hi, this approach takes that into account. I simply add the custom dimensions (via macros) into the event tag into the relevant slots. They fire off only if in the data layer from page load or when visitor interaction occurs. The beauty of this approach is if you capture 6 pieces of information regarding one visitor interaction, can use two as event action & event label and the other four go into custom dimensions.

  4. Mickael ROBIN says:

    What you’re saying is that you create one lookup-table macro per custom dimension, so that an event will be enriched by a custom dimension only when he gets a non-empty value from the dimension’s lookup-table macro ?

    Sounds good, thanks 🙂

    • Peter O'Neill says:

      Actually, for custom dimensions, you can only use one slot per dimension. So video length may go into custom dimension index 12 and number of products displayed after filter applied may be recorded in index 13. Both are pieces of information sent with the relevant visitor interaction push to the data layer. Both recorded as macros from the data layer. Then in your single event tag, both are listed in their relevant dimension index. But with the video actions events, dimension 13 is automatically not included (as not available). And the same for dimension 12 when people apply a new product filter.

      Make sense? It just works…

Leave a Reply

Your email address will not be published. Required fields are marked *

Looking to improve your digital analytics or conversion rate optimisation?
Contact us today on +44 (0)20 7148 5970

Alternatively, come visit us in London and we’ll buy the coffee!
Get in touch
Leave us a message
Use the form below to leave us a message.

Lindsey Street