Webclat / Tealium Practice

Event tracking in Tealium: taxonomy first, tags second

Event tracking fails in the design, not the deployment. If the taxonomy is not specified - names, attributes, owners, versions - then every tag, connector, and dashboard invents its own dialect, and the estate spends years reconciling numbers that were never the same measurement.

The taxonomy is the product

A Tealium event tracking implementation is, at its core, a specification document the platform enforces: which events exist, what each one means, which attributes it carries, and who owns it. The specification outlives every tool decision - it is what makes integrations mappable, profiles meaningful, and warehouse models sane. We write it before touching the container, and version it like code afterward.

The data layer: one object, one truth

Tealium reads a universal data object - the page's declaration of what is true right now: page type, product context, user state, transaction detail. Every tag and connector consumes that one object. The discipline is unglamorous and decisive: fields are named to standard, typed consistently, populated server-side where possible, and never duplicated with variant spellings. An estate's data layer quality is the ceiling on everything downstream.

What a working event spec looks like

EventFires whenCarries
page_viewEvery template renderpage_type, site_section, content identity
product_viewProduct detail renderproduct id, name, price, currency, category
add_to_cartCart add confirmedproduct fields + quantity + cart value
purchaseOrder confirmation, onceorder id, revenue, tax, shipping, items array
lead_submitForm success (not button click)form id, page context - never field values into analytics

The table is the shape, not the whole spec - a real taxonomy carries versioning, owner, and validation rules per event, and covers the lifecycle events your business actually decides with.

QA that catches drift

  • Runtime capture per template - the events that actually fire, with payloads, against the spec.
  • Duplicate-fire checks - purchase events especially; double-counted revenue is the classic silent failure.
  • Cross-destination reconciliation - the same event counted in GA4, the warehouse, and the ad platform, with deltas explained.
  • Release regression - re-run the capture on every publish; taxonomy drift arrives one release at a time.

Common questions

Is there a standard event taxonomy we should adopt?

Start from a recognized ecommerce/lifecycle schema shape and adapt deliberately - the value is not which standard, it is that exactly one is enforced. Multi-standard estates are the ones with reconciliation teams.

How many events should we track?

Fewer than most estates do. Every event costs governance; events nobody decides with are pure liability. The spec review's best output is usually the deletion list.

Can you fix an existing broken taxonomy?

Yes - by mapping current-state events to a target spec and migrating destination by destination with a reconciliation period, the same parallel-run discipline as a platform migration.

Does this cover mobile apps?

The taxonomy must - one specification across web and app, with per-platform implementation notes. Separate web and app taxonomies are how customer journeys become unjoinable.

Get an event spec your whole stack agrees on.

Taxonomy design or rescue, data layer specification, and the runtime QA that keeps them true release after release.

Review My Event Governance