Event Taxonomy Pruning: When Fewer Events Mean Better Data

The event list has 140 entries. The team uses eleven. The other 129 arrived from a product analytics migration, three agencies, two app releases, and a “let’s track it in case” habit that nobody has broken. They cost money on an event-priced license, they confuse every new hire and every AI feature that reads the schema, and they hide the eleven that matter.

Every event is a promise that something downstream will read it. A taxonomy that has never been pruned is a list of broken promises. Pruning it is a two-day job with a method, and keeping it pruned is a rule the platform owner enforces.

Why fewer is better, not just cheaper

Cost is the visible reason. On an event-priced license, an event nobody reads is billed anyway. But the larger cost is legibility. A model, an agent, an analyst, or a new CRM manager reading 140 events has to guess which purchase event is real. Eleven events with clear names leave no room to guess.

There is a third cost: dead events are where errors hide. A broken source that stops sending a dead event is never noticed. A broken source that stops sending one of eleven is noticed by lunch.

Step one: the inventory with volume and readers

Fig 1 · Keep, fix, or retire · Volume and readers decide what happens to each event type

For every event type, fill in three columns: its volume in the last 30 days, the last date anything read it (a campaign, segment, report, or export), and the source that sends it.

Volume comes from the platform. Readers take longer: search every scenario condition, segment definition, report, aggregate, and export for the event name. It’s tedious, and it’s the most important step. Once the reader column is empty, “we might use it” stops being an argument.

Four categories fall out:

• Live and read. Keep. These are the taxonomy.

• Live, never read. The billable waste. Candidates to stop tracking.

• Read, zero volume. A broken source or a retired feature with a campaign still pointing at it. Fix the source or retire the reader.

• Zero volume, never read. Dead. Retire.

Step two: merge before you retire

Some “never read” events are duplicates of live ones under a different name: purchase, order_completed, and transaction from three integrations. Pick the one with the best properties, point the other sources at it, and retire the rest. The naming convention decides which name survives.

Some are status snapshots: a daily “points balance” event, a weekly summary. They are a property or an aggregate wearing an event’s clothes. Move the value to a profile attribute or a computed aggregate and stop the event.

Step three: retire with a soft period

Retiring isn’t deleting. For each event on the list, stop the source from sending it and leave the historical data in place. Then set retention so the platform deletes it once your reports no longer need it. Write the reason in the tracking plan next to the event name, with the date.

Thirty days of soft retirement, where the event stops arriving but nothing is removed, catches the reader you missed. If a report breaks, the event was read; restore the source and record the reader. If nothing breaks, the retention window runs out.

Step four: the properties inside the survivors

Pruning the list is half. The other half is the properties on the eleven that stay. A purchase event with 40 properties, twelve of them never read, is the same problem one level down. The same inventory applies: which properties do readers reference. Unused ones stop being sent. Used ones get their type and format checked against the plan, because a price as a string survives for years until a segment compares it to a number.

Keeping it pruned

The taxonomy regrows because adding an event is easy and nobody says no. The rule that stops it: no new event without a named reader. The request states which campaign, segment, or report will read it, and that reader is built in the same week. An event tracked for a use case that never ships is retired at the 90-day review.

The platform owner holds the rule. After the first pruning, the quarterly inventory takes an hour. The tracking plan lists every event with its reader next to it.

What it changes

Fewer events, lower usage, one purchase event, a schema a stranger can read. The quieter change: the team starts asking “who will read this?” before tracking anything. That question keeps the platform readable after the consultant leaves.

The takeaway

Inventory with volume and readers, merge duplicates and snapshots, retire with a soft period and a written reason, prune the properties inside the survivors, and refuse any new event without a reader. Two days the first time, an hour a quarter after. Every event that remains is a promise somebody keeps.

Read next

• Naming conventions that survive the third consultant. Which name survives when duplicates merge.

• The roles you need for a CDP program to work. The platform owner who holds the no-reader, no-event rule.

• How to run a CDP data audit in one week. Monday’s inventory is step one here.