Historical depth (book history)
Historical depth, or book history, is the recorded sequence of order book states for a past period: the resting size at each price level over time, including the updates between snapshots. It is required to replay a liquidity heatmap or to backtest a rule that reads the book, and it cannot be reconstructed from historical trades.
Senzoukria · Glossary · Updated September 2026
Why trades cannot rebuild the book
A trade record says what executed. An order book record says what was waiting. Orders that rested for an hour and were cancelled never appear in the trade stream, and neither do the sizes that sat behind the ones that did execute. So a history of trades, however complete, contains no information about the book's shape between executions. To have historical depth for a period, someone had to record the depth updates during that period.
That recording has two levels of fidelity. Periodic snapshots capture the book at intervals, for example once per second, and miss whatever happened in between. Event-level recording keeps every update, which is larger but allows exact replay.
What needs it
- Replaying a liquidity heatmap for a past session, since the heatmap is depth drawn over time.
- Backtesting any rule that reads resting size, cumulative depth or wall behaviour.
- Auditing whether a level that appeared to hold was defended by resting orders or simply not reached.
- Studying pulled liquidity, which is by definition size that left without trading.
In Senzoukria
For CME futures, the Replay screen states plainly that the broker's tick history contains transactions only and that there is no order book in a replayed session; the connection manager lists Databento as the source of CME tick history and depth for backtests and replay, per dataset licence. The heatmap's depth, when live, is accumulated from the moment the application connects.
For crypto, the tour explains that on the heatmap depth history is recorded as you watch. The Historical order book view, under the Crypto history tab, loads a completed UTC day of Bybit depth: 200 levels per side, one observation per second, peak resting liquidity in base units, with blank columns where there is no observation and a readout of observed seconds, gaps and the longest gap. Days that are not published stay absent rather than being interpolated. This is a private collection for analysis, not a redistributed dataset.
Common mistakes
- Believing a historical heatmap can be generated from candles or from a tick file.
- Reading a snapshot series as if it were event-level: a wall that appeared and vanished between two samples is not in the data.
- Comparing depth history across venues as if they shared one book.
Related
- Crypto order flow and footprint charts
- Futures backtesting guide
- Backtest
- Liquidity heatmap explained
- Order book snapshot
This page in other languages
Frequently asked questions
- Can historical trades recreate a liquidity heatmap?
- No. A heatmap shows resting size over time, and trades only record what executed. The two datasets answer different questions. A historical heatmap needs book data recorded during the period, including the updates between snapshots, from a source that captured it.
- How complete is a one-second sampled book history?
- It shows the book as it stood at each sample. Orders added and cancelled within the same second are invisible, and sizes are the values at the sample instant rather than peaks inside the interval unless the recorder tracked peaks. Senzoukria's crypto book history reports the count of observed seconds and the gaps so that completeness is visible rather than assumed.
- Is historical depth included with historical ticks from my broker?
- For Rithmic-served history it is not: the archive contains transactions only. Historical depth for CME comes from a recorded dataset licensed from a vendor. The two are separate entitlements even when the same vendor sells both.