Data Strategy

From 40 metrics nobody trusts to a KPI framework that drives decisions

A marketplace scale-up had 40 metrics on its executive dashboard and zero decisions coming out of its Monday meeting. Here is how we rebuilt their KPI framework around one North Star and a tree of input metrics each team could actually move.

Forty metrics, zero decisions

The executive dashboard had 40 tiles. I counted them in the first meeting, because nobody else could tell me the number from memory - which was, in a way, the whole diagnosis.

This was a marketplace scale-up, around 290 people, growing fast. Every Monday the leadership team opened the dashboard, and every Monday the same ritual played out: marketing's "active users" was up 4%, product's "active users" was down 2%, and the first twenty minutes went to arguing about which number was right. Then the meeting ended, and no decision had been made.

Nobody trusted the dashboard, so everybody kept their own spreadsheet. Three teams had three definitions of an "active user," two definitions of GMV, and finance quietly maintained a fourth version of everything. The company didn't have a KPI framework. It had 40 opinions refreshing nightly.

Why "just clean up the dashboard" fails

The naive fix is a dashboard diet: delete tiles until it looks tidy. We've seen companies try this two or three times. The metrics grow back within a quarter, because the dashboard was never the problem - it was the symptom.

Metrics proliferate when there is no shared model of how the business grows. If nobody has agreed on what ultimately matters, every team defends its own scoreboard, because losing your tile means losing your argument in the Monday meeting. A KPI framework isn't a shorter list of metrics. It's an agreed causal story about the business, with numbers attached.

A dashboard with 40 metrics is not a measurement system. It is 40 unresolved arguments, refreshed nightly.

Start from the growth model, not the metric list

So we didn't start with metrics at all. We spent the first two weeks mapping the growth model: how does a euro of value actually get created here? For this marketplace, the loop was clear once drawn - buyers arrive, some experience the product's core value quickly, some come back, sellers respond to demand with better supply, which brings more buyers.

We structured it as the classic four stages - acquisition, activation, retention, monetization - and asked one question per stage: what single number tells us this stage is healthy? That exercise, done with the leadership team in a room (fine: a very long video call), produced more alignment in two workshops than two years of dashboard debates.

Choosing the North Star

A good North Star metric has three properties: it measures value delivered to users (not just extracted from them), every team can influence it, and it leads revenue rather than lags it. Revenue itself is a poor North Star - it's a result, arriving too late to steer by.

For this client we landed on weekly transacting users: unique buyers completing at least one purchase in a week. It captures both sides of the marketplace being healthy, it moves within weeks of a product or marketing change, and - after some honest modelling - it predicted next-quarter revenue far better than any single metric on the old dashboard.

The KPI tree: input metrics each team can move

The North Star alone changes nothing, because no single team can move it directly. The power is in the tree beneath it: each team gets two or three input metrics they genuinely control, chosen so that moving them mechanically moves the North Star. Here is a simplified version of the tree we shipped:

Level Owner Metric Why it feeds the North Star
North Star Everyone Weekly transacting users Value delivered on both sides of the marketplace
Input Marketing Qualified new visitors per week Top of the funnel, quality-adjusted - not raw traffic
Input Product (activation) % of new users purchasing within 7 days The activation moment that predicts long-term retention
Input Product (retention) Week-4 repeat purchase rate Returning buyers compound into weekly transactors
Input Supply / Sales Listings with <24h seller response Responsive supply converts demand into transactions
Input Monetization Take rate on completed transactions Converts North Star health into revenue, watched as a guardrail

Notice what's not in the tree: vanity totals, cumulative anything, and metrics no team owns. Each row has one accountable owner and a plausible mechanism connecting it upward. If you can't explain the mechanism in one sentence, it's not an input metric - it's a hope.

Metric definitions as code

Now the unglamorous part that makes it stick. The three competing definitions of "active user" didn't exist because people were careless - they existed because every definition lived in a different BI tool, saved query, or spreadsheet. Prose definitions drift. Code doesn't.

So every metric in the tree was defined exactly once, in the dbt semantic layer, version-controlled and reviewed like any other code change:

metrics:
  - name: transacting_users
    label: Transacting Users (North Star)
    type: simple
    agg: count_distinct          # unique buyers
    expr: buyer_id
    filter: status = 'completed' # completed transactions only

That is the entire definition of the company's most important number: six lines, sitting in the same version-controlled repository as the data itself. Weekly, monthly or daily is chosen when someone asks the question - one definition, every time frame.

Every dashboard, every tool, every ad-hoc analysis now queries the same definition. Changing a metric means opening a pull request - visible, reviewed, and logged - instead of quietly editing a saved query at 11 p.m. before a board meeting. The Monday argument about whose number is right simply has nowhere to live anymore.

Fair warning: none of this works on top of a broken pipeline. For this client the semantic layer came after we had hardened their transformation project - very similar to the story I tell in rescuing a 2-year-old dbt project. Trustworthy definitions need trustworthy tables underneath.

The weekly rhythm: where metrics become decisions

A KPI framework earns its keep in a meeting, or not at all. We redesigned the Monday session around one page: the North Star trend, the input metrics with owners, and a hard rule - every metric that moves beyond its normal range gets exactly one of three responses: explained, investigated (owner + date), or acted on. No metric gets silently admired.

The investigations are where the tree pays off. When week-4 repeat rate dipped, the owner didn't guess - we broke it down with cohort-based retention analysis and traced it to an acquisition-mix shift, not a product problem. The tree tells you where to look; the analysis tells you what you found.

Results

What to take away

If your dashboard has 40 metrics and your meetings produce no decisions, the fix is not a prettier dashboard. Agree on the growth model first. Pick one North Star that measures delivered value. Give every team input metrics they can actually move, with one owner each. Define everything once, as code. Then build a weekly rhythm where numbers must end in explanations or actions.

The goal was never more measurement. Fewer metrics, more decisions.

Drowning in metrics nobody trusts?

Satyadata helps scale-ups define a North Star, build the KPI tree beneath it, and lock the definitions into code - typically in four to six weeks. Tell us what your Monday meeting looks like today.

Start a conversation