Event Taxonomy Best Practices

A good event taxonomy is what stands between an analytics tool that produces decisions and one that produces noise. Most teams know they should have a taxonomy. Few have one that survives contact with reality after 12–18 months.

This guide is the principles Adasight applies on every engagement. Not the only correct approach, but a defensible one that scales.

Why the taxonomy matters more than the tool

A clean taxonomy in a basic tool produces better analyses than a messy taxonomy in a sophisticated tool. The tool determines what queries are easy to write. The taxonomy determines what answers can be trusted.

Most "Amplitude is broken" complaints are taxonomy problems. The team thinks the platform is failing them; the platform is faithfully producing the data the team gave it. Better instrumentation upstream produces better analysis downstream — there is no analytics tool that can rescue a broken taxonomy.

The naming convention

The single highest-leverage rule: pick one convention and enforce it.

The convention we recommend:

• snake_case for all event names and property keys. Lowercase, words separated by underscores. signup_completed not SignupCompleted or signup-completed.
• Verb-object pattern for events. payment_failed, workflow_started, invitation_accepted. Reads as a sentence.
• Object-attribute pattern for properties. plan_tier, workflow_id, invitation_method.
• Length cap of 40 characters for events. Longer names usually indicate the event is doing too much (combining what should be event + property).
• Reserved prefixes off-limits. Anything starting with [Amplitude] is auto-collected. Don't manually fire events with that prefix.

The convention is less important than the consistency. camelCase would also work if applied universally. The cost of a half-applied convention is higher than picking either.

What every event needs

Each event has six attributes worth specifying explicitly in the plan:

1. Name. Verb-object, snake_case, ≤40 chars.
2. Description. One sentence: when does this fire? Specific, not vague.
3. Trigger. The exact moment in the user flow.
4. Properties. 3–5 properties that capture the context. More than 8 properties usually means the event is too generic.
5. Required vs optional properties. Govern enforces this — use it.
6. Owner. One person responsible for this event continuing to work.

Without descriptions, events become tribal knowledge. After two years and three engineering teams, no one remembers when signup_flow_step_3 fires. Descriptions are the cheapest insurance against that.

Property hygiene

Three rules.

Same property, same name, everywhere. plan on one event and plan_name on another fragment your data. Pick a canonical name per concept and use it across all events.

Don't duplicate user properties on events. If the user is on the pro plan, that's a user property (plan_tier). Don't also send it as an event property on every event — Amplitude joins them automatically.

Use $set for values that change, $set_once for values that don't. signup_date is set once and never updated. current_plan_tier is set on every plan change. Confusing the two means signup_date gets overwritten on every plan upgrade — destroying retention analysis.

Governance

A plan without governance decays in 6–18 months. The team ships features faster than they update the plan, drift accumulates, and the plan stops being trusted.

Three habits that keep it alive:

1. PR review on tracking changes. New events do not get merged without an entry in the plan. Renames require migration plans. Property additions get logged.
2. Monthly reconciliation. Pull the top 20 events by volume from Amplitude. Compare to the plan. Untracked events get added or deleted; dead plan entries get removed.
3. Designated owner. Even at 5% of someone's role. Without an owner, the plan has no immune system.

Amplitude Govern is the platform-level enforcement layer. Use it to set categories, mark events as hidden or blocked, define required properties, and enforce naming patterns. Govern enforces; the plan defines what should be enforced. Both layers are needed.

What we check for

The Amplitude Auditor checks the following automatically:

• Event naming (snake_case, lowercase, length)
• Event descriptions present in the taxonomy
• Event categories used in Govern
• Suspected duplicate events (taxonomy drift signal)
• User property naming
• Property coverage on top events

Run an audit to see what shows up on your project.

FAQ

What if I'm inheriting a broken taxonomy — should I fix it or start over? Fix it incrementally. A full reset usually breaks 12 months of dashboards and burns goodwill. The right move: stop the bleeding (enforce conventions on new events), then migrate the worst offenders one at a time.

Should I track every interaction or only meaningful ones? Every meaningful one. Auto-capture handles the rest at low fidelity. Explicit instrumentation is for the events the business actually analyses.

How do I know if my taxonomy is mature? Pull the top 10 events. If 5+ are domain-specific business actions (signups, conversions, feature uses), you're in good shape. If they're dominated by Page Viewed and auto-collected events, the taxonomy hasn't caught up to the platform.