By Matt Connor · Differenza tra dati order book MBO e MBP spiegata
Analisi tecnica tra flussi MBO e MBP: la distinzione tra eventi per singolo ordine e profondità aggregata per livello di prezzo, costi operativi e casi d'uso specifici.
I dati dell'order book MBO e MBP rappresentano una distinzione sostanziale che si cela dietro un'etichetta apparentemente simile. Due fornitori possono vendere entrambi un prodotto chiamato "Level 2": l'MBP (market by price) trasmette la dimensione totale presente a ogni livello di prezzo, mentre l'MBO (market by order) trasmette ogni singolo ordine come evento distinto, dotato di un proprio ID. Il primo è un riepilogo del book; il secondo è il registro contabile da cui il book viene costruito e richiede ordini di grandezza superiori in termini di traffico dati.
Cosa contengono realmente i dati dell'order book MBP e MBO
L'MBP, market by price, è una profondità aggregata. Ogni aggiornamento indica un lato, un livello di prezzo, la dimensione totale visualizzata in quel punto e, talvolta, il numero di ordini sottostanti. Un prodotto venduto come MBP-10 fornisce i dieci migliori livelli di prezzo su ciascun lato, ovvero il ladder in una piattaforma di trading e la scala in ogni grafico di profondità.
L'MBO, market by order, è un flusso di eventi. Ogni messaggio identifica un ordine: il suo ID, il lato, il prezzo, la dimensione visualizzata e cosa gli è appena accaduto. Nulla è pre-aggregato. Se quaranta ordini si trovano allo stesso prezzo, quaranta messaggi separati li hanno posizionati lì, e l'utente deve mantenere tutti e quaranta gli ordini in memoria per conoscere il totale di quel livello.
La nostra guida ai dati di mercato Level 1 vs Level 2 illustra cosa significano le etichette del segmento retail presso un broker. MBO e MBP sono i nomi precisi di ciò che si trova "dentro la scatola" quando un fornitore parla di "Level 2", ed è il nome dello schema quello su cui vale la pena informarsi.
Le azioni sui messaggi trasmesse da un feed MBO
Un feed MBO è una tassonomia di azioni applicate agli ID degli ordini. Quattro di queste costituiscono la maggior parte del traffico:
- Add (Aggiunta): un nuovo ordine si unisce al book a un determinato prezzo con un nuovo ID.
- Modify (Modifica): un ID esistente cambia prezzo o dimensione. Aumentare la dimensione o spostare il prezzo invia l'ordine in coda al nuovo livello; ridurre la dimensione solitamente ne mantiene la posizione.
- Cancel (Cancellazione): un ID lascia il book, in tutto o in parte.
- Trade o fill (Esecuzione): un ordine aggressivo viene eseguito contro uno o più ID presenti, riducendoli o rimuovendoli.
L'MBP non contiene nulla di questo vocabolario. Un aggiornamento MBP è una dichiarazione su un livello: questo prezzo ora contiene questa quantità. Che la dimensione sia diminuita a causa di una cancellazione o di un'esecuzione, l'aggiornamento appare identico. Il pannello sottostante mostra tale limite sul book più sottile possibile, ovvero il top of book consolidato, con un livello di prezzo per lato e MBP-1 in questa nomenclatura.
L'esatto SQL dietro ogni numero
WITH
ordered AS
(
SELECT
row_number() OVER (ORDER BY sip_timestamp, sequence_number) AS msg_index,
bid_price,
bid_size,
lagInFrame(bid_price) OVER (ORDER BY sip_timestamp, sequence_number) AS prev_bid_price,
lagInFrame(bid_size) OVER (ORDER BY sip_timestamp, sequence_number) AS prev_bid_size
FROM global_markets.cache_stocks_quotes
WHERE ticker = 'AAPL'
AND sip_timestamp >= '2026-06-16 14:00:00'
AND sip_timestamp < '2026-06-16 14:30:00'
AND bid_price > 0
),
classified AS
(
SELECT multiIf(
bid_price != prev_bid_price, 'best bid price changed',
bid_size > prev_bid_size, 'size joined at the best bid',
bid_size < prev_bid_size, 'size left the best bid',
'bid untouched, ask side updated') AS message_type
FROM ordered
WHERE msg_index > 1
)
SELECT
message_type,
count() AS message_count,
round(100 * count() / sum(count()) OVER (), 1) AS share_pct
FROM classified
GROUP BY message_type
ORDER BY indexOf(['best bid price changed', 'size joined at the best bid', 'size left the best bid', 'bid untouched, ask side updated'], message_type)In quella mezz'ora, 17.6% dei messaggi ha spostato il miglior bid su un prezzo diverso, 17.4% ha aggiunto dimensione a un bid invariato, 12% ha rimosso dimensione a un bid invariato e 53% ha lasciato il bid invariato mentre l'altro lato si muoveva. Ogni gruppo è una dichiarazione netta su un livello di prezzo. Nessuno nomina un ordine e nessun calcolo aritmetico può recuperare l'ID mancante.
Cosa può e non può rispondere ciascuno schema
L'MBP-10 risponde alle domande formulate come "quanta dimensione c'era": la forma del ladder, lo sbilanciamento del book, la liquidità presente vicino al mid, il grafico di profondità stesso. I livelli aggregati sono tutto ciò che serve per queste analisi.
L'MBO risponde alle domande formulate come "cosa è successo a questo ordine": quanta dimensione c'era davanti al proprio ordine quando è stato inserito, quanto tempo sopravvivono gli ordini prima di essere cancellati e la probabilità che un ordine passivo al touch venga eseguito prima che il prezzo si sposti. Queste quantità non esistono in forma aggregata e sommare gli ordini in un totale di livello distrugge la sequenza che li definiva.
La posizione in coda è l'esempio più lampante e ha significato solo in presenza di priorità prezzo-tempo rispetto al matching pro-rata, dove l'ordine di arrivo decide chi viene eseguito per primo. Ciò che la rende rilevante è la dimensione dei print: un livello viene riempito da molte piccole esecuzioni, non da una sola grande.
L'esatto SQL dietro ogni numero
SELECT
multiIf(size < 100, '1 to 99 shares',
size < 200, '100 to 199 shares',
size < 500, '200 to 499 shares',
size < 1000, '500 to 999 shares',
'1000 or more shares') AS trade_size_bucket,
count() AS trade_count,
round(100 * count() / sum(count()) OVER (), 1) AS share_pct,
round(avg(size)) AS avg_shares
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= '2026-06-16 14:00:00'
AND sip_timestamp < '2026-06-16 14:30:00'
AND size > 0
GROUP BY trade_size_bucket
ORDER BY min(size)I print inferiori a cento azioni, un odd lot, hanno costituito 92.3% degli scambi in quella finestra, e il bucket più grande presente, 1000 or more shares, ha costituito 0.1%. Se si inviano print di tale dimensione a un livello che mostra 4.000 azioni, un ordine che si è unito alla coda per ultimo può restare in attesa per decine di esecuzioni senza essere eseguito. L'MBP mostra le 4.000 azioni. L'MBO mostra la fila.
Nessuno dei due schemi mostra la dimensione nascosta. Un iceberg order mostra una piccola punta e si aggiorna con un nuovo ID ogni volta che la punta viene eseguita, quindi la riserva non appare mai in alcun messaggio.
Ricostruire un book da MBO è una macchina a stati
Un feed MBP fornisce la risposta. Un feed MBO fornisce gli input e richiede che l'utente sia estremamente preciso:
- Partire da uno snapshot o da un book vuoto più il messaggio di clear della sede di negoziazione.
- Applicare ogni add, modify, cancel e fill in rigoroso ordine di sequenza, indicizzato per ID ordine.
- Mantenere un secondo indice per livello di prezzo, poiché è ciò che la strategia legge.
- Monitorare i numeri di sequenza e risincronizzarsi da uno snapshot aggiornato ogni volta che ne manca uno.
La modalità di errore è silenziosa. Se si perde una cancellazione, un ordine fantasma rimane nel book per il resto della sessione, gonfiando quel livello, senza che venga sollevata alcuna eccezione. L'MBP degrada in modo molto più graduale: ogni aggiornamento ribadisce il totale di un livello, quindi un valore corrotto viene sovrascritto nel giro di pochi messaggi.
L'MBO vive inoltre solo su feed diretti delle sedi, un book per exchange, il che significa gestire e unire diversi flussi. Il nastro consolidato è un riepilogo per costruzione, una suddivisione trattata in SIP rispetto ai feed diretti degli exchange.
Quanto costa in banda il dettaglio extra
Il conteggio dei messaggi è il modo onesto per valutare la differenza di prezzo. Il pannello sottostante confronta i messaggi del top-of-book consolidato con i print effettivi nello stesso arco di mezz'ora per cinque nomi noti.
L'esatto SQL dietro ogni numero
WITH
quote_load AS
(
SELECT ticker, count() AS quote_messages
FROM global_markets.cache_stocks_quotes
WHERE ticker IN ('SPY', 'AAPL', 'NVDA', 'MSFT', 'KO')
AND sip_timestamp >= '2026-06-16 14:00:00'
AND sip_timestamp < '2026-06-16 14:30:00'
GROUP BY ticker
),
trade_load AS
(
SELECT ticker, count() AS trades
FROM global_markets.stocks_trades
WHERE ticker IN ('SPY', 'AAPL', 'NVDA', 'MSFT', 'KO')
AND sip_timestamp >= '2026-06-16 14:00:00'
AND sip_timestamp < '2026-06-16 14:30:00'
GROUP BY ticker
)
SELECT
q.ticker AS ticker,
round(q.quote_messages / 1000, 1) AS quote_messages_thousands,
round(t.trades / 1000, 2) AS trades_thousands,
round(q.quote_messages / t.trades, 1) AS quotes_per_trade_ratio
FROM quote_load AS q
INNER JOIN trade_load AS t ON t.ticker = q.ticker
ORDER BY quotes_per_trade_ratio DESCSPY ha generato il traffico di quote più pesante per print, 9.6 messaggi per ogni scambio e 510 mila messaggi in trenta minuti. Lo spread tra i cinque nomi è ampio: in fondo al pannello, MSFT ha registrato 0.7 messaggi di quote per print, meno di un messaggio per ogni scambio. Si ricordi cosa conta quella colonna: un livello di prezzo per lato, su un feed che ha già accorpato ogni sede in un unico miglior bid e offer. Un prodotto con dieci livelli di profondità moltiplica questo valore, e un feed per singolo ordine lo moltiplica ulteriormente, poiché ogni ordine dietro ogni livello su ogni sede genera il proprio add, le proprie modifiche e la propria cancellazione, a prescindere che venga mai eseguito o meno. La stessa aritmetica si ripresenta su scala maggiore in la dimensione del feed delle quote opzioni.
Di quale feed dell'order book ha bisogno una strategia?
La maggior parte del lavoro viene eseguita su MBP-10. Grafici di profondità, indicatori di sbilanciamento, misurazione della liquidità al prezzo, modelli di costo di esecuzione e quasi ogni domanda di ricerca su quanta dimensione fosse presente e dove, sono risolvibili a partire dai livelli aggregati, con una frazione del volume di messaggi.
L'MBO è necessario quando la risposta dipende da un ordine specifico: posizione in coda, durata dell'ordine, comportamento di cancellazione, probabilità di esecuzione passiva al touch. Una strategia che dipende dall'essere a duecento o ventimila azioni di profondità nella fila non può ottenere tali informazioni dai dati aggregati, e ne paga il prezzo in licenze, banda, archiviazione e nell'ingegneria necessaria per mantenere corretto un book ricostruito per tutta la giornata.
Come sono stati costruiti questi pannelli
- Il feed dietro ogni pannello è il top of book consolidato, un livello di prezzo per lato, più il nastro degli scambi. Non è un feed di profondità né un feed per singolo ordine, quindi questi pannelli illustrano l'argomento del volume dei messaggi piuttosto che campionare l'MBO stesso.
- Le finestre sono fissate a una data passata, dalle 10:00 alle 10:30 ET del 16 giugno 2026, archiviate come 14:00-14:30 UTC. Le finestre fisse mantengono i numeri stabili tra le rigenerazioni.
- Il pannello di classificazione etichetta ogni messaggio rispetto al precedente in sequenza. Non può separare una cancellazione da un'esecuzione, che è l'esatta limitazione descritta in questo post.
FAQ
Qual è la differenza tra i dati di mercato MBO e MBP?
L'MBP, market by price, aggrega la dimensione visualizzata a ogni livello di prezzo e invia un aggiornamento per livello. L'MBO, market by order, invia ogni singolo ordine con il proprio ID, insieme agli eventi di add, modify, cancel e fill che lo riguardano.
I dati Level 2 sono uguali ai dati MBO?
Di solito no. "Level 2" presso un broker retail significa quasi sempre profondità aggregata, quindi MBP con da cinque a venti livelli di prezzo. Alcuni fornitori commercializzano un feed per singolo ordine sotto lo stesso nome di categoria, quindi è il nome dello schema, non il nome della categoria, a determinare cosa arriva sul terminale.
Quanto è più grande un feed MBO rispetto a un feed MBP?
Di ordini di grandezza, variabili in base alla sede e al simbolo. Il solo top of book consolidato ha viaggiato a 9.6 messaggi per print per il nome più attivo nel pannello sopra. Un feed per singolo ordine aggiunge ogni add, modify e cancel dietro ogni livello su ogni sede, inclusa la grande maggioranza degli ordini che non vengono mai eseguiti.
È possibile ricostruire un book MBP dai dati MBO?
Sì, e questa è la pipeline normale: applicare ogni evento d'ordine a un book indicizzato per ID ordine, quindi pubblicare i totali di livello. L'inverso è impossibile: una volta che gli ordini sono sommati nel totale di un livello, gli ID individuali e il loro ordine di arrivo sono persi.
Ogni pannello qui presente viene fornito con l'esatto SQL sottostante. Per contare gli stessi messaggi su un simbolo o una sessione diversa, poni la domanda in inglese semplice sul terminale Strasmore.