Forecasting With Exogenous Variables: What a Model Needs Beyond History

An exogenous variable is one the model reads but does not forecast. Adding one is often described as free accuracy. It is not: the variable’s own future is now part of your problem, and whether that is trivial or fatal depends on a property of the variable you can determine before fitting anything.

Leading, coincident, lagging

Take a demand series for a consumer product and three candidate regressors, one of each kind.

• Leading: branded search volume. People search before they buy. If the useful relationship is between this week’s searches and demand two weeks later, then at any moment you already hold two weeks of the regressor’s future. A leading indicator with lag L is known for free out to horizon L, and that is the entire reason to prefer one.
• Coincident: daily temperature. Ice cream sells when it is hot, on the same day. The relationship may be strong and the fit may be excellent, and it buys you nothing beyond the length of a weather forecast, because to forecast demand for next month you must first forecast the temperature for next month.
• Lagging: warranty claims. Claims follow sales by months. They are highly correlated with demand and they are useless for forecasting it, because by the time the claim exists the sale has happened. A lagging indicator confirms; it does not predict.
• The fourth kind, and the best one: a decision variable. Your own promotion calendar, your price, your planned store openings. Known exactly, arbitrarily far ahead, because you set them. In most commercial forecasting these carry more of the improvement than every external regressor combined.

The question that decides everything

Before asking whether a regressor is correlated with the target, ask whether you will have its value at the time you need the forecast. That single question sorts regressors into three groups.

Known in advance: calendars, holidays, your own decisions, and any regressor entered at a lag at least as long as your horizon. These cost nothing and can be used at any horizon.

Available only historically: anything you observe but cannot forecast and are not willing to. Hosted forecasting services make this an explicit choice — Nixtla’s API, for instance, takes future exogenous values in one argument and a list of historical-only exogenous features in another, and its documentation is clear that supplying a variable historically without future values means the model assumes its historical pattern continues. That assumption is fine for a slowly varying regressor and disastrous for a volatile one, and it is being made whether or not you noticed.

Requiring their own forecast: everything else. These are usable, and the cost is quantifiable.

What forecasting the regressor costs you

Suppose demand is well described by y = 12 + 0.6x plus noise with variance 16, so the residual standard deviation is 4. If x is known, the one-step forecast standard deviation is 4. If x must itself be forecast, with a forecast error standard deviation of 5, that error passes through the coefficient and adds to the variance:

var(y_hat) = 16 + (0.6)^2 x 25 = 16 + 9 = 25       sd = 5

interval width grows from +/- 1.96 x 4 = +/- 7.84
                       to +/- 1.96 x 5 = +/- 9.80        (25% wider)

That is the honest accounting, and it is the accounting almost never done. The regressor improved the fit — it explains variance in sample — and simultaneously widened the out-of-sample interval by a quarter, because you traded known residual noise for unknown regressor noise amplified by the square of the coefficient. A large coefficient makes this worse, not better: doubling the coefficient to 1.2 makes the added term 36, taking the total to 52 and the standard deviation to 7.2.

The corollary is a rule you can apply before fitting. A regressor is worth including at horizon h if the variance it explains exceeds the coefficient-squared times the variance of its own h-step forecast error. For a regressor with a strong relationship and a series that is itself hard to forecast, that inequality often fails, and the resulting model is worse than one that never saw it while scoring better on every in-sample statistic.

The evaluation mistake

The most common error in this whole area is evaluating a model with actual future values of the regressor rather than forecast ones. Backtest a demand model using the temperatures that actually occurred, and you have measured the accuracy of a model that will never exist, because on the day you run it for real the temperature is a forecast with its own error.

The fix is procedural. At every forecast origin in your backtest, replace each not-known-in-advance regressor with the forecast you would actually have had at that origin, produced by the method you would actually have used, from data available at that origin. It is more work and it usually reveals that a chunk of the apparent improvement was borrowed from the future. This is a specific instance of the general rule behind rolling-origin evaluation: every input to the forecast must be reconstructible from the state of the world at the origin.

Two secondary traps sit next to it. Restated data — figures revised after publication — leaks the same way, because the value in your historical table is the revised one and the value you would have had is the first print. And a regressor whose availability is delayed by collection lag is not available at the origin even though its timestamp suggests it is.

Choosing regressors

1. List candidates and mark each as known in advance, historical only, or requiring a forecast. Do this before looking at any correlation, so the correlation cannot talk you into a variable you cannot supply.
2. For the leading ones, find the lag by cross-correlating the regressor with the target over a range of lags, and keep only lags at least as long as your horizon. A lead of one week does not help a four-week forecast.
3. Encode calendar effects properly. Holidays are indicator columns, not a smooth function of the day of the year, and a holiday that moves between years is why the naive year-ago comparison fails every spring.
4. Add one regressor at a time and score each addition on a rolling origin with the regressor forecast, not the regressor actual. Stop when the interval stops narrowing, since a point forecast that improves while its interval widens is not an improvement for anything you would use it for.