Simple Event Naming Conventions for Product Analytics

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.

Present: submit, create, view
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: