Template for event-scoped parameters in Google Analytics 4 (GA4)

UPDATE:

Thanks to the feedback from the lovely folks at #measure. I’ve now added a couple more points to this post. Would love to hear your thoughts as well so leave a comment down below or message me on LinkedIn.

If you have not joined the community of analysts at #measure, don’t be silly and join here.

With the sunsetting of Google Analytics’s (GA) Universal Analytics, many may find themselves stuck without GA’s simple, yet restrictive event parameters; event category, action, label and value.

If that’s you, here’s a an update to my 2018 guide on structuring event values in Google Analytics. Now that we have 50 event-scoped custom dimensions (on standard) to play with and very little guidance from Google other than a scanty list of recommended events, it’s time to discuss how you can make the most of event tracking without getting lost.

This guide is for you …

…if you have events that do not fall under the list of the recommended events. For example, you may want to track an internal link on a page especially when there are two on a page that have the same link to discover which link performed better based on their position on the page. How would you go about naming the event parameters or the event itself?

Before you read any further…

There is a wonderful guide on Consolidating Event Names & Event Parameters which makes for a great pre-read and forms the guiding principle for how we are structuring events and parameters.

Here’s yet another on naming conventions for clean data from Segment.

This guide focuses on how that will build on the principle of consolidating event names and parameters so that you can start to have a template for your site’s data layers or GA4 event tags from day one.

The example

In this article, we will use a scenario of a custom event that will be setup to track what product colours or options did a user select before adding to cart? This could be worth comparing to give an idea of which options didn’t make the cut.

Image Credit

Unfortunately, planning for the event name would be difficult as it’s not currently in the list.

So how would we structure the event and parameters? What are some guidelines? How can we structure the event so that we do not use up the custom dimensions quota?

Here are some ideas to kick you off.

Best practice

When thinking of a name for the event or its parameter, it is best to:

• Use an action or a verb for the event name — Almost all of Google Analytics’ native events has a user action like view, click or add in its name. It makes sense to stick to the plan and stay away from events that are purely a noun like “carousel” or “button”.
• Keep it lowercase — Event names are case sensitive so keeping it all lower case would help maintain consistency with the other automatically collected or enhanced measurement events.
• Use underscores (_) to separate between words instead of spaces — Again, to maintain consistency, be sure to use underscores.
• Check the reserved list — Google Analytics has a list of event names and parameter names that are in use so stay away from these names.
• Check the list of recommended events and parameters — Check Google’s recommendations for some ideas — some of them DO appear as staples in Explore and Looker Studio reports (esp. Ecommerce parameters).

Event name

For this scenario, we will use page_interactions. This allows for the event name to be used for any page on the site. So rather than having, product_page_interactions or checkout_page_interactions cluttering the event list, we can use one event name to denote interactions on a page that do not fall under the other events.

It may be easier to have it broken down into the different types of pages but that will be entirely up to you.

Event parameters

When deciding what parameters to track, think of the end goal. What business questions would you like to answer? In this scenario, we would need to know

• How did the user perform the action? Was it through a click or typing in a value?
• Which step of the funnel did the user perform this action? This would be useful to compare how many interactions a user took through the funnel.
• What value did the user choose in the colour picker or size option?
• Where were these options located on the page? This may be useful if you’re running an A/B test to determine whether the location matters.
• How was the value displayed? Was it through a button or a link?

By running through these questions, we can arrive at a preliminary list of things we’d like to track.

This can then be broken down into the kind of data we’d like to collect:

• Interaction type
• Funnel stage — this can be page type as well for non e-commerce sites
• Name of the module on the page
• The type of module — this can be useful to group modules that have a display type e.g. button, link,
• Location of the module
• Value that was chosen by the user

You can fortunately use these parameters and questions for most of the “modules” on the site whether it’s the product options or product reviews.

When they are laid out, you can easily plan out what the values are for the different interactions.

A visual example

Here are two examples of how it’ll play out. You can see that because there is a standardised template between both interactions, it is easy to see the difference and when you’re reporting, you can filter based on the module name or type to determine which modules are interacted with the most.

1 event name, 6 event parameters that are consistent for different interactions. Values are different for 3 parameters.

The parameters below can be used for virtually any interaction on a website.

• interaction_type
• funnel_stage or page_type
• module_name
• module_type
• module_location
• event_value

You can optionally add

• event_detail — for when the interaction is with an internal link and you need to capture the URL or page path
• event_conversion_value — for when you’d like to assign a monetary value to the action

Other examples/interactions

Additionally, you can break down the interaction groups/event names into other areas to distinguish them from page interactions:

• menu_interactions — for interactions with the header or footer menus
• search_interactions — for interactions with the search filters
• form_interaction — for capturing specific form actions like hovering over a form info

Here are how it will pan out with the standardised parameters:

What do you think?

If you appreciated this template or have feedback on how we can improve this to be a common standard, let me know in the comments or connect with me on LinkedIn.