Event Taxonomy Best Practices: Naming Conventions for Clean Product Analytics
Picture a 90-person marketplace startup doing about $12M ARR where the activation dashboard had been quietly lying for four months before anyone caught it. The web team fired signup_completed. iOS fired SignUpFinished. Android, built by a contractor who’d never seen the other two platforms’ code, fired Signed Up with a capital S and a space. Three events, one user action, and a funnel report that showed activation dropping 30% quarter over quarter, because two-thirds of the signal had quietly split off into events nobody was querying. The fix wasn’t a new analytics tool. It was an event taxonomy nobody had ever written down.
Event taxonomy is the least glamorous part of product analytics and the part everything else depends on. A tracking plan is only as trustworthy as the naming convention underneath it, and most teams don’t discover theirs is broken until a metric that should move doesn’t, or moves for a reason nobody can explain.
The cost compounds because a single event rarely has a single consumer. Marketing pulls the same event into an attribution report. Finance pulls it into a revenue-recognition query. Data science pulls it into a churn model. When the event is fragmented across three names, none of those three teams sees the full picture, and worse, none of them knows they’re missing two-thirds of the signal, the dashboard just looks internally consistent and quietly wrong. A QBR where marketing reports one activation number and product reports a different one from the same underlying user action is a familiar scene at growth-stage companies, and the thirty minutes it takes to figure out why usually isn’t about disagreement over methodology. It’s about two teams querying two differently-named events that should have been one.
Why Event Taxonomy Breaks Before Anyone Notices
Event taxonomy doesn’t fail all at once. It fails one shipped feature at a time, because naming an event feels like a two-second decision an engineer makes while writing a pull request, not a product decision with downstream consequences. Nobody sits down and decides to fragment the activation funnel across three names, each name felt reasonable in isolation, on its own platform, in its own sprint.
The decision that looks right early on and turns out wrong is letting each platform team name their own events to keep velocity up during a fundraising push. It’s the right call for about two quarters. By month five, the data team is maintaining a manual mapping spreadsheet just to reconcile which events meant the same thing, which is itself a signal the taxonomy has already broken, because a mapping layer is a symptom, not a fix.
The Core Event Taxonomy Naming Convention: Object + Action
The convention that scales best across a growing engineering org is Object + Action, in a fixed case format, applied without exception: signup_completed, listing_created, payment_failed. Object first because it makes an event list sortable and scannable by feature area, every “listing” event groups together, every “payment” event groups together, and action second, always past tense, because an event is a record of something that already happened, not an instruction.
The alternative, Verb-first (completed_signup, created_listing), reads more like natural language, and growth teams often push for it because it matches how they talk about funnels out loud. It doesn’t sort or group as cleanly in a flat event list, which matters more than conversational fit once you’re past a few dozen events. This is exactly the disagreement that can split a data team and a growth team for the better part of a sprint: data wants Object+Action for the sorting property, growth wants Verb-first because it matches their funnel language. The convention doc that ends the argument picks Object+Action as the system of record and lets the BI layer alias display names however growth wants them to read on a dashboard. Nobody has to lose the argument; the underlying data and the human-facing label just stop being the same string.
Property Naming Conventions That Keep an Event Taxonomy Clean
Events without consistent properties are almost as unreliable as inconsistent event names. A few rules that hold up in practice:
- snake_case for every property key, no exceptions for “just this one” camelCase field an engineer prefers.
- Consistent units, stated in the key —
price_usd_cents, notprice, so nobody has to guess whether a number is dollars or cents six months later. - Booleans prefixed with
is_orhas_—is_first_purchase, notfirst_purchase, which reads ambiguously as either a boolean or a timestamp. - No free-text properties for anything you’ll ever filter or group by — a
plan_nameproperty with unconstrained string input will eventually contain “Pro,” “pro,” and “PRO tier” as three different values in the same chart.
A property schema this strict feels like overhead when you’re a five-person team shipping fast. It’s cheap to enforce at five people and extremely expensive to retrofit at fifty, which is the actual argument for doing it early, not because rigor is virtuous on its own, but because the cost curve only goes one direction.
Timestamps deserve a specific callout because they cause a quieter version of the same failure. One engineer logs a property as created_at in UTC. Another logs local_time in the user’s device timezone, because that’s what the mobile SDK handed them by default. Neither is wrong on its own, but a funnel that joins both properties across platforms will silently misorder events for any user outside UTC, and the error shows up as noise in session-length metrics that nobody traces back to a timezone mismatch for months. The fix is boring and specific: every timestamp property is UTC, named with a _utc suffix, full stop, and any local-time display happens in the BI layer, never in the raw event.
Who Should Own Your Event Taxonomy?
Ownership is the part most teams skip past, and it’s the part that determines whether any of this survives contact with a real sprint calendar. A taxonomy with no named owner degrades within two or three release cycles, because “everyone’s responsibility” means nobody blocks a PR over an inconsistent event name. mParticle’s data governance documentation frames this as a data-quality function that needs an accountable owner the same way a codebase needs a maintainer, not because the owner writes every event personally, but because someone has to have the authority to say no to a poorly named one before it ships.
The realistic staffing answer for most seed-to-Series-B teams isn’t a dedicated analytics engineer, it’s whichever PM most depends on the data being right. That person doesn’t need deep SQL skill to do this well; they need the standing to block a PR in a taxonomy review, and enough context to ask “does this event already exist under a different name” before approving a new one. A part-time owner with real authority outperforms a full-time analytics engineer with none, because the failure mode here is organizational, not technical.
Event Naming Convention: Do vs. Don’t
| Situation | Don’t | Do |
|---|---|---|
| User completes signup | SignUpFinished, Signed Up |
signup_completed |
| Price property | price (ambiguous unit) |
price_usd_cents |
| Boolean flag | first_purchase |
is_first_purchase |
| Plan tier | free-text plan_name |
enum: free / pro / enterprise |
| New event proposal | shipped directly in a feature PR | reviewed against the taxonomy doc before merge |
In cases like this, ownership tends to land best with the PM most responsible for activation metrics, not the data team, a deliberate choice, because the data team can enforce a schema but has no product context to judge whether a newly proposed event actually represents a meaningful user action or is just noise. That PM doesn’t need to approve every event personally forever; within two quarters, the convention is usually internalized enough that a lightweight PR template checklist does most of the enforcement. The ownership matters most in the first two quarters, while the convention is still being tested against edge cases.
When This Breaks: Redefinition Drift
Even a well-designed event taxonomy breaks over time through redefinition drift, the same event name quietly starts meaning something different as the product changes underneath it. listing_created might mean one thing when a product has a single listing type. Eighteen months later, after the product adds draft listings, imported listings, and duplicated listings, the same event fires for all four cases with no property distinguishing them, and every historical chart using that event silently starts measuring something broader than it used to.
This is the failure mode that’s hardest to catch, because nothing errors and no dashboard goes obviously wrong, it just gradually stops meaning what everyone assumes it means. The fix isn’t a one-time taxonomy cleanup; it’s a recurring audit, roughly quarterly, where whoever owns the taxonomy pulls the full event list against the current product surface and asks, for each event, “does this still mean what its name says it means, or has the feature grown past the definition.” A quarterly audit like this can catch listing-type drift before it corrupts another two quarters of reporting, and cutting duplicate and redefined events from the taxonomy during a first cleanup pass commonly reduces the total active event count by roughly a third, with no loss of tracked signal, since most of what gets cut was noise nobody was querying anyway.
Building an Event Taxonomy That Survives Team Growth
The taxonomy that survives a team going from 10 engineers to 40 isn’t the most elegant one, it’s the one written down somewhere every engineer actually looks before shipping a new event, with an enforcement mechanism lighter than a full review board. A shared taxonomy doc, a PR checklist item, and a named owner who reviews new event proposals weekly get you most of the way there.
This connects directly to the plan you should have written before any of this — a product analytics tracking plan is where the taxonomy gets defined before a single event ships, not reverse-engineered from whatever engineers happened to name things. If your team is running analytics without one, taxonomy drift isn’t a risk, it’s already happening and you just haven’t measured it yet.
None of this needs to be a heavyweight process to work. Amplitude’s own governance documentation and Segment’s protocols both converge on the same minimum viable structure: a single shared spreadsheet or doc listing every event, its properties, its owner, and the date it was last reviewed, checked as part of the PR template for anything touching an SDK call. That’s a half-day of setup, not a quarter-long initiative, and it’s the single highest-leverage half-day a growth-stage team can spend on its data infrastructure.
The instruments matter too, but less than most teams think. Whether you’re on Amplitude or Mixpanel, a bad taxonomy produces bad data in either tool equally well. The taxonomy is upstream of the tool choice, not downstream of it, teams that pick a new analytics platform hoping it will fix a messy event list are usually disappointed, because the mess migrates with the data.
Clean taxonomy also pays off directly in retention analysis. Customer health scoring and any serious churn analysis depend on consistent behavioral events to build a reliable health signal, a health score built on top of three differently-named signup events, or an event whose meaning drifted eighteen months ago, will misclassify accounts and either miss real churn risk or flag healthy accounts as at-risk. The taxonomy work is invisible until it’s the reason a churn model is wrong, and then it’s the first place worth checking.
A north star metric has the same dependency, one level up. A north star metric framework is only as trustworthy as the input events feeding it, and an input metric built on a fragmented or drifted event is a north star quietly pointing in a direction nobody chose.
Start With the Ten Events That Already Lie to You
Skip the full taxonomy rewrite this week. Pull your ten most-viewed events from whatever analytics tool you’re on, and for each one ask two questions: does another event anywhere in the codebase mean the same thing under a different name, and has this event’s real-world meaning changed since it shipped without anyone updating its definition. Most teams find at least one split like the one described above and one case of redefinition drift in the first pass. That’s usually enough evidence to get budget for the taxonomy doc that should have been written before the first event ever shipped.
References
Segment — “Tracking Plan Guide,” 2026 (https://segment.com/docs/protocols/tracking-plan/)
Amplitude — “Taxonomy and Governance Best Practices,” 2026 (https://amplitude.com/docs)
mParticle — “Data Governance and Event Naming,” 2026
RudderStack — “Event Tracking Plan Best Practices,” 2026
