Time series and forecasting · insight-0201
Drop or forecast any regressor that is not known at the forecast origin for the full horizon
- Evidence type
- documented fact
- Difficulty
- medium
- Roles
- Data scientist, ML engineer
- Industries
- aviation, retail, energy
Summary: situation, action, reason, boundary
Situation
A demand model uses yesterday's competitor fare as a feature, and the business needs forecasts 1 to 28 days ahead.
Action
For each feature, write down the last timestamp at which it is known relative to the origin. Keep it only for horizons where it is available, or replace it with its own forecast and evaluate with that forecast.
Reason
A feature is only useful at horizon h if its value at origin plus h is known at the origin. Otherwise the backtest measures a model you cannot run.
Boundary
Any multi-step forecast with exogenous inputs: prices, weather, promotions, macro series.
Symptom or risk
Backtests feed the realised competitor fare for every target day, so accuracy looks strong; in production the value exists only for day 1.
Exceptions
Features measured at the origin and used as lagged inputs (for example competitor fare at origin for all horizons) are legitimate when the model is trained the same way.
Trade-offs
Forecasting the regressor adds its error to yours; dropping it may cost short-horizon accuracy.
Pitfalls
Using a feature table keyed by target date instead of origin date hides the problem.
Example
Synthetic airline data: competitor fare on departure day is unknown 21 days out; the fare seen at the snapshot is known.
Lessons and concepts
Claims and their sources
Regression forecasts require future values of the predictors, either forecast or assumed; predictors known in advance such as calendar variables are straightforward.