Product & DesignFree
Product Analytics Event Tracking Audit
Your taxonomy has 412 events. 245 still fire, 89 of those feed a report anybody reads, and 28 of those 89 are wrong.
River's tracking audit joins two things that normally live apart: the event taxonomy and the list of things that actually consume it. Dashboards, saved reports, cohort definitions, warehouse models and alerts all go in alongside the event catalog. What comes back is a severity order, because a broken event is only as urgent as whatever reads it. In the worked audit, 412 defined events produced 245 that still fire, 89 that feed something anybody looks at, and 28 of those 89 that are wrong.
Consumption is the signal, and the analytics vendors know it. Mixpanel's own governance surface reports "the total UI and API queries in the last 30 days" for every event. The stated purpose is that it "lets you easily discover the parts of your implementation that are most valuable and the parts that are not being used". Almost nobody reads that column. In the worked audit, 156 active events fed nothing at all, and they accounted for 41% of monthly event volume.
Built for the product or data lead who has just been asked why two dashboards disagree, and for the quarter before a migration when somebody has to decide what is worth reimplementing. Run it before the metric definitions pack settles what each number means, and before OKRs commit to targets nobody can query. Findings feed straight into the funnel analysis and the feature adoption review, both of which are only as trustworthy as the events underneath them.
The alert that stopped firing looks exactly like good news
Every tracking audit in circulation grades events on their own health: is it firing, is the volume stable, are the properties populated. That produces a list sorted by how broken things are, which is the wrong order. An event with 4% property coverage that nothing consumes is harmless. The same event powering the board deck is a wrong number in front of the board. Crossing health against consumption splits 245 active events four ways, and only one of the four quadrants is urgent.
Two failure modes hide better than the rest. A duplicate set is the first: booking creation fired as three differently named events in the worked audit, each consumed by a different report, returning 8,410, 7,932 and 9,077 bookings for the same week. Nobody was wrong and nobody could reconcile it. The second is worse, because an event that stops firing produces silence, and a billing alert that has not fired in 41 days is indistinguishable from a month with no failed payments.
The taxonomy itself is the third finding. Of 412 defined events, 71 were never implemented and 96 have not fired in 90 days, so two fifths of the tracking plan describes instrumentation that does not exist. Growth without pruning has a hard edge: Google Analytics caps event parameters at 25 per event and simply does not log what exceeds it. And hiding an unused event does not stop it costing you, because hidden events keep being ingested.
How it works
Send the catalog
A Lexicon or taxonomy export, a tracking plan, or a warehouse schema. Volumes and last-seen dates if you have them.
Name the consumers
Dashboards, saved reports, cohort definitions, alerts and warehouse models. A list of names is enough to start.
Cross the two
Each event is graded on health and on consumption, which splits the active set into four very different piles.
Read the order
Broken and consumed first, ranked by what reads it. Then the duplicates, then what to stop sending.
What you get
- Every event with volume, last-seen date, property completeness and the reports that consume it
- A severity order driven by what reads the event, not by how broken the event is
- Duplicate sets grouped by the action they measure, with the spread between their answers
- Events that stopped firing, flagged against the alerts and dashboards still reading them
- The unconsumed set sized as a share of monthly event volume, so pruning has a number
- The rows of the tracking plan that were never implemented or have gone dead
Common questions
Why does consumption change the priority order?
Because a broken event nobody queries costs nothing to leave broken, and a slightly broken event feeding the exec weekly is a wrong number in front of the board. In the worked audit, 38 broken events were consumed by nothing at all. Sorting on health alone puts those at the top and buries the 28 that matter.
What counts as a consumer?
Anything that reads an event and shows the result to a person or a system: saved dashboards, scheduled reports, cohort and audience definitions, alerts, warehouse models, reverse ETL syncs and experiment metrics. Alerts matter most, because an alert reading a dead event goes quiet and quiet looks like good news.
We do not have a tracking plan. Can it still run?
Yes. The event catalog from your analytics tool is enough, and the absence of a plan becomes one of the findings. Where a plan does exist, comparing it against what actually fires is usually the fastest result: two fifths of the worked plan described instrumentation that had never shipped or had gone quiet.
How does it find duplicate events?
By grouping on the user action rather than the name. Casing and convention drift, provider migrations and two teams instrumenting the same button all produce sets like booking_created, Booking Created and job_booked. The useful output is the spread between what each one reports, which in the worked audit was 14.4% for the same week.
Can we just hide the events we do not use?
Hiding removes them from the interface, not from the bill. Mixpanel is explicit that hidden events "continue to be ingested in your project and count toward your data allowance". Stopping the cost means stopping the send, which is a client change, so the audit sizes the unconsumed set by volume to make that work schedulable.
What do we do with the findings?
Four lists, in order: fix the broken-and-consumed events, reconcile each duplicate set onto one canonical event, stop sending what nothing reads, and delete the plan rows that were never implemented. Then settle what each surviving number means: the metric definitions pack for what a number means across the company, and the product metrics definition pack for which of these events compute it, on which platforms.
Product Analytics Event Tracking Audit
Fill in the form and your workspace opens with the work already underway.