How to Structure Event Names

Naming conventions for the events you track or tag sounds simple in principle. However, over time this can become an issue if there was never a system put in place for how your events are named. Let's say you track somewhere between 75 and 150 events across your entire website or app, how do you know what to call each event to make sure it is sensical in your downstream tools? In my career, I've seen some hideous naming conventions that you'd need to reference a glossary anytime you did an analytics pull. This is what we want to avoid. On the other side of the coin, I've seen analyst get trigger happy on naming events too specifically so, in the end, they had hundreds of events you had to sort through to figure out which was which. You may now start to see the writing on the wall as to why naming conventions are so important.

There are two principles to keep in mind when you set out to create your event tracking spec to make everyone's lives easier. That is to generalize your event names and rely on adding extra properties to the payload. Then to use a consistent naming convention. I cover both of these in detail below.

1 - Events & Properties

At the end of the day, you are going to pull data on events and you want to make sure you are capturing conversions for a given email form submit on a specific page vs. only being able to capture all email form submits across the site as your only option. In your analytics tool if you have an event that is let's say Email Form Submit that fires in 4 different places on your website you should distinguish the event on all 4 pages as distinct events because you should be able to segment based on page event data. Another example would be menu navigation. Let's say you have a main menu with 15 navigation options. The question arises, do we have an event for each click (creating 15 events) or one event with a property for the specific link they clicked on? 

The point is to try and use a combination of simple events and the use of properties to limit the number of events you create. Let's look at event spec I created for an e-commerce client of mine in the table below.

You can see in column C the more generalized event names and then in column D the property names. When you use these combinations you can still see in your downstream analytics all these events through the use of filtering and segmentation without having to create hundreds of unique events for every single scenario. The engineers who implement this tracking spec will appreciate this approach as well. 

If you are interested in using this tracking spec spreadsheet you can download it on my tools page here.

track-spec

2 - Naming Conventions

The typical naming convention I use follows these 3 frameworks:

Object Action

Making sense of the event data in terms of the object the user is interacting with (CTA, Top Nav, Footer, Hero Image, etc.) and what their action on that object is (Click, Submit, Select, Play, Pause, etc.)

English Language

Making sense of the event data in logical, sequenced and consistent terms. So ensuring your naming convention is easy to understand by an outsider quickly, the order in which you define events and keeping a list of defined terms to describe your website that is scalable will help you.

Programmatically Generated

CTAs, buttons, copy changes frequently on websites. So it is important to have the engineers creating a tagging mechanism that is programmatically generated.