Predictive analytics use cases: which method fits which question

Predictive analytics use cases are usually described by their business label: churn, demand, maintenance, fraud, credit risk. That label says what the organisation cares about. It does not say what is being predicted, and two projects under the same label often need entirely different methods, different data and different evaluation. This article works the other way round: from the shape of the question to the method that answers it, and to the practical constraint that decides whether the answer ever reaches an operational system.

Five question shapes

Behind the business labels sit a small number of question shapes. Naming the shape first removes most of the method debate.

How much, over a period. Demand next quarter, call volume next week, energy consumption tomorrow. A continuous quantity over a horizon. This is forecasting.

Will this happen, for this entity. Will this customer churn, will this transaction be fraudulent, will this application be approved. A probability attached to an individual case. This is classification.

When will this happen. How long until this component fails, until this contract is not renewed, until this account becomes inactive. A time, with the complication that many cases have not happened yet at the time of analysis. This is survival analysis, or time-to-event modelling.

What changes if we act. Does contacting this customer improve the outcome, compared with not contacting them. Not a prediction about the customer but about the effect of an action on that customer. This is uplift modelling, and it requires a different data-collection design.

Is this normal. Does this reading, this transaction, this sequence differ from the usual pattern, where the abnormal cases are rare and mostly unlabelled. This is anomaly detection.

Most misdirected projects can be traced to a mismatch between the shape and the method. The most common is answering a "when" question with a "will it" method, and the second most common is answering a "what changes if we act" question with a "will it happen" method.

Churn, and the difference between prediction and decision

Churn is worth its own section because it is where the mismatch is most expensive.

The standard build is a binary classifier over customer attributes and behaviour, trained on who left in a past window, producing a churn probability per customer. It usually works. The scores are informative, the evaluation looks good, and the model goes live feeding a retention campaign that targets the highest scores.

The campaign then underperforms its business case, for a reason that is structural rather than technical. The highest-probability churners include a large group who will leave regardless of what is offered, and the retention budget spent on them produces nothing. Meanwhile a group of customers who would have stayed anyway receive a discount they did not need. In some segments, contact itself triggers a reconsideration that would not otherwise have happened.

The question the business has is a different one: for whom does our intervention change the outcome. That is uplift, and it cannot be extracted after the fact from a churn model. It needs a randomised holdout built into the campaign from the beginning, so that treated and untreated groups are comparable, and a model trained on the difference between them.

The practical consequence is that the experimental design has to be agreed before the first campaign runs, not after the first disappointing one. We work through this in predictive analytics engagements as a scoping question rather than a modelling question, because by the time it is a modelling question the data needed no longer exists.

Time-to-event, the method most estates should use more

Survival analysis was developed for clinical trials and is underused in industry, mostly because it is less familiar than classification rather than because it fits less well.

The situations it fits are common. A maintenance team wants to know when a component is likely to fail, not merely whether it will fail in the next thirty days. A subscription business wants expected remaining tenure per account. An inventory team wants time until stockout. In each case the natural output is a distribution over time, and each case has the same statistical complication: at the moment of analysis, many units have not experienced the event yet, and treating them as negative examples is wrong, because they may fail tomorrow.

That complication is called censoring, and handling it correctly is the whole point of the method family. A binary classifier over a fixed window handles it by throwing the timing away and by mislabelling everything outside the window. That is a real loss of information when the question is a planning question, because planning needs a date rather than a flag.

The output also communicates better. A hazard curve showing rising failure probability across a component's remaining life is directly usable by a maintenance planner. A probability of 0.63 is not, without a threshold that someone has to justify. We covered the data side of this pattern in predictive maintenance for fleets, where the timing information sits in workshop history that most organisations already hold.

Forecasting: the horizon and the interval are part of the answer

Forecasting is the most requested and the most casually specified. Two things are routinely missing from the specification, and both change the method.

The horizon. A forecast one period ahead and a forecast twelve periods ahead are different problems. Short horizons are dominated by recent state and respond well to methods that lean on autocorrelation. Long horizons are dominated by trend, seasonality and external drivers, and recent state matters less. A single model asked to serve both usually serves one badly.

The uncertainty. A point forecast is planned against as if it were certain, which is how safety stock disappears and capacity plans break. Prediction intervals are not a refinement to add later. They are what makes the number usable, because the decision the forecast feeds is almost always about coverage against a downside.

The classical methods have not been displaced here. Statistical approaches in the exponential smoothing and ARIMA families remain competitive on many business series, particularly when history is short, and gradient-boosted trees on lagged features handle multiple related series with external regressors well. Deep learning earns its complexity when there are many correlated series with shared structure and enough history to learn it. Choosing the heaviest available method for a monthly series with four years of history is a reliable way to underperform a seasonal naive baseline.

Which brings up the baseline. Every forecasting project should start by measuring the trivial answer: last period's value, or the same period last year. A surprising share of models that reach production do not beat it, and nobody checked.

Anomaly detection and the label problem

Anomaly detection is chosen when there are no labels, and that choice has consequences that need to be accepted up front.

Without labels there is no accuracy to measure. The model flags cases that differ from the norm, and whether those cases are the ones the business cares about is a separate, empirical question. A transaction can be statistically unusual and entirely legitimate. A sensor reading can be an outlier because the sensor is dirty.

Two things make these projects work in practice. The first is a labelling loop: whatever the investigators decide about the flagged cases gets recorded in a structured form, so that after some months there is a labelled dataset and the problem becomes a classification problem with much better economics. The second is calibrating the alert volume to the capacity of the people receiving it. A detector producing four hundred alerts a day for a team of three is not a detection system, it is a source of ignored notifications, and the threshold discussion is a staffing discussion.

The constraint that decides deployment

Across all five shapes, the reason a working model does not reach production is usually the same, and it is not accuracy.

It is availability at decision time. A model trained on a warehouse table that is loaded nightly cannot score a customer during a call. A feature that depends on a field completed by an operator two days after the event is not available at the moment the prediction is needed. A model that requires a join across three systems, one of which answers in four seconds, cannot sit inside a checkout flow.

The discipline that avoids this is simple to state and often skipped: before modelling, write down for each candidate input where it comes from, how fresh it is, and whether it exists at the exact moment the decision is taken. Inputs that fail that test are excluded from the training set, even when they are predictive, because a model built on them cannot be deployed. The alternative is a pilot with excellent metrics and no path to production, which is a common and expensive outcome.

The second constraint is where the output lands. A prediction that arrives in a dashboard depends on someone opening the dashboard, forming a view, and acting. A prediction that arrives as a work order in the maintenance system, a task in the CRM, or a flag in the approval queue is acted on because it appears inside a process that already exists. The integration work that puts it there is not a detail after the model, it is the part that determines whether anything changes.

Working back from the decision

A method choice made from the question shape, an input list constrained by decision-time availability, and an output written into an operational system: those three together account for most of the difference between predictive work that gets used and predictive work that gets presented.

The order matters. Start from the decision that should change, define the question shape it implies, then pick the method. Starting from the method, or from the dataset that happens to be available, produces models that answer a question nobody asked. Our data and analytics practice tends to spend the first weeks of an engagement on exactly this framing, because it is cheaper to correct there than after a model exists.