A data analyst who can only retrieve and visualise data is useful. An analyst who can design the metrics a business should be tracking — and explain why — is indispensable. The difference is a working knowledge of metrics frameworks: how to choose what to measure, how to structure metrics so they explain each other, and how to prevent the common failure modes where teams optimise a metric at the expense of actual business health.
This chapter covers the complete toolkit: North Star metrics, metric trees, input vs output metrics, leading vs lagging indicators, counter-metrics and guardrails, OKR alignment, and the practical questions to ask before you build any dashboard.
Why Most Metrics Frameworks Fail
Most teams have too many metrics, not too few. They track everything they can measure rather than what they should measure. The result is dashboards nobody reads, weekly reports that generate questions but no decisions, and analysts spending most of their time answering "why did this number change?" rather than "what should we do next?"
A well-designed metrics framework solves this by creating a hierarchy: one North Star metric that captures business health, a small set of driver metrics that explain it, and guardrail metrics that flag when you are trading one thing for another. Every number has a job. Every number connects to a decision.
The North Star Metric
The North Star metric (NSM) is the single number that best represents the core value your product delivers to customers. It should be:
Value-reflecting
Measures actual value delivered to the customer, not internal activity or vanity metrics
Predictive of revenue
When it goes up, revenue follows — but it is not revenue itself (which lags customer behaviour)
Actionable
Teams can run experiments and initiatives that directly move it
Understandable
An engineer, a salesperson, and a customer success manager can all understand it without a data dictionary
North Star examples by business type
| Business type | North Star metric | Why this, not revenue? |
|---|
| B2B SaaS | Weekly active accounts | Revenue lags adoption; active accounts predict retention and expansion |
| E-commerce | Orders delivered on time | Captures both demand AND operational fulfilment — both needed for loyalty |
| Edtech platform | Lessons completed per learner per week | Completion drives outcomes; outcomes drive word-of-mouth and renewals |
| Fintech / lending | Approved loans disbursed per month | Measures the full funnel — application, approval, and disbursal all have to work |
| Marketplace / logistics | GMV of fulfilled orders | Unfulfilled orders don't count; this captures both supply and demand health |
| Recruiting / HR tool | Positions filled per quarter | Reflects the core job-to-be-done — nobody buys an ATS for the ATS |
Metric Trees: Decomposing the North Star
A metric tree breaks the North Star into its component parts, creating a structured way to diagnose what is driving changes and where to focus effort. The tree has three levels:
NORTH STAR: Weekly active learners (WAL)
│
├─ New learners activated this week
├─ New sign-ups → lesson 1 conversion rate
└─ Acquisition channel volume (organic / paid / referral)
│
├─ Retained learners (active last 4 weeks AND this week)
├─ Week-over-week retention rate by cohort
├─ Lessons completed per session
└─ Streak continuation rate
│
└─ Resurrected learners (inactive ≥2 weeks, active this week)
├─ Re-engagement email open → click rate
└─ Push notification click-through rate
With this tree, when WAL drops, you immediately know whether to look at acquisition, retention, or resurrection — rather than having to interrogate a dozen disconnected dashboards.
Input vs Output Metrics
Output metrics measure results (revenue, WAL, NPS). Input metrics measure activities that should cause those results (calls made, lessons published, support tickets resolved in under 2 hours). Most dashboards track outputs only. Good frameworks balance both.
Input (leading) metrics
Teams can directly control these. They move first — before output metrics change. Use them to catch problems early and to give teams agency over metrics they own.
Examples: daily posts published, support response time, experiments launched per sprint, onboarding calls completed
Output (lagging) metrics
Teams cannot directly control these — they result from input activities. They tell you whether past inputs worked, but by the time they move, the cause is usually weeks old.
Examples: monthly revenue, churn rate, NPS, quarterly active users, customer acquisition cost
The analyst's job:Find the input metrics that are statistically correlated with the outputs your leadership cares about, with a lag of weeks or months. These become your early-warning system. A decline in "new content published per day" today predicts a decline in organic traffic 6–8 weeks from now — that's an actionable lead indicator.
Counter-Metrics and Guardrail Metrics
Counter-metrics exist to prevent optimising one metric at the expense of something equally important. Guardrail metrics are the things you must not break while pursuing the North Star.
Growth team optimises for sign-ups
⚠️ Risk: They run aggressive ads that attract users who never complete onboarding, driving up acquisition cost and killing retention
COUNTER METRIC
Day-7 lesson completion rate
GUARDRAIL
Cost per activated learner (not cost per sign-up)
Support team optimises for tickets closed per day
⚠️ Risk: They close tickets quickly without fully resolving issues, boosting the count but wrecking customer satisfaction
COUNTER METRIC
Re-open rate (same issue within 7 days)
GUARDRAIL
CSAT score on closed tickets
Sales team optimises for deals closed
⚠️ Risk: They close low-quality customers who churn within 90 days, increasing ARR temporarily but destroying net revenue retention
COUNTER METRIC
90-day churn rate by sales rep
GUARDRAIL
Average contract value × retention probability
Aligning Metrics with OKRs
OKRs (Objectives and Key Results) set the direction; metrics measure the movement. The alignment looks like this:
Objective: Make the learning experience genuinely sticky for working professionals
│
KR1: Increase 4-week retention from 38% → 55%
→ Metric: cohort retention at day 28, tracked weekly
│
KR2: Grow average lessons per active user from 2.1 → 3.5 per week
→ Metric: median weekly lessons, segmented by learning goal
│
KR3: Reduce "no activity in 7 days" from 52% → 35% of registered users
→ Metric: 7-day inactivity rate, with funnel breakdown
Common OKR-metrics misalignments to avoid
✗KRs that are outputs only: Pair each output KR with the input metric that drives it — otherwise teams have no lever to pull
✗KRs nobody knows how to calculate: Every KR needs a metric definition document before the quarter starts: what exactly counts, what is excluded, which table and logic produce the number
✗Too many KRs: 3 KRs per objective maximum. More than that and teams lose focus — and you cannot track everything well anyway
✗KRs that move in the same direction as sandbag targets: If teams set targets they can hit in the first three weeks, they were set too low. Review targets quarterly with your manager
The Metrics Definition Document
Before publishing any KPI, write a metrics definition document. This prevents the most common source of analyst friction: two people showing different numbers for the "same" metric because they made different assumptions.
METRICS DEFINITION: Weekly Active Learners (WAL)
Definition: Count of distinct user_ids who completed ≥1 lesson in the 7 calendar days ending on the reporting date
Included: All subscription tiers; all lesson types (video, quiz, practice); all devices
Excluded: Internal test accounts (email domain @evikaacademy.com); accounts marked is_deleted = 1; preview/demo sessions
Data source: events.lesson_completions table; event_type = 'lesson_complete'
SQL:
SELECT COUNT(DISTINCT user_id)
FROM events.lesson_completions e
JOIN users u USING (user_id)
WHERE e.completed_at BETWEEN :week_start AND :week_end
AND u.email NOT LIKE '%@evikaacademy.com'
AND u.is_deleted = 0
Owner: Growth analytics team
Last updated: 2026-10-19 | Reviewed: quarterly
Presenting Metrics to Stakeholders
Accurate metrics presented badly are useless. Here is the structure that reliably produces decisions, not discussions:
1. Lead with the change, not the current value
"WAL is 4,200 this week" tells someone a number. "WAL dropped 8% week-over-week — the largest single-week decline in Q3" creates urgency and context.
2. Immediately follow with the cause
Do not present a number and then say "we're investigating." Come to the meeting with a hypothesis. Even "we believe the drop is driven by cohort X because Y" is better than an undiagnosed change.
3. Show the metric in context of its target and trend
One number is meaningless. Show: current value, target, last period, same period last year (where applicable), and the trend direction. A dashboard without targets is just a number board.
4. Separate observation from recommendation
"The data shows X" and "I recommend Y" are different statements. Be explicit about which one you are making. Stakeholders need to know when you are stating a fact versus expressing an opinion.
5. End with a decision question
Every metrics presentation should end with "Given this, do we want to [specific action]?" If your presentation ends without a decision point, it was a report — not an analysis.
A Metrics Audit: Questions to Ask Before Building Any Dashboard
1
What decision will this dashboard inform? (If none, it shouldn't exist.)
2
Who is the primary audience — and what is their level of data literacy?
3
What is the update frequency this audience needs — real-time, daily, weekly?
4
Does this metric have a written definition that everyone agrees on?
5
Is there a target this metric should be measured against?
6
What is the counter-metric or guardrail that prevents gaming this metric?
7
Who owns this metric — who is accountable when it moves unexpectedly?
8
Is this a leading or lagging indicator? Does the audience understand which?
Learn to Build Metrics That Matter
EVIKA ACADEMY · Sector 51, Noida · Live classes online & offline