Property Naming Conventions Guide for Product Analytics

Just like it’s important to establish naming conventions for your events, you should do the same with properties. Without clear guidelines, analyzing your data can quickly become confusing and difficult.

And if it already has… It’s still not too late to bring some order into chaos. You can start applying new rules moving forward, and gradually see them bear fruit.

Once you’ve decided on the exact principles, you and your colleagues should stick with them to avoid any further confusion about the changes in your naming conventions.

First, we’ll define properties, and then jump into the checklist of everything you need to know about naming them appropriately.

User Properties vs. Event Properties

User properties describe and give context to a user performing an event. They can include, for example, name, location, email address, or acquisition source.

Event properties describe and give context to the event being performed.

Within a session, there can be multiple different events performed with varying event properties, but what stays the same is the list of user properties, because the same person is doing different activities.

‍Example: Imagine a user named Jane logs into an online store for electronics, adds a phone to her cart, and then adds a phone case as an accessory.

As you can see in the table, the user property userName (Jane) stays the same for all events.

On the contrary, the event properties (such as itemCategory) change according to which event they’re describing.

(1) Placement

Before getting into the naming convention details, you need to decide whether to place your properties in the event name or in the actual property field.

Here’s what to take into consideration before making that choice.

Option 1: Adding Information to Event Names

In this approach, you create detailed event names that include specific contextual information.

Example

As an admin, you want to remove access from certain people in your workspace. The types of people whose access can be changed include guest and member.

Here’s how you might structure events:

settings:people:remove___guest
settings:people:remove___member

(In this example, we separated the property from the event name with three underscores (___), but this is not the only way to do it.)

Note: It’s preferable to add the property name either at the very beginning or end of the event name. This makes searching for specific events easier, especially in analytics tools with basic search functionality. When searching for something specific, you often want to see the full list of similar events first and then narrow down your search. Placing the key term at the beginning or end ensures all related events appear together in your search results.

What this means

Each event name provides clear and concise information about the specific action performed, possibly making it easier for everyone to understand the data at a quick glance.
Queries are simple because the context is built into the event name itself.

When to use this approach

Your analytics tool easily groups and manages multiple event names under a common feature.
You want quick and straightforward queries without having to filter by properties.
You need flexibility to easily track different properties depending on the nuances of the action.
- This could include variations based on the action's outcome (e.g., success or failure of a form submission) or the context where it happens (e.g., a button click on the homepage vs. a product page). Using separate event names allows you to easily associate different properties with each context.

Trade-off

Too many detailed event names can become overwhelming and harder to manage.
Adding new events means creating new names, which can easily lead to inconsistencies over time.

Option 2: Using Event Properties for Context

In this approach, you use generic event names and describe the context using event properties.

Example

For the same action of removing workspace access, you could use a single event name and add the details as properties separately:

Event Name: settings:people:remove

Event Property: peopleType: “guest” or peopleType: “member”

What this means

The event name is concise and reusable across different contexts.
Contextual details are stored in separate properties (peopleType in this case), allowing for flexible filtering and analysis of the data.

When to use this approach

Your analytics tool makes it easier to group and filter events using properties.
You need a scalable structure that avoids creating too many event names.

Trade-off

Queries may require more steps, as you’ll need to filter events by their properties to get the desired results.

(2) Casing

Being consistent in the way you write property names helps reduce confusion. Once again: when you choose a method, stick with it.

Here are the most common options:

camelCase — userAge
snake_case — user_age
PascalCase — UserAge
kebab-case — user-age

‍

Avoid using the same casing for both event and property names if possible.

We recommend snake_case for events and camelCase for properties.

(3) Structure

Properties complement event names by adding context. To keep them organized and queryable, use a consistent pattern in the structure.

objectAdjective
- Use this for descriptive properties tied to the event.
- Examples:
Use is/has prefix for boolean values
- Use prefixes like is or has to clearly label properties with true/false values.
- Examples:
Include Date or Timestamp for date values
- Properties with date or time values should include clear suffixes.
- Examples:

(4) Avoid Redundancy

Ensure your properties provide additional context without duplicating information from the event name.

Example of redundancy:

Event Name: FeedbackForm:submitButton:click
Property: action: "click"

Instead, use properties to describe unique details about the event:

Event Name: button:click
Properties:

buttonName: "submit"
buttonColor: "orange"

(5) Use Generic, Reusable Names

Properties should be flexible and reusable across different events. Avoid names that are too specific to a single event. Otherwise you’ll be flooded with too much redundant information that all looks the same.

Bad example:

❌ signupButtonColor: Only applies to the signup button.

Good example:

✅ buttonColor: Can be used across multiple events for signup buttons, checkout buttons, etc.

(6) Keep It Short and Descriptive

Use concise, meaningful names that describe the property’s purpose. Avoid unnecessary words or vague descriptions.

Too much information starts to become confusing and time consuming very quickly. The shorter and simpler you can make it, the better.

Examples:

❌ numberOfItemsInTheCart → Too long and redundant.
✅ itemCount → Clear and concise.

(7) Establish a Documentation Process

This one is for those who are meticulous about organizing their product analytics data.

As your product evolves and your tracking implementation grows, maintaining clarity and consistency becomes more and more important. To prevent inconsistencies, maintain a tracking plan or data dictionary documenting all event and property names.

Include:
- Name: The exact event or property name.
- Purpose: What it tracks or describes.
- Format: The data type (e.g., string, boolean, timestamp).

Example Documentation:

By documenting your naming conventions, you ensure clarity for your entire team and reduce the risk of errors.

Conclusion

Establishing clear and consistent naming conventions for your properties makes understanding and managing all your product data easier and faster.

Remember to choose a naming style that suits your needs and stick with it consistently.

If you already have lots of old, disorganized data, there’s no need to worry too much. You can still create new rules, communicate with others about them, and start making small changes. As you keep making new changes, slowly the whole system can become more organized.