The Tracking Problem That Wasn't a Tracking Problem

"We need a tracking concept."

That's how the conversation started. A B2B SaaS company for project management, solid product, growing user base. The request seemed clear:

• What data should we track?
• What schema should we use?
• What reports do we need?

Three questions. All wrong.

What They Wanted vs. What They Needed

The request:

"We want to measure impact when we make changes, understand user behavior, and enable different stakeholders to make data-driven decisions."

The actual problem: Nobody had defined what those decisions should be.

"Measure impact" – and then? What happens if the impact is negative? Who decides? At what threshold?

"Understand user behavior" – for whom? The CEO needs different insights than the Product Owner. Without stakeholder mapping, you get a dashboard nobody uses.

"Data-driven decisions" – which decisions? Without defined options, there's no decision. Just observation.

The Reframe: From Events to Decisions

The real question is never "What do we track?"

The real question is: "What decision are we trying to make – and what signal would change it?"

A tracking concept without decision logic is just a list of events. Nothing more.

What an Evidence Brief Delivers

Instead of an event list, an Evidence Brief delivers:

1. A Target Metric – With a Threshold

The "One Metric That Matters" concept comes from Lean Analytics. The idea: Focus on one metric per phase instead of a KPI zoo.

The problem: A metric without a decision threshold is just a number on a dashboard.

Not: "Our target metric is Activation."

But: "If Activation drops below 35%, we pause the rollout and analyze drop-off points."

2. Guardrails With Thresholds

Not "monitor churn". But: "If churn > 3% → stop rollout, start root cause analysis."

3. Maximum 12 Signals

Only events that would change the next step. Everything else is noise.

4. If/Then Logic

For each metric: What do we do if it's above/below the threshold? Who's responsible? By when?

5. Stakeholder Mapping

CEO sees the target metric and guardrails. Product Owner sees the signals. Nobody needs everything.

The Difference

Why Tracking Projects Fail

Teams that want a "tracking concept" often get exactly that: a list of events, a schema, a dashboard.

Six months later:

• Nobody looks at the dashboard
• Decisions are still made from gut feeling
• Tracking is labeled "not helpful"

The problem was never the tracking. The problem was: Nobody defined upfront what decision the data should enable.

Conclusion

"We need a tracking concept" is almost never the right request.

The right request is: "We have a decision ahead of us – and don't know what signal would help."

An Evidence Brief answers that:

• One target metric with a threshold
• 2-3 guardrails with trigger points
• Maximum 12 signals that would change the next step
• If/Then logic for each metric
• One owner per decision

Everything else is an event list with hope.