Regression forecasting with known future covariates

Regression forecasting can combine trend, calendar effects and external variables. The central question is not whether a feature correlates with the target. It is whether its value will be available for every future horizon at the moment the forecast is issued.

Month number and a published holiday calendar are normally knowable. An approved promotion schedule may be knowable if the plan is frozen and versioned. Realized discount, final campaign spend and end-of-month weather are not known unless they are themselves forecast or supplied as scenarios.

Compare an available feature set

The local lab fits linear models on 120 months. Both models contain a trend and sine/cosine annual calendar terms. The second also contains an authored promotion flag available in advance.

The promotion coefficient is approximately 8.52 units, close to the fixture’s authored lift. This recovery is possible because the fixture is simple; it is not a causal estimate from observational business data.

from timeseries_cases import regression_case

result = regression_case()
base = result["models"]["calendar_only"]["test_rmse"]
promo = result["models"]["calendar_plus_planned_promotion"]["test_rmse"]
assert result["future_covariate_known"] == "planned promotion calendar"
assert promo < base
print(round(base, 2), round(promo, 2))

The improvement is modest because the test also contains a structural break that the approved calendar does not describe. A genuine known feature cannot repair every unknown future change.

Build an availability ledger

For each candidate covariate, record its source, publication timestamp, revision policy, future horizon, missing-value fallback and owner. Backtesting should use the version that was available at each historical origin. A final corrected promotion table can leak cancellations and date changes that planners did not know earlier.

When future values are uncertain, create explicit scenarios such as low, approved and high spend. Keep scenario assumptions beside forecasts and do not present a conditional scenario as an unconditional prediction. If another model forecasts the covariate, its uncertainty and errors must flow into the end-to-end evaluation.

Prevent calendar mistakes

Encode cyclic month behavior with sine and cosine or appropriate categorical terms rather than treating December as numerically far from January. Handle movable holidays by actual dates. Include exposure when months or stores have different operating days. Check duplicated events and distinguish “promotion planned” from “promotion ran.”

Regularization and nonlinear models can add flexibility, but they retain the same availability constraint. Validate the complete feature pipeline at chronological origins. Compare it with seasonal naïve and include a model that can run if the planning system does not deliver its future calendar.

The Data Science course connects feature engineering to time-aware validation, reproducible evidence and deployment contracts.

Exercise

Create a feature ledger for month, festival date, approved price and realized campaign spend. Mark availability at horizons 1, 3 and 6. Build a base forecast with always-known features and a scenario forecast for the rest; do not fill unknown futures with realized values.

Continue learning

This article is part of the Forecasting and time-series analysis sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Forecast intervals: measure coverage as well as width.
• Continue with Lag features for tree-based forecasting.

Reference: Forecasting: Principles and Practice on time-series regression.