Aggr.trade Trade Aggregation: Why Several Prints Become One Row
One market order often fills against many resting orders. Aggregation reunites those fills so the tape shows the order, not the fragments.
Short answer
Aggr.trade merges trades that share a timestamp, market and side into one row, because a single aggressive order typically fills against many resting orders at once and the exchange reports each fill. Aggregation turns those fragments back into one visible order with a combined size and, since version 3.6.2, a weighted average price. It also aggregates liquidations when enabled. The trade-off: two independent traders hitting at the same millisecond can be merged too.
Why several prints become one
Since version 3.1.3, Aggr uses Binance's aggTrade stream instead of raw trades; that stream already compresses some fills at the exchange level, and Aggr's own aggregation then groups by timestamp and side.
Worked example
| Fill | Price | Size (BTC) |
|---|---|---|
| 1 | 60,000.0 | 2.0 |
| 2 | 59,999.5 | 3.0 |
| 3 | 59,999.0 | 1.5 |
| 4 | 59,998.0 | 3.5 |
Aggregated: one sell of 10.0 BTC at a weighted average of (60,000×2 + 59,999.5×3 + 59,999×1.5 + 59,998×3.5) / 10 = 59,998.95. The last fill price, 59,998.0, would understate where most volume traded. (Illustrative numbers.)
When to turn aggregation off
Aggregation answers "what orders were sent?" Turning it off answers "how did the book absorb them?" With aggregation off, one large market order shows as a staircase of fills at successive prices, which tells you how many levels it consumed and how thin the book was at that moment.
That view is useful when studying slippage or the depth behind a level. It is noisy for real-time reading, which is why most tape users keep aggregation on and switch it off only for review.
If you compare the tape with a footprint, remember that footprints count individual trades at each price. An aggregated row of 10 BTC at a weighted average price appears in the footprint as several cells at the actual prices. Both are correct views of the same event.
What aggregation can get wrong
- Independent orders at the same timestamp and side merge into one row.
- Orders sliced over milliseconds by algorithms stay as separate rows.
- Cross-venue sums are separate from aggregation; keep venues visible.
Compare aggregated tape rows with the footprint cells at the same price.
Inspect this setup in ChartsPodTurn aggregation on to see orders rather than fills, and remember that a row is a timestamp-and-side group, not a confirmed single trader.
Related: Aggr.trade vs ChartsPod: Live Tape and Full Research Workflows, Aggr.trade Bitcoin Settings: Reduce Noise Without Hiding Relevant Trades.
Test Aggr.trade Trade Aggregation on a perpetual chart; no account is needed to chart.
Launch ChartsPodQuestions readers ask
Why does Aggr show one big trade when the exchange shows many?
It merges fills with the same timestamp, market and side.
Is the aggregated price the last fill?
Since 3.6.2 the feed shows a weighted average price.
Can aggregation merge two different traders?
Yes, if their fills share timestamp, market and side.
Sources and methodology
Aggr.trade behaviour is taken from its public README and CHANGELOG (version numbers cited) as read on 17 October 2026; the interface changes over time, so confirm settings in your build. Numbers in examples are illustrative.
- Aggr repository README — exchanges, aggregation, audio, history via aggr-server.
- Aggr changelog — workspaces, audio thresholds, liquidations, alerts.
- Binance: USD-M Futures market data API — trades, depth, funding and open interest.
This article explains research tools and workflows. It is not financial advice, does not recommend buying or selling any asset and does not predict prices. Crypto derivatives carry a risk of rapid and total loss of margin.
CHARTSPOD EDITORIAL EDITION · RESEARCH AND EDUCATION ONLY · NOT FINANCIAL ADVICE.