Label Design for Microstructure Prediction

Ask a new quant to build a model that predicts short-term price direction and they'll usually reach straight for a classifier and a feature set. The part that actually determines whether the project succeeds is quieter and comes first: what, precisely, is the model trying to predict? In microstructure, where "the future" can mean the next tick, the next second, or the next five minutes, and where "moved" can be defined a dozen different ways, label design is where most of the real thinking — and most of the silent mistakes — happen.

The horizon is not free to ignore

The first choice is when to look for the outcome. Predicting the mid-price move over the next 100 milliseconds is dominated by microstructure noise — bid-ask bounce, queue mechanics — that has nothing to do with information and everything to do with the mechanics of how quotes update. Predicting the move over the next 30 minutes captures genuine information diffusion but drowns any short-horizon signal in unrelated intervening news and order flow. There's no universally correct horizon; it has to match the timescale of the decision the model is meant to support — a market-making quote decision needs a horizon of seconds, an execution-scheduling decision needs minutes to hours.

Common label design mistakes

The most damaging error is a label that peeks into the future via a feature computed over a window that overlaps it — for instance, labeling "did the price rise in the next minute" using a feature that's an average over "the next five minutes," which partially contains the very move being predicted. A second common mistake is defining the label using event time (the next $k$ trades) when the features are computed in calendar time (the next 10 seconds), or vice versa — the two clocks run at very different speeds depending on how busy the market is, and mismatching them silently changes what "horizon" actually means from one period to the next. A third is using a raw return as the label without triple-barrier-style logic (a stop level, a target level, or a max holding time, whichever comes first) — a plain fixed-horizon return label can call a trade a "loss" even though price briefly moved favorably and would have been captured by any realistic exit rule.

Worked example: two labels, two different conclusions

A researcher tests whether order-book imbalance predicts price direction. Using label A — return over a fixed 5-second clock horizon — the feature shows weak, inconsistent predictive power. Using label B — return over the next 20 trades regardless of how long that takes (event time) — the same imbalance feature shows a clear, statistically significant relationship. The difference isn't the feature; in a fast market, 20 trades might occur in 2 seconds, and in a slow market, in 60 seconds. Fixed calendar time forces the model to predict across wildly different amounts of "market activity" from one instance to the next, diluting a signal that's genuinely tied to how much has actually happened, not how much wall-clock time has passed.

What this means in practice

Before touching a model, write down exactly how the label is computed, over what clock, using what data, and confirm on paper that none of the features could see any part of that window. Most microstructure "signals" that look strong in-sample and vanish live turn out to be label-design leakage rather than genuinely useless features — the fastest way to build trust in a new feature is to first prove the label itself is clean.