Predictive analytics use cases: which method fits which question

Predictive analytics use cases are usually named by their business label: churn, demand, maintenance, fraud, credit risk. The label says what the organisation cares about. It leaves open what is being predicted, and two projects under one label often need different methods, data and evaluation. This article works from the shape of the question to the method that answers it, and to the constraint that decides deployment.

Five question shapes behind predictive analytics methods

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 prediction and uplift modelling

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 DNA Solutions 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.

Survival analysis: the underused predictive analytics method

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 methods: horizon and prediction intervals

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.

What stops predictive analytics models reaching production

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 to the predictive analytics method

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.

Talk through your predictive analytics methods

DNA Solutions helps teams take predictive analytics from question shape to production: matching forecasting, classification, survival analysis, uplift or anomaly detection to the decision, and constraining the inputs to what exists at decision time. 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. Talk to us.