Event taxonomy is the difference between an analytics setup you can reason about in year three and a graveyard of events nobody remembers creating. Most tracking plans don’t fail at launch — they fail slowly, as each new feature ships its own ad-hoc events with names like btnClick2 and signup_final_REAL. A taxonomy is the naming and structure discipline that stops that drift. Get it right early and your tracking plan scales with the product instead of collapsing under it.
This guide covers what an event taxonomy is, the structure that holds up over time, and how to keep it clean as teams and features multiply.
What Is an Event Taxonomy?
An event taxonomy is the agreed system for naming and structuring the events and properties you track. It defines how an event is named, what it always carries, and where it fits in the bigger picture. Think of it as the grammar of your analytics: a shared set of rules so that any event, created by any team, reads consistently.
Without one, every developer invents their own convention. With one, checkout_completed and signup_completed follow the same predictable shape — and a new analyst can guess an event name before they look it up. That predictability is the entire payoff.
A taxonomy isn’t bureaucracy — it’s the rule that lets someone who never met you understand your events on first read.
The Object-Action Framework
The most durable naming structure is object-action: name the thing, then what happened to it. order_completed, video_played, invite_sent. The object comes first, the action second, both in past tense, joined consistently.
This single rule eliminates most naming chaos. It groups naturally — every order_* event sits together — and it scales, because new features just add new objects and actions to a pattern everyone already knows. It also aligns with standard GA4 event naming conventions, so your taxonomy and your tooling agree.
| Object | Action | Event name |
|---|---|---|
| order | completed | order_completed |
| signup | started | signup_started |
| video | played | video_played |
| invite | sent | invite_sent |
The Three Layers of a Taxonomy
A complete taxonomy defines three layers, not just event names. Skip any one and the structure leaks.
1. Events
The actions users take, named with the object-action rule. Keep the list deliberately small — a focused set of meaningful events beats hundreds of granular ones nobody analyzes. If an event would never change a decision, it probably shouldn’t exist.
2. Properties
The parameters attached to events: plan, platform, source. Properties are where most taxonomies rot, because everyone names them differently — plan, planName, subscription_plan for the same thing. Define each property once, name it once, and reuse it everywhere.
3. Conventions
The rules themselves: casing (snake_case throughout), tense (past), and the allowed values for each property. Write them down. A convention that lives only in one engineer’s head isn’t a convention — it’s a single point of failure.
How to Keep a Taxonomy Clean
A taxonomy is a living system, not a one-time document. Three habits keep it from drifting.
- One source of truth. Maintain a single tracking plan that every team consults before adding an event. If it’s not in the plan, it doesn’t ship. This is the backbone of any real measurement plan.
- A review gate. New events get a quick review against the taxonomy before they go live. Five minutes of review saves months of cleanup.
- Deprecate deliberately. When an event is retired, mark it deprecated rather than deleting it silently. Versioning your changes keeps historical reports readable.
Left unmanaged, every taxonomy accumulates tracking debt — the slow buildup of inconsistent, duplicated, and orphaned events. The habits above are how you stop paying interest on it.
Common Mistakes
- Mixing naming styles.
order_completednext toVideoPlayednext tobtn-click. Pick one convention and enforce it everywhere. - Tracking everything. A taxonomy with 800 events is as useless as none. Track what informs decisions, not what’s technically possible.
- Undefined property values. If
plancan be “pro”, “Pro”, and “PRO”, your reports fracture. Constrain values to an allow-list. - No owner. A taxonomy without a steward drifts within a quarter. Someone must own the plan.
FAQ
What’s the difference between a taxonomy and a tracking plan?
The taxonomy is the set of rules — how events and properties are named and structured. The tracking plan is the living document that applies those rules to your specific events. The taxonomy is the grammar; the tracking plan is the dictionary.
Should event names be past or present tense?
Past tense, consistently. An event records something that already happened, so order_completed reads correctly. The exact choice matters less than picking one tense and never mixing it.
How many events should we track?
Fewer than you think. A focused set of decision-driving events is far more valuable than exhaustive coverage. If you can’t name the decision an event informs, it’s a candidate for removal, not addition.
Can we change our taxonomy later?
Yes, but deliberately and with versioning. Renaming events breaks historical reports, so treat changes like schema migrations — planned, documented, and backward-compatible where possible.
The Bottom Line
An event taxonomy is the quiet infrastructure that decides whether your analytics still makes sense in three years. Name events with a consistent object-action rule, define your properties and conventions once, and protect the whole thing with a single source of truth, a review gate, and deliberate deprecation. None of it is glamorous, and all of it compounds. The teams with clean analytics didn’t get lucky — they decided their naming rules before the chaos started, and then held the line.