Lag Features and Horizons

## What a lag feature is A time series is a target measured repeatedly over time: daily units sold, hourly requests, weekly revenue. Tabular forecasting turns that sequence into a supervised learning table, one row per timestamp, with the value to predict in a target column and everything known before that timestamp in feature columns. A **lag feature** is the simplest such column: the target's own earlier value, copied forward onto a later row. Writing the series as `y[1], y[2], ..., y[T]`, the lag-k feature on the row for time `t` is `y[t-k]`. Lag-1 is yesterday, lag-7 is the same day last week, lag-28 is four weeks back. The lag is a shift of the target column downward in time; nothing is aggregated or transformed. The first `k` rows have no value for lag-k and are usually dropped or masked. ## Why lag-7 specifically Daily human-driven series almost always have a weekly cycle. Retail demand peaks on weekends, B2B traffic peaks midweek, payroll-driven spending clusters on particular days. That cycle repeats with period 7, so `y[t-7]` sits at the same phase of the cycle as `y[t]`. That matters because lag-1 is a poor guide across a weekday boundary. If Sunday sells three times what Monday sells, a model leaning on lag-1 has to learn a large correction that depends on which day it is. Lag-7 removes most of that: it is already a Sunday when the target is a Sunday. A typical daily feature row therefore carries `lag-1` for the current level, `lag-7` for the same weekday last week, and `lag-28` for the same weekday four weeks back, which averages away a single unusual week without a long window. Lag features also carry information a calendar flag cannot. A day-of-week indicator says only *which* weekday it is, so the model can learn an average weekday effect. Lag-7 carries the actual number, which moves with trend, price changes, promotions and store-level shocks. The two are complementary, not substitutes. ## The horizon constraint Every feature must be computable at the moment the forecast is produced. Call that moment the forecast origin, and call the number of steps ahead the horizon `h`. A row predicting `y[t]` from an origin `h` steps earlier may only use values up to `y[t-h]`. That rule immediately restricts which lags are legal. For a next-day model (`h = 1`), lags 1, 7 and 28 are all fine. For a ten-day-ahead model (`h = 10`), lag-7 would require `y[t-7]`, which is three days *after* the origin — it does not exist yet. The usable lags start at 10: lag-14, lag-21, lag-28 keep the same-weekday property while remaining observable. Building a feature table once and reusing it for every horizon is a common way to smuggle unavailable values into training. There are two standard escapes. A **direct** model per horizon simply drops the lags shorter than `h` and trains on what remains. A **recursive** model predicts one step, feeds its own prediction back in as the lag for the next step, and iterates to the required horizon — cheaper in models but its errors accumulate as the horizon grows. ## Building lags correctly Three mechanical points cause most bugs. First, sort by timestamp within each series before shifting; an unsorted table produces lags that mix unrelated rows. Second, shift in the right direction — a sign error yields `y[t+7]`, a future value, which is a leak that makes offline metrics look brilliant and production collapse. Third, respect series boundaries: with many series in one table, lags must be computed within each series, otherwise the first rows of one product inherit the tail of another. Missing dates deserve care too. If a store is closed on Sundays and those rows are simply absent, a naive shift of seven rows lands six calendar days back, not seven. Reindex to a complete calendar and lag by date, not by row position. ## What an interviewer is checking The question looks definitional but it separates candidates who have built a forecasting table from those who have only read about one. Strong answers name the shift, tie the choice of 7 to the weekly period of the data, and volunteer the availability constraint without prompting. Weak answers describe lag-7 as "a rolling average of the last week", which is a different feature entirely, or claim any lag can be used at any horizon.