Event Taxonomy Design: Name Your Events Before Tracking Sprawls

No one decides to create three events named form_submit, formSubmitted, and submit_form_new. Sprawl happens because each event was added by a different person, in a different quarter, solving a different ticket, with no shared grammar to consult. Two years later the property has hundreds of events, nobody can say which are trustworthy, and every analysis begins with an archaeology phase where someone reverse-engineers what the events actually mean.

The cost is not aesthetic. Analysts stop trusting the data and rebuild counts from raw sources, dashboards quietly disagree with each other depending on which event they picked, and new instrumentation takes longer because every engineer has to guess at precedent. A taxonomy designed before sprawl sets in costs an afternoon; untangling sprawl after the fact costs a quarter.

A usable taxonomy is a grammar, not a list. Decide the structure of every event name once, and the most durable pattern in practice is object plus action in a fixed order and a fixed case, such as form_submitted, trial_started, demo_booked, pricing_viewed. Past-tense verbs describe things that happened, snake_case survives every tool's quirks, and putting the object first groups related events together in any alphabetized picker your team will ever scroll through.

Then push variation into properties instead of names. One form_submitted event with a form_id property beats fifteen events named after individual forms, because analyses that span all forms become a single filter instead of a fifteen-way union, and adding a sixteenth form requires no new instrumentation decisions. The general rule: the event name captures what kind of thing happened, properties capture which one and in what context.

Property sprawl is quieter than event sprawl and just as corrosive. Define a small set of shared properties with fixed names and types that ride along on every event where they apply, things like page_type, content_category, or plan_tier, so the same concept is never called category in one event and content_type in another. Document allowed values for anything enumerable, because a property whose values are freeform text degrades into a synonym pile exactly the way untagged UTMs do.

Write all of this down in a tracking plan that lives somewhere versioned and visible, whether that is a spreadsheet, a document in the repo, or a dedicated schema tool. The format matters far less than the habit: every event, its trigger, its properties, their types and allowed values, and an owner. The tracking plan is the contract between whoever asks for data and whoever instruments it.

A taxonomy without a gate decays back into sprawl within a few quarters, because the pressure to just ship one quick event never goes away. The gate does not need to be heavy: a rule that no event ships without a tracking plan entry, plus one named reviewer who checks new events against the grammar and asks whether an existing event with a new property value would do instead. Most proposed new events fail that second question, and each one that does is a future cleanup avoided.

Review the plan against reality on a cadence, since even gated taxonomies accumulate dead weight. Twice a year, list events by volume and by last-queried date where your tooling allows it, deprecate what nothing consumes, and fold accidental near-duplicates together. A taxonomy is not a monument, it is a garden, and the weeding is part of the design.