naming your events and parameters

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.

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

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.
    page_view code block
  2. 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 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 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, 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 “All 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, when a user submits a lead form on a website, you may have previously tracked this with a “destination goal”, that allows 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 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:

  1. The business requirements or questions that you are solving with Google Analytics.
  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.
  3. Instructions for testing that your data is setting properly.
  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 “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”).

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.

8 Replies to “5 Best Practices for Creating Your Events and Parameters in Google Analytics 4”

  1. Hi Ken, is there any where I can find out what Values should I put under Event Name > Event Parameters > Parameter Name AND this —> Value?

    Event Name: Purchase
    Parameter name: “items”
    Value: what should I put?

    Another example”
    Event Name: Purchase
    Parameter name: “value”
    Value: what should this field be input as?

    Thank you!

  2. Thank you so much for this tutorial! I was looking at all internet about this type of explanation. A question, what is the meaning of a parameter, and could you give me an example for an app with GA4?

    You earn a new follower for sure!

    Thanks a lot

    1. Glad you’re enjoying the blog Rocio. A parameter is used to describe or give context to an event. For example, if you would like to know how frequently users tap several buttons in your app, you might fire an event on each button tap with the name “button_tap” and create a parameter to capture the text of the button.

  3. Hey, thanks for the explanation. However I have an issue that maybe you can help me with. Right now I have a GTM tag that triggers when people scroll on 10%, 20%, 50% and 70% of each the page. On the Real time report it shows the “parameter value” and I can see how many people did the 10%, 20%, 50% and 70%, but when I go to Events I can’t manage to show the parameters value. Can you help me with this? Thanks!

      1. Hi Ken! Thanks for this.

        I’m wondering if this means the parameter cannot be dynamic. I have a file upload that could fail, and I have an event set like `gtag(‘upload-fail’, { file: filename })`. I too can only see the parameters on the real time report. Is there no way for me to see a report of failed uploads? I also have a similar event for location hash changes, which I also set to a variable: `gtag(‘hash-change’, { hash: window.location.hash } )`.

        Thanks for your help!

        1. Ben – The value of your parameter can be dynamic, but the key cannot. So, for your “upload-fail” event, you can create a parameter called “file” and set it as a custom dimension. Then, 24 hours later you should have the option to pull this in an exploration report.

Leave a Reply

Your email address will not be published.