Where the number really comes from
By now you can read a query, spot a filter, and question a metric. This session is about the moment before any of that: the request you send to your analyst. Most "the data is wrong" pain is really "the ask was fuzzy" pain. A vague request gets a plausible-looking number that answers a slightly different question than the one in your head - and you find out in the board meeting. The fix is a shared shape for how you ask.
The anatomy of a good data request 7 min live
Every answerable data request carries the same five fields. Leave one out and the analyst has to guess - or come back to ask, which costs you a day. Name all five and the query almost writes itself: metric (what number), grain (per what), filter (which rows count), timeframe (over what window), and comparison (against what).
LiveWalking the five fields4 min▶
Each field closes a door the analyst would otherwise have to guess through. Miss the grain and you get one total when you wanted a trend. Miss the filter and refunds sneak into your revenue. Miss the comparison and you get a number with no context - "$412k" tells a board nothing until it sits next to last period.
- Metric: the number itself, defined - "completed revenue", not just "revenue". This is the field people skip and regret.
- Grain: per what. Per customer? Per week? Per country? The grain decides whether you get a single figure or a table you can chart.
- Filter: which rows are allowed in. Completed orders only? A single plan? Excluding test accounts? Say it.
- Timeframe: the window. "Last 6 months", "Q2", "since launch". Without it, an analyst picks one and you may not agree.
- Comparison: against what. Prior period, target, or another segment. A number alone is not an insight.
The request that came back three times. "Can you pull our revenue by country?" bounced twice - first the analyst included refunds, then used calendar months instead of the fiscal weeks the exec had in mind. The third version, sent as five explicit fields, was right in twenty minutes. The fields did not slow the ask down. They removed two full days of rework.
Self-studyWhy the comparison field is the one leaders forget2 min read▶
Metric, grain, filter and timeframe get you a correct number. The comparison is what turns it into a decision. "$412k in completed revenue" is data; "$412k, up 9% on the prior period but down in two of five countries" is a conversation. Analysts often leave comparison out because you did not ask for it - so ask. Naming the baseline up front also prevents the subtle trap of comparing against a cherry-picked period after the fact.
- Prior period: the honest default - same length window, immediately before.
- Target or plan: when there is a budget or forecast to measure against.
- Peer segment: this country versus that, this plan versus that - context from within the same pull.
Define the metric so two people get the same number 7 min live
A metric is not defined until two people, working separately, would compute it the same way. "Active customer" feels obvious until you try to pin it: active in the last 30 days, or ever? By any order, or a paying one? On any plan, or Pro only? Each choice is a different query and a different number. The leader's job is to make the choice explicit before the query is written, not to discover it in a disagreement later.
LiveEven "how many customers" needs a definition4 min▶
Watch how quickly a simple count forks. The query below counts every row in the customer table, split by plan. Read it: "give me plan and a count of customers, from customers, grouped by plan." Run it and you will see two groups, Basic and Pro. But now ask the real question: when the board says "how many customers do we have", do they mean all 15 signups here - or only the paying ones, or only those who ordered recently? The number changes with the definition, and the query has to change with it.
SELECT plan, COUNT(*) AS customers FROM customers GROUP BY plan;
LivePinning "active customer" in one sentence3 min▶
Here is how you take an ambiguous term and make it queryable. "Active customer" becomes: a customer with at least one completed order in the last 90 days. Every fuzzy word is now a concrete rule an analyst can write - "completed" is a status filter, "90 days" is a timeframe, "at least one order" is the grain. You did not write SQL. You removed every guess the person who does write it would have had to make.
| Fuzzy word | Pinned to a rule |
|---|---|
| "active" | has at least one completed order |
| "recently" | in the last 90 days |
| "customer" | any plan, but a real (non-test) account |
| the number | count of distinct customers meeting all three |
Two dashboards, two "active" counts. Marketing reported 11,000 active customers; finance reported 6,400. Neither was wrong. Marketing counted anyone who logged in during the quarter; finance counted anyone with a paid order in 30 days. The company had never written the definition down, so both teams invented one. A single sentence in a metrics catalog would have saved a quarter of arguments.
Self-serve versus analyst work, and request etiquette 6 min live
Not every question needs an analyst. Filtering a dashboard, changing a date range, or reading a certified metric is self-serve - you can do it in the BI tool in seconds. Net-new logic, a metric that does not exist yet, or a one-off deep dive needs an analyst. Knowing which is which - and how to ask when it is the second kind - is what keeps a data team fast and willing.
Try self-serve first. If the number is a filter or date change on an existing dashboard, do it yourself. It is faster for you and it protects analyst time for real questions.
Batch and give lead time. Send five questions together with a real deadline, not five pings across a morning marked urgent. Context-switching is the hidden tax on a data team.
Bring the definition, not just the ask. "Just pull the numbers" makes the analyst guess your intent. The five-field request removes the guessing and gets you the right cut first time.
| Vague request | Good request |
|---|---|
| "Can you pull our revenue?" | "Completed revenue (refunds excluded), per country per week, last 6 months, vs prior period." |
| "How many active customers do we have?" | "Count of customers with a completed order in the last 90 days, by plan." |
| "Need this ASAP" (at 4pm) | "Not urgent - by Thursday is fine. Here are three related questions in one go." |
| "The dashboard looks wrong" | "The country tile shows $412k but I expected ~$450k - which filter or status is it using?" |
Self-studyThe "just pull the numbers" trap2 min read▶
"Just pull the numbers" sounds efficient and is the opposite. It hands the analyst all the hard decisions - which metric, which filter, which window - while making it sound like clerical work. The analyst either guesses (and you get a wrong-shaped answer) or comes back with questions (and you lose a day). Treat a data request like a brief to any skilled professional: say what you want, why, and how it will be used. The five fields are that brief.
- Say how it will be used: "for the board" versus "quick gut-check" changes how much rigor is worth.
- Flag the decision it feeds: analysts prioritize better when they know what hangs on the number.
- Respect the queue: not every ask is a fire. Marking everything urgent means nothing is.
Take this back to your desk ◐ 15 min
- Find one real data request you sent recently - a Slack message or email to your analyst. Rewrite it using the five-field template: metric, grain, filter, timeframe, comparison. Notice how many fields you originally left the analyst to guess.
- Pick one metric your team uses often - "active user", "churn", "revenue" - and write its definition in one sentence precise enough to pass the two-people test.
- Before your next ask, decide honestly: is this self-serve in the BI tool, or does it genuinely need an analyst? Do the self-serve ones yourself.
- Optional: skim the builder track's session on filtering and grouping to see how your five fields turn into real WHERE and GROUP BY clauses.
What this maps to
This session distills how effective data leaders commission work - the decision-intelligence and analyst-collaboration practice that sits above SQL syntax. It covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · What are the five parts of a good data request?
Metric (what number), grain (per what), filter (which rows), timeframe (what window), comparison (against what). Name all five and the analyst never has to guess.
2 · Why should you define a metric precisely before asking for it?
A metric is only defined when two analysts in separate rooms would return the same figure. Until then it is a word everyone fills in differently.
3 · What is the fastest way to annoy your data team?
"Just pull the numbers" hands the analyst every hard decision while marking it urgent. Batched, defined, lead-time requests are what keep a data team fast and willing.