Concepts
Naming conventions for events and properties
The conventions you pick matter less than picking them and enforcing them. A set that works well as a default.
The conventions you pick matter less than picking them and enforcing them. What ruins analytics is inconsistency: user_signup in one place, Signed Up in another, UserSignedUp in a third, all representing the same action.
This chapter covers a set of conventions that works well. If you already have conventions you like, keep them. The goal is consistency, not adopting these exact rules.
Why this matters
Without agreed-on standards, each developer defaults to their own preferences: Title Case, snake_case, camelCase, past tense, present tense. Within six months, your Amplitude project has duplicate events with three different names, and anyone analyzing data has to investigate whether they represent the same thing.
The pain is invisible at first — the tracking still works. It only becomes obvious when someone tries to answer a question and discovers the data is fragmented across half a dozen near-duplicate events.
Event names
Use sentence case, structured by event type.
| Event type | Structure | Examples |
|---|---|---|
| Direct user actions | Noun + past participle | Sign-up completed, Cart updated, Trial started |
| Indirect or system events | Noun + noun | Sign-up failure, Subscription renewal, Session timeout |
Why noun + past participle for direct actions
Two reasons.
Alphabetical grouping. All your subscription events (Subscription canceled, Subscription renewed, Subscription resumed) appear together in Amplitude's event picker. Trial events cluster too. This makes the event list scannable.
Tense signals completion. Past participle ("completed", "submitted", "canceled") makes it obvious the event represents a finished action, not an attempt. This reinforces the tracking on successful states principle: events represent things that happened, not things that were tried.
Why noun + noun for indirect events
Indirect events — failures, system processes, things the user didn't directly complete — read differently because they aren't user accomplishments. Sign-up failure is something that happened to the user; Sign-up completed is something they did.
The structural difference makes it easy to scan the taxonomy and tell direct from indirect at a glance.
Property names
Use snake_case for both event properties and user properties.
| Property type | Examples |
|---|---|
| Event properties | button_location, plan_type, error_code, referral_source |
| User properties | account_tier, signup_source, company_size, subscription_status |
The visual distinction (sentence case for events, snake_case for properties) helps when you're building charts or writing formulas — you can tell instantly whether a token is an event name or a property name. This matters more than it sounds; mixing them up in formulas is the kind of bug that costs an afternoon to debug.
Property values
Pick a format for property values and stick to it. The two common choices:
- Lowercase, snake_case:
account_tier: pro,referral_source: google_ads - Title Case:
account_tier: Pro,referral_source: Google Ads
Either works. Pick one. Document it. The problem isn't which one you choose — it's that you'll get all three of pro, Pro, and PRO in your data if you don't pick.
For values that have a natural format (URLs, country codes, ISO dates), preserve the raw format. Don't normalize country codes like US to us just because the rest of your properties are lowercase.
Special properties
A few property names are reserved by your analytics tool and have special meaning. For Amplitude:
- Properties prefixed with
$are reserved (e.g.,$revenue,$price,$productId) - Properties matching internal names (
user_id,device_id,session_id) are interpreted by the SDK
Don't invent your own $-prefixed properties. Don't use names that conflict with reserved ones. Your tool's docs will list them — check before you name.
A short rule of thumb
If you're naming an event, ask: "Is this a thing the user accomplished or a thing that happened to them?" Past participle for the former, noun + noun for the latter.
If you're naming a property, ask: "Is the value a category, a count, a flag, or a free-form string?" Categories and flags get snake_case enum values; counts and IDs stay as raw values; free-form strings stay raw too.
That's it. The taxonomy spreadsheet enforces the rest.