Product Analytics: An Event Taxonomy That Won't Rot

An event taxonomy — a structured system for naming, organizing, and categorizing the user actions and properties your product captures — is the foundation every dashboard, funnel, and cohort sits on. When it is sound, analysis is boring and fast. When it rots, every downstream number quietly becomes a guess, and nobody can say which ones.

Taxonomies rarely fail loudly. They erode. One engineer logs Song Played; another, six weeks later and unaware, logs song played. Amplitude treats those as two entirely separate events — and the metric that was supposed to count one behavior now splits across two irreconcilable streams. No malice, no bug report, just entropy. The plan on the wiki still looks correct; the data underneath it no longer matches.

This guide covers the pathology and the cure: why event data decays, the naming convention that has become the industry default, the client-versus-server capture decision, the cross-platform identity trap that silently corrupts every cohort, how the major analytics platforms enforce governance, and — the part most teams skip — how to turn a tracking plan from a document into a gate that runs in your CI pipeline.

The decay is structural. Tracking is implemented at the edges of a codebase, by many people, over a long stretch of time, usually under deadline pressure. Each engineer makes a defensible local choice — checkout_complete versus Checkout Completed versus purchase — at the exact moment a feature ships. None of those choices is wrong in isolation. The damage is in the aggregate: an uncoordinated set of locally rational decisions produces a shared namespace that nobody designed and everybody has to live with.

Atticus Li frames this precisely as a tragedy of the commons, and the framing is worth quoting in full because it names the mechanism rather than the symptom.

Naming drift is the visible symptom, but it is not the only decay vector — it is just the easiest to see. Property types mutate when an amount field arrives as a number in one event and a string in another. Autocaptured events shift when a button is renamed or a page restructured, breaking the dashboards built on top of them. And the subtlest killer, covered in Section 05, is identity: anonymous-to-identified stitching that fails silently at login, poisoning every cohort downstream without throwing a single error.

The corrosive part is the false confidence. A plan that has drifted from reality is, in a real sense, worse than no plan at all — it invites teams to trust numbers that no longer mean what the documentation says they mean. The question for any non-trivial product is not whether tracking will degrade, but how quickly, and whether anything stands in the way.

The object-action naming convention has become the industry standard. The reasoning is functional, not aesthetic: it clearly describes the action that has already taken place, makes events more discoverable when someone is searching the catalog, speeds up the naming decision at implementation time, and — critically — reduces duplicate event names. Checkout Completed reads as a fact about a thing that happened, and the next engineer reaches for the same shape without thinking.

Avo's naming framework decomposes the decision into four independent axes, and the value is in fixing each one once, as a team, rather than re-litigating it at every implementation:

PostHog pushes the convention one notch further with a category:object_action pattern — for example account_settings:forgot_password_button_click — which adds a namespace prefix so events from the same product surface stay grouped. Property names get their own discipline: object_adjective format (user_id, item_price, member_count), boolean properties prefixed with is_ or has_ (is_subscribed, has_seen_upsell), and date or timestamp properties suffixed with _date or _timestamp.

The single most important rule across every platform is this: event names and property names must be fixed strings in your code, never generated dynamically. Variable data belongs in property values, never in event names — the moment you interpolate a user ID or a product name into an event name, you have created an unbounded namespace that no plan can govern. On sizing, Amplitude’s guidance is concrete: keep a tracking plan to between 10 and 200 event types (fewer obscures funnel analysis; more becomes a dictionary nobody can navigate), and no more than 20 properties per event. For the full vocabulary of events, properties, and identity, our analytics glossary of event, property, and identity terminology is a useful companion reference.

Naming drift gets the press, but it is one of several distinct decay vectors — each with a different root cause, a different detection signal, and a very different recovery cost. The table below maps them. It is, deliberately, a taxonomy of the things that break a taxonomy. Read your row, find the prevention mechanism, and you have most of a governance program.

The pattern in the recovery-cost column is the actionable insight: the two highest-cost failures — owner departure and identity fragmentation — are precisely the two that throw no error and surface no obvious signal. They are expensive to recover from because they are silent. That is the argument for prevention over cleanup: the failures that hurt most are the ones you will not notice until a quarter of cohort analysis is already built on bad foundations.

Client-side tracking is convenient and lossy. Server-side tracking is reliable and more work. The honest answer for almost every product is to use both, deliberately — and the reason comes down to what you can and cannot control on a user's device.

How big is the client-side loss? Tracking vendors put the figure at roughly 25–40% of client-side traffic affected by ad blockers, depending on industry, with Apple's Intelligent Tracking Prevention further limiting cookie lifespan and blocking third-party trackers. Treat that range as directional, not gospel — it is vendor-stated and not independently audited, and the vendors quoting it sell server-side tracking, so the incentive runs toward emphasizing the problem. The qualitative point survives the caveat regardless: a non-trivial, hard-to-measure slice of client-side events never arrives, and you cannot tell in advance which users it affects. For anything mission-critical — revenue, sign-ups, activation — that uncertainty is unacceptable, and server-side capture is the only way to remove it.

The recommended approach is a hybrid capture model: use client-side autocapture for baseline behavioral data, and manually instrument your 10–20 core KPIs server-side with structured properties. When precision is critical — sign-up events are the canonical example — Amplitude recommends instrumenting the same core event on both client and server, but with different names to avoid double-counting. PostHog makes the same demand: backend and frontend events tracking the same action must have distinct names, and the distinct_id must always be supplied for server-side events, typically from the user's database ID or session cookie. Our deeper treatment of this lives in the guide to server-side event capture.

There is a hidden cost to leaning hard on autocapture, and it is its own decay vector. Autocaptured events are tied to the structure of your UI — so when a button is renamed or a page is restructured, the captured events shift in ways that quietly break the dashboards and analyses built on them. Schema drift from autocapture is subtler than naming drift, but just as destructive, which is exactly why the core, business-critical events should be instrumented by hand rather than inferred from the DOM.

Naming drift and untyped properties get the attention. The vector that does the most damage with the least noise is identity. When a user is anonymous, your analytics tool assigns a distinct_id. When they log in, that anonymous identity has to be stitched to their known identity — and if that stitch is done inconsistently, or at the wrong moment, the result is not an error. It is a quietly fractured user graph where one human shows up as several, and every funnel, retention curve, and cohort built on top is wrong in ways no alert will catch.

The implementation rule is concrete: call identify() at first load (to bind the anonymous session) and again after login (to merge it into the known user). Skip the first call and you lose pre-login behavior; skip the second and your logged-in users fragment from their anonymous selves.

User properties carry their own subtle rule. PostHog distinguishes two setters, and using the wrong one corrupts your acquisition analysis:

Get this distinction wrong and the damage is permanent in a specific way: if you use $set for referral source, every later session overwrites the original acquisition channel, and you lose the ability to ever say where a user truly came from. The original context is gone — there is no recovering it from the data, because the data was overwritten the moment the user came back through a different door. This is why identity discipline belongs in the same governed, reviewed layer as event naming.

Every major analytics platform now ships some form of governance tooling, but they differ sharply in how they enforce, where in the pipeline enforcement happens, and what plan tier it requires. The comparison below maps the five most relevant platforms across the governance dimensions that actually determine whether your taxonomy holds. Every cell is drawn from primary vendor documentation.

Two structural choices separate these tools. The first is where validation runs: PostHog and Avo push it left to compile time via generated, type-safe code (Avo Codegen produces type-safe code in 12 languages, with events and properties named identically across every platform and codebase), while Segment Protocols validates at ingestion using JSON Schema. The second is what happens on a violation — covered next, because Segment’s answer is the most consequential and the most misunderstood.

Here is the insight most content on this topic misses. The most common tracking-plan failure mode is not technical — it is organizational. The plan exists. It is just not enforced. Engineers implement tracking under deadline pressure without consulting it, the plan and the reality diverge, and you arrive at the state where the plan is worse than no plan at all because it provides false confidence. A document cannot prevent this. Only a gate can.

The governance shift that works is to treat tracking like code: integrate event testing into your existing CI/CD and unit-testing workflows, require code review for any tracking change, and run regular audits of event volume and property completeness. Without governance, entropy wins — the question was never whether tracking will degrade, only how fast. PostHog operationalizes this concretely: generate typed definitions (TypeScript, Go, Python) from your property groups via posthog-cli exp schema pull, then commit the posthog.json schema file and the generated types to version control so the whole team stays in sync and every tracking call is checked at compile time.

The practical artifact is a pull-request review checklist that turns the abstract plan into a pass/fail gate on every change that touches tracking:

That last check is the one teams skip most. Renaming an event without a migration plan does not fix a naming problem — it creates two broken time series where there was one. The disciplined move is to ship the new event alongside the old, run both until the dashboards are migrated, then formally remove the deprecated event. This is the difference between an organization that has a tracking plan and one whose plan still describes reality a year later. If you want this gate built into your stack rather than maintained by hand, our analytics engineering engagements start by wiring schema validation into CI before the first event ships.

If GA4 is anywhere in your stack, its limits are not guidelines — they are hard constraints the platform enforces, and a taxonomy that ignores them silently loses data. These are the ones that bite most often.

A few rules within those limits trip teams up repeatedly. GA4 event names are case-sensitive — my_event and My_Event are distinct, the same fragmentation trap as Amplitude — must start with a letter, may contain only letters, numbers, and underscores, may not begin with ga_, firebase_, google_, or gtag., and may not contain spaces. Worth noting on the distinct-name limit: web streams are effectively unlimited, but app streams cap distinct event names at 500 per app user — always qualify which stream you mean before claiming GA4 has no event-name ceiling.

One operational gotcha sits in custom dimensions: deleting one does not free its slot immediately. The dimension enters an archived state, and the slot only becomes available again after 48 hours. If you are juggling near the 50 event-scoped limit, plan that delay into any reshuffle. For the full GA4 picture — including how these event limits and schema constraints flow into warehouse-grade analysis — see our reference on GA4's event limits and schema constraints.