Funnel instrumentation

Event taxonomy is the schema your analytics use to describe what users do on the site. It sounds boring and is in fact the load-bearing infrastructure for every CRO test, analytics dashboard, and growth model that depends on the data. Most teams treat it as an afterthought, then spend years dealing with the consequences.

The components:

• Event names. What you call each thing. “Add to cart” or “AddToCart” or “product.cart.add” - pick one convention and stick to it.
• Event properties. The structured data attached to each event. SKU, price, category, position in the page, variant, source. Same property names mean the same thing every time they appear.
• Event timing. When the event fires relative to the user action. The “purchase” event fires on checkout completion, not on order processing. Inconsistency between these causes analytics drift.
• User and session identifiers. Stable IDs that let you stitch events together across pages, sessions, and devices.

Why this matters for CRO

A/B test results depend on the events firing reliably and consistently across variants. If “purchase” fires on the checkout page in control but on the order confirmation page in variant, the conversion-rate comparison is meaningless. Variant-specific tracking bugs are one of the most common reasons tests produce non-replicable results.

The other major effect is on test velocity. A clean event taxonomy means new tests can rely on existing events rather than instrumenting from scratch. Each test takes hours of analyst time instead of days. Across a year, the difference between clean and messy instrumentation is dozens of additional tests in flight.

What a healthy taxonomy looks like

Concrete patterns:

• A single event spec doc that every team contributes to and pulls from. Either a wiki page, a typed schema in code, or both.
• Consistent naming conventions. Verb-led (“clicked.add_to_cart”) or noun-led (“addToCart”), but the same across the codebase.
• Required properties on every event. User ID, session ID, timestamp, source, device. Optional properties for the specific event type.
• Validation in the tracking layer. Events that don’t match the spec get rejected or flagged, not silently logged with corrupt fields.
• Versioning. When the taxonomy changes (and it will), document the change and the cutover date so historical comparisons stay interpretable.

Where it goes wrong

• Letting marketing tools auto-create events. Klaviyo, Meta, and Google all create their own events with their own naming, which then live alongside your structured taxonomy as a parallel mess.
• Adding events ad-hoc per test. Each test creates a one-off event that nobody else uses. Six months later there are 400 events, 200 of which fire once a year.
• Letting the taxonomy drift across platforms. GA4, your data warehouse, and your experimentation platform should all agree on what “purchase” means. They usually don’t.
• Treating instrumentation as an engineering task disconnected from analysis. The analyst who’ll use the data should help design the schema, otherwise the events fire but don’t answer the questions.