Event Taxonomy
Data & TrackingAlso: Tracking Plan · Event Schema
Quick definition
Event taxonomy is the naming and structure rulebook for how a business labels the things people do on its website or app, such as sign_up, add_to_cart or button_click. It defines event names, required properties and consistent formatting so tracking data can be trusted and compared over time.
How it varies across Australia
Most Australian businesses build their event taxonomy reactively, adding events as campaigns need them rather than planning the structure upfront. The businesses with the cleanest attribution and conversion rate reporting are almost always the ones that documented their taxonomy before building it in Google Tag Manager, not after.
See data and tracking maturity across Australian industries →What it actually means
Imagine a warehouse where every worker labels boxes however they like. One writes 'signup', another writes 'Sign_Up', a third writes 'new_user_created'. Nobody can run inventory because the same box has three different names depending on who packed it. That's what most tracking setups look like without an event taxonomy.
An event taxonomy is the agreed naming convention for every trackable action. It defines the event name (sign_up, not Signup or new_user), the properties that must travel with it (plan_type, source, value), and the casing rules everyone follows. It sits underneath GA4, your data layer, your customer relationship management (CRM) system and any customer data platform (CDP) you run.
Without it, attribution reporting quietly breaks. A conversion event fires as purchase on the website and Purchase in the app. Reports split the same action into two rows. Segmentation becomes guesswork because nobody trusts whether the data is actually complete or just inconsistently labelled.
The fix isn't a tool. It's a document, agreed before anyone opens Tag Manager, that survives staff turnover and platform migrations.
An event taxonomy is a filing system. Build it after the mess and you're relabelling boxes forever.
How it shows up
Event taxonomy shows up as a spreadsheet or Notion doc listing every event name, its trigger, its required properties and an owner. It shows up in GA4 as consistently named events instead of duplicates like checkout_complete and CheckoutComplete sitting side by side. It shows up in the data layer as a predictable object shape every developer follows without asking.
It also shows up in the gaps. When a new campaign launches and someone has to guess what to call the event, or when two teams build the same tracking twice because neither knew the other existed, that's a missing taxonomy revealing itself.
The Australian context
Australian businesses running both a website and app commonly split tracking between two teams with no shared taxonomy document, which is where the worst duplication happens. It's also worth building consent state into every event definition from the start, given the Privacy Act amendments are pushing more Australian sites toward explicit consent tracking rather than retrofitting it later.
Where people get this wrong
Related terms
Common questions
What should an event taxonomy document include?
Every event name, the trigger that fires it, required properties, expected values, casing rules and an owner. Some teams add a status column showing whether the event is live, planned or deprecated so nobody rebuilds something that already exists.
Who should own the event taxonomy?
Usually whoever owns analytics or data and tracking, working with a stakeholder from marketing and one from product or engineering. It needs a single owner with authority to reject inconsistent naming, otherwise every team quietly does its own thing again.
How is event taxonomy different from a data layer?
The data layer is the technical structure that carries the data on the page. The event taxonomy is the naming and property rules that decide what goes into that structure. One is the container, the other is the contents list.
Do small businesses need a formal event taxonomy?
Yes, even a simple one. A single shared spreadsheet with ten event names and their properties prevents the duplication that shows up later once tracking grows. It's far cheaper to build early than to untangle after two years of inconsistent tagging.
Debrief
Get the next one
No spam. No fluff. Just the next article, straight to your inbox.
Keep exploring
About New Rebellion
New Rebellion is a marketing intelligence consultancy. We build tools, score Australian businesses on how their marketing actually performs, and publish Debrief every day. This dictionary is part of how we work in the open.
How we think →