Types of Analytics and the Questions They Answer

In an illustrative scenario, 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 makes a different claim and needs evidence suited to that claim; prediction does not require a causal diagnosis of every relationship it uses.

Question	Form	Evidence and conditions it needs
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, constraints, and a valid model of action outcomes; causal identification when the decision depends on intervention effects

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. The available route depends on whether an intervention can be randomized, whether observational identification assumptions are defensible, and what other evidence can support a reasoned account.

• 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 depends on the target and available information as well as modeling 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.”

Use those questions for an initial feasibility assessment, then test the available information and methods at the required horizon. The textbook illustrates short-horizon stability with residential electricity demand, not demand in general. A changing environment can still have predictable patterns; sparse history may call for other evidence or judgment. Validate forecasts with backtests that respect what was known at each forecast origin.

The possibility that a forecast changes behavior is easy to miss, and it is not a technicality. A published forecast can change the behavior 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.

Some requested targets may not be forecast accurately enough for the decision. 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

A predictive model can use associations that do not identify causes, but its inputs must be available at the actual prediction or decision time. An outcome’s later consequences are unavailable for forecasting that outcome and can create data leakage. A diagnostic or nowcasting task may legitimately observe signals that a future forecast cannot; define the information cutoff for each task. Estimating what would happen if an action changed is a separate causal question.

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.

Ask what claim the decision requires. Predictive performance measures how well a model estimates outcomes using the information available at that time. If a recommendation assumes that changing a variable changes an outcome, that effect needs causal support. Sorting cases for review can use prediction, but accuracy alone does not establish the value of the resulting allocation policy: intervention effects, review costs, capacity, and consequences still matter.

“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, combine the expected effect with outcome value, contact cost, and constraints. Effect ranking alone fits equal-value, equal-cost cases; outcome risk can still be an input when intervention effectiveness is known.

What prescription additionally requires

Prescriptive analytics recommends an action. Its decision model needs an objective, constraints, and a valid account of action outcomes.

• 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 valid model of action outcomes. Scheduling jobs against known costs and capacity can use a physical or contractual optimization model without a separate statistical causal study. Recommending discounts based on their effect on purchases needs causal identification; what discounted customers did is not by itself that effect.

A recommendation and its reasoning can support a person who decides; some decisions can be automated. Frequency, individual size, and reversibility inform that choice but do not authorize it. Check legal and organizational authority, cumulative harm, monitoring, exception handling, and safe recovery. Define when a person must review or override the action and verify that the arrangement works.

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.

• Descriptive: Domain knowledge, definitional rigor, and the judgment to notice when a number is wrong. Usually called analytics or BI
• Diagnostic: Experimental design or causal methods, plus enough skepticism 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

Ignoring the capability a question needs wastes effort in different ways. Hiring data scientists to answer descriptive questions can produce expensive dashboards and bored staff. Asking analysts for causal answers without experimental support can produce confident stories. Building predictive models before establishing the decision they support can be especially expensive, 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 question about what would change someone’s mind is particularly valuable and often goes unasked. 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
• Google OR-Tools, Solving a Linear Programming Problem
• scikit-learn, Common pitfalls and recommended practices: Data leakage