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.
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.
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
dataLayer.push({ ‘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.
[one_half]
Click on homepage widget
dataLayer.push({ ‘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
[/one_half_last][one_half]
Track completion of a form field
dataLayer.push({ ‘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
[/one_half_last]
Scrolling to the bottom of a content page
dataLayer.push({ ‘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.
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.
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”.
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.
