After auditing and working with many Google Analytics 4 setups, I noticed that some errors occur more often than others. Some of them are the result of the unintuitive structure/interface of GA4, others might be considered a misunderstanding.
To help you with that, I have picked the 10 common Google Analytics 4 mistakes. In this blog post, I will explain what they are and how to fix/avoid them.
Table of contents
+ Show table of contents +
#1. Missing currency
#2. Collect Universal Analytics events
#3. Always sending the debug_mode parameter
#4. Using the “Create event” feature when you should not
#5. event_category, event_action, event_label
#6. Too many unique parameters as dimensions
#7. Data retention
#8. Live vs test website
#9. Internal traffic, unwanted referrals
#10. Persistent values in the GA4 configuration tag
Final Words
Video
If you prefer video content, here’s a tutorial about the same topic from my Youtube channel.
#1. Missing currency
If you selling products/services online, you have to implement ecommerce tracking in GA4. If you (or your company) is on a tight development budget, you should track at least purchases.
This will help you understand which traffic sources/campaigns drive the most sales.
To implement this, you would need to follow the official Google Analytics 4 documentation. However, not everything there is emphasized properly, therefore, we reach our first common GA4 mistake.
Even though the documentation does not specifically say that every purchase must also include a currency parameter, you should always send it.
Even if your online store operates in just one currency, you still need to send that parameter with every purchase. In GA3, that kind of data was optional. In Google Analytics 4, it is required. Otherwise, some parts of your monetization reports will not be showing all possible data.
So make sure, that in your GA4 tag (within Google Tag Manager), you also include the currency parameter and its value must follow the ISO standard. For example, the US dollar must be set as USD, euro – EUR, etc.
Do NOT include the currency signs (like $). GA4 will not understand what it is. You must follow the standard, e.g. EUR, USD, CAD, etc. You will find the list of supported currencies here.
#2. Collect Universal Analytics events
If you are considering the migration from Universal Analytics to Google Analytics 4, you probably noticed a feature called Collect Universal Analytics Events. It is available in the settings of a web data stream.
This feature works if your Universal Analytics is installed with analytics.js (that’s an old version of the tracking code) and you don’t use Google Tag Manager in that setup.
Once this feature is enabled, GA4 will try to catch all events tracked by that analytics.js tracking code and you should see them in the Google Analytics 4 reports.
Sounds amazing, right? No need to develop anything, just reuse the existing tracking code.
But there’s a problem with that. When you use this feature, you lose control. And you transfer the GA3 technical debt to GA4.
All event names will get whatever value you have in event action. Event category and event label will be sent as event_category and event_label parameters. Sure, you can use the Modify event feature in GA4, but that allows only 50 rules per property.
Google Analytics 4 is your chance to start fresh with your analytics setup and naming convention. You also probably have a lot of redundant GA3 events that are no longer relevant. But with this feature, you will continue collecting those events and polluting GA4.
#3. Always sending the debug_mode parameter
One of the great additions to Google Analytics 4 is DebugView which allows troubleshooting incoming data on a more granular level.
There are 3 ways how you can start seeing data in it:
You can enable the GA debugger Chrome extension
Have enabled Google Tag Manager’s Preview mode on a page that you’re debugging
Send a debug_mode parameter together with an event
This Google Analytics 4 mistake is related to the 3rd option.
If your GA4 tag looks like this…
…and you have a debug_mode parameter included in the Fields to set section AND that parameter contains *any* value (except undefined), this means that events will be displayed in the DebugView.
What’s the problem?
If this setting is published and all your website visitors send the debug_mode parameter, you will have A LOT of devices here:
This makes the debugging process difficult and you will have a hard time finding your own device in that list. What’s the solution? Option #1: create a custom GTM variable that returns either true or undefined and use it as a value of that parameter.
Or just don’t remove that parameter at all. When you have the preview and debug mode in GTM enabled, the DebugView in GA4 is enabled automatically. There is no need to set debug_mode=true additionally.
#4. Using the “Create event” feature when you shouldn’t
This mistake is common among GA4 beginners. I guess that you already know this: if you are sending custom parameters to Google Analytics 4 and you want to use them as custom dimensions in the interface, you have to register them.
And this occasionally brings confusion because some beginners think that they have to register custom events too.
First, they start sending an event with Google Tag Manager or GTAG and then they go to GA4 > Configure > Events > Create event and create the same event there.
End result? Duplicate data. You will get one event from GTM/GTAG, and then the same event from the “Create event” feature.
When you are sending custom events to GA4, they will eventually appear in your reports automatically. You don’t have to register/create them in the interface.
#5. event_category, event_action, event_label
This is not necessarily a mistake but I would personally not do that. You are free to do otherwise, but I just wanted to share my opinion.
When you were sending events to Universal Analytics, you had to fill in several fields:
Event category
Event action
Event label
Event value (but now let’s focus on the first three)
Some people (when they implement event tracking in GA4) just reuse the same parameters.
Technically, this is possible and you are free to do so. But in this case, I would recommend for you rethink the naming convention and not migrate event category, action, and label.
Instead, think about more descriptive parameter names. For example, here we have two events (see below). One is banner displayed and values surrounded by square brackets can dynamically change. And the second event is form submission. Event action and label values are different.
Instead of blindly migrating event category, action, and label, here’s what I would suggest for Google Analytics 4.
The event names would be banner_displayed and generate_lead (or whatever works for you). And then I would try to come up with some parameters that could be shared between those events.
For example, when I look at the parameter “element_name“, I will immediately know that this will be either the name of a form or banner.
element_id also sounds generic enough so that I could apply it to multiple events and website elements. But don’t go with too many unique parameters, otherwise, you’ll end up making mistake #6.
#6. Too many unique parameters as dimensions
Be aware of certain limitations in Google Analytics 4. For example, you can register up to 50 custom dimensions per property.
So if you are using way too many unique event parameter names that you want to later use in the interface, you will quickly hit that wall.
You might be tempted to name parameters like this (unique for each event):
If you’re working on a small project, the limit of 50 custom dimensions might not be a problem for you. But who knows what will happen in 2 years? Maybe your small project will explode (in a good way) and will start growing fast? This means more events, more data, and a rapidly exceeded limit of 50 dimensions.
So try to be one step ahead and come up with a proper naming convention as soon as possible: not too many unique event parameters, not too few.
#7. Data retention
There are two types of reporting features/modules in Google Analytics 4: standard reports and explorations.
The data in standard reports does not expire but things are different in explorations. By default, you are able to work only with the data from the last 2 months.
Want to build a custom report in explorations with the data from the last 6 months? Too bad. That is not possible by default UNLESS you extend the data retention period from 2 months (default) to 14 months.
This is something that every GA4 user has to do when a new property is created. Go to Admin of your GA4 > Data settings > Retention and change to 14 months. Keep in mind that this change does not apply to historic data. Your 14 months start when you change that setting.
Paid users of GA 360 can have even longer data retention.
#8. Live vs test website
If you have several versions of the same website (e.g. one for testing/development and the other one is the live version), you have to use separate GA4 properties. I talk more about this here.
The mistake that I sometimes notice is that people send data from both versions of the website to the same property hoping that they will use filters, segments, or comparisons. But that is not convenient and will still most likely pollute your reports.
Use separate properties for each version of the website.
#9. Internal traffic, unwanted referrals
This tip is related to the data quality in your Google Analytics 4 property. If you have a lot of coworkers browsing the site, their events will be collected by GA4. Unfortunately, I have seen way too many properties that ignore this fact.
To reduce data pollution, you have to exclude internal traffic. And I have a tutorial that explains that.
Another thing that often gets forgotten is the exclusion of unwanted referrals. You can learn more about it here.
#10. Persistent values in the GA4 configuration tag
This problem is especially important for those who have implemented Google Analytics 4 on single-page applications. In a nutshell, if you set a parameter in the GA4 configuration tag, its value with remain the same until the page is reloaded. Even if the GTM variable’s value changes, it does not change in the configuration tag.
A more in-depth explanation of the problem and solution is available here.
Maybe that will change in the future. But right now, a solution for this would be to set parameters not only in the configuration tag but also in all other event tags.
That’s a lot of manual work but that’s the current reality.
Google Analytics 4 mistakes: Final Words
Hopefully, this blog post will help you avoid at least some of the Google Analytics 4 mistakes. If some of the tips in this blog post were not clear enough, take a look at this Youtube tutorial as well.
Struggling with the setup? You can download my free e-book here or you can enroll in a very in-depth GA4 course where I will show you the entire process from A to Z.
The post 10 Google Analytics 4 Mistakes in Configuration You Should Avoid appeared first on Analytics Mania.
Read MoreAnalytics Mania
