Skip to content
Data Modeling

03.06 · Walkthrough

Label Modeling and Leakage

Create a label table with observation windows and prediction windows that avoids target leakage.

A leak-free label table anchors every training example to the time a production prediction would occur, separates historical feature data from future outcomes, and records the entity, prediction time, windows, and label. That structure prevents features from containing information that would only be known after the decision point.

What this lesson answers

  • how to design label tables without leakage
  • what are observation and prediction windows
  • how target leakage enters machine learning features

Notes

A label table defines what you are trying to predict, for which entity, and at what point in time. For each row, choose an “as of” timestamp that represents the moment a prediction would have been made in production. Features must be computed only from data available up to that timestamp, usually over an observation window such as the prior 30 or 90 days. The label is then computed from what happens after that timestamp, inside a prediction window such as the next 7 days or next 30 days.

Common questions

What should a label table contain for time-based prediction?
It should identify the entity being predicted, the timestamp when the prediction would be made, the historical window used for features, the future window used to compute the outcome, and the label itself. Those fields make the training row auditable against the real production decision.
How do observation windows and prediction windows prevent leakage?
The observation window limits features to information available before the prediction timestamp. The prediction window defines the later period used to decide whether the target happened. Keeping those windows separate stops future events, future updates, and outcome-derived fields from entering the feature set.
Why can leakage make offline model results look too good?
Leakage gives the model signals it will not have when serving real predictions. Examples include records updated after the decision time, aggregations that include the outcome period, or status fields written after the event. Offline validation then rewards impossible knowledge, so production performance drops.