Why you should NOT use GA4 enhanced events and what you should use instead
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:
The image above shows an example of the problem. We have a GTM listener attached to a click listener, alongside a GA4 and Facebook listener. In effect, three things are listening for the same bit of information. It’s likely this will cause JavaScript bloat and slow-down client-side execution.
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?
What are auto-events / enhanced-events?
You might recognise some of the below options from Google Tag Manager.
GA4 has a very similar set of options. The only slight difference is that form interactions have a start form as well as a form submit. And of course, ‘JavaScript error’ events don’t exist in GA4.
When we talk about enhanced events and auto events, we’re only talking about these two types of listeners (GTM & GA4).
Why enable auto events / enhanced events?
Let’s look at some reasons why you might want to enable GA4 enhanced events and GTM auto events:
- Bounce rate & time-on-site stats will be better and more accurate.
- They don’t require developers to be enabled.
- They help with ga4 conversion tracking, for example
- Contact Form
- Click on Mailto
- Click on Tel
History of auto events / enhanced 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.
The goal: Combine GA4 enhance events with GTM 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.
The problem – unexpected bugs!
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.
Problems with GA4 enhanced event DataLayers
1. Video
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.
2. Outbound clicks
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.
3. File downloads
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.
4. Scrolls
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.
5. Timer
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.
6. Forms
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.
Summary
Let’s summarise the issues we’re facing.
- CRITICAL – Forms (gtm.form) are counting Facebook & Snapchat pixels sending using method=post as false positives.
- RECOMMENDED – HTML attributes such as data-category and CSS selectors are not possible as {{Click Element}} is not exposed.
- ClickText is not exposed on OutboundClicks (gtm.eventModel.link_text).
- ClickClasses is not exposed on FileDownloads (gtm.eventModel.link_classes).
- File Downloads have a bug whereby .mov .mp4 .mpg .mpeg .wmv .mid .midi .mp3 .wav .wma are not being tracked due to an inline JS typo.
The solution to GA4 enhanced events DataLayer issues
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.
1. Video
When it comes to video, everything is exposed as it should be, and directly mapped.
2. Outbound clicks
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.
3. File downloads
Again, with file downloads everything is working as anticipated, we have full control. You’ll notice that we’re outputting the same event name as GA4 in this instance – ‘file_download’. But we’re also adding a data layer file called javascript listener GTM. This is done intentionally so that if GA4 auto events are tuned on by accident, two events aren’t being fired at once.
4. HistoryChange
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.
5. Scrolls
If scrolls are handled in GTM, we get complete control. We can set any thresholds, add trigger groups, combine scrolls, and more.
6. Timer
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.
7. Forms
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:
- 10-sec heartbeat is not exposed by the data layer (on next page click, or tab closed).
- We’ve left internal site search being run by GA4 as it is simple to manage in the interface. There are, however, some reasons you might want to use GTM. For example, If the lowercasing of site search is important.
Big Picture: Data collection standardisation
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.
GTM is too flexible
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.
Why Standardise?
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 problem with AI: Bad input data means bad output data
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.
What you should do now
With all this in mind, what should your next steps be? Let’s summarize.
For larger sites
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.
For medium or small 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.
For the future
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.
Make Google aware!
Google needs to know the truth about GA4 issues with gtag.js. Sadly, there isn’t an effective way of reporting javascript problems within the interface. Instead, it can be more effective to send a tweet to Google Analytics. Scan the above QR code with your phone or click this link, we’ve got Tweet prepared for you. All you need to do is hit tweet!!
