Everyone is excited to get data into Amplitude and start building charts. But in the rush to get answers, it’s easy to overlook the single most important step: designing your event taxonomy.
A poorly planned event taxonomy leads to messy, inconsistent, and unreliable data. Taking the time to build a solid foundation is the key to trustworthy analytics that can confidently drive business decisions. This guide will walk you through the two core principles for designing a robust and scalable event taxonomy.
The Foundation: Your Data’s Rulebook
A successful event taxonomy is built on a clear, documented set of rules that your entire team agrees on. This ensures that as your company grows and new team members join, your data remains consistent and easy to understand. There are two main pillars to this rulebook:
- Naming Conventions: What you call your events.
- Syntax: How you format the names of your events.
Pillar 1: Naming Conventions – The Object-Action Framework
The most crucial rule is to establish a consistent pattern for naming every event you track. A simple but powerful framework for this is Object-Action.
- Object: The noun, or the “thing” a user interacts with.
- Action: The verb, or what the user does to the object.
For example, if a user plays a song:
- The Object is the Song.
- The Action is Played.
- The final event name becomes Song Played.
This simple framework can be applied to almost any user interaction:
| Object | Action | Event Name |
| Button | Clicked | Button Clicked |
| Order | Completed | Order Completed |
| Checkout | Initiated | Checkout Initiated |
| Sign Up | Completed | Sign Up Completed |
Why is this so important?
Without a rule, one developer might track Song Played while another tracks Play Song. While they mean the same thing, Amplitude sees them as two completely separate events. This creates duplicate, confusing data and makes accurate analysis impossible.
By enforcing the Object-Action framework, you create a predictable, scalable system that everyone in the company can easily follow.
Pro Tip: Use the Past Tense
It is a strong best practice to use the past tense for your actions (e.g., “Played,” “Clicked,” “Completed”). This clearly signifies that the event is a record of an action that has already successfully occurred.
Pillar 2: Syntax – Keep Your Formatting Consistent
Syntax is about the formatting style you use for your event names. While the choice of style is less important than having a naming convention, being consistent is critical.
The two most common styles are:
- PascalCase (or Capitalized Case): Each word is capitalized and joined together.
- SongPlayed
- FormCompleted
- snake_case: All words are lowercase and separated by an underscore.
- song_played
- form_completed
Which one should you choose? It doesn’t really matter. Pick the one your developers are most comfortable with. The only rule is to pick one style and stick with it across all events.
The final step is to document your decisions.
Create a simple document in your company’s knowledge base that clearly defines your event taxonomy rules. This document should be the first place anyone looks before implementing a new event. It ensures everyone—from product managers to new developers—is aligned, preventing data discrepancies before they happen and building a foundation for clean, trustworthy analytics.