Regardless of the nomenclature you choose, the most important factor is that all events consistently follow it.

👩‍💻 How to name an event

Structure

Clear event names are descriptive and denote what is occurring. For clarity about when the event triggers we recommend: 

  1. an object/noun (e.g. Song) 
  2. followed by an action a user performs on that object (e.g. Played, Paused) to construct events like "Song Played" or "Song Paused". Past-tense verbs minimizes any confusion. 
  3. preceded by a category to clarify where this action happens (e.g. Homepage, Playlist page) to construct events like "Homepage Song Played". This structure makes events easy to search and enhances your discoverability. If you don't know what events are in the homepage, you can simply type “homepage” and see every event that falls under that category.

Syntax

Consistency in your naming means that all events share the same syntax. The main syntaxes are:

  • snake_case
  • camelCase
  • Title Case

If you do not have your own standard syntax in naming data, we recommend snake_case (e.g. homepage_song_played). All lowercase removes the possibility of casing instrumentation errors.

You should also take into consideration the length of your names, concise event names will make data much more readable and easy to understand.

👮 Enforce the schema

All of this is a waste of time if there is no process to ensure that the naming convention is known internally. The best way to do this is to make sure it is visible or shared internally. 

June does this by making your event names visible at a glance, making it easy to understand and copy the format for anyone in your organisation.

📚 Other resources

Tracking conventions recommended by others:


Did this answer your question?