What Kind of Question Is It? Matching Analytics Work to the Answer You Need

Someone asks the data team why revenue dropped last month. Two weeks later they receive a deck with fourteen charts, each showing something that also changed last month, and no answer. Nobody did poor work. The question was causal and the work was descriptive, and no amount of additional charts closes that gap.

Most disappointment with analytics is a mismatch of this kind. The useful skill for anyone commissioning the work is recognizing what kind of question has been asked, because the kind determines what data is needed, which method applies, and what a credible answer even looks like.

Four kinds of question

The familiar four-way split — descriptive, diagnostic, predictive, prescriptive — is worth keeping not as a maturity ladder to climb but as a diagnostic for the request in front of you. Each kind demands something the previous one did not.

Question	Form	What it needs beyond the last row
Descriptive	What happened?	Agreed definitions and trustworthy data. Nothing else — and this is where most value is actually delivered
Diagnostic	Why did it happen?	A causal claim, which requires either an experiment or explicit assumptions about what else could explain it
Predictive	What will happen?	A stable relationship between past and future, and a defensible answer to how stable
Prescriptive	What should we do?	An objective, stated constraints, and a causal model of what your actions do

Read down that third column and the common failure becomes visible: organizations invest in the later rows while the first one is still unreliable. A prescriptive model built on metrics two teams define differently produces confident recommendations from numbers nobody agrees with — which is why metric definition is not a preliminary to analytics work but a permanent part of it.

The jump from description to diagnosis

Descriptive and diagnostic analytics are usually named in one breath and separated by the hardest step in the whole sequence. Describing is counting things correctly. Diagnosing is claiming that one thing caused another, and the data that supports the first does not support the second.

The usual diagnostic method is slicing: break the drop down by region, channel, segment, and device until something looks responsible. It is genuinely useful for generating candidates and it cannot distinguish the cause from the things that moved with it. A channel that fell at the same time may be a cause, a consequence, or a fellow symptom of a third thing — and correlation in the slices cannot tell you which.

What is worth noticing is that the question was never associational. The epidemiologist Miguel Hernán makes this point sharply about research that describes itself in associational language while pursuing a causal aim: “the primary scientific aim of this observational study is to quantify ‘the causal effect of wine on heart disease,’ not ‘the association between wine and heart disease’.” He argues the evasion has a cost — “Without causally explicit language, the means and ends of much of observational research get hopelessly conflated” — and that this is not a matter of study design alone, since “causal inference is a core task of science, regardless of whether the study is randomized or nonrandomized.”

Translated into a business setting: if the question is why revenue fell, say so, and then be explicit about how the answer will be justified. Three routes exist, and they differ in strength rather than in kind.

• An experiment. A/B testing answers the causal question directly, when the thing in question can be randomized and you can wait.
• An observational causal analysis. Causal inference methods can estimate a causal effect from data you already have — at the price of assumptions that must be stated and cannot be verified from the data itself.
• A reasoned argument from evidence. Timing, mechanism, and the elimination of alternatives, written down. Weaker, entirely legitimate, and much better than a chart presented as if it settled the matter.

The third is what most organizations actually do, and the improvement available is not to do something fancier but to make the reasoning explicit — including what would have to be true for the conclusion to be wrong.

Prediction answers a narrower question than people hear

A predictive question asks what will happen, not what to do about it, and its feasibility is not a matter of modelling skill. Hyndman and Athanasopoulos list what predictability depends on: “how well we understand the factors that contribute to it,” “how much data is available,” “how similar the future is to the past,” and “whether the forecasts can affect the thing we are trying to forecast.”

Every one of those is answerable before any modelling starts, which makes them the right questions to ask when a forecast is requested. The third does most of the work in practice — the reason short-horizon forecasting works while long-horizon forecasting frequently does not is that, as the same text puts it, “For short-term forecasting (up to a few weeks), it is safe to assume that demand behaviour will be similar to what has been seen in the past.”

The fourth is the one people miss entirely, and it is not a technicality. A published forecast can change the behaviour it predicts: “If there are well-publicised forecasts that the exchange rate will increase, then people will immediately adjust the price they are willing to pay and so the forecasts are self-fulfilling.” The same effect operates on an internal sales forecast that sets the quota it is supposed to predict.

And some things are not predictable at any budget. The authors’ example is deliberately deflating: forecasting tomorrow’s exchange rate direction is “about as predictable as forecasting whether a tossed coin will come down as a head or a tail.” A team asked for that forecast should say so rather than produce a model with an accuracy figure.

One delivery choice matters more than model selection here. A point forecast — a single number — hides exactly the information a decision needs, while a probabilistic forecast states a range and how confident it is. “Demand will be 4,200” and “demand will be between 3,100 and 5,400 with 80% probability” support very different inventory decisions, and only the second is honest about what is known.

Prediction and diagnosis are not the same job

This is the confusion that costs the most, because both produce models and the models look alike from a distance. A model that predicts well can be built from anything correlated with the outcome, including its consequences; a model that tells you what to change has to isolate the effect of changing it.

Hernán states the methodological consequence plainly: “Automatic variable selection procedures may work for prediction, but not necessarily for causal inference.” A churn model can be highly accurate because it has learned that customers who contact support three times are about to leave — and the recommendation “reduce support contacts” that someone reads out of it is worse than useless.

The practical test is a single question, asked before the work starts: will anyone act on this by changing one of its inputs? If yes, it is a causal question in a predictive costume, and it needs a causal method. If the model only sorts cases for attention — which transaction to review, which machine to inspect — prediction is the right tool and the accuracy figure means what it says.

“Who to call first” sits on the boundary and is worth separating out, because it looks like triage and is usually an intervention. Ranking customers by churn risk answers who is most likely to leave. Deciding whom a limited number of calls should go to is a different question — who will stay because of the call — and the two orderings can be almost unrelated. A customer at 90% risk who would leave regardless is worth less contact than one at 40% whose risk a call halves. Where the ranking allocates a scarce intervention, the quantity you need is the effect of intervening, not the probability of the outcome.

What prescription additionally requires

Prescriptive analytics recommends an action, and it needs three things no forecast requires.

• An objective, stated. Maximizing revenue, margin, retention, or lifetime value produce different recommendations from the same data. A system that recommends without a declared objective has one anyway, chosen by whoever wrote it.
• Constraints, written down. Budget, capacity, fairness requirements, regulatory limits, and what the organization will actually do. An optimal recommendation nobody can execute is not an answer.
• A causal model of the action. Recommending a discount requires knowing what a discount does, not what discounted customers did — which returns to the previous section, since this is where prescriptive systems quietly rest on predictive machinery.

The honest version of prescription in most organizations is narrower than the word suggests and considerably more useful: a recommendation plus its reasoning, presented to a person who decides. Full automation is appropriate where decisions are numerous, individually small, and reversible — and where you can keep measuring, because a recommendation loop with no measurement drifts without anyone noticing.

Where measurement is possible, experimentation is what keeps the loop honest. The rules of thumb Kohavi and colleagues generalized from experiments at “Amazon, Booking.com, LinkedIn, and multiple Microsoft properties” include the reminder that “Speed matters” — with the qualification that “certain areas of the web page are more critical” — which is a good illustration of the general shape of experimental knowledge: effects are real, and they are conditional on where and how you looked.

Who does which, and why titles mislead

Job titles map onto these question types loosely and inconsistently across organizations, which is a poor basis for staffing. Capabilities map better.

Question type	What the work actually demands
Descriptive	Domain knowledge, definitional rigour, and the judgment to notice when a number is wrong. Usually called analytics or BI
Diagnostic	Experimental design or causal methods, plus enough scepticism to resist the first plausible story
Predictive	Statistical and machine learning method, evaluation discipline, and the production engineering to keep a model running
Prescriptive	Optimization and decision analysis, and above all the business conversation that fixes the objective and the constraints

Three mismatches follow from ignoring this, and all three are common. Hiring data scientists to answer descriptive questions, which produces expensive dashboards and bored staff. Asking analysts for causal answers without experimental support, which produces confident stories. And building predictive models nobody has established a decision for — the most expensive of the three, because it looks like progress until deployment.

Turning a request into a decision question

Most of this is preventable at intake. Four questions convert a vague request into a decision question, and they take a few minutes.

• What decision does this inform? If there is none, the answer is interesting, and interesting is a legitimate but low-priority category.
• What are the options? An answer that does not distinguish between the available actions changes nothing regardless of its quality.
• What result would change your mind? This is the one that reveals whether the request is for evidence or for support. Both happen; only one should be resourced as analysis.
• By when, and how precisely? A rough answer on Thursday frequently beats a rigorous one next month, and knowing which is needed changes the method, not just the schedule.

The third question is the most valuable and the least asked. It is the same discipline as stating a value hypothesis before building something, and it works for the same reason: committing in advance to what would count as disconfirmation is what separates an investigation from a justification.

Where analytical outputs are consumed by other teams or systems, the same clarity belongs in a data contract — what this number means, what it may not be used for, and how it may change. A forecast consumed as if it were a measurement, or a predictive score read as a causal explanation, is a misuse that a stated scope prevents and a chart title does not.

References: Hyndman & Athanasopoulos, Forecasting: Principles and Practice (3rd ed.), §1.1 What can be forecast?; Hernán, The C-Word: Scientific Euphemisms Do Not Improve Causal Inference From Observational Data, American Journal of Public Health 108(5), 2018; Kohavi, Deng, Longbotham & Xu, Seven Rules of Thumb for Web Site Experimenters, KDD 2014.