Free SEO tool for SaaS founders
Generate a clean naming convention for your analytics events. Keep dashboards readable before inconsistent tracking names pile up.
No account required. Built for indie makers and product builders.
Why this tool exists
Inconsistent event names create analytics debt fast. This generator helps you standardize event language before dashboards, docs, and product discussions drift apart.
You can also browse more free tools, use the tracking plan generator, or explore BSData.
Standardize analytics event names before your dashboards become a mix of styles and meanings.
A clean naming convention with example events, property rules, anti-patterns, and migration guidance.
The generator helps you choose a stable analytics language so dashboards, docs, and SQL all use the same event names.
Example Markdown preview
# Bonson Event Naming Convention ## Recommended Prefix - project ## Naming Convention Rules - Use one naming style consistently across the whole product analytics setup. - Prefer business actions in snake_case instead of UI labels or internal implementation names. - Use a single canonical event per milestone and keep context in properties, not in many near-duplicate event names. - Name completed milestones in a way that reads clearly in dashboards, docs, and SQL queries. ## Example Events | Category | Meaning | Event name | Why it works | | --- | --- | --- | --- | | Acquisition | User viewed the landing page | landing_page_viewed | Keeps acquisition language focused on a business milestone instead of a UI implementation detail. | | Signup | User completed signup | user_signed_up | A completed action is easier to query and compare than a vague label like new_user or account_flow. | | Onboarding | User completed onboarding | onboarding_completed | One canonical onboarding completion event is easier to maintain than many step-specific variants. | | Activation | First project created | first_project_created | It reflects a value milestone, not just a click, so dashboards stay tied to product progress. | | Conversion | Subscription started | subscription_started | Conversion names should map to a real commercial milestone such as checkout_completed or subscription_started. | | Retention | Repeated Create the first project | create_the_first_project_repeated | Repeated usage should be described as a stable outcome, not a pile of low-value session events. | ## Property Naming Rules - Use snake_case for properties too, for example signup_method, billing_period, and workspace_type. - Use properties for context like source, plan, and role instead of creating separate events for each variation. - Keep property values stable and finite when possible so filtering stays reliable. ## Anti-Patterns - Mixing multiple naming styles like userSignedUp, signup_complete, and NewUser in the same product. - Encoding page location or button color inside the event name instead of in properties. - Creating separate events for every minor UI state instead of one milestone event with context properties. - Using vague names like conversion, success, or action_done that nobody can interpret later. ## Migration Tips - Start by standardizing the top funnel events first: signup, onboarding, activation, conversion, and retention. - Map old event names to new canonical names in one migration document before changing dashboards. - Keep a naming reference in your docs so product, engineering, and marketing use the same language.
An event naming convention is a shared set of rules for how analytics events and properties should be named. It keeps product analytics readable, consistent, and easier to query.
For early-stage SaaS, a simple naming convention usually beats a complicated taxonomy. The goal is clarity, not ceremony.
Use clear snake_case names that describe business actions such as user_signed_up, onboarding_completed, first_project_created, checkout_started, and checkout_completed.
Event names should express the milestone. Properties should hold the context like source, plan, role, or billing period.
Common mistakes include mixing camelCase and snake_case, naming events after UI elements, and creating many near-duplicate events instead of one canonical milestone with properties.
Consistent naming makes product analytics easier to maintain across code, dashboards, specs, and cross-functional discussions. It also reduces rework when you need to standardize tracking later.
This example shows a simple naming system for a micro SaaS product.
| Category | Meaning | Event name |
|---|---|---|
| Acquisition | User viewed the landing page | landing_page_viewed |
| Signup | User completed signup | user_signed_up |
| Onboarding | User completed onboarding | onboarding_completed |
| Activation | First project created | first_project_created |
| Conversion | Subscription started | subscription_started |
| Retention | Repeated Create the first project | create_the_first_project_repeated |
An event naming convention is a set of rules for how you name analytics events and properties so dashboards, docs, and implementation stay consistent.
snake_case is easy to read in dashboards, data warehouses, and code. It also avoids the inconsistency that often appears when some teams use spaces, camelCase, or mixed punctuation.
Usually no. Better event names describe business milestones such as user_signed_up or checkout_completed rather than button colors or modal states.
Start by choosing canonical names for key milestones, map old events to the new names in one document, and then update dashboards and tracking code in a controlled order.
Context like source, plan, role, billing period, or button location belongs in properties. The event name should stay focused on the milestone itself.
Most early-stage teams do well with snake_case names based on completed business actions, because that style is readable, query-friendly, and easy to maintain.