The category, action and label dimensions in legacy versions of Google Analytics made it simple to organize your events, but these variables have been deprecated in Google Analytics 4. Before you start creating GA4 tags you need to do some careful planning to ensure that your reports are set up properly. In this post I will share the best practices that I have gathered when setting up events and parameters so that you can avoid common mistakes.
Old Events vs. New Events
The concept of an event has changed in Google Analytics 4. Here is a quick summary of the differences:
- The traditional definition of an “event” was any action that you would like to track other than a page view (click, impression, form submit, error, etc). When you created events, you simply set a “category”, “action” and “label” to specify how it should appear in the “Top Events” report. Then, you passed any other context about the event to the “value” parameter or any custom dimensions/metrics you would like.
- The new definition of an “event” is more broad: “…any distinct action occurring at a distinct time associated with a user” (source). To provide further context to the event, the concept of a generic “category”, “action”, and “label” has been replaced by an event name and a list of key-value pairs called “parameters”. On the web, every time you fire an event to GA4 you are telling the browser to send data to Google Analytics (mobile apps send events in batches, but the concept is the same).
There is no page view hit in GA4. All hits are events, and so to track a page view you need to create an event and give it the name “page_view”. The page title, URL and other dimensions are set as parameters.
Also, the “Top Events” report has been replaced with the “All Events” report in GA4, and the first thing you’ll notice about this report is that events cannot be grouped. If you click on the event, you will be taken to a special report with details about that specific event.
Why Planning Is More Important for Google Analytics 4
In GA4 you cannot use view filters to correct mistakes (at least not at this time). Additionally, for native apps, you have a limited ability to modify the data that has been captured in GTM (read more). So, for example, if your developers create an event name called “signUp” instead of “sign_up”, this will probably need to be corrected in the code.
Also, GA4 properties allow you to roll up data across all of your websites and apps now (previously only available to 360 properties). If you choose to do this you will need to ensure that events within each stream use consistent event names, parameter names, and parameter values. Even small mistakes like capital letters can prevent data from merging properly.
Don’t forget that in any version of Google Analytics, once data is collected it cannot be changed.
Best Practices to Avoid Common Mistakes
Okay, so hopefully I scared you a little bit in the section above. Now let me put you at ease. Here are the best practices that I’ve gathered to get you off to a good start:
1) Use the Suggested Events when Possible
This should be obvious, but I am guilty of setting up custom events only to realize later that a suggested event was available (see full list here). There are two reasons why it is important to use the suggested events:
- In many cases, the suggested events unlock new reporting. Take the page view event on a website for example. If you mistakenly create an event called “pageview”, Google will not have any context to understand what this event is tracking. But if you use the standard event name “page_view”, then your tag will automatically capture additional parameters such as the page title and name, and make these available in the reporting interface.
- Google Analytics 4 is brand new, so it is important to set yourself up to gain access to new features and integrations that are released as the product is expanded. It’s important that we set up events and parameters properly the first time because making changes down the road can be painful, so using the suggested events might just help you avoid this pain down the road.
2) Use Unique Event Names to Track Conversions
The concept of a “goal” in previous versions of GA has been replaced with events that have been “marked as conversions” in GA4. And although you previously created goals out of an event or page view where certain parameters were set (such as: event category = “lead submitted” or URL matches some regular expression), you now enable an event to be recorded as a conversion by the event name only — no parameter conditions are allowed.
As a result, each event that you would like to track as a conversion must have a unique name. For example, when a user submits a lead form you cannot track the view of the thank you page as a goal any more. Instead, you will want to set an event with the name “sign_up” to fire when the thank you page loads.
3) Plan Your Custom Dimensions & Metrics
The event parameters you create feed the custom dimensions and metrics that you will use in your reports. Custom dimensions work very differently in App+Web than they did in Universal Analytics, so if you use Universal Analytics today then you should read my article about this here.
You are limited to 100 custom dimensions or metrics (source), and they should be defined in exactly the same way across your streams.
4) Be Careful Not to Set Too Many Distinct Event Names
Currently, you are limited to 500 distinct event names (source). As a result, you should keep your event names focused on the actions that users are taking (click, video_play, etc) and use parameters to define the objects being acted upon (‘link_href’, ‘video_name’, etc).
5) Create and Maintain Good Documentation
Good documentation is critical. Even if you’re only setting up a single website, there is no way to validate that your tracking code is doing what it is suppose to do if no one has written that down somewhere along with test instructions. And if you are merging data between multiple streams, this is even more important.
This type of documentation is called a “Solution Design”, and at a minimum it should include:
- The business requirements or questions that you are solving with Google Analytics.
- A list of the events, parameters and user properties that you are using across all of your data streams (with a description for each) to address these business requirements.
- Instructions for testing that your data is setting properly.
- (OPTIONAL) I also like to include instructions for the development team in the same document.
To help get started with good documentation, I’ve created a sample Solution Design template that you can copy and modify.
Don’t Forget to Protect User Privacy
Google Analytics 4 includes a new feature that allows you to flag events that should not be used for personalized remarketing. When you enable this feature on an event, audiences that are created using the event can only be used within non-advertising products, and cannot be exported to products like Google Ads or Search Ads 360 (more info here).
To use this feature, navigate to the “All Events” report and click the three dots next to any event to see the option “Mark as NPA” (which stands for “no personalized ads”).
If you have not set up a Google Analytics 4 property yet, take a look at my guide HERE.
If you already have a legacy version of Google Analytics installed on a website, take a look at my article on Translating Website Tags from Universal Analytics to GA4.