Designing an Event Taxonomy for Amplitude

Start from verbs, not screens

The most common mistake is naming events after the screen they fire from (HomeScreenButtonClicked) instead of the action a user took (Call Started, Report Exported). Screen names change with every redesign; the underlying action usually doesn’t. A taxonomy organized around actions survives UI churn.

Object + Action, not free text

A convention that scales: Object Action, both in title case — Call Started, Export Requested, Plan Upgraded. This keeps the event list groupable in Amplitude’s UI by object (all Call * events together) without needing a separate naming registry to remember which events exist.

Properties carry the variance, not the event name

Don’t create Call Started — Cloud and Call Started — SIM as two events. Use one Call Started event with a medium: "cloud" | "sim" property. This keeps funnels and retention charts comparable across variants instead of fragmenting the same user action into events that can’t be summed.

User vs. event properties

• User properties (set once, persist) — plan tier, signup date, team size, platform.
• Event properties (per-event, contextual) — what changed this time: call medium, export format, error code.

Mixing these up shows up later as identical event properties repeated on every single event call, when they should have been set once via identify.

Deduplication is a taxonomy problem, not just a code problem

If the same logical action can fire from two code paths (a retry button and an automatic retry), give both a shared trigger property (manual / automatic) under the same event name, rather than letting the two call sites drift into separate, inconsistently named events over time.

A minimal taxonomy doc beats a perfect one

A spreadsheet with event name | trigger condition | properties | owner that’s actually kept up to date is worth more than a fully normalized schema nobody maintains. Treat the taxonomy doc as the thing PRs are reviewed against, not a one-time design exercise.

Review new events against the doc, not against vibes

The taxonomy doc only stays useful if it’s actually part of the review process for new events — otherwise it drifts out of sync with the codebase within a few sprints, and nobody trusts it enough to consult it, which makes it worthless even though it’s technically still there. Treating “does this new event fit an existing object, or does it need a genuinely new one” as a real review question, the same way a schema migration gets reviewed, keeps the taxonomy doc accurate enough to actually rely on months later.