Event Naming Linter
Paste your analytics event names and get them checked against a consistent snake_case object_action convention — the same one Pug's typed event registry uses.
-
page_view -
Signed Up→signed_up- contains spaces — use snake_case
- uppercase letters — use lowercase
- duplicate — 2 names collapse to "signed_up"
-
addToCart→add_to_cart- uppercase letters — use lowercase
-
checkout-started→checkout_started- kebab-case separator — use underscores
-
purchase_2- contains a number — never embed dynamic values in names
-
click- too generic — add object context (e.g. signup_button_clicked)
-
user_signed_up -
signed_up- duplicate — 2 names collapse to "signed_up"
One convention, enforced
The single biggest source of messy analytics is naming drift: signup,
sign_up, SignedUp, and signed_up all coexisting. Each is
a separate event to your tool, so your funnels and reports quietly split. Pick one convention
and lint against it.
The rules this checks
Lowercase only; underscores as the separator; an object_action pattern; no spaces,
hyphens, or dotted namespaces; and no dynamic values (numbers, IDs) baked into the name — those
belong in properties. It also flags near-duplicates that collapse to the same canonical name.
Built on a real registry
These rules are exactly how Pug's 127 well-known events are named. Pug is open-source product analytics with a typed event registry — clean names in, queryable data out.
Frequently asked questions
- What makes a good event name?
- Consistency and an object_action pattern. Pug's well-known events use snake_case — page_view, add_to_cart, checkout_started. Lowercase, underscores, past-tense for completed actions, and never a dynamic value baked into the name.
- Why does casing matter so much?
- Most analytics tools treat SignedUp, signed_up, and "Signed Up" as three separate events. Inconsistent casing silently fragments your data so nothing rolls up. One convention, applied everywhere, prevents it.
- Why avoid numbers in event names?
- A number in a name (purchase_2, step3) usually means a dynamic value leaked into the event kind. That explodes your event list and breaks aggregation. Put the value in a property instead.
- What is the object_action pattern?
- Name the thing, then what happened to it: cart → add_to_cart, checkout → checkout_started, subscription → subscription_canceled. It keeps related events grouped and self-documenting.
Ship events that map to a typed registry.
Pug ships 127 well-known events with typed properties — open-source product analytics with a naming convention built in.