Naming conventions

The conventions you pick matter less than picking them and enforcing them. What ruins analytics is inconsistency. The same action shows up as user_signup in one place, Signed Up in another, and UserSignedUp in a third, and now nobody can tell whether the three are one action or three.

This chapter lays out a set of conventions that works well. If you already have conventions you like, keep them. The goal is consistency, not these exact rules.

#Why this matters

Without an agreed standard, each developer falls back on their own habits. One writes Title Case, another snake_case, a third camelCase. One uses past tense, another present. Within six months your Amplitude project holds duplicate events under three different names, and anyone analyzing the data has to stop and work out whether they mean the same thing.

The cost is invisible at first. The tracking still fires and the numbers still move. It surfaces later, when someone tries to answer a real question and finds the data split across half a dozen near-duplicate events. The same drift happens across platforms. The web app fires Signed Up, the mobile app fires sign_up_complete, and your cross-platform signup funnel quietly undercounts.

#Event names

Use sentence case, structured by event type. Sentence case reads like plain English, and you never have to stop and decide whether both halves of "Sign up" get a capital.

#Why noun + past participle for direct actions

Two reasons.

Alphabetical grouping. All your subscription events (Subscription canceled, Subscription renewed, Subscription resumed) sort together in Amplitude's event picker. Trial events cluster the same way. A list you can scan beats one you have to search.

Tense signals completion. A past participle ("completed", "submitted", "canceled") makes it obvious the event marks a finished action rather than an attempt. That reinforces the tracking on successful states principle. Events stand for things that happened, not things that were tried.

#Why noun + noun for indirect events

Indirect events are failures, system processes, and things the user didn't directly complete. They 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 lets you scan the taxonomy and tell direct from indirect at a glance.

#Keep variable data out of event names

Put the thing that varies in a property, not in the event name. It's tempting to ship Pro plan upgraded, Team plan upgraded, and Enterprise plan upgraded as three separate events. Don't. Fire one event, Plan upgraded, and attach the plan as a property such as plan_type: pro.

The reason is analysis. With one event you chart every upgrade, then break it down by plan_type when you want the split. With three events you have to remember all three names, add them up by hand, and edit every chart the day you launch a fourth plan. The event picker fills with near-identical rows, and the taxonomy grows a line for every value instead of every action.

The test: if two events differ only by a value, they're one event with a property.

#Property names

Use snake_case for both event properties and user properties.

The visual split, sentence case for events and snake_case for properties, helps when you build charts or write formulas. You can tell instantly whether a token is an event name or a property name. That matters more than it sounds. Mixing the two in a formula is the kind of bug that costs an afternoon to debug.

Lowercase acronyms too. Write api_key, cta_id, and url_source, not API_key or URL_source. One casing rule with no exceptions is one fewer thing to remember.

#Reuse the same name for the same thing

Use one property name for one concept, everywhere it appears. If a user's plan is plan_type on Sign-up completed, it should be plan_type on Plan upgraded and Subscription canceled too, never plan on one and subscription_plan on another.

When the names match, you can group or filter any event by plan_type and trust it means the same thing across all of them. When they drift, every cross-event question turns into a hunt for which name that particular surface happened to use.

#Put units in the name

When a value carries a unit, bake the unit into the name. duration_ms, revenue_usd, file_size_bytes. Six months from now nobody remembers whether duration was seconds or milliseconds, and the chart that assumed seconds has been wrong the whole time. The name removes the guess.

#Property values

Pick a format for property values and stick to it. 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 in the taxonomy, and stay consistent. Skip that step and the same property fills up with pro, Pro, and PRO, and every filter and chart has to account for all three.

For values that have a natural format (URLs, country codes, ISO dates), keep the raw format. Don't lowercase a country code like US to us just because your other values are lowercase.

#Special properties

A few property names are reserved by your analytics tool and carry special meaning. For Amplitude:

• Properties prefixed with $ are reserved ($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, and don't reuse names that collide with reserved ones. Your tool's docs list them. Check before you name.

#A short rule of thumb

When you name an event, ask whether it's something the user accomplished or something that happened to them. Past participle for the first, noun + noun for the second. If the only difference between two events is a value, make it one event and move the value into a property.

When you name a property, ask whether the value is a category, a count, a flag, or free-form text. Categories and flags get snake_case enum values. Counts and IDs stay as raw values. Free-form text stays raw too.

That covers the decisions you make by hand. The taxonomy spreadsheet enforces the rest.