Event Naming Considerations for Google Analytics 4 Properties

Google Analytics 4 (GA4) properties feature a new event-based data model borrowed from Google Analytics for Firebase. For web analysts familiar with the Universal Analytics (UA) data model, we have some work to do to map our old event schema to the new data model.

In GA4, we've come a long way from when events carry a category, action, label, value, and perhaps some custom dimensions or custom metrics. We can now send up to 25 event parameters with each event and up to 500 distinct events. With the new event structure, we get a more flexible framework for generating and delivering insights and analysis.

We gain so much flexibility in how we name our events and parameters that it can be difficult to ascertain the event naming convention that's most fitting for our needs. This blog offers considerations as you renew your measurement strategy and migrate from UA properties to GA4 properties.

Best Practices for Naming Events in Google Analytics 4 Properties

In this article, we're careful not to call these considerations "best practices" because, frankly, new features for the tools are still being built and it's a bit early for that type of characterization. The industry hasn't had enough time to identify "bad practices" from which a consensus around "best practices" has emerged.

Notwithstanding that caveat, Ken Williams has put forward a pretty good list to get the "best practices" conversation started. Ken's list focuses on general best practices throughout the planning, implementation, and documentation phases of an analytics project; this article focuses on considerations specific to the measurement strategy and solution design phases (i.e. before you begin any instrumentation). We encourage you to read Ken's blog as you get familiar with GA4 properties, and this post when you're crafting your analytics strategy.

Granular Event Names Provide Greater Flexibility and Clarity

We've begun to favour granularity in our event naming conventions and you'll see granularity is a recurring theme throughout this article.

As companies set up parallel tracking between their UA properties and GA4 properties, one of the first challenges you'll come up against is how to map the old event structure to the new.

In UA properties, we had events that carried a category, action, label, value, and any custom information we added. In Google Analytics 4 properties, we define an event name and it carries with it up to 25 parameters. Parameters are additional pieces of information that describe the event.

A common starting point is to map either the Event Category or the Event Action to the event name, and to set the event label and custom definitions as parameters.

For example, suppose you're mapping video events to the new event structure. You may have used the following event schema in Universal Analytics:

Your first thought might be to set the event name to the Event Category and add everything else as parameters, using the UA dimension name as the name of the parameter:

Put another way, in your first thought, you might have an event named videos that carries event parameters event_action, event_label, and event_value.

The benefit of this approach is that anybody familiar with your existing UA event model will pretty quickly be able to understand the mapping structure.

One of the downsides to this approach is that it's esoteric. We must be familiar with the UA event model to make sense of it. On its own, it's actually not that clear.

A better approach would be to replace the event_action, event_label, and event_value parameter names with what they actually represent:

This is clearer. If we don't know the UA event structure, it's no problem. We can immediately understand what each parameter represents. If we do know the UA event structure, we can still map it to the old model; but having that knowledge isn't imperative anymore.

A third approach would be to use a more granular event name. Here we're departing from the one-to-one relationship with the old UA model to really take advantage of the greater flexibility introduced by GA4 properties.

When you get into downstream reporting (more on that later), you'll find that having a single event, videos, to describe such a vast array of possible user interactions is too limiting.

• Somebody clicks the play button? Send a videos event.
• Somebody clicks the pause button? Send another videos event.

And so on. We want our event structure to make immediately clear the event that transpired; so far we haven't accomplished that yet with our one-to-one UA to GA4 mapping exercise.

So, in our third approach, we may elevate the user action to the event name itself:

And so on. This approach is, in fact, Google's recommended naming convention for video engagement events. This granularity gives us the tools we need to measure these user journeys and report on them in meaningful ways.

Increasingly we're finding ourselves leaning toward a granular naming convention; we think it will emerge as a best practice.

Google Analytics 4's Data Collection Limits Are Helpful for Establishing Structure

You might be thinking, OK, granularity is better, so why not make the event name virtually interminable? For instance, why stop at video_start? Why not give a unique event name for each video (e.g. video_start_getting_started_with_the_google_analytics_4_property)?

The question is a bit facetious; making events too granular would make analysis unwieldy. It would be hard to imagine an analysis that would be unlocked by the above-described, excessively long event name that we couldn't perform with the more elegant recommended naming convention described in the previous section.

Indeterminate event names won't necessarily break the user interface, but they will make it virtually impossible to see the full name of the event:

In the screenshot above, the event name gets cut off in a dropdown menu in the interface.

Also, GA4's data collection limits help us manage the size of the network requests that get sent, as well as the size of the event that we're paying to store in BigQuery (provided you've enabled the BigQuery integration and are storing data).

All this is to say, be mindful of the GA4 data collection limits, especially character limits, when mapping your GA4 event schema. For example, if you're working in a spreadsheet to define your parameters, you might want to add data validation rules to ensure you adhere to the limits.

One more note on data collection limits: the screenshot above features an event called 3+_hat_pageview. Event names must be alphanumeric characters or underscores only and they must start only with an alphabetic character. You can see that in this demonstration, we're breaking the rules by starting the name with a number and including a + sign but nothing bad happens. We wouldn't recommend relying on the non-enforcement of a rule for your data collection. The rule could be enforced at any time and something may break. By following the rules, you future-proof your solution design.

It feels weird to characterize the practice of following the rules as a "best" practice (it should be the only practice), so we're calling it a consideration instead. Consider data collection limits when you name events.

Analysis Hub Sampling Favours Granular Event Names

The Analysis Hub is one of our favourite features available in GA4 properties. Its drag-and-drop interface allows you to build insightful visualizations on the fly. Those familiar with Adobe Analysis Workspace will feel right at home.

Unlike standard reports in GA4 properties, which present data from tables that Google has already aggregated, Analysis reports are not aggregated before the query is made. Whereas standard reports are based on 100 percent of the available data, Analysis reports may apply sampling when the size of the query exceeds your quota.

The quota for free GA4 properties is 10 million events per query.

In practice, we’ve seen queries with more than 10 million events avoid sampling. For example, here we have an Analysis report with the following configuration:

Notice in this report, that we have more than 10 million events in this query and yet no sampling is applied (see the green icon in the top-right corner).

If additional dimensions are added to the report, the event count doesn’t change but sampling kicks in. For example, when we add an extra dimension to the report, we get sampling.

Notice the green icon has turned yellow and the notification indicates we’re working with less than 100 percent of the available data:

You can see that the complexity of the query impacts whether sampling is applied. With an elegant naming convention, we can minimize query complexity and avoid sampling.

We've found that more granular event names lend themselves to more elegant queries; regardless of whether this tendency is universally true, we recommend considering downstream sampling implications as you devise your event schema.

As an aside, it's also been our experience that queries with fewer dimensions applied seem to run faster. We haven't done any extensive testing to verify whether that's always the case but the speed of the query's execution is worth noting as a consideration for your event schema.

Design Features of Cohort and Path Analysis Techniques Carry Limitations

Some analyses are easier to create with more granular event names; notably, the cohort analysis and path analysis techniques.

Suppose, for example, that we're interested in creating a cohort analysis that includes users who viewed our Services web page and we want the report to feature return criteria for any conversion.

Our first instinct might be to create the report with a configuration that resembles the following setup:

Unfortunately, we can't add conditional criteria when defining inclusion and return criteria, and there is no way to filter the cohort report:

Instead, we would need to fire a separate event on the /services page, and use that event in our cohort inclusion criteria:

In this instance, additional granularity in the event name makes it easier for us to use the cohort analysis.

The granularity also comes in handy when we're creating a path analysis. Here, you can see we're able to choose an event name or a page title as a starting point; we can't choose a specific event name/page title combination. That's where a more granular event (e.g. page_view_services) comes in handy.

An aside, the ability to add and modify events directly in the interface is a great way for us to collect these types of more specific events without having to re-tag the app or website. More on that later.

Marking Events as Conversions Is Easier but Requires More Forethought

Of course, we wouldn't want to fire a uniquely named event for every page of the website because that would become unmanageable (if not impossible, depending on the number of pages). Instead, we would only want this degree of granularity for events that are especially important to our business. We want more granularity for events marked as conversions.

In UA properties, we had a greater degree of control over how we defined an event goal completion. For instance, we might collect an event:

In the UA Behavior reports, we would be able to see all of the events where a video was completed. From a conversion perspective, we might only care about when our video called "Product Demo Sales Video" was completed. 

In UA properties, we would set a goal completion when the following criteria were met:

In other words, in UA properties, we don't need to send a separate event for the goal completion; defining the goal completion would recognize that a session contained a hit that met our goal completion criteria and we now have an additional metric to be used in reports. No new hit required.

In GA4 properties, conversions are indicated by a true/undefined flag using a dimension Is conversion event. We need to send a separate event and then mark that event as a conversion.

In the above scenario, we would have an event called video_complete which would be carrying a parameter for video_title with a range of possible values, including Product Demo Sales Video. We would have a separate event for the conversion, possibly called something like video_complete_conv carrying the same parameters; but this one would fire only when video_title matches exactly Product Demo Sales Video.

In the Events > Conversions section of the GA4 interface, we would toggle the "is conversion event" flag to the "on" position for the video_complete_conv event.

As you think about your event schema, consider whether a subset of parameters need to be counted as conversions, and create a separate conversion event for those name/parameter combinations accordingly.

You Can Create and Modify Events Directly in the Interface

If everything we've discussed sounds like a lot to consider, that's because it is.

But don't fret! You have some space to learn and adjust. Even if you don't have a perfect schema at the outset, your schema can evolve and you can make enhancements to your data collection over time.

GA4 properties offer the ability to create and modify events directly in the user interface. For instance, suppose our initial data collection accounted for the page_view event but we did not foresee the need for an additional page_view_services event. We can either ask our developers to add a tag to the /services page, or we can create a new tag in Google Tag Manager, or we can create the event directly from the interface.

From the Events > All Events section, click Create Event. Here, we can automatically trigger a new event when an existing event matching specific criteria is sent.

Configure the criteria for when this event should be triggered. For instance, we may want to send page_view_services when the page_view event is sent and carries /services in the page_location parameter:

Once you click Create, the event will be collected moving forward. Note that the feature does not apply retroactively; the event will only begin to appear in reports starting on the date that you created it.

In addition to creating events in the interface, we have the ability to modify them. Some example use cases for modifying events include rewriting an event name, rewriting a parameter, and adding or removing a parameter from an existing event.

Charles Farina and Krista Seiden both expand on these features. See Charles's post, Modify Events – Google Analytics 4, and Krista's post, Modifying Events in the GA4 User Interface, for step-by-step instructions for modifying events.

As you create and modify events in the interface, keep in mind some limitations:

• Modifications and custom events don't apply to historical data
• You can create up to 50 modifications to existing events and up to 50 custom events
• Modifications require time (generally minutes but possibly longer) before taking effect
• Modifications are executed client-side before data is sent to Analytics for processing

We would also recommend, for events created in the GA4 interface, that you add a parameter or use an existing parameter to help you identify where the event was created. It will be useful for troubleshooting.

For example, if you're not sending a parameter to indicate the event's collection source, you could add a parameter for data_source and send the value ga4ui (which would stand for Google Analytics 4 User Interface). If you're already sending a similar parameter—for example, gtm_tag_name—you could repurpose this parameter by sending a value like ga4ui, adding the parameter to the newly created event.

Repurposing an existing parameter would be especially useful if you’re at or near the 25 params per event limitation.

If you find yourself creating a report in the Analysis Hub and you realize your event schema is too restrictive for the analysis you're looking to create, just add the necessary events from the interface and you’ll be OK moving forward.

Additional Resources

There's a lot to consider when you're mapping your Universal Analytics events to the Google Analytics 4 data model. We recommend checking out some of the additional resources below.

Key Google Resources

• Universal Analytics versus Google Analytics 4 data
• How to instrument Universal Analytics events as Google Analytics 4 events

Key Bounteous Blog Resources

• Google Analytics 4 Properties: Everything You Need to Know
• How to Implement Google Analytics 4 Properties on Your Website & Mobile App
• Explore Depths of Your Data in Google Analytics 4 Properties' Analysis Tools
• Get the Most Out of Your Reporting with Google Analytics 4 Properties
• Ultimate Guide to Querying Google Analytics 4 Properties or Firebase Data in BigQuery