What you are predicting and over what horizon

Forecasting and time series · Lesson 1 / 22

A forecast starts with a decision, not with a series

The first question is not which model to pick. It is which decision someone will make from this number, and when they will make it. Until you can answer that, accuracy means nothing: you do not know the granularity you need, you do not know the horizon, and you do not know the price of being wrong.

Forecasting demand for a warehouse and forecasting revenue for the board are different problems built on the very same sales series. The first needs one product in one location, 21 days ahead, broken down by week. The second needs a single country-level number for the quarter. A model that is excellent for one is useless for the other.

Four parameters of the problem statement

Object. What exactly you predict: a SKU in a store, total company sales, the number of tickets arriving in a queue, peak load on a cluster.
Granularity. Hour, day, week, month. The finer the granularity, the more noise you carry and the higher your relative error.
Horizon. How many steps ahead. The forecast horizon is set by supplier lead time, hiring time, or the budget cycle, not by what is convenient for the analyst.
Cutoff. The day and hour when the forecast has to be ready, and which data physically exists by that moment.

The cutoff is the most underrated detail

The buyer sends the purchase order on Monday morning. Sunday sales land in the warehouse on Tuesday evening. So a model trained on data through yesterday will not work in production: that data does not exist on Monday morning. The gap between what is available on paper and what is available at the moment of the decision is the source of most forecasts that looked excellent in testing and fell apart in production.

Forecast problem statement (fill this in before the first line of code)
Object:        SKU sales in a store
Granularity:   daily
Horizon:       14 days ahead
Cutoff:        Monday 06:00
Available at cutoff: sales through Saturday, stock through Friday,
                     promo calendar for 4 weeks ahead
Decision:      order quantity sent to the supplier
Cost of error: under-order = lost margin, over-order = write-off

Insight. The horizon and the cutoff together define how many steps ahead the model really predicts. If data arrives with a two-day lag, a 14-day forecast is really a 16-step-ahead forecast, and the error will reflect that.

Common mistake. Assuming that stretching the horizon costs almost nothing. Error grows with the horizon non-linearly: a week out, the series still carries its own inertia, while a quarter out it is driven by events that are not in the history at all.

Pro tip. Ask the stakeholder what they will do if the forecast says 100 and what they will do if it says 130. If the answer is the same, the problem is framed wrong: nobody needs accuracy inside that range, and the money is better spent on a different horizon or a different object.

Not everything is worth forecasting

Some quantities honestly do not need a forecast. If the decision is made faster than the quantity moves, the current value is enough. If the decision is cheap and reversible, reacting is cheaper than predicting: autoscaling on observed load often beats forecasting load. A forecast pays off where there is a lag between the decision and its effect that you cannot shorten: delivery time, hiring time, the time it takes to bring capacity online.

Cheat sheet

Start with the decision and its lag, then fix the object, granularity and horizon.
The cutoff determines which data the model actually has.
Error grows with the horizon faster than you expect.
If the decision does not change with the forecast, you do not need the forecast.

1. Where does framing a forecasting problem start?

2. What is the cutoff?

3. When is a forecast honestly unnecessary?

🔒 Answer the question correctly to move on to the next lesson.