The value of the same series seven periods earlier, such as last week's sales for a daily series.

Why do lagged features cause leakage so easily?

Because a small alignment error fetches values from after the prediction moment, smuggling the future into the inputs.

Which lags should I start with?

The ones matching the business rhythm: 1 and 7 for weekly patterns, 12 for monthly, plus a rolling average to smooth noise.

AI Glossary / AI and machine learning / Intermediate

Lagged features

Definition

Lagged features are inputs built from the past values of a series: yesterday's sales, last week's balance, the same customer a month ago, giving a model memory it does not naturally have.

What it means

Most models see one row at a time with no sense of history. Lagged features are how history enters: for each case, you add fields carrying what the same thing looked like one, seven or thirty periods ago.

The idea is simple and the effect is large. A snapshot of today's sales says little; today's sales plus the last eight weeks say trend, seasonality and momentum, which is most of what forecasting knows.

Building them is alignment work: for each case you look backward along its own timeline and fetch the earlier values, carefully, because looking forward by mistake, even by one period, smuggles the future into the inputs and manufactures fake accuracy.

The choice of lags encodes a theory of memory: daily lags for weekly rhythms, monthly or yearly lags for seasonal businesses, several distances together when both matter, and validation decides which distances earn their place.

For a business, lagged features are usually the highest-value feature engineering in any time-based problem: cheap to build, easy to explain, and responsible for most of the lift between a naive model and a competent forecaster.

How it works

Choose the lag distances from the rhythm of the business: 1 and 7 for weekly cycles, 12 for monthly seasonality, and so on.

For each case, fetch the series' own values at those distances back in time, strictly before the prediction moment.

Add derived history where useful: rolling averages, differences from the previous period, distance from the seasonal norm.

Guard the boundary: early cases lack full history, so decide whether to drop them, pad them or mark the missing lags.

Validate on time-ordered holdouts, the only honest test for features that live on the timeline.

Three practical examples

A sales forecast whose inputs include the same product's sales 7, 14 and 28 days earlier, plus the four-week rolling average.
A cash-flow model using each account's balance 1, 3 and 12 months back, capturing both trend and annual seasonality.
A churn model with each customer's usage this month and the month-over-month change, so decline is visible to the model.
A maintenance model using each machine's vibration readings from the previous three inspections, so deterioration over time is visible rather than each reading standing alone.

Think of it this way

Think of a doctor reading a chart rather than a thermometer. The thermometer says now; the chart says now in the context of the last week, and the diagnosis lives in the context. Lagged features turn the model's thermometer into a chart.

The limit: the chart must not contain tomorrow's page. One alignment slip, one field fetched from after the prediction moment, and the model reads the ending in advance, scoring brilliantly in testing and uselessly in life.

Worked example

the one-day slip

Suppose a grocer builds weekly lag features for a demand model and validates an exciting 93 per cent accuracy. The figures are illustrative.

A timing audit finds the four-week rolling average was computed including the target week, a one-row alignment slip.

Rebuilt strictly, accuracy drops to 84 per cent, still the best model they have, now honestly so.

The slip costs a week; the lesson is permanent: every lag feature gets a written definition of its time boundary before it enters training.

Illustrative case study

A fictional energy trader trained a price model with lagged features assembled by a join that, under daylight-saving transitions, occasionally fetched the future hour.

The model backtested superbly and lost money calmly and consistently, because its memory included a few forbidden glimpses of the future.

The invented lesson: in time-series features, the direction of time is a data type. Get it wrong and the past contains the future.

Common misconceptions and mistakes

Lagged features are only for forecasting. Any decision with history benefits: churn, credit, maintenance, anywhere the recent past informs the near future.
More lags always add signal. Each lag is another field to feed and another chance for noise; validation should decide which distances stay.
The database join handles the timing. Joins fetch rows, not chronology; only an explicit time boundary per feature guarantees the past stays past.

Business use

Write a time boundary for every lagged feature: exactly which periods it may see, enforced in code and reviewed.

Start every time-based model with the obvious lags and rolling averages before reaching for exotic features.

Test time-based models on time-ordered holdouts exclusively, because random splits leak the future through correlated neighbors.

Check your understanding

Why are lagged features the highest-value feature engineering for time-based problems?

Answer: Because they give a memoryless model the recent history of the series itself, and trend, seasonality and momentum, most of what forecasting knows, live in that history.

Related terms

Learn next

AI for Business Owners covers how to sanity-check a forecast's inputs before betting inventory on its outputs: https://aiforbusinessandlife.com/academy/ai-for-business-owners. [C2]

Sources

[S7] Hopsworks, MLOps Dictionary. Full URLs are in the source ledger. Verified 11 October 2026.

Previous: Lag operator Next: Lagrange dual function