By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Preferences
Product Management

Simple Event Naming Conventions for Product Analytics

Published
November 13, 2024
Read time
5
Min Read
Last updated
November 13, 2024
Jenna Pitkälä
Simple Event Naming Conventions for Product Analytics
Table of contents
Share article:

To reduce everyone’s mental load and avoid confusion when analyzing product data, it’s important to establish some sort of naming conventions for your events.

Once you’ve decided on the exact rules, you and your colleagues should stick with them. Many analytics platforms don’t allow you to rename events without losing historical data, so your initial choice often becomes permanent. It’s far better to invest time up front to define a system that works for everyone.

While it’s important to be clear, there’s no need to overdo it. Choose names that describe the action without being overly detailed. checkout:purchase_complete conveys the necessary information more effectively than checkout:cart_page_complete_purchase_with_promo_code.

If possible, add validation logic around analytics API calls to enforce your conventions, ensuring every event follows the established structure. This, along with clear documentation, provides a strong foundation for new developers to easily adopt and maintain best practices, keeping your data consistent and actionable over time.

examples of bad and better event naming with the search term "android". For example, compare "login_android" with "android_app:login:success"
Search result examples relating to your product’s Android mobile app. See the difference? In the latter, all events follow the same format.

Step 1: Casing

Paying attention to how you capitalize words might seem redundant, but it is important because…

  • It eliminates confusion: When casing is consistent, it's easier for anyone reading or analyzing the data to quickly understand event names
  • It reduces errors: Uniform casing reduces the likelihood of mistakes, such as duplicate or misinterpreted event names that occur when similar names have different casing.

Here are the five most common options:

  • snake_case — call_deleted
  • all lowercase — call deleted
  • camelCase — callDeleted
  • Sentence case — Call deleted
  • Proper Case — Call Deleted

We recommend…

  • using snake_case, i.e., call_deleted for event names, especially if you are exporting data to downstream processes like data warehouses or ETL pipelines. Many data processing tools and databases favor this casing style.
  • using different casing for event and property names: For example, use snake_case for event names (e.g., call_deleted) and camelCase for property names (e.g., userId). This differentiation helps distinguish between types, enhancing clarity when analyzing data.

Step 2: Verb Tense

You need to decide whether you’ll use the present or the past verb tense.

  1. Present: submit, create, view
  2. Past: submitted, created, viewed

People have different preferences, so below are pros and cons for both to help you make the decision.

1) Present Tense

Pros:

  • Indicates Real-Time Actions: Makes it clear that actions are occurring in the moment, aiding in active session tracking.
  • Aligns with Standard Naming Conventions: Many analytics tools and data platforms default to present tense, providing consistency with industry norms.
  • It’s Shorter: Why use more characters with the past tense when a shorter, more efficient form will do?

Cons:

  • Ambiguity for Completed Actions: Present tense may leave it unclear if an action is fully completed, which can be problematic for tracking processes with a definitive end state (e.g., distinguishing payment_process from a completed "payment").
  • Potential Confusion in Historical Analysis: Present tense can be less intuitive when reviewing past data, as it might read like actions are ongoing rather than completed.

2) Past Tense

Pros:

  • Clarifies Completed Actions: Makes it clear that an action was completed, which can reduce ambiguity in processes with completion requirements.
  • Feels Natural for Historical Analysis: When looking at event logs, past tense aligns with retrospective analysis, making it more intuitive for reviewing completed user journeys.

Cons:

  • Less Standard in Analytics Tools: Many industry practices and analytics platforms favor present tense, so using past tense may be inconsistent with these norms.
  • Can Create a Sense of Disconnection: For live or active sessions, past tense can make the data feel less immediate, which may be less helpful for interpreting real-time user behavior.

Step 3: Verb Vocabulary

You want to make a list of standardized, allowed verbs to use. When everyone’s on the same page about this, data is much easier to interpret across teams.

Choose verbs that describe the action as clearly and accurately as possible: For instance, use submit for form submissions and click for button interactions. For page loads, use view, not “visit”, “load”, etc.

Here are some commonly used verbs to get you started:

  • view
  • click
  • submit
  • create
  • add
  • delete
  • start
  • end
  • cancel
  • fail
  • send

Step 4: Structure

demonstrating how to build an event name with category, object and action and examples of each

For event names, we highly recommend the category:object:action framework. Here,

  • category refers to the context the event took place in – e.g., account_settings or android_app
  • object is a noun that describes the component or location the event took place in, like delete_account_button or pricing_page.
  • action is a verb that describes what was done, like click, view, or delete

When you keep the same order for each name, it’s easy to scroll through a list and find what you’re looking for: all the events related to the same theme are bundled together in alphabetical order.

So, for example, an event name would look like this:

account_settings:delete_account_button:click

Because category or object names might often consist of many words, it makes sense to use a colon after both of them. Just compare these two examples:

account_settings_delete_account_button_click

account_settings:delete_account_button:click

You see? It’s a lot easier to differentiate between category, object, and action in the latter example.

Q: Should I make event names longer, or add information in properties?

A: Depends on the product analytics tool you’re using. If the tool takes care of multiple different events and bundles them within a feature easily (to analyze feature performance), it might be easier to create more event names that are descriptive.

For example, if it’s possible to add a meeting summary to a folder (or collection) from two different pages (mycalls_view and notes_view), we can make different events for each location:

  • collections:add_to_collection_button_mycalls_view:click
  • collections:add_to_collection_button_notes_view:click

On the other hand, if your tool makes it inconvenient to have too many different events and instead focuses on fetching information from properties, it’s better to create fewer separate events and fill them with properties.

In this case, we’d only make one event:

  • collections:add_to_collection_button:click

and add the location (mycalls_view) as a property.

Q: Isn’t it bad to use colons in event names?

A: In programming, you might have been taught to always use either snake_case or camelCase for event names, so this is a valid concern.

However, product analytics tools (such as Segment, Amplitude, and Posthog) read event names as a string, so they don’t get confused by the colon.

In other words, it’s not a problem.

But if you are adamant about avoiding colons, we suggest you use double or triple underscore (__ or ___) to replace it.

Step 5: Avoid These

To avoid common errors (possibly while exporting data), do NOT use these characters in your event names:

  • blank spaces
  • . dot
  • < left angle bracket
  • right angle bracket
  • + plus sign
  • = equal sign
  • % percent
  • ! exclamation point
  • ? question mark
  • ` backtick
  • ' single quotes
  • " double quotes
  • $ dollar sign
  • & ampersand
  • * asterisk
  • hash
  • { left curly bracket
  • } right curly bracket
  • / forward slash
  • | pipe
  • \ back slash
  • @ at sign
  • emojis
Automatic quality online meeting notes
Try Wudpecker for free
Dashboard
Simple Event Naming Conventions for Product Analytics
Min Read
Simple Event Naming Conventions for Product Analytics
Min Read
Simple Event Naming Conventions for Product Analytics
Min Read