Sales & Revenue Performance Analytics Questions
Analyzing and reporting how the commercial engine is performing, from the descriptive-analytics seat. Covers defining and computing sales and revenue KPIs (MRR, ARR, bookings versus billings versus recognized revenue, NRR/GRR, logo and revenue churn, ACV, ARPA, DSO, run rate, magic number), including the SQL behind them; retention and cohort analysis of customers, leads and opportunities; sales funnel and pipeline analysis (stage conversion, win rate, deal velocity and sales cycle length, pipeline coverage, quota attainment, rep productivity, win/loss); executive and manager revenue dashboards and reporting design; and revenue data quality (reconciling CRM against billing, stage and closed-won definitions, overstated pipeline, multi-currency and revenue-recognition effects on reported metrics). Also covers explaining a worsening metric to stakeholders, resolving disputes over metric definitions, and spotting and handling metrics that incentives push people to game. Forecasting method, revenue-operations process and compensation design, CRM administration, marketing attribution, BI platform engineering, customer-success operations and unit-economics modelling are covered elsewhere.
Accounts receivable is $2,000,000 and credit sales average $5,000,000 a month. Compute DSO and say how you would interpret it.
Sample Answer
Direct answer
DSO (days sales outstanding) is the average number of days it takes to collect cash after a credit sale: accounts receivable (money customers owe you) divided by credit sales over a period, times the days in that period. Here it is $2,000,000 / $5,000,000 x 30 = 12 days. Interpret it against the payment terms you offer, your own trend, and the breakdown of what is overdue.
Calculation
DSO=credit sales in periodaccounts receivable×days in period=$5,000,000$2,000,000×30=12 daysThe basis matters, so state it:
- Credit sales only. If the $5M includes cash or card sales that are paid immediately, DSO is understated.
- Same period for both sides. Receivable is a balance at period end; sales are a flow over the period. Using the average receivable over the period is safer when it moves a lot.
Window length changes the answer
- 31-day month instead of 30: 2.0 / 5.0 x 31 = 12.4 days.
- A smaller case: $600,000 receivable over $1,800,000 of credit sales in a 30-day window gives 0.6 / 1.8 x 30 = 10 days.
- Seasonality: if the last month was $5M but the previous two months were $3M each, 90-day sales are $11M, and DSO = 2.0 / 11 x 90 = 16.4 days. The one-month window divides the same $2M balance by a spike month, so it makes the balance look like only 12 days of sales. Over the three months, average sales are about $3.67M a month, and $2M is more than half a month of that, which is why the longer window reads higher. The $2M balance mostly consists of recent invoices, so a spike month inflates the denominator and flatters the short window. For a steady $5M a month, the 90-day window gives 2.0 / 15 x 90 = 12.0 days, same as the monthly one.
Pick the window that matches the billing rhythm, keep it fixed over time, and compare like windows.
How to interpret 12 days
- Against terms. If customers are on net 30 (invoice due in 30 days), an average collection time of 12 days is quick. To see why: if every customer waited until day 30 to pay, almost the whole month's $5M would still be owed at month end and DSO would be close to 30. A $2M balance means about 60% of the month's billing was already collected, which usually means prepayment, card or auto-pay (automatic charge on the due date), or a mix with many immediate payers. If terms were net 60, it would be very fast. Check that the number is not too good because of a definition issue.
- Against its own trend and segment. A rise from 12 to 16 over three months is the signal; segment by customer size and region.
- Beyond the average. DSO hides the tail: one $500,000 invoice 90 days overdue can sit beside many quickly paid ones. Look at an aging report (receivables grouped by days overdue) and customer concentration.
- Cash impact. Daily credit sales are $5,000,000 / 30 = $166,667, so each day of DSO ties up about $166,667; cutting 2 days would free about $333,333 of cash.
Pitfalls
- Mixing cash sales into the denominator, or using ending receivables against sales from a different period.
- Using DSO as a target on its own, instead of watching overdue percentage as well.
Given a subscriptions table with a nullable end date, write a query for monthly churn rate across the last 12 months, and define churn precisely.
Sample Answer
Direct answer
Define monthly churn rate as: of the subscriptions that had service on the first day of the month, the share whose service ended during that month. Write that with two pieces: a denominator (started before the month began, and end_date is null or on or after the first day), and a numerator (the same subscriptions whose end_date falls before the next month's first day). Generate the last 12 complete months with a recursive query and join subscriptions to each. The denominator counts subscriptions that started strictly before the first day, so one that starts exactly on day 1 first enters the base the following month (use <= if you want day-1 starts included). This assumes end_date is the last day of paid service, inclusive; if your table stores the first day without service, shift the comparisons by one day.
Why these choices
| Choice | Reason |
|---|---|
| Denominator is "active on day 1" | fixes the population before anything happens in the month, so new signups cannot dilute churn |
| Started before the month, not during | someone who starts and cancels in the same month is in neither number; report them separately if early cancellations matter |
| end_date null means active | the nullable end date is the active flag |
| Counted in the month the service ends | not the month the cancel button was pressed; a scheduled cancellation is a leading indicator, not churn |
| One row per subscription | if a plan change creates a new row, the old row looks like churn; deduplicate by customer first |
Runnable example (Python with SQLite)
600 synthetic subscriptions with a pinned seed; 205 of the 600 (about 34%) have an end date. The 12 months run from July 2025 to June 2026.
import random
import sqlite3
from datetime import date, timedelta
rng = random.Random(7)
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE subscriptions (subscription_id INTEGER, customer_id INTEGER, start_date TEXT, end_date TEXT)")
first, last = date(2024, 1, 1), date(2026, 6, 30)
for i in range(1, 601):
start = first + timedelta(days=rng.randint(0, (last - first).days))
end = None
if rng.random() < 0.45: # 45% are given an end date; those past the cutoff are reset to None below
end = start + timedelta(days=rng.randint(20, 500))
if end > last:
end = None # cannot have ended after the data cutoff
db.execute("INSERT INTO subscriptions VALUES (?,?,?,?)",
(i, i, start.isoformat(), end.isoformat() if end else None))
QUERY = """
WITH RECURSIVE months(m) AS (
SELECT date(:last_month, '-11 months') -- 12 complete months ending :last_month
UNION ALL
SELECT date(m, '+1 month') FROM months WHERE m < :last_month
), base AS (
SELECT m.m AS month_start,
date(m.m, '+1 month') AS next_start,
s.end_date
FROM months m
JOIN subscriptions s
ON s.start_date < m.m -- started before the month began
AND (s.end_date IS NULL OR s.end_date >= m.m) -- and still had service on day 1
)
SELECT month_start,
COUNT(*) AS active_at_start,
SUM(CASE WHEN end_date < next_start THEN 1 ELSE 0 END) AS churned,
ROUND(100.0 * SUM(CASE WHEN end_date < next_start THEN 1 ELSE 0 END)
/ COUNT(*), 2) AS churn_rate_pct
FROM base
GROUP BY month_start
ORDER BY month_start
"""
print("month_start active_at_start churned churn_rate_pct")
for row in db.execute(QUERY, {"last_month": "2026-06-01"}):
print(*row)
Output:
month_start active_at_start churned churn_rate_pct
2025-07-01 277 8 2.89
2025-08-01 286 8 2.8
2025-09-01 291 7 2.41
2025-10-01 303 11 3.63
2025-11-01 320 9 2.81
2025-12-01 329 8 2.43
2026-01-01 338 12 3.55
2026-02-01 348 7 2.01
2026-03-01 359 12 3.34
2026-04-01 359 7 1.95
2026-05-01 372 6 1.61
2026-06-01 380 6 1.58
Reading it. July 2025 started with 277 active subscriptions and 8 ended during the month: 8 / 277 = 2.89%. The synthetic data is random, so the month-to-month movement carries no business meaning; it shows what the output shape is and that the denominator grows as the base grows.
Edge cases
- Reactivations. A customer who ends and later starts a new row counts as churn when it ends and as a new start later.
- Future end dates. An end_date set in the future (scheduled cancellation) has not churned yet; the numerator uses end_date < next month start and the denominator uses the same rows, so future-dated rows stay active until their month.
- Trials and zero-dollar plans. If the table includes them, filter to paying subscriptions or the rate is understated.
- Incomplete current month. Use complete months only; a partial month undercounts churn.
- Time zones. Store dates in one zone or the day-boundary comparisons move rows between months.
Trade-offs and pitfalls
Dividing by end-of-month active customers or by average customers is also seen but gives a different number; whichever you pick, state it. A monthly rate compounds: 2.89% a month is not 2.89% x 12 a year. Convert with 1 - (1 - rate)^12 if you need an annual equivalent.
Define NRR and GRR, then compute both for a cohort that starts at $1,000,000 of ARR with $100,000 churned, $50,000 of contraction and $200,000 of expansion. What does each number say, and what does an NRR above 100% not tell you?
Sample Answer
Direct answer
NRR (net revenue retention) is the share of a starting cohort's recurring revenue that remains a year later, counting expansion, contraction and churn but excluding new customers. GRR (gross revenue retention) is the same, but counts only losses (churn and contraction) and ignores expansion, so it can never exceed 100%. For this cohort, NRR = 105% and GRR = 85%. An NRR above 100% says the existing base grew on its own; it does not say the base is healthy, broadly happy or growing evenly.
Definitions and the computation
All figures are annual recurring revenue (ARR) for the same customers over the same 12-month window.
NRR = (starting ARR - churned - contraction + expansion) / starting ARR
GRR = (starting ARR - churned - contraction) / starting ARR
- Churned: ARR from customers who left entirely. Contraction: ARR lost from customers who stayed but reduced (fewer seats, a downgrade). Expansion: ARR gained from the same customers (upsell, cross-sell, more seats, price increases).
Arithmetic:
- GRR = ($1,000,000 - $100,000 - $50,000) / $1,000,000 = $850,000 / $1,000,000 = 85%.
- NRR = ($1,000,000 - $100,000 - $50,000 + $200,000) / $1,000,000 = $1,050,000 / $1,000,000 = 105%.
What each number says
- GRR 85%: 15% of the starting revenue leaked away (10% through lost customers, 5% through shrinking ones). It measures how sticky the product is, with no help from upsell.
- NRR 105%: expansion of $200,000 more than covered the $150,000 of losses, so the same customers pay 5% more in total than a year ago. If NRR holds above 100%, the business grows without signing a single new customer.
- The gap, 20 points, is the expansion. A large gap means retention leans on upsell.
What an NRR above 100% does not tell you
- It can hide concentration. Three-account illustration: starting ARR $500,000 (account A), $300,000 (B), $200,000 (C), total $1,000,000. A expands to $800,000, B stays at $300,000, C churns to $0. NRR = ($800,000 + $300,000 + $0) / $1,000,000 = 110% and GRR = ($500,000 + $300,000 + $0) / $1,000,000 = 80%. A healthy-looking 110% is one account's growth covering a lost customer.
- It hides how many customers left. A lost customer shows up as dollars, not as a count (the logo count could be falling).
- It does not say why expansion happened: real adoption versus a one-time price increase, and whether it can repeat.
- It ignores new customers, so it is no measure of total growth.
- It depends on the cohort and window: young cohorts, large renewals clustered in one quarter, or currency moves can lift it temporarily.
Trade-offs and pitfalls
- Always report GRR next to NRR; the pair, not either alone, shows retention quality.
- Measure on the same customers at both ends (new customers are excluded from the numerator as well as the denominator), and keep the window explicit, for example trailing 12 months.
- Break NRR down by segment and customer size so one large account cannot carry the headline.
Monthly counts are 10,000 leads, 1,200 SQLs, 300 opportunities and 60 wins. Work out the conversion at each stage and overall, and say which stage you would investigate first and why.
Sample Answer
Direct answer
Each stage converts as follows: lead to SQL is 1,200 / 10,000 = 12%, SQL to opportunity is 300 / 1,200 = 25%, and opportunity to win is 60 / 300 = 20%. Overall, 60 / 10,000 = 0.6%, or one win per roughly 167 leads. I would investigate lead to SQL first, but only after checking each rate against the previous few months, because one month of counts cannot tell you which stage is the weak one.
Terms: a lead is a person or company that showed interest. An SQL (sales-qualified lead) is a lead that sales has accepted as worth working (here it does not mean the query language). An opportunity is a live deal logged in the CRM (customer relationship management system) with an amount and an expected close date. A win is a deal closed-won.
The arithmetic
| Stage | In | Out | Conversion |
|---|---|---|---|
| Lead to SQL | 10,000 | 1,200 | 1,200 / 10,000 = 12% |
| SQL to opportunity | 1,200 | 300 | 300 / 1,200 = 25% |
| Opportunity to win | 300 | 60 | 60 / 300 = 20% |
| Overall | 10,000 | 60 | 60 / 10,000 = 0.6% |
The overall rate is the product of the stage rates: 0.12 x 0.25 x 0.20 = 0.006. That identity is the useful part: every stage multiplies, so an equal relative improvement (say 10% of the stage's own rate) at any single stage yields the same overall gain (60 x 1.10 = 66 wins). Measured in relative terms, no stage has a bigger arithmetic payoff than another, so the choice has to rest on other evidence. An equal one-point change is a different comparison, and the sensitivity table below shows why it favours the first stage.
Which stage first, and why
I would pick lead to SQL, for three reasons I can defend from these numbers alone:
- Volume lost. 8,800 of 10,000 leads exit here, far more than the 900 and 240 lost at the later stages. A rate this low is where a definition, routing or scoring problem hides, and those are cheap to test.
- It feeds everything. Fixing it changes the volume for every later stage; fixing a later stage changes nothing before it.
- Two teams influence it (marketing sets what counts as a lead, sales decides what to accept), which makes it the stage where a disagreement most often masks a measurement problem.
The step before any deep dive is the trend. Pull the same three rates for the previous three to six months. A stage that has moved against its own history is the real lead; a stage that has always sat at 12% may simply be how this business works (for example if "lead" includes newsletter sign-ups).
What would flip my call: if lead to SQL and SQL to opportunity have been stable but opportunity to win slid from, say, 28% to 20%, I would start at opportunity to win, because that is a measured deterioration that sits closest to revenue.
Worked sensitivity
One extra percentage point at each stage, other stages held fixed:
| Lever | Change | Extra wins |
|---|---|---|
| Lead to SQL, 12% to 13% | +100 SQLs | 100 x 0.25 x 0.20 = 5.0 |
| SQL to opportunity, 25% to 26% | +12 opportunities | 1,200 x 0.01 x 0.20 = 2.4 |
| Opportunity to win, 20% to 21% | +3 wins | 300 x 0.01 = 3.0 |
Per percentage point the first stage pays most because it has the most volume flowing through it, but that is not the same as being cheapest to move: one point is 1/12, about an 8% relative change, at 12% and only 1/25, a 4% relative change, at 25%, so a point is a harder ask at the first stage. The two views reconcile: a relative change of 1/12 on the first stage gives 60 x 1/12 = 5.0 extra wins, 1/25 on the second gives 60 x 1/25 = 2.4, and 1/20 on the third gives 60 x 1/20 = 3.0, the same figures as the table. Read the table as showing where the volume is, not as a ranking of effort.
Trade-offs and pitfalls
- Period ratio, not a cohort. The 60 wins this month mostly came from leads created weeks or months ago, because deals take time to close. 0.6% is a rough monthly ratio. For decisions, follow each month's lead cohort (all the leads created in that month) through the stages.
- Tightening the definition raises the rate and cuts volume. If lead to SQL rises from 12% to 20% by qualifying harder but wins per 1,000 leads fall, nothing improved. Judge by wins (or revenue) per 1,000 leads and by cost per win (total spend divided by wins).
- Mix. Blended rates hide segments. A 12% blend can be 25% for one source and 4% for another.
What is the SaaS magic number? Show how you compute it from quarterly ARR change and sales and marketing spend, and describe what values around 0.5, 1.0 and above 1.5 imply and where the metric misleads.
Sample Answer
Direct answer
The SaaS magic number is a sales-efficiency ratio: how much new annualised revenue each dollar of sales and marketing (S&M) spend produced. The common form is
Magic number=S&M spendQ−1(RevenueQ−RevenueQ−1)×4
and the ARR (annual recurring revenue) form is the change in ending ARR over the quarter divided by the prior quarter's S&M spend, with no x4 because ARR is already annual. Rules of thumb, which vary a little by source: below about 0.5 suggests spend is not converting and needs a diagnosis, 0.5 to 0.75 is a grey zone worth investigating, about 0.75 to 1.0 is healthy, and above about 1.0 (especially 1.5 and up) says the engine is efficient and may justify spending more. A quick way to remember it: under 0.5 fix, 0.75 to 1.0 healthy, over 1.0 consider investing. The x4 in the revenue form turns one quarter's revenue change into an annual rate, so it is comparable with the annual ARR form. Treat those bands as prompts for investigation, not verdicts.
Computing it (illustrative numbers)
Quarter-end ARR: Q3 $12.0M, Q4 $13.5M. S&M spend: Q3 $3.0M, Q4 $3.2M. Recognised revenue (the part of contracts earned as the service is delivered in the period, which lags bookings, the value of contracts signed): Q3 $2.9M, Q4 $3.2M.
| Version | Calculation | Result |
|---|---|---|
| ARR, prior-quarter spend | (13.5 - 12.0) / 3.0 = 1.5 / 3.0 | 0.50 |
| ARR, same-quarter spend | 1.5 / 3.2 | 0.47 |
| Revenue, prior-quarter spend | (3.2 - 2.9) x 4 / 3.0 = 1.2 / 3.0 | 0.40 |
Three defensible versions give 0.40 to 0.50 for the same company, so always state which one you use.
What the bands imply
Turn the ratio into a payback figure to make it concrete. Payback in months = 12 / (magic number x gross margin), where gross margin is the share of revenue left after the cost of delivering the product. Derivation: $1 of S&M buys M dollars of new annual revenue; at gross margin g that revenue leaves M x g of gross profit a year; so it takes 1 / (M x g) years to earn the dollar back, and multiplying by 12 gives months. Assuming a 75% gross margin (an assumption, not a fact about any company):
| Magic number | Meaning | Payback on S&M |
|---|---|---|
| 0.5 | $1 of S&M buys $0.50 of new ARR | 12 / (0.5 x 0.75) = 32 months |
| 1.0 | $1 buys $1.00 | 12 / 0.75 = 16 months |
| 1.5 | $1 buys $1.50 | 12 / (1.5 x 0.75) = 10.7 months |
Around 0.5 look for a problem: weak conversion, discounting, high churn netted against new ARR, or hiring ahead of ramp (new reps who are paid but not yet productive). Around 1.0 you are converting spend into growth at a sustainable pace. Above 1.5, check the cause before celebrating: it can mean a strong engine that is under-invested, or a one-off such as a big renewal wave (many contracts renewing in the same quarter), a price rise or a quarter of pulled-forward deals.
Where the metric misleads
- Spend lag. Prior-quarter spend assumes roughly a one-quarter sales cycle (the time from first contact to a signed deal). With a six-month enterprise cycle the lag is wrong, and spend that is rising fast makes the same-quarter version look worse than the lagged one: with $1.5M of net new ARR, prior-quarter spend of $3.0M gives 0.50, but if spend has climbed to $3.6M it gives 0.42 (illustrative).
- Revenue versus ARR inputs. Revenue lags bookings: a deal (a booking) signed in the last week of a quarter adds a sliver of revenue but its full ARR. Revenue-based figures also include usage and services that ARR excludes.
- Net, not new. ARR change is net of churn (customers leaving) and contraction (customers staying but paying less). A company with excellent selling and bad retention shows a low number and the wrong diagnosis. Split new ARR from net where you can, and new logos (new customers) from expansion of existing ones.
- Seasonality. If most deals close in Q4, Q1 looks weak and Q4 looks heroic. Use a trailing four-quarter version (the last four quarters of ARR change over the last four quarters of spend) or compare like quarters.
- Spend that is not selling. S&M includes brand and marketing for next year's pipeline (open opportunities that could become deals); expansion driven by customer success is credited to a spend line that did not produce it.
- Small bases. At early stage a single deal swings the ratio: on $0.4M of quarterly S&M, one $0.4M deal gives 1.0 and no deal gives 0 (illustrative).
Pitfall that separates strong answers
Do not use the ratio to set budget alone. Pair it with payback, net revenue retention (the share of last year's recurring revenue still there now, including upgrades and net of churn) and sales capacity (are reps hitting quota, their assigned sales target?), and change spend only when they agree.
Unlock Full Question Bank
Get access to all Sales & Revenue Performance Analytics interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.