Product & DesignFree
Product Analytics Event Tracking Audit
Share your event list and the dashboards that use it. Get a spreadsheet of every event and a fix list ordered by what each problem breaks.
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 one illustrative 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
Share the event list
An export from your analytics tool, a tracking plan, or a description. Volumes and last-seen dates help.
Name what reads them
Dashboards, saved reports, cohorts, alerts and warehouse models. A list of names is enough to start.
River compares the two
Each event is graded on its health and on whether anything reads it, which sorts them into four piles.
Fix in order
Broken events that feed something come first, then duplicates to merge, then events to stop sending.
What you get
- A spreadsheet of every event: how often it fires, when it last fired, and what reads it
- Fixes ordered by what each broken event feeds, not by how broken it looks
- Duplicate events grouped by the action they record, with how far their counts disagree
- Events that stopped firing, flagged against the alerts and dashboards still waiting on them
- The events nothing reads, sized as a share of your monthly event volume
- Tracking-plan rows that were never built or have since gone quiet, listed separately
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.
Built by
Chandler Supple
Co-founder & CEO, River
Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.
Product Analytics Event Tracking Audit
Describe what you need, add any files you have, and your workspace opens with the work already underway.