How is a label table different from an ordinary training table?

An ordinary training table may just contain features and a target. A label table makes the time logic explicit: entity, as-of timestamp, observation window, prediction window, and label. Features are then generated against that structure. This separates deciding what is being predicted from deciding how to compute the inputs.

Is leakage only about using future data?

Future data is the classic case, but leakage also includes fields that are proxies for the answer. A cancellation status, fraud investigation result, fulfilment outcome, or manually corrected category may be recorded before the dataset extract yet still be unavailable at prediction time. The test is not when you queried it, but when the production system would have known it.

Where should observation and prediction windows be set?

It depends on the decision the model supports, data freshness, and how quickly the outcome becomes meaningful. The observation window should capture history available before the prediction. The prediction window should match the action horizon: when the business would act and when success or failure can be observed. Arbitrary windows often produce labels that are easy to train but operationally irrelevant.

Label Modeling and Leakage

Label modelling is the design of a training table that states the entity, prediction time, available history, future outcome window, and target value for each example. Leakage is the error of letting information unavailable at prediction time enter features, making offline evaluation look better than the model can reproduce in production.

The need for label modelling comes from a mismatch between datasets and decisions. Raw data usually records facts when systems happen to write them, not when a model would have known them. If you train on a convenient snapshot, you can easily include events, statuses, or aggregates that were created after the decision point. The model then appears to learn useful patterns, but it has actually learned answers encoded by time travel.

A leak-resistant label table starts with an entity and an as-of timestamp: the moment the prediction is pretending to be made. The observation window ends at that timestamp and defines what history features may read, such as prior 30 or 90 days. The prediction window starts after the as-of time and defines where the outcome is measured, such as the next 7 or 30 days. Features are joined using effective-time filters, not just ids.

The trade-off is that correct modelling is stricter and often less flattering. You may discard rows without sufficient history, ignore late-arriving facts, or recompute features as they would have looked at the time. Metrics can fall when leakage is removed, which is good news rather than bad news: the estimate is becoming honest. The hard parts are usually timestamp semantics, backfilled records, slowly changing fields, and operational definitions of the target.

Engineers meet label modelling when building churn, fraud, risk, recommendation, sales, support, and lifecycle models. In practice it shows up as a label-generation job, a feature pipeline contract, and review questions in pull requests: what was the prediction time, what data was knowable then, and does every join respect it? A common misunderstanding is that train-test splitting alone prevents leakage. It does not if each row already contains future-derived feature values.

Go deeper

Everything DataLabel Modeling and LeakageCreate a label table with observation windows and prediction windows that avoids target leakage.Open the lesson

Common questions

How is a label table different from an ordinary training table?: An ordinary training table may just contain features and a target. A label table makes the time logic explicit: entity, as-of timestamp, observation window, prediction window, and label. Features are then generated against that structure. This separates deciding what is being predicted from deciding how to compute the inputs.
Is leakage only about using future data?: Future data is the classic case, but leakage also includes fields that are proxies for the answer. A cancellation status, fraud investigation result, fulfilment outcome, or manually corrected category may be recorded before the dataset extract yet still be unavailable at prediction time. The test is not when you queried it, but when the production system would have known it.
Where should observation and prediction windows be set?: It depends on the decision the model supports, data freshness, and how quickly the outcome becomes meaningful. The observation window should capture history available before the prediction. The prediction window should match the action horizon: when the business would act and when success or failure can be observed. Arbitrary windows often produce labels that are easy to train but operationally irrelevant.

Every term