Turn a vague business question into a data definition

The hardest part of an analysis happens before you touch a formula. It's deciding exactly what you're counting.

When someone hands you a question like "Are our customers coming back?" they think they've given you a task. They haven't. They've given you a feeling. And you cannot count a feeling.

I've watched capable people lose an entire afternoon to this. They open the spreadsheet, start summing columns, build a chart, and only when someone asks "wait, what does 'coming back' mean here?" do they realize they've been answering a question nobody actually asked. The work was fine. The definition was missing.

So before any of the Excel work, there's a step almost everyone skips. You turn the question into a data definition: a sentence precise enough that two different people would pull the exact same rows.

A vague question is not a question yet

Here's the uncomfortable truth. Most business questions arrive vague, and the vagueness hides the real work.

"Are customers coming back?" Coming back to do what — visit, or buy? In what window — this month, this year, ever? Does one repeat purchase count, or do they need three? "How are sales doing?" Doing compared to what? Which sales, over which period?

None of these are answerable as written. Not because the data is missing, but because the question hasn't decided what it's asking. And if you start calculating anyway, you'll produce a number. It will look authoritative. It will be wrong, or at least unaccountable, because you can't say precisely what it measured.

This is the part that feels backwards to people. They think the skill is in the formulas. The skill is in the sentence you write before the formulas. Get the sentence right and the calculation becomes almost mechanical. Get it wrong and no amount of spreadsheet cleverness saves you.

The three moves that make a question countable

A data definition is built from three decisions. Make all three on purpose.

First, name the group or action. Who or what is this actually about? Users, orders, customers, tickets, shipments? "Are customers coming back" is about customers who purchased more than once. Say that out loud.

Second, define the specific metric. What exactly are you counting, summing, or averaging? Not "activity" — a count of customers, a sum of purchase totals, an average rating. A metric is a number you track to understand performance. If you can't name the number, you don't have a metric yet.

Third, add a time frame or filter. For when, and for whom? "Last month" needs a start and end date. "Q1" needs the year. This is the step people drop most often, and it's the one that makes two analysts disagree about the same spreadsheet.

Put those together and the vague question becomes something you can hand to anyone: a data definition.

What this looks like in practice

Take the real one: "How many new users did we get last month?"

Vague version, as delivered. You could answer that six ways. So you run the three moves.

• Group: users, specifically ones who signed up.
• Metric: a count of them.
• Time frame: the target month, with actual dates.

The data definition: "Count of users whose sign-up date falls between March 1 and March 31, 2025."

Now look at what changed. There is no ambiguity left. You know which column to check (sign-up date), which rows qualify (the ones inside that date range), and what to do with them (count). Two people handed that sentence would return the same number. That's the test. If your definition passes it, you're ready to calculate. If it doesn't, you're not — and no formula will rescue you.

One more, because the pattern matters more than any single example. "Are customers coming back?" becomes "Count of customers with a first purchase and a later purchase within the same 12-month window." Group: customers. Metric: a count. Time frame and rule: two purchases, inside one window. Countable.

Here's a habit worth building. If you cannot write the data definition, you do not yet understand the question well enough to answer it. That's not a failure — it's information. It tells you the next step is a conversation, not a calculation. Go ask the person who asked you. "When you say coming back, do you mean bought again, or just logged in?" That one question saves you the afternoon.

The definition is a small contract

There's a second payoff to writing the definition down, and it shows up weeks later when someone challenges your number. "That can't be right, we had way more new users than that." Without a written definition, you're stuck defending a calculation you half-remember. With one, you point to the sentence: "New users means sign-up date between March 1 and March 31. If you're counting people who came back after a lapse, that's a different number and I can pull it." The disagreement resolves in thirty seconds, because you're arguing about the definition, not the math.

That's what a data definition really is — a small contract between you and whoever asked. It records what "new users" meant on the day you counted, so nobody can quietly move the goalposts later and call your work wrong. It also means the next person who runs the report gets the same answer you did, instead of a number that drifts every time someone new touches the spreadsheet. Precision up front is what makes a result reproducible and defensible, and both of those matter far more than they seem to until the first time a number of yours gets questioned in a meeting.

There's a discipline in this that goes beyond any single analysis. When you make a habit of writing the definition first, you stop producing numbers you can't stand behind. Every figure you hand over comes with a clear statement of exactly what it counted — which is the difference between being the person whose data people trust and the person whose data people quietly double-check.

Where AI helps, and where it can't

This is exactly the kind of step where an AI tool earns its place — and exactly the kind where it can't do the whole job. In the course I teach this with a tool called AI-2: Analysis Objective Builder. You give it your rough question and what data you have access to, and it hands back a sharpened analysis objective, the likely metric, and the source that probably holds it.

That's genuinely useful. It's faster than staring at the wall. But notice what it can't decide: whether "coming back" should mean a purchase or a login is a call about your business, this quarter. The tool can draft the definition. You own whether it's the right one. That's the whole shape of good data work — the machine drafts, you decide.

The caveat worth naming

A precise data definition can still measure the wrong thing precisely. You can nail the group, the metric, and the window, and be counting something that doesn't actually answer what your boss cares about. Precision is not the same as relevance.

So there's a second question after you've written the definition: does this number, if I get it, actually settle the thing we're trying to decide? Sometimes "new users last month" is a perfect definition of a metric nobody needed, because the real question was whether the new ad campaign worked — which needs a before-and-after, not a single month. Write the definition. Then check that the definition is pointed at the decision. Both steps are yours.