Aggregated depth vs order-by-order
Aggregated depth reports one total size per price level, while order-by-order depth (market by order, MBO) reports each individual resting order with its own identity, size and queue position. The two feeds describe the same book, but only the order-by-order feed lets a platform follow an order through its life and separate cancellations from executions.
Senzoukria · Glossary · Updated September 2026
What each feed carries
| Aggregated (market by price) | Order-by-order (market by order) | |
|---|---|---|
| Message content | Price, side, total size, order count | Order id, price, side, size, priority |
| Queue position | Not available | Derivable from priority |
| Cancel vs modify vs fill | Only the net change in total | Each event attributed to an order |
| Bandwidth | Lower | Higher |
| Entitlement | Depends on the data subscription | Separate entitlement, where offered |
What can be inferred from totals, and what cannot
- A drop in total size at a level tells you size left; it cannot tell you whether one order cancelled or ten orders each trimmed.
- Matching a decrease with a trade at the same price and time supports the reading that the size was executed; it does not prove which order filled.
- An iceberg refilling is visible as repeated replenishment on both feeds, but only the order-by-order feed shows whether the refills are the same order or new ones.
- Queue position, how much size is ahead of your order at a price, requires the order-by-order feed.
Which exchanges offer what
CME documents both the market by price and the market by order feeds for its futures; which one reaches a platform depends on the entitlement attached to the data subscription, not on the platform's code. Crypto exchanges generally publish aggregated depth snapshots and differential updates over public websockets, without order identities.
In Senzoukria
The heatmap screen draws depth from whichever feed the connection delivers. Features that need the order-by-order feed say so: the Liquidity tracker panel's empty state reads that it needs the order-by-order feed (MBO), because it reads each order's life, not just the visible totals. Readings derived from aggregated depth carry the hint inferred from the aggregated book, never presented as an MBO observation.
Market data is billed by the provider, and the depth entitlement is part of that subscription; the app does not substitute an inferred order-by-order view when the feed is aggregated.
Common mistakes
- Expecting queue position or per-order tracking from an aggregated feed.
- Assuming a platform that advertises a heatmap receives the full order-by-order feed.
- Comparing depth pictures across two feeds as if they had the same coverage.
Related
This page in other languages
Frequently asked questions
- Do I need order-by-order data to use a heatmap?
- No. A heatmap draws total resting size per price over time, which aggregated depth provides. The order-by-order feed adds the ability to attribute changes to specific orders, which powers a liquidity tracker and queue estimates. The picture is the same; the attribution is what differs.
- Can aggregated depth tell a cancellation from a fill?
- Only by inference. If a level's total drops at the same moment a trade prints at that price for a matching size, the drop is consistent with a fill. If no trade prints, the drop was a cancellation or a modification. The inference is often right, but it is a correlation between two streams rather than an observed event.
- Why does the order-by-order feed cost more to handle?
- Because every order event is a message. A liquid index future generates far more order submissions, modifications and cancellations than trades, so the message rate is several times that of the aggregated feed. The platform has to process and store each event to reconstruct order lives, which is heavier than maintaining totals per price.