Order book features: what actually carries information
The book contains far more numbers than signal. A handful of constructions carry most of what is usable, and most of the rest is a slower way to look at price.
Vizanix engineering · about the author
- SECTION
- Market mechanics
- PUBLISHED
- 2026-08-31
- CHAPTERS
- 5
- READ NEXT
- 3
- LANGUAGE
- written in English
An L2 book gives you dozens of levels updating many times per second. Almost all of that is noise or redundant with price. The features that survive honest validation are few, and they tend to measure the same underlying thing: pressure that has not yet been expressed in price.
The ones that reliably carry information
Depth imbalance. The classic: resting volume on the bid side relative to the ask side over the first N levels. Normalise it so it lives in [-1, 1] and it becomes comparable across instruments.
def imbalance(book, levels=5):
b = sum(q for _, q in book.bids[:levels])
a = sum(q for _, q in book.asks[:levels])
return (b - a) / (b + a) if (b + a) else 0.0Two cautions. It is highly autocorrelated, so a naive train/test split leaks — see look-ahead bias. And it is trivially spoofable, so weight levels near the touch more than distant ones.
Taker flow imbalance. Aggressive buy volume against aggressive sell volume over a short window. This measures executed intent rather than displayed intent, which makes it harder to fake and generally more informative than depth alone.
Liquidity depletion rate. How fast resting size at the touch is being consumed. A level being eaten through quickly behaves very differently from the same level sitting untouched, and depth snapshots cannot distinguish them.
Book slope. How fast cumulative depth grows as you move away from the mid. A steep book means large orders move price little; a flat one means the opposite. This is the feature that should be feeding your position sizing, not just your signal.
Cancel-to-trade ratio. Lots of placement and cancellation with few executions indicates algorithmic positioning rather than genuine interest. Useful as a regime marker.
The ones that mostly are not
- Spread alone. Mostly a volatility proxy. Include volatility directly instead.
- Total book depth. Dominated by instrument and time of day. Normalise or drop.
- Deep levels, beyond a few percent from the mid. Rarely executed, frequently fake, and they dilute the levels that matter.
- Number of orders per level. Interesting where the venue exposes it faithfully; usually it does not.
Time or events
Book features sampled on a clock are strange objects: during a burst you average away the information, and during quiet periods you sample the same state repeatedly.
Event-based sampling — one observation per N trades, or per fixed traded volume — produces series with better statistical properties. Volume bars in particular give returns closer to normally distributed, which most methods appreciate.
This is one reason our microstructure engine is event-driven end to end: the feature engine updates on book and trade events into RAM ring buffers, with no resampling step and no pandas anywhere in the realtime loop.
Horizon determines everything
| Prediction horizon | Do book features help? |
|---|---|
| Milliseconds to seconds | Yes — this is where they dominate |
| Seconds to a minute | Yes, decaying |
| Minutes | Marginal; flow features outlast depth features |
| Hours or longer | Essentially no |
If your strategy holds for hours, order book features are an expensive distraction. The infrastructure to record and process them at event resolution only pays for itself if the prediction horizon is short enough for the information to still be there.
Practical order of work
- Record raw book and trade events first. You cannot reconstruct them later.
- Start with imbalance, taker flow and depletion. Three features, honestly validated.
- Run the look-ahead audit on each one before it enters a model.
- Use book slope for sizing even if you never use it as a signal — it is the highest-value application of book data for most operations.
- Add complexity only when the simple version has a measured baseline to beat.
This article describes engineering practice. It is not investment advice. Vizanix develops software and does not promise trading returns.