Track only the events tied to a decision you'll actually make this quarter, log the assumption behind each metric when you form it, and delete everything else. Most tracking bloat is really an unexamined-assumption problem: someone instrumented an event "just in case" and never recorded what decision it was meant to inform.
Quick Answer: A minimalist analytics strategy means instrumenting only events tied to a specific decision, running a scheduled prune, and logging the hypothesis behind each metric before you build it — not reconstructing it from memory once a dashboard goes stale.
Why Tracking Fatigue Happens
Tracking fatigue happens when a team instruments events faster than it retires them, because adding an event feels free and removing one feels risky. It's common for a mature product to end up wired with 2,000 or more events, of which barely a dozen get queried in a typical month — the rest sit as dead weight everyone pays to store, index, and scroll past.
This is an old failure mode wearing a new coat of paint. Eric Ries named the underlying problem in The Lean Startup: teams gravitate toward "vanity metrics" — numbers that go up and to the right regardless of whether the product is actually improving — because they're easy to log and flattering to report. Event sprawl is vanity metrics at instrumentation scale: track enough things, and something always looks good.
Avinash Kaushik, one of the most cited voices in web analytics, has made a related point for two decades: most analytics implementations are over-instrumented and under-analyzed, producing reports nobody reads because nobody defined the question before building the report. Volume of data was never the goal. One more good decision was.
Symptoms of tracking fatigue tend to show up in a predictable order:
- Query paralysis — a PM opens the analytics tool, sees hundreds of events, and can't tell which one answers their question.
- Dead events — properties still firing from features that shipped and were killed two years ago.
- Duplicate logic — three engineers each add a near-identical
button_clickedevent because nobody could find the existing one. - Trust erosion — once one number is caught being wrong, teams start double-checking everything, which is slower than having no data at all.
- Rising cost — most usage-based analytics tools price on event volume, so bloat is a literal line item, not just a UX problem.
None of this is really an engineering failure. It's a discipline failure: nobody owns the decision to say no to a new event.
The bill for that discipline failure lands in more than one budget line. Engineering time goes into maintaining schema for events nobody queries. Data teams spend cycles debugging pipelines for dead instrumentation instead of building anything new. And every new hire spends their first month guessing which of the 2,000 events is the "real" one, because no one wrote that down either.
Start From Decisions, Not Data Points
The minimalist method inverts the usual instrumentation habit: instead of asking "what could we track?", start with "what decision am I trying to make, and what's the smallest signal that would move it?" Every event on the plan should trace back to a named decision-maker and a named decision.
That reframing does most of the pruning automatically, because most proposed events fail the test on contact — nobody can say what decision they'd inform. A practical four-step version:
- List the decisions, not the metrics. "Should we keep the new onboarding flow?" is a decision. "Onboarding completion rate" is a metric — derive it from the decision, not the reverse.
- Assign one owner per decision. If no one will act on the answer, the event doesn't get built. This alone kills most "nice to have" tracking requests.
- Pick the smallest event that resolves the decision, not the richest one. A single
onboarding_completedevent with atime_to_completeproperty usually beats five granular step events nobody will ever segment by. - Set a review or kill date at creation time. An event with no expiration is how you end up with 2,000 of them.
Choosing a single guiding metric first makes this test sharper — a North Star Metric gives every proposed event something concrete to justify itself against. Teams that skip this step tend to rebuild the same data-driven decision-making muscle from scratch every quarter, relearning which numbers actually move the business.
Consider a common request: "let's track every field a user edits in settings." Run it through the four steps and it usually collapses. What decision does field-level edit data inform? Often nobody can answer. What survives is a single settings_updated event with a field_name property — one event, not fifteen, and the property still answers "which fields get edited most" if that question ever turns out to matter.
The Minimalist Event Taxonomy: What Earns a Place in Your Tracking Plan
A minimalist tracking plan rarely needs more than 15-20 events to run a product, because most decisions cluster around the same handful of moments: someone arrives, activates, comes back, pays, refers a friend, or leaves. Nearly everything else belongs as a property on one of those events, not a new event of its own.
The table below is a starting taxonomy, not a mandate — swap the specific event names for your product's own, but keep the discipline of one event per decision-worthy moment:
| Journey Stage | Example Event | Decision It Informs |
|---|---|---|
| Acquisition | signup_started | Is the top of funnel converting from the channels we're paying for? |
| Activation | first_value_moment | Did the user reach the "aha" point, and how long did it take? |
| Engagement | core_action_completed | Is the primary workflow being used repeatedly, or once and abandoned? |
| Retention | session_started (7/30-day) | Are users coming back without a prompt? |
| Monetization | plan_upgraded | What triggers a user to pay or expand? |
| Referral | invite_sent | Is the product growing itself? |
| Friction | error_encountered | Where is the product actively losing people? |
| Churn signal | feature_usage_dropped | Who's at risk, and can we intervene before cancellation? |
Eight rows, roughly a dozen actual events once you split a couple by platform — close to the "twelve events you actually use" reality most teams eventually converge on, however many hundreds they started with.
Mapping events this way only works once you've thought through the path a user actually takes, which is why customer journey analytics and event taxonomy design are really the same exercise seen from two angles. A vanity-metrics audit is the fastest way to check whether an existing event belongs on this table or should be retired: if it can't be tied to one of these rows, it's decoration.
Events vs. Properties: The Distinction That Prevents Most Sprawl
The single biggest lever for staying minimal is knowing when a new signal should be a property on an existing event rather than a brand-new event. A new event is warranted when the moment itself is new — a user did something categorically different. A new property is warranted when you're just adding detail to a moment you already capture.
- New event: a user upgraded their plan (
plan_upgraded) — this is a distinct moment with its own timing and triggers. - New property, not a new event: which plan tier they upgraded to, what payment method they used, whether it was annual or monthly — all of these are properties on the same
plan_upgradedevent.
Most tracking-plan bloat comes from treating every new property as an excuse to spin up a parallel event instead. plan_upgraded_annual, plan_upgraded_monthly, and plan_upgraded_enterprise should almost always be one event with a billing_cycle property, not three events that now all need separate maintenance.
Where Bad Events Come From: The Assumption You Never Wrote Down
Most analytics mistakes don't originate in the tracking plan — they originate earlier, in an assumption someone made and never wrote down. "Users will drop off if onboarding takes more than three steps" becomes an event, then a dashboard, then a roadmap decision, without anyone ever recording that it started as a guess.
That matters because an unlogged assumption is invisible to scrutiny. Nobody can challenge a hypothesis they don't know exists, and nobody can check, months later, whether it held up. Teresa Torres, in Continuous Discovery Habits, argues that the habit separating strong product teams from weak ones isn't better tooling — it's explicitly surfacing and testing assumptions before they harden into "known facts" nobody remembers questioning.
The pattern shows up constantly in tracking-plan bloat:
- A PM assumes a feature will drive retention, so five events get added to prove it.
- The feature ships, the events fire, and the hypothesized effect never shows up.
- Nobody revisits the original assumption, because it was never written down anywhere queryable — so the events stay, unexplained, indefinitely.
Working through a Jobs to Be Done analysis before instrumenting is one structural fix, because JTBD forces the assumption into the open: "we believe users hire this feature to do X" is a falsifiable claim, not a vibe. Pair it with a full customer journey map and most proposed events can be pressure-tested against a sequenced hypothesis instead of a hunch from a hallway conversation.
Logging the Assumption Before You Log the Event
The fix for assumption-driven tracking bloat is procedural, not aspirational: write the hypothesis down, with a timestamp, before the event goes into the tracking plan — not during a retro three months later, when nobody remembers exactly what they believed.
Analytics debt compounds the same way technical debt does: quietly, and mostly through decisions nobody wrote down at the moment they were made.
In practice, this is where most teams fail — not because they undervalue the discipline, but because capturing a fleeting assumption mid-conversation or mid-standup is friction, and friction loses to "I'll write it up later." Later rarely comes. When it does, memory has already smoothed the original hypothesis into whatever the outcome turned out to be.
This is the specific gap Prodinja's Journals are built around. A Journal entry lets you log a metric hypothesis or an analytics assumption the moment you form it — including with real browser voice capture, so you can talk through the reasoning out loud instead of stopping to type — and it's timestamped automatically. Weeks later, when the event data comes back, you're checking it against what you actually predicted, not a reconstructed memory of what you probably thought at the time.
That distinction is the whole point of a minimalist tracking strategy: fewer events, each one anchored to a claim you can actually go back and verify.
Running the Quarterly Prune: Keeping the System Minimal
A minimal tracking plan doesn't stay minimal on its own — it needs a scheduled prune, because every feature launch is a natural occasion to add "just one more event," and nobody schedules time to remove one to compensate.
Amplitude, whose product analytics guidance is built on patterns observed across a large base of teams building tracking plans, has made a version of the same observation for years: the events a team actually queries for decisions are a small fraction of what's instrumented, and the gap widens every quarter it goes unaudited. A quarterly review is the counterweight.
A workable comparison for spotting where your own system sits:
| Signal | Tracking Fatigue | Minimalist System |
|---|---|---|
| Events instrumented | Hundreds to thousands | Roughly 15-20 core events |
| Events queried monthly | A small minority | Most of them, by design |
| Ownership | Unclear or collective | One named owner per event |
| Documentation | Tribal knowledge | Assumption + decision logged at creation |
| Review cadence | Never, until something breaks | Quarterly, scheduled |
| New event process | Anyone can add one | Tied to a stated decision, reviewed before ship |
Run the prune as three questions per event, asked out loud in a recurring meeting:
- Who queried this in the last 90 days, and for what decision? No answer, no keep.
- Does this map to a row in the taxonomy — acquisition, activation, retention, monetization, referral, friction, churn? If not, it's likely duplicating another event under a different name.
- Was the original assumption behind this event ever validated? If the hypothesis was disproven and nobody acted on that, the event is now noise with a timestamp attached.
Google's HEART framework, from Kerry Rodden, Hilary Hutchinson, and Xin Fu's widely cited 2010 UX research, makes a related structural point: pick one metric per dimension — Happiness, Engagement, Adoption, Retention, Task success — rather than instrumenting everything adjacent to each. "One metric per goal" is itself an anti-bloat mechanism, and it generalizes well past the five categories Google originally proposed.
The Privacy Dividend of Fewer Events
Fewer events isn't just an internal-tidiness argument — it directly reduces regulatory exposure. Every event that captures user behavior is a data point a privacy regulation like the EU's GDPR or California's CCPA may classify as personal data, subject to consent, retention limits, and deletion requests.
A tracking plan with 2,000 events means 2,000 potential surfaces to audit when a user files a deletion request or a regulator asks what you collect and why. A tracking plan with 15-20 well-documented events, each tied to a stated decision, is dramatically easier to defend, document, and honor deletion requests against — minimalism and compliance point the same direction.
Key Takeaways
- Instrument from decisions backward, not from "what could we measure" forward — every event should trace to a named owner and a named decision.
- A minimalist tracking plan rarely exceeds 15-20 core events; most teams converge near a dozen once acquisition, activation, retention, monetization, referral, friction, and churn are each covered once.
- Most tracking bloat starts as an unlogged assumption — a hypothesis nobody wrote down, checked, or retired once it was proven wrong.
- Log the hypothesis before you log the event, timestamped, so a later review checks data against a real prediction instead of a reconstructed memory.
- Schedule a quarterly prune. Event volume only ever grows by default; someone has to actively choose to remove.
- Borrow structure from named frameworks — a North Star Metric, JTBD, or HEART — instead of reinventing "what's worth tracking" from scratch every cycle.
Frequently Asked Questions
How many events should a product actually track?
Most products can run on roughly 15-20 core events once acquisition, activation, engagement, retention, monetization, referral, and churn are each mapped to one event. More granular properties on those events usually cover what a dedicated new event would otherwise capture.
What's the difference between analytics fatigue and healthy instrumentation growth?
Healthy growth adds an event because a specific decision needs it and retires others on a schedule. Analytics fatigue is asymmetric — events get added freely and almost never removed, so the tracking plan grows regardless of whether anyone uses what's already there.
Should every button click be tracked?
No. Track the clicks that resolve a specific decision — did users find the primary action, did they abandon a specific step — and skip the rest. A generic button_clicked event is usually a sign the underlying decision was never defined before instrumenting.
How do I clean up an already-bloated tracking plan without breaking existing dashboards?
Audit query logs first to see which events anyone actually uses, deprecate (don't delete) unused events for one full reporting cycle so nothing breaks silently, and require a stated decision and owner before any replacement event goes live.
Does a minimalist approach work with tools like Google Analytics 4 or Amplitude?
Yes. The taxonomy and audit discipline are tool-agnostic — GA4, Amplitude, Mixpanel, and Segment all support the same decision-first event design. The minimalism comes from process discipline, not a specific platform's feature set.