Demand Forecasting with Supervised Learning: Does More Context Help?用監督式學習做需求預測：更多情境資訊真的有幫助嗎？

This article continues the case study introduced in Forecasting iPhone 17 Pro Demand: From Statistics to Deep Learning and follows the statistical deep dive, Demand Forecasting with Statistical Models: How Far Can Demand History Alone Take Us?.

The statistical article showed how Holt–Winters and SARIMA could turn one store–SKU demand history into a useful one-day-ahead forecast. In such a setup, each store–SKU combination needs its own fitted model. Twenty stores and six SKUs would therefore require 120 models, each learning its own parameters. This local approach also creates a practical maintenance burden.

Now we change both the scope of the forecasting system and the information available to it. Instead of fitting one model to one demand history, we train global supervised-learning models across 120 related store–SKU series. A global model can share evidence across stores and products, represent nonlinear relationships, and—depending on the experiment—use price, promotions, marketing, competitor activity, and weather alongside demand history and the calendar.

This article is structured as follows:

1. The forecasting question changes
2. Turn a time series into supervised-learning rows
3. Feature engineering creates memory
4. Supervised learning
   • Linear regression
   • XGBoost
5. Model selection
   • Compare model structures
   • Evaluate additional business context
   • Selection outcome
6. What feature importance can and cannot say
7. Operational recommendation
8. What supervised learning costs

The forecasting question changes

The statistical models in the previous experiment answered:

How does demand evolve from its own past?

Holt–Winters represented demand through level, trend, and seasonality. SARIMA modelled relationships between previous values and previous forecast errors. Both extracted substantial predictive information from demand history. However, because demand history was their only input, they could not directly account for information known before the forecast date, such as:

• a promotion would begin tomorrow;
• the price had changed;
• a marketing campaign was active;
• the store would be closed;
• a competitor had launched an offer;
• heavy rain was forecast.

Unlike the local statistical models, the global supervised-learning model is trained on pooled observations from all 120 series, allowing patterns learned from one store or product to inform forecasts for related series.

To a history-only model, an unexpected promotion surge was simply a forecast error.

Supervised learning reframes the problem:

Can one global supervised-learning model share patterns across 120 store–SKU series—and do nonlinear modelling and additional business context improve its held-out forecasts?

For store $s$, SKU $k$, and forecast date $t+1$, we write:

The feature vector $x_{s,k,t}$ can contain demand history, calendar position, store and SKU identity, and business signals known before $t+1$ begins.

This question separates three ideas: learning across related series, comparing linear and nonlinear models, and testing whether business context adds value beyond demand history and calendar features.

Keep evaluation chronological

To answer the forecasting question fairly, we retain the chronological boundaries used in the statistical experiment. The final 112 days are divided into consecutive 56-day validation and test windows, rather than randomly shuffling observations across time.

The figure shows one representative store–SKU series, but the same date boundaries are applied to all 120 series. For supervised learning, the first 28 training dates are additionally removed because the lag and rolling features do not yet have sufficient history.

After the 28-day warm-up, the chronological windows contain:

All series share the same date boundaries. Pooling never permits a target from a future date—even from another store—to enter the training set.

Turn a time series into supervised-learning rows

A tabular model has no memory of sequence order. It sees independent rows of features and targets. To use it for forecasting, we must turn the sequence into a supervised-learning table.

For each store–SKU and date, one row contains:

Information available before tomorrow → Tomorrow's demand

An illustrative row might be:

The target appears in the training table because the historical outcome is known when the model is fitted. It must never appear among the input features for that same row.

The synthetic dataset contains 730 daily observations for each of 120 store–SKU series—20 stores and six SKUs—giving 87,600 rows in total. Our longest historical feature looks back 28 days, so the first 28 observations of each series do not have a complete feature history. Removing this warm-up period leaves 702 observations per series, or 84,240 supervised-learning rows.

Feature engineering creates memory

The statistical models represented temporal structure internally. A tabular model needs us to expose that structure as columns.

Lag features

A lag gives the model an earlier demand value:

Consider four consecutive days from one store–SKU series:

Each lag 1 value is the demand observed one day earlier. For Day 4, the model receives 38 as an input, while 50 is the target and remains unknown when the forecast is produced.

The experiment uses lags of 1, 7, 14, and 28 days:

• lag 1 captures the most recent demand and short-term persistence;
• lag 7 compares the forecast date with the same weekday last week;
• lag 14 checks whether the weekly pattern has persisted for two weeks;
• lag 28 provides a four-week reference that is less sensitive to one unusual week.

Shifted rolling statistics

Rolling means and standard deviations summarise recent level and volatility. For a seven-day mean used to predict date $t$:

The sum ends at $t-1$. This one-period shift is essential: including $y_t$ would leak the target into its own predictors.

The experiment uses rolling statistics of 7 and 28 days.

Cyclical calendar features

Weekdays and days of the year repeat. Representing weekdays as integers would assign Monday 0 and Sunday 6, creating an artificial distance between two adjacent days. Instead, sine and cosine map their positions onto a circle:

Here, $P=7$ for the weekly cycle and $P=365.25$ for the annual cycle.

Both are needed because sine alone assigns the same value to more than one position on the circle. The pair uniquely represents position within the weekly or annual cycle.

• Weekly position: dow_sin and dow_cos
• Annual position: doy_sin and doy_cos

The history, calendar, and identity feature set ultimately contains 18 numeric features and four categorical fields. The full-context set expands this to 27 numeric features and five categorical fields.

The 18 numeric features are:

The four categorical fields are store ID, SKU ID, store tier, and colour family. The full-context set adds nine numeric business features—price and discount information, promotion and competitor flags, marketing, and weather—and promotion type as a fifth categorical field. This produces 27 numeric features and five categorical fields before one-hot encoding.

Prevent data leakage

Creating a feature is only half the task. We must also confirm that its value would have been available when the forecast was produced. Otherwise, the model may learn from information that belongs to the future.

Data leakage is not only a coding error; it can also be a business-definition error. A variable may exist in the final dataset without having existed at the forecast timestamp. Realised rainfall, for example, is not a valid input to a forecast created the previous evening—the model would have had access only to the weather forecast available at that time.

The experiment uses the following availability assumptions:

The synthetic data contain realised values for marketing, competitors, and weather. For this case study, we treat them as perfectly available day-ahead signals. That assumption is deliberately optimistic.

In a production backtest, each input should come from the point-in-time snapshot that genuinely existed at the forecast timestamp. Replacing a historical weather forecast with observed weather would quietly make the model look better than it could have been in operation.

The rule is simple:

A feature is valid only if its value, source, owner, and availability time are known before the prediction is made.

Prepare features for modelling

Before training, the numeric and categorical features must be converted into a model-ready matrix.

Standardisation is particularly useful for linear regression because its inputs may have very different scales—for example, storage capacity, price, and rainfall. Tree-based XGBoost does not require scaled numeric features.

Store, SKU, tier, colour family, and promotion type are one-hot encoded. For example, store_id becomes a collection of store-specific indicator columns rather than an integer that would incorrectly imply an order between stores.

Most importantly, the preprocessor is fitted only on the training data. Its learned means, standard deviations, and categories are then applied unchanged to validation data. This prevents preprocessing itself from leaking future information.

Supervised learning

The experiment uses two supervised-learning model families. Linear regression provides an interpretable baseline; XGBoost provides nonlinear interactions and greater flexibility.

Linear regression

Linear regression estimates tomorrow's demand as a weighted sum of features:

An illustrative forecast might be:

Baseline demand              25 units
Strong demand last week      +8 units
Weekend                      +6 units
Promotion                    +4 units
Higher price                 −3 units
Competitor promotion         −2 units
------------------------------------------------
Predicted demand             38 units

The model is fast and easy to inspect. It reveals whether simple additive relationships already explain the target.

That simplicity comes with several assumptions and limitations:

1. Linearity and additivity.

Linear regression assumes that expected demand can be represented as a weighted sum of the supplied features. Without additional terms, a discount receives the same marginal effect across stores, products, and calendar conditions. Nonlinear or non-additive relationships can be introduced through engineered features.

To make the promotion effect different on weekends, for example, we would need a feature such as:

These terms make the relationship nonlinear in the original inputs, but the regression remains linear in its coefficients. The limitation is that the modeller must decide which interactions and transformations to include; linear regression does not discover them automatically.

2. Multicollinearity.

Features such as price, discount, promotion status, and promotion type may contain overlapping information. Strongly correlated features can make individual coefficients unstable, even when the resulting predictions remain similar. Typical remedies include removing redundant variables, selecting a reference category during one-hot encoding, or using regularisation such as Ridge regression. Standardisation puts features on comparable scales, but it does not remove multicollinearity.

3. Error behaviour.

Classical regression analysis assumes that the remaining errors have no systematic relationship with the inputs, have reasonably stable variance, and are not strongly correlated across observations. Time-series errors may violate these conditions because neighbouring dates share demand patterns and high-demand periods may produce larger errors. Normal residuals are mainly needed for conventional statistical tests and analytical intervals, not for calculating point forecasts.

In this experiment, linear regression is used as a predictive baseline rather than for causal interpretation, coefficient significance tests, or analytical prediction intervals. We therefore do not need to correct every violation for statistical inference. Instead, we assess whether the model generalises through its chronological validation and test performance. The assumptions still matter when their violation reduces forecast accuracy, but their practical effect is judged through MAE, RMSE, WAPE, and bias rather than through coefficient $p$-values. If coefficient stability became important in production, Ridge regression and residual diagnostics would be sensible extensions.

XGBoost

Unlike linear regression, XGBoost can learn nonlinear relationships, thresholds, and feature interactions directly from the data. A decision tree begins with all training observations in one group. At each node, it tests possible features and thresholds, then selects the split that produces the largest reduction in prediction error.

XGBoost builds an ensemble of decision trees sequentially. The first tree improves an initial prediction. Each later tree focuses on where the current ensemble still incurs loss.

The final prediction is the sum of many small corrections:

where $f_m$ is tree $m$, $M$ is the number of trees, and $\eta$ is the learning rate controlling how much each tree contributes.

Under squared-error loss, the negative gradient is proportional to the residual:

This is why boosting is often described as repeatedly learning the remaining errors. More generally, XGBoost uses the first and second derivatives of its objective to evaluate efficient split improvements.

A simplified sequence might look like:

Initial prediction                    40
Tree 1: lifecycle adjustment          −5
Tree 2: weekend interaction           +7
Tree 3: promotion-weekend interaction +6
Tree 4: recent-demand correction      +3
------------------------------------------------
Final forecast                        51

Individual trees are not normally interpretable as clean business effects like this; the example only illustrates how corrections accumulate.

Tree splits naturally represent thresholds and interactions. A discount can matter only after it exceeds 10%, heavy rainfall can matter more than light rain, and a promotion can behave differently by store, SKU, weekday, and lifecycle stage without manually defining every combination.

That flexibility needs control. The experiment uses shallow-enough trees, learning-rate shrinkage, row and feature subsampling, L1 and L2 regularisation, and early stopping. Training stops when validation MAE fails to improve for 50 rounds. The history, calendar, and identity model selects 529 trees, while the full-context model selects 289. Those counts are then locked before the test window is opened.

Model selection

The experiment evaluates three global model configurations through two controlled comparisons. WAPE remains the primary metric, aggregated across all 120 store–SKU series. Validation guides model development; the locked test window shows whether those choices generalise.

Compare model structures

Objective. Determine whether a tree-based model improves forecasting when both models receive exactly the same information.

Controlled design. Full-context linear regression and full-context XGBoost use the same history, calendar, and business features, as well as the same chronological training, validation, and test windows. The main difference is model structure: linear regression uses predefined additive relationships, whereas XGBoost learns thresholds and interactions.

Performance. WAPE remains the primary metric, aggregated across all 120 store–SKU series.

XGBoost improves test WAPE by 0.55 percentage points. This suggests that the more flexible tree structure adds predictive value beyond the additive model, although the improvement is modest rather than transformational.

Evaluate additional business context

Objective. Determine whether price, promotions, marketing, competitor activity, and weather improve XGBoost beyond demand history and calendar information.

Controlled design. Both configurations use XGBoost and the same global training process. The core model sees lags, rolling statistics, calendar fields, and store and product identity. The full-context model adds the business signals. Only the information set changes, making this a group-level ablation rather than individual feature selection.

Performance. Validation initially favours the richer model, but the locked test result changes the conclusion.

Additional context improves validation WAPE by 0.41 percentage points but does not improve test WAPE. The 0.02-point test difference is negligible, so the two models are effectively tied on the primary metric. The full-context model has a lower test RMSE—6.48 versus 6.64—but its extra forecast-time dependencies are not justified by WAPE alone.

Their biases also point in opposite directions: the core XGBoost model underforecasts by 4.91% in aggregate, while full-context XGBoost overforecasts by 2.30%. Model selection therefore depends on more than ranking a single accuracy number.

This does not prove that promotions, price, marketing, competitors, and weather are useless. The 56-day test window may represent a different regime, some context variables may duplicate information already contained in demand history, and the synthetic signals may be noisy relative to daily store–SKU variation. Importance and a single holdout cannot complete feature selection; incremental value should be checked across additional rolling validation windows.

Selection outcome

The evidence supports XGBoost over the additive linear baseline. It does not show a stable WAPE benefit from the additional business-context feature group. The simpler history, calendar, and identity configuration is therefore an operationally attractive candidate, but that choice remains provisional until it is confirmed across more rolling validation periods and a new untouched evaluation window.

What feature importance can and cannot say

Gain-based feature importance measures how much a feature reduced XGBoost's regularised training objective across tree splits. Every time XGBoost builds a tree, it evaluates possible splits. A split is useful when dividing the observations into two groups reduces the model’s regularised training objective.

In simplified form:

Suppose a tree node contains observations with a training loss of 1,000. Splitting those observations using is_black_friday_week reduces the combined loss of the two resulting branches to 700:

That split contributes a gain of 300 to is_black_friday_week. XGBoost repeats this process across every node and every tree. The gains from all splits using the same feature are then added together:

The importances are then normalised.

For the full-context model, the leading fields include:

• Black Friday week: 18.8%;
• seven-day rolling mean: 15.1%;
• weekend: 8.2%;
• marketing index: 7.9%;
• 28-day rolling mean: 7.1%;
• discount percentage: 6.2%.

This looks like evidence that context matters. But importance answers a training question, not a deployment question. It says the model used a feature to reduce its fitted objective. It does not say that the feature caused demand, would survive a policy change, or improved held-out accuracy.

Correlated features can substitute for one another. Store identity can absorb information associated with store tier; price can overlap with discount and promotion type. A field with low individual importance may still matter through interactions, while a field with high importance may fail to generalise.

The most important evidence remains the controlled context comparison: the full-context model did not beat the core model on test. Feature importance cannot overturn that result.

Operational recommendation

Treat history, calendar, and identity XGBoost as the provisional leading candidate for the global forecasting system. It achieves the lowest held-out panel WAPE and requires fewer forecast-time dependencies, but its 0.02-percentage-point advantage over full-context XGBoost is negligible. Confirm the choice across additional rolling validation periods and a new untouched evaluation window before treating it as final.

Retain full-context XGBoost, global linear regression, and seasonal naive as challengers. They provide useful reference points for detecting whether the core model has stopped adding value. Its 4.91% aggregate underforecasting bias should also be monitored rather than hidden behind its leading WAPE.

Before promoting the full-context model:

• reconstruct every feature from genuine point-in-time sources;
• evaluate across additional rolling windows and business regimes;
• verify performance during promotions, holidays, launches, and competitor events;
• measure stockouts and excess inventory alongside WAPE and bias;
• add an uncertainty method if the forecast will set service levels or safety stock.

Each daily model run should generate one demand forecast for every store–SKU series. These predictions are demand baselines, not order quantities. Replenishment must still account for stock on hand, confirmed inbound inventory, lead time, and the chosen safety buffer.

What supervised learning costs

Supervised learning expands what the model can represent, but it also expands what the forecasting system must maintain.

• Feature pipelines create memory. Every lag and rolling statistic must be computed consistently in training and production.
• Availability rules prevent leakage. Every future covariate needs a point-in-time source and an accountable owner.
• Global training shares evidence. One model can learn across stores and products, but identity features and distribution shifts must be monitored.
• Flexible models can overfit. Early stopping and regularisation reduce the risk; held-out time windows reveal whether they succeeded.
• Importance is not causality. A model using a feature does not prove that changing the feature will change demand.
• Uncertainty is not automatic. Calibrated intervals require an additional method such as conformal prediction, quantile objectives, or a probabilistic model.

The experiment answers its title with a qualified result. Supervised learning helped: both XGBoost models improved global panel WAPE over linear regression and seasonal naive. More context did not help global test WAPE: the fuller information set failed to generalise better on the article's primary metric, although it achieved a slightly lower RMSE.

That is not a disappointing conclusion. It is exactly why we use chronological validation, ablation tests, and honest holdouts. A feature earns its operational cost only when it improves decisions outside the data used to choose it.