Predictive Analytics in Practice: Regression, Time-Series and Tree Ensembles

Three problems, three different shapes of data

Predictive analytics is often talked about as one activity, but the three canonical business problems — demand forecasting, churn prediction, credit scoring — have genuinely different data shapes underneath, and that shape dictates the method. Demand forecasting is a time-series problem: you have one (or many) sequences of numbers ordered in time, and autocorrelation, seasonality and trend dominate the signal. Churn prediction is a cross-sectional classification problem: at a snapshot in time, you have many customers each described by a row of features, and you're predicting a binary outcome (leaves within 90 days, or doesn't) with no inherent time-ordering between rows. Credit scoring is also cross-sectional classification, but with an added constraint that the model has to be explainable and auditable because it makes decisions about people's access to money, which pulls the choice of method towards more interpretable options even at some accuracy cost.

Regression and tree ensembles for churn and credit

For churn, a gradient-boosted tree ensemble like XGBoost or LightGBM is the default industry choice, and the reason is structural: churn drivers are rarely linear or additive. A customer's risk of leaving might depend on a specific combination — low usage AND a recent support complaint AND a competitor promotion running in their region — and trees capture this kind of interaction naturally because each tree splits the data recursively on whichever feature best separates churners from non-churners at that point, and later splits can condition on earlier ones. A boosting ensemble builds hundreds of small trees sequentially, where each new tree is trained specifically to correct the residual errors of the ensemble so far — tree 50 isn't predicting churn from scratch, it's predicting the mistakes trees 1 through 49 are still making, and its predictions get added in at a shrunk learning rate so no single tree dominates.

Credit scoring historically leaned on logistic regression precisely because its coefficients are directly interpretable — a one-unit increase in a specific ratio changes the log-odds of default by exactly this much, full stop, and a regulator or applicant can be shown that relationship. Modern credit models increasingly use tree ensembles for the underlying prediction but wrap them with post-hoc explainability tools (SHAP values, which decompose each individual prediction into the additive contribution of each feature) to recover the auditability that logistic regression gave for free, trading some model simplicity for a meaningful accuracy gain, particularly on non-linear affordability signals like the shape of someone's spending across a month rather than just its average.

Time-series forecasting: what ARIMA and Prophet-style models actually do

ARIMA (AutoRegressive Integrated Moving Average) forecasts a value from two internal sources: its own past values (the autoregressive part — today's demand is a weighted sum of the last p days' demand) and its own past forecast errors (the moving-average part — if the model has been under-predicting recently, it nudges the next forecast up). The "integrated" part handles trend by differencing the series — subtracting each value from the previous one — until what's left looks stationary (constant mean and variance over time), because the underlying maths only works cleanly on stationary series. This makes ARIMA excellent for a single, fairly regular series like total daily website traffic, but it struggles with multiple overlapping seasonal cycles (day-of-week plus month-of-year plus a slow multi-year trend) without significant manual configuration.

Facebook's Prophet, and the broader family of decomposition-based forecasting models it popularised, take a different structural approach: rather than modelling the series as one autoregressive process, they explicitly decompose it into additive components — an overall trend curve (fit with changepoints where the trend's slope is allowed to shift, which the model detects automatically from the data), a yearly seasonality curve, a weekly seasonality curve, and holiday effects — and simply sum them. This is easier to configure for business series with known irregular events (Black Friday, a product launch, a factory closure) because you can inject that domain knowledge directly as a named regressor, and easier to inspect because you can literally plot the trend component separately from the seasonal component and sanity-check each one against what a demand planner already knows about the business.

The validation trap that ruins forecasts silently

The single most common mistake across all three problem types is validating with a random train/test split rather than respecting the structure of the data, and it fails in different ways for each. For time-series demand forecasting, randomly shuffling data before splitting lets the model "see the future" during training — a model trained partly on next week's data will look artificially accurate when tested on a randomly held-out chunk from three weeks ago, because information has leaked backwards through the shuffle. The correct approach is a rolling-origin (walk-forward) validation: train on data up to time t, forecast t+1 through t+k, then move the origin forward and repeat, which mimics exactly how the model will be used in production and exposes whether performance degrades as it forecasts further out.

For churn and credit scoring, the equivalent trap is temporal leakage through features rather than through the split itself: a feature like "days since last support ticket" computed using data collected after the customer had already decided to churn will make the model look excellent in backtesting and fail in production, because that information wasn't actually available at prediction time. The discipline that catches this is building every feature with an explicit point-in-time cutoff and testing the model on a genuinely future time window that was held out entirely during feature engineering, not just during model fitting — a subtler and more commonly violated rule than most teams initially realise.

Picking a metric that matches the business decision

Accuracy metrics need to match what the forecast or classification is actually used for, not just be statistically convenient. A demand forecast used to set safety stock cares asymmetrically about under-forecasting (stockouts lose sales and damage customer trust) versus over-forecasting (excess stock costs holding fees but doesn't lose the sale), so a symmetric metric like RMSE is often the wrong optimisation target — many production forecasting systems use a custom asymmetric loss, or report a full predictive distribution (quantile forecasts at the 10th, 50th and 90th percentile) so the inventory team can choose their own service-level trade-off rather than have it baked into a single point estimate. Churn and credit models similarly need precision-recall trade-offs chosen against the actual cost of a false positive (wasting a retention offer, or wrongly declining a good borrower) versus a false negative (losing a customer, or approving a defaulter), which is a business decision the data science team cannot make unilaterally from an ROC curve alone.