5 Best Practices for Creating Your Events and Parameters in Google Analytics 4

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.

• Update: Nov 13, 2020

  This post has been updated with the release of Event Editing.

• Update: March 24, 2023

  Migrated to new CMS. Updated images and a few instructions.

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. This often included clicks, impressions, form submits, errors, etc. When you created events in the past, you typically added three dimensions to describe the event: “category”, “action” and “label”. If you had additional context about the event to pass you could choose to use the “value” parameter or add custom dimensions/metrics.

• 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, because the concept of a "hit type" has been removed. All data is collected with events (and multiple events may be included in a hit), 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 “Configure > 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.

Best Practices to Avoid Common Mistakes

Okay, 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:

1. 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.

2. It is important to set yourself up to gain access to features and integrations that are released as the product is expanded. It’s also 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 Event Editing 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 Google Analytics 4. 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, to track a conversion you will either create a tag to fire a unique event name for your conversion event, or click the "Create event" button from the "Admin > Property Settings > Events" report to use Event Editing.

Event Editing allows you to modify the parameters of an existing event (which is useful for correcting typos), or to create a synthetic event on the backend when certain conditions are met.

For example, you may have previously tracked when a user submits a lead form with a "destination" goal. This allowed you to count how frequently a page loaded with a value in the URL (such as "/thank-you.html"). In GA4, you would not want to mark your "page_view" event as a conversion, so instead you will want to create a synthetic event with a name like “lead_submitted” to fire when the thank you page loads, and then mark this new synthetic event as a conversion.

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 GA4 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 135 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:

1. The business requirements or questions that you are solving with Google Analytics (ex. "Are users submitting the lead form?").
2. 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 (ex. "form_submit").
3. Instructions for testing that your data is setting properly (ex. "Go to www.test.com and submit the lead form").
4. (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 "Admin > Property Settings > Events" report and click the three dots next to any event to see the option "Mark as NPA" (which stands for “no personalized ads”).

Next Steps

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.