People are talking about GA4 enhanced events. But in this article, we want to talk about an alternative. We’ll be looking at why you might want to standardise and improve GTM auto events and the GA4 library.
We’ll also talk about any problems you might run into with this approach and some solutions for fixing them.
This is a write-up of the talk by Phil Pearce at GA4ward MKIII. You can find his slides here, and the recording is below:
This becomes even more of a problem when you start adding other types of listeners. But is it possible to standardise and consolidate those listeners?
You might recognise some of the below options from Google Tag Manager.
When we talk about enhanced events and auto events, we’re only talking about these two types of listeners (GTM & GA4).
Let’s look at some reasons why you might want to enable GA4 enhanced events and GTM auto events:
So, auto-events are useful. But how did we get to them in the first place?
In 2012, Stephane Hamel produced gaaddons.js. Google Analytics on steroids (gas.js) by Eduardo Carvalho consolidated this. Carvalho then went on to work for Google and the code contributed to autoTrack.js which was a Google plugin script.
Roughly after that, GTM auto events launched with click listeners, link listeners and auto submit. There were two versions of this, V1 GTM auto events and V2.
Facebook soon realised that a page view was no longer enough. They wanted to detect other activities of users and read information about the page. Facebook introduced their equivalent to autoTrack.js called auto-config (autoConfig=true). This was enabled by default.
In 2020 we had GA4 enhanced events as part of gtag.js. You’ll notice Google has not been brilliantly quick in updating and adding new features to auto-events.
We want to combine the simplicity of GA4 Enhanced Events, with the power of GTM auto events. If we’re able to accomplish this, we’ll get an optimal setup.
It sounds like it should be simple to enable all these features and get them to talk together. Unfortunately, this is far from the case.
We started the process knowing that GA4 was the way ahead, as GA3 was being deprecated. It made sense to tap into the GA4 data layer that these enhanced events output.
We put this idea into practice (shown in the image above). Then piggybacked those outputs (scroll, link click, etc) and mapped them to the equivalent that GTM outputs.
We tested this in a variety of formats, but sadly we also ran into some issues. Let’s look at these.
This image shows an example of a video listener. This example is listening for the GA4 video listener and converting the GA4 data layer into a GTM YouTube listener.
There were a couple of small issues in this instance. GA4 doesn’t track 90% of video progress. There is also no pause, seek, or buffering tracking. These are not critical issues, and we still get some valuable data.
Another problem is if you have YouTube running as an autoplay, it can’t be disabled in GA4 unless you use GTM server-side. But since not many sites will be using a YouTube video as a background, this isn’t a huge issue.
The same method applies to outbound clicks. Again, we’re listening for the link click, as there is no click-only event. This isn’t ideal, as we don’t have a second listener to map to.
But as you can see from the image, there are elements that are exposed. The click selector, however, is not exposed. Instead, we have to read elements of the link for HTML attributes. We also can’t use GA4 for CSS selectors.
This is a real shame, and greatly limits the functionality we can get out of GA4 features.
We had some very similar issues with file downloads. There are some slight nuances with the file name, technically it should have a forward slash but doesn’t.
GA4 does a 90% scroll natively – this is great! There are, however, some issues if you’re looking at a short page, or if you want to combine a scroll with a 15-second delay. You won’t have control over the scroll thresholds, which can be limiting.
We can also choose a 75% scroll when setting up GTM. It’s defaulted to 90% here, which is right at the end of the page. This lack of control is a big issue.
There is a ten-second timer in GA4 (plus a second event like a next page or close tab). Unfortunately, when you add a user engagement event, it’s not pushed into the data layer. You see an event attached to the GTM initializer, but there’s no other event that’s pushed.
Because this value isn’t exposed, it can’t be mapped to GTM.
We’re starting to get bigger problems with forms, which were listening for any form posts. This could be a Facebook pixel sending a post request instead of a get request, producing a fake form submission.
Normally in GTM, you’d simply ignore any forms posted to Facebook. But as there is no control over GA4 form submissions, you cannot exclude the form URL. There is also no way of adding a two-second delay, as you would with GTM.
We recommend turning off the GA4 form submit, as this will autofire as soon as you have a Facebook pixel active.
Let’s summarise the issues we’re facing.
But what is the solution to these issues? Having gone through this process, we had to think about what might be a better option to consolidate these libraries, improve site speed, and retain good data collection.
The answer we came up with was to supercharge GTM and depower GA4. We set GA4 to just the basic page view and set GTM to push all GA4-enhanced events. The data is identical, it’s just using GTM as the listener.
The image above shows what this looks like put into practice. In this example, we’re carrying out GTM to GA4 mapping. We have a list of triggers including a Trigger group, LinkClick, form submit, and more. These all push into a generic GA4 event which is presented in the interface.
Let’s look at some of the results from this approach.
When it comes to video, everything is exposed as it should be, and directly mapped.
Outbound clicks are also working as they should. Crucially, the click element is exposed. We have full control over CSS selectors and HTML 5 attributes.
The reason we recommend this in GTM is that you cannot exclude parameters easily in GA4. If you have email addresses and PAIs and you need to clean them on the page_location as part of a history change push, you have to use GTM tools.
For PushState, we have a page URL cleaner that allows us to purge all PAIs. We can use a whitelisting approach that only allows certain UTM tags, GCL IDs, and other parameters. We also purge and clean the referral URLs. GA4-enhanced events don’t do this.
As there is no exclude parameter in the interface, this is a useful safeguard.
If scrolls are handled in GTM, we get complete control. We can set any thresholds, add trigger groups, combine scrolls, and more.
When it comes to timers, no action is needed. We can’t stop the timer or user_engaged event in GA4, as there is no setting to disable it. Since we can’t turn it off, there’s no need to send it to GTM.
For forms, we have the form submit listener. GTM does not have a form_start listener, which is the only area handled by GA4.
We’ve also had to leave the following areas as exceptions:
The big benefit of using GTM auto events is that it is one click to enable everything. This standardizes data collection in the same way that Facebook is standardizing input and digestion.
Deviating from the standard approach is great when it comes to building dashboards. You can also better understand the context of data, especially from small sample sets.
The names of variables can be anything in GTM, as can the names of events. Google has given marketers too much power creating some standardization issues.
It would be useful if Google would standardize elements such as the GA4 event ID, double click ID, or Google ads ID. Since there are no built-in variables for these areas, it’s easy to set up areas like consent mode incorrectly.
There are also potential issues with the GA4 config tag since some instances can be fired twice.
After July 1st it’s widely expected that Google will introduce some improvements to intelligent events. This will likely include AI insights into analytics. This seems like an obvious progression, given Google’s investment in Bard.
We carried out a quick test. We asked Bard to connect to Google Analytics and give a sample of our best marketing campaigns. Then asked for some suggestions for improving CPA whilst maintaining conversion levels. Finally, we asked the tool to use the context of our data.
This is likely where we’re headed when it comes to AI in GA4. We’ll have the ability to authenticate our Google Ads and Google Analytics accounts. We’ll be able to use the context of our data and benchmarking data, plus machine learning and predictive analytics, to come up with solutions.
The only downside to AI is that if the data input is wrong it can lead to the wrong output. A good example is Microsoft Tay, a chatbot similar to Chat GPT, which was trained on Twitter data. The tool started digesting Donald Trump’s tweets and produced some slightly strange responses.
This image was from an account that was linked to Firebase. The intelligent alert informed us that we had 600,000 more screen views. This happened because Firebase had only just been connected, producing a false positive. Because of the lack of historic data, the tool couldn’t flag the result as an invalid suggestion.
Over time GA4 users will provide feedback and usage data. This allows the interface to better know what’s working and what needs to be improved.
With all this in mind, what should your next steps be? Let’s summarize.
If you’re running a massive site and a global loadout, supercharge your GTM account and depower GA4. You can do this by moving listeners from GA4 over to GTM.
But make sure you output the same data layer, that way you’re not losing any detail or data input. This is like putting GA4 into training wheels mode or page view-only mode.
Doing this requires a technical setup, that’s why this is only really suggested for large sites.
If you have a medium or small site, go for the simplest possible option. This is to use GTM auto events and turn on GA4 enhanced events, which is easy to manage. The only exception is the form interaction event, as this is very buggy.
No announcements or updates have been made for GTM for almost a year now. Once bugs have been fixed, we hope that Google will start investing more time into gtm.js. Using gtag as your primary will probably be a good solution once bugs are fixed.
There is, however, as you can see above, a long list of bugs that still need to be fixed!
If you’re a fan of GTM, the good news is that the tool isn’t going away anytime soon.