Label Construction and Prediction Horizon

"Predict whether the stock goes up" sounds like a well-defined task until you try to code it: up over what window — the next minute, the next day, the next month? Up relative to what — zero, the risk-free rate, the sector? Measured from what starting point — the current bar's close, or the next bar's open, which is the price you could actually trade at? Every one of these choices is a modeling decision baked into the label, made before a single feature is computed, and a sloppy answer here can make an otherwise sound model worthless or, worse, look great in backtest and fail live.

The idea: the label encodes both the target and the horizon

A label is the target variable the model learns to predict, and it always has an implicit or explicit horizon — the gap between the time the features are observed and the time the outcome is realized.

$$y_t = f\big(P_{t+h}\big) - f\big(P_t\big)$$

In plain English: the label at time $t$ is built from the price (or some function of it) $h$ periods ahead compared with the price now — $h$ is the horizon, and it must be chosen deliberately: too short and the label is dominated by noise and transaction-cost-eating microstructure jitter; too long and the label smears together many unrelated future events, diluting whatever signal the features actually capture. The label must also be computed from prices actually achievable at execution time (the next tradable price after the decision, not the bar's own close), or the model is effectively trained on prices it could never have traded at.

Worked example: three horizon choices for the same signal

A feature computed from order-book imbalance at 10:00:00 might be labeled three different ways: (1) return from 10:00 close to 10:01 close — a 1-minute horizon dominated by bid-ask bounce noise; (2) return from 10:00 close to 16:00 close — a full-day horizon where the order-book imbalance signal, which typically decays within minutes, has long since become irrelevant to what happens by end of day; (3) return from the next tradable price after 10:00 (say the 10:00:05 execution) to 10:05 — a 5-minute horizon aligned with how long the imbalance signal is known to persist and starting from a price the strategy could actually achieve. Only the third framing gives the model a fair shot at learning the real relationship: horizon 1 is too noisy, horizon 2 is measuring the wrong thing entirely, and the difference between the three labels is the entire difference between a viable strategy and a random one built on identical features.

What this means in practice

Label design deserves as much scrutiny as model architecture, arguably more — a wrong horizon or a label built from unreachable prices can produce a backtest that looks excellent and a live strategy that loses money, without any bug in the modeling code itself. Practitioners typically study the signal's own decay profile first (how long does the underlying effect actually persist?) before fixing a horizon, and always define the label using only prices and information that would genuinely have been tradable and known at that point in time.