Defining analytic events — how to approach the challenge of naming convention and structure

Published in

Melio’s R&D blog

8 min readJun 7, 2023

Introduction

Imagine this: You launched a new feature in your product — one you believe will be a game changer for your company and will drive conversion. It’s been live for two weeks and you want to know how your users have interacted with it, and how it has affected their behavior in the product. To do this, you need to have analytic events that represent the user experience and the user’s actions in the product. That is, the user’s interactions should trigger events with the relevant information on this trigger.

What we monitor about user behavior and how we formulate that data is important, and it’s a challenge every data-driven company faces. We want to be able to accurately depict the user journey, understand it, analyze it in bulk, and derive insights that can help make our product better.

Having an event naming convention helps us organize the data we collect from user interactions, creates a common language in the company for that data, and helps different stakeholders (analysts, product managers, developers, etc.) know how to approach the product assessment process. Choosing the right naming convention and structure for your company can be challenging, but in this article I’ll give you tools to help define the best solution for you.

Considerations and challenges

Analytic events generally consist of event names and event properties. This can range from having all of the context in the event name and a minimal number of properties to having minimal context in the event name and most of the context in the event properties.

For example, you can define an event for a click on a specific category in your website navigation, it could be any (or none) of the following:

HomePage_Navigation_ItemCategory_Appliances_Click
HomePage_Navigation_Click and put other info in the properties
HomePage_Click and put other info in the properties
Navigation_Click and put other info in the properties
Any other combination of information between the event name and properties

But with that freedom comes a lot of confusion. There is no one method that fits all companies and no method without its trade-offs. There are a lot of possibilities for event names and the division of information between the name and the properties it can make it difficult to formulate a system. You’ll need guidelines to navigate through the process easier.

Although there are differences in needs for different companies and products, there are some characteristics that you should always take into account when you create analytic events conventions:

Representativeness — when using this method can you represent a variety of user actions and experiences in your product? Can it provide the information you need in order to reflect the context experienced by the users and their journey?
Consistency — will it allow and promote consistency when defining new events, by different creators (other analysts, other product teams in the company)? How easy will it be to create new events and follow this method?
Room for growth (scalability) — Will this fit planned and unplanned growth, such as new features, new products, new partnerships or growth in active users in the company’s future?
Exploration — How easy will it be to explore the data we collected and derive relevant insights?
Data consumption tools — As some tools have limitations in regards to the amount of unique event names, some are not good at filtering properties, consider whether the naming convention is a good fit for the tool you would use to consume the data.

Approaching the structure challenge

Golden tip: Avoid overloading the event name with information that can be a property, as it makes it harder to combine related actions and build funnels. Keep your event names clean and relevant for your common analysis, and don’t be afraid to add properties instead.

The starting point should be identifying what are the main use cases for analysis in your company and the common point of view for analysis, so that the naming convention will address these needs. Let’s say you work at Google, and your company has multiple products- such as Google Search, YouTube, Waze and Gmail. Consider how you would usually analyze users’ product activity-

From a high level point of view, how the users interact across the different company products as an overall user journey analysis.
From a product point of view, how users interact with the different features within Youtube.
From a flow point of view, how users go from searching an address in Waze to completing a drive from point A to point B.
From a specific object point of view, how users interact with the search feature in Gmail vs. Google Search vs. YouTube vs. Waze?

These are common examples, but your company might have other perspectives you use for analysis, such as analysis from the point of view of partnerships, medium (app vs. online), or other considerations that are relevant to how your company works.

Once you identify your main use cases, you can identify what is the most common scope that represents the point of view you are trying to capture, and that would be the basis of your event structure.

My recommended structure for events would include 2 levels of scopes at the most, together with indication of the high level action (e.g. View, Click):

[First level scope]_[Secondary level scope]_[Action]

[Scope]_[Action]

The scope can be one of the examples above, such as flow/product/object, or any segmentation that makes sense for your company. When you know what is the scope of your events, it’s easier to search and explore the data you collected, build funnels, and analyze the product activity.

All other details go into the properties, such as indication of step in the flow, additional information on what the customer saw (such as version or A/B test indication), the specific intent of the action taken by the user, and any additional context that is needed about the experience.

By applying the above examples, we can decide that the first scope would be the product, and the second scope would be a product area. Thus an event can be Gmail_Inbox_View, and in the properties we can put additional context- such as which tab of the inbox is open, how many emails were presented, whether or not this is a corporate or a private user and more. On the other hand, we might care more about a specific feature across different products. Then we might consider having a scope of a feature, such as Search_View, adding in the properties that it was viewed in the product Gmail etc.

When choosing the scope and structure, remember your guiding question should be– does this structure/convention make my most common analysis use case easy, while allowing the less common use cases to be also analyzed with some additional steps.

Don’t forget about formatting

Structure of event names and allocation between event name and properties is not enough to create clean and consistent analytic convention. Make sure you address and define the following:

Choose a single type of separator between the different parts of the event. It can be a dash, underscore, colon, space or anything that works for you, but make sure you’re consistent. This will prevent mistakes and will make for an easier search.
Use formatting for string structure. I recommend using Pascal Case (the first letter of each word is always capitalized), as it makes it easier to read, compared to having all the letters lowercase/uppercase or using camel case (the first letter is capitalized only from the second word and onward.
Decide on phrasing and language rules. For example, use present tense in your events names, properties and values. Avoid using abbreviations as this may cause confusion and gaps.
When naming scopes and properties use the commonly used terminology/naming in your company, so that each person who reviews or searches for the data will understand what it means without additional reference or assistance.
Decide on a set of possible actions for the event name, to make sure that there aren’t variances, for example “select” vs. “choose” vs. “click” can all be used for a click event, but you want to use the same one across different click events.
Consider creating a stack of default properties that are relevant for all the user interactions in the product, such as the device used to access your product (mobile/desktop/tablet), user identifiers and more.

Golden tip: Add a property of “cta” (call to action) on all click events that captures the text on the button — to always know what the customer saw when clicking, regardless of the action the button initiates.

Data governance

Even when you have a good structured analytic naming convention, as companies grow, it can be difficult to make sure every team adheres to the convention. The best way to avoid these issues is to complement the analytics convention with a data governance process.

As part of your data governance process I suggest using at least one of the following methods:

Create an analytics automation that inserts the correct and relevant scope, object, properties and values as default, and adding unique/additional properties only for unique interactions that are not covered by your default. That automation can be part of the code, an analytics dispatcher, an analytics micro-service or even a third party tool. When the creation of the event automatically structures the data — it’s easier to remain consistent across the company.
Create a glossary of scopes, actions, properties & values that are the only ones that can be used to build a new event. That glossary should have gatekeepers that can edit the list or add missing items, and make sure that any new item would be consistent with the convention.

Together with the analytics convention you can create a clean, consistent and easy-to-work-with product data.

Summary

Having the guidelines and a list of considerations to account for can make the process of creating event naming conventions much simpler. Defining the right convention and structure for your company will help you better understand the product and improve it.

To sum it all up, here are the 4 steps to get your events structured and easier to work with:

Understand the common use case for analysis in your company.
Define the scope and structure of naming conventions accordingly.
Define the rules for formatting the events and the properties.
Complement the analytics convention with a data governance process.