An Improved Method of Tracking Generic Events in GTM

Rather than creating multiple tags in Google Tag Manager to track events in Google Analytics (which takes time to set up), some people opt to create a single generic tag which listens for a generic event in the data layer. The data layer also contains details on what values to set event action, category and label to.

The dataLayer push would typically look like this:

  event: 'triggeredGenericEvent',
  eventAction: 'Clicked Outbound Link',
  eventCategory: 'Links',
  eventLabel: ''

And a trigger in GTM would look like this:

GTM Generic Event Trigger

And a tag in GTM would look like this:

GTM Generic Event Tag

Nothing wrong with this set up at all.


Dealing with Complexity

What happens if you want to add more sophistication to your tracking.

Maybe you want to track all outbound link links, EXCEPT a click on a particular URL. Your generic event logic can’t handle that right now.

Yes, you could add some logic in the trigger to check the event label value and not fire the tag if appropriate.

But then another requirement comes in.

You’ve got a promotion on BMW’s in your car showroom and marketing is concentrating their efforts on increasing test drives. You know they’ll want to see a report of ‘Booked Test Drive’ events broken down by car make.

Make Test Drives
Vauxhall 100
BMW 80
Renault 60

“Great!” you think to yourself.

I’ve already got a ‘Booked Test Drive’ event in Google Analytics due to my generic event capturing setup:

  event: 'triggeredGenericEvent',
  eventAction: 'Booked Test Drive',
  eventCategory: 'Test Drives',
  eventLabel: 'BMW'

Creating the report is simply due to the event label containing the car make. All I have to do is pull a report of Total Events broken down by Event Label filtered by Event Action = ‘Booked Test Drive’.

Then the CMO tells you she wants to see test drives booked by car make AND model.

Uh oh.

We’re not tracking model. We need to get the tracking implemented ASAP!

The wrong approach

Your initial thought is to update your data layer push to include car model in the event label:

  event: 'triggeredGenericEvent',
  eventAction: 'Booked Test Drive',
  eventCategory: 'Test Drives',
  eventLabel: 'BMW|Series 7'

The benefit of this approach is there’s no need to alter your Google Tag Manager of Google Analytics set up at all.

The drawbacks however, are pretty major. Any analysis will have to be done by extracting the data from the events report into another tool, and splitting the event label on the pipe symbol.

Every time you add an extra step in the analysis you are decreasing the chances someone is going to do said analysis. And if you’re the person who does the reporting, you’re increasing your work load.

What should we do?

Approach #1

Create two hit scoped custom dimensions in Google Analytics called Make and Model, and set these as attributes of the ‘Booked Test Drive’ event.

Update your data layer push to include car model as below.

  event: 'triggeredGenericEvent',
  eventAction: 'Booked Test Drive',
  eventCategory: 'Test Drives',
  eventLabel: 'BMW',
  carModel: 'Series 7'

Create a GTM variable called dl_car_model to read this value, and update your Google Analytics Settings variable to set it as a custom dimension.

Setting car model as custom dimension in GTM

This works brilliantly, and we only had to make a couple of easy changes. We can build a custom report in Google Analytics to pull the Total Events metric grouped by Event Label and Car Model, filtered by the ‘Booked Test Drive’ Event Action, giving us a table like this:

Make Model Test Drives
Vauxhall Vectra 80
Vauxhall Astra 20
BMW Series 7 40
BMW Series 5 40
Renault Megane 60

Approach #2

Approach 1 is an improvement, but not without limitations.

The developers now need to understand what data attributes are tracked with what event, defeating the point of decoupling the complexity from them by using a generic data layer push in the first place. There’s not much we can do about this except provide them will good data layer specification documentation.

The other drawback is still not being able to add complex logic to the trigger. For example, let’s return to the example at the beginning of this article, tracking all outbound link clicks except to a particular URL.

Here’s the data layer push.

  event: 'triggeredGenericEvent',
  eventAction: 'Clicked Outbound Link',
  eventCategory: 'Links',
  eventLabel: ''

Notice the clicked URL is stored in the eventLabel variable. This is what we want to filter on. If the eventLabel contains ‘’ we don’t want the trigger the Clicked Outbound Link event in Google Analytics (I realise the example is a little contrived but bear with me).

Again, we can update our exiting trigger in GTM to not fire if eventLabel contains ‘’, but this may break other events (for example a ‘Shared Article on Social Media’ event).

The solution?

Set a new boolean variable in the dataLayer object called eventRequiresCustomisation.

  event: 'triggeredGenericEvent',
  eventAction: 'Clicked Outbound Link',
  eventCategory: 'Links',
  eventLabel: '',
  eventRequiresCustomisation: true

Create a new variable called dl_event_requires_customisation in Google Tag Manager to read the eventRequiresCustomisation variable from the data layer:

Event Requires Customisation variable in GTM

Update your generic event trigger in Google Tag Manager to only fire if this variable is not true.

Updated GTM trigger with Event Requires Customisation

What has this accomplished?

The developers can still use the generic data layer push code they are used to, but we can stop GTM firing these to Google Analytics with the addition of the eventRequiresCustomisation: true value.

In GTM we can now create a new trigger which still uses the triggeredGenericEvent data layer values, but can be customised to not trigger when Facebook links are clicked.

GTM Custom Outbound Link Trigger

And finally we create a new event tag, which is still able to use the eventAction, eventLabel and eventCategory labels from the data layer, but fires on our more complex trigger.

GTM Clicked Outbound Link Tag

Another benefit of this approach are being able to override the values for event category, action and label set by the developers, should you need to.


I’ve presented a way to implement Google Tag Manager in a way that minimises the number of tags necessary, and simplifies the data layer code the developers need to implement, but also allows more sophisticated tracking when necessary.

As with most things, there are multiple ways to accomplish the same result and you should think carefully about whether this approach is the best for YOUR business before blindly implementing.

What are you thoughts on using this approach?

Drop me a comment below to let me know!

Ed Brocklebank (aka Metric Mogul) is an analytics and digital marketing consultant. He helps business of all sizes become more data-driven through measurement, strategy and activation. He works as a Strategic Analytics Director at Jellyfish in London, as well as delivering training on behalf of Google and formerly General Assembly.