What is an Event Naming Convention?

Why Event Naming Conventions Matter

A naming convention is the single highest-leverage decision you make when setting up analytics. Every query, every dashboard filter, every segment definition depends on event names being predictable. When names are inconsistent, analysts waste time guessing whether the event they need is called sign_up, SignUp, user_registered, or registration_complete. Multiply that confusion across hundreds of events and dozens of team members, and the cost becomes significant.

Consistent naming also enables tooling and automation. Auto-complete in analytics platforms works better when names follow a pattern. Governance rules can flag violations automatically. Code generators can produce readable SDK methods from predictable event names. Without a convention, each of these workflows breaks down and requires manual intervention.

Choosing a convention early is important because renaming events after they are in production is expensive. Historical data is stored under the old name, so any rename creates a split in your data. You either lose continuity or build mappings to bridge old and new names. Both options cost time. Getting the convention right from the start avoids that entirely.

How It Works in Practice

The most widely adopted pattern is object-action, where the event name describes what was acted on followed by what happened. For example, checkout_completed, invoice_downloaded, or filter_applied. This pattern groups related events together when sorted alphabetically, making it easy to find all events related to a specific feature or object.

Casing should be uniform across your entire tracking plan. The two most common choices are snake_case (preferred by Segment, Amplitude, and most data warehouses) and Title Case (used by Mixpanel). Pick one and enforce it everywhere. Mixing casing across platforms or teams is one of the fastest paths to analytics event naming chaos.

Tense matters more than most teams realize. Past tense (e.g. button_clicked, form_submitted) describes something that already happened, which aligns with how analytics events work: they record completed actions. Present tense (button_click) is ambiguous because it could refer to the action itself or the event that records it. Past tense removes that ambiguity and reads more naturally in queries like "show me all users who checkout_completed last week."

Common Mistakes

• Using verb-first names like click_button or view_page. Verb-first naming scatters related events across the alphabet. Object-first naming like button_clicked and page_viewed keeps them grouped together, which is critical when your plan grows past 50 events.
• Encoding context into the event name. Names like homepage_hero_cta_clicked or settings_dark_mode_toggled create an explosion of unique events. Instead, use a generic event like button_clicked with properties such as page, section, and button_label to capture the context.
• Allowing per-team or per-platform naming. If the iOS team uses camelCase and the web team uses snake_case, cross-platform analysis becomes a data engineering problem. One convention must apply everywhere.
• Not documenting the convention itself. A convention that exists only in tribal knowledge is not a convention. Write it down in your tracking plan and link to it from your naming conventions guide.

Frequently Asked Questions

What is the best event naming pattern?

Object-action in past tense is the most widely recommended pattern. Examples include order_completed, search_performed, and invite_sent. This pattern groups events by feature area when sorted alphabetically, reads naturally in plain English, and is compatible with every major analytics platform and data warehouse.

Should I use snake_case or Title Case?

snake_case is the safer default. It is the native format for SQL queries, most data warehouses, and APIs. Platforms like Amplitude and Segment use it as their standard. Title Case is primarily associated with Mixpanel. If you are starting fresh or using multiple tools, snake_case avoids conversion issues downstream and is less prone to inconsistency.

Should event names use past tense or present tense?

Past tense is recommended because analytics events represent actions that have already occurred. When you query for users who checkout_completed, the past tense reads correctly. Present tense like checkout_complete is grammatically ambiguous and can be confused with a state or a command rather than a recorded action. Whichever tense you choose, the key rule is to apply it consistently across every event in your tracking plan.