Best Practices for Events and Parameters in Google Analytics 4

Google recently made the shock announcement that it will be retiring Universal Analytics (UA), leaving Google Analytics 4 (GA4) as the only available platform. This changeover is expected to happen on July 23rd 2023. UA data will not be transferable to GA4, so starting early and getting to grips with the platform whilst compiling historical data is essential for your business to transition smoothly. 

Why the change?

GA4 combines website and app users’ tracking, whereas, historically, if you wanted to track both app and website users’ journeys, it was necessary to use Google Analytics for Firebase and UA separately. These had different data collection models and made like-for-like comparisons very difficult.

Moreover, Google is looking to future-proof itself against a potentially cookieless world. Considering that UA uses cookies to track visitors to a website, there is an increased demand to create a new platform that secures privacy, but at the same time allows for user identification. GA4 has machine learning at its heart, so should allow Google to be a lot more flexible with future privacy changes.

Recording the activity of onsite users within a time frame is session and pageview tracking, however GA4 sets to move away from this. Instead, it will be using event and parameter-based tracking, which tracks users by predefined interactions on your website. As a result, there will be a revamp of best practices to create your tags within GTM.

The difference between configuration and event tags

We’ll start by understanding the difference between the configuration and event tags. Event tags use an event name + parameter structure. Configuration tags use a measurement ID + parameter structure. See below:

Event Tags:

Configuration Tags:

The configuration tag acts as the base setting for every event tag and is also responsible for sending a pageview and session start event on page load. Within the configuration tag, you should set non-dynamic event parameters, which reflect the base data you would like to collect on web pages.  Such as the URL of the page the event is firing on:

How to deal with tracking ID changes

Another change is the Tracking ID, as GA4 uses a Measurement ID that is assigned to your data streams.

GA4 has one property and instead of multiple views, you have data streams, where each stream has a Measurement ID. Data streams are another new feature where streams may be split up by website, IOS and Android apps, allowing you to analyse your website and app data in one property. You’re able to have 50 data streams within each property, a caveat of this is 30 app data streams. To track several websites under one company, setting up several properties and enabling cross-domain tracking is the new way to pass information between domains. 

Understanding event tags

Next comes the event tags. Event tags inherit variables about the page from the configuration tag. The overall structure of the events tag is an event name, a parameter name and a value set to that parameter.

There are four types of events to note here: recommended events, enhanced measure events, automatically collected events and custom events. 

Automatically collected events are specific events that collect parameters associated with that event ( Clicks, File Downloads). They can be web and/or app events. Moreover, there are parameters that are collected with every event which gets fired.

You can choose to switch on the enhanced measurement in your data stream. Once turned on it automatically fires events with set parameters. Read the full list here.

The key part of this event is no event needs to be configured for the information to be collected. 

Google has released guidelines for ‘recommended’ events. Although the full functionality is unknown, what is understood is that they will allow you to utilise the new predictive metrics in GA4. Purchase probabilities, churn probabilities and predictive revenue. This is especially important as Google is looking to fill in the gaps left by cookies. GA4 will use machine learning to complete reports.

Finally, there are custom events, which are any event not covered by the above. There are no required event naming conventions and can be what you like. 

Testing events with GA4’s debug view

GA4 also comes with a new debug view, a real-time report on what events are firing on a page. First, you need to enable debug mode on your browser or device, or a parameter in a tag. See here for a list of methods to monitor events in debug mode.

Once you have enabled it, to navigate to the debug mode, go to Configure > Debug mode. You will be greeted by two timelines of events triggered. The first timeline is in intervals of 1 minute denoted by a circle. If you click on the circle, you can see the number of events triggered. The dropdown menu on the top allows you to switch between multiple devices. 

Minute Timeline:

The second timeline is in intervals of 1 second. Here you can get a fully comprehensive overview of all the tags fired on the page, as well as a list of the user properties and parameters associated with the event.

Seconds Timeline:

Next, there is an easy to see list of your general, conversion and erroneous events in the last 30 minutes.

User property and event limitations

Google has imposed certain limitations on the number of user properties and event parameters you can create per property, as well as a soft cap on the number of distinctly named events. 

• 500 distinct events
• 25 custom user properties
• 25 event names per parameters
• 1 million hits exported to BigQuery
• GA4 stores your data for a max of 14 months

Exporting your data to BigQuery overcomes these limitations., allowing you to see any data where the tags have gone over the limits imposed by Google.

Amongst the several limitations that Google has put on GA4, there is another one of significance, that limits data collected and sent to BigQuery to 1 million hits per day. This is a huge issue for acquiring a complete picture of a website, however, there are a few ways to work around this – one of which is server-side tracking. 

Server-side tracking works by a web tag sending the data to a server hosted by yourself, after which you can send it to the platform of your choice. The second option is highjacking GA hits, this is done on the client-side and sends the Google analytics data to a custom endpoint. Both allow you to have a lot more control over your data and overcome the 1 million hits per day limitation.

What’s next?

GA4 replacing UA is going to cause a big stir. However, it comes with exciting new features to garner even more in-depth insights into your customer base. Reviewing and updating existing setups is recommended. Implement GA4 in tandem with your current UA framework before it’s depreciated in mid next year. 

Stay tuned for further insights into Google Analytics 4 or get in touch with our Analytics team if you’re looking for expert Google Analytics 4 services to help you get the most out of your data.