19 Settembre 2026 · backtesting

I dati tick non salveranno il tuo backtest — per la maggior parte delle strategie lo peggiorano

I dati tick non salveranno il tuo backtest — per la maggior parte delle strategie lo peggiorano

Il consiglio standard è: se vuoi un backtest onesto, procurati i dati tick. Secondo me quel consiglio è sbagliato per la maggior parte delle strategie, e seguirlo di solito peggiora il backtest, non lo migliora. Non perché i dati tick siano inaccurati — sono la cosa più accurata che puoi ottenere — ma perché il modo in cui la maggior parte delle persone li usa mette la risoluzione al posto del rigore, e le due cose non sono la stessa cosa.

Ecco la modalità di fallimento. Un ricercatore costruisce una strategia su barre da 1 minuto, ottiene uno Sharpe che gli piace, e qualcuno — un mentore, un post su un forum, il proprio dubbio insistente — gli dice che il backtest è disonesto perché è costruito sulle barre. Così ricostruisce l'intera pipeline sui dati tick: ogni trade, ogni aggiornamento di quote, con timestamp al microsecondo. Il backtest diventa più lento, il codice diventa tre volte più complesso, e lo Sharpe... si muove a malapena, o si muove in una direzione che nessuno sa spiegare. Lo mette comunque in produzione, perché i dati tick danno una sensazione di maggior rigore, e la sensazione di rigore non è il rigore.

Cosa ti compra davvero la risoluzione tick

I dati tick ti dicono la sequenza e il prezzo di ogni trade e (se li paghi) di ogni aggiornamento dell'order book. È informazione vera. Ti permettono di ricostruire la posizione in coda, stimare la probabilità di fill a un dato livello di prezzo e vedere l'adverse selection — se il mercato si muove contro di te subito dopo il fill ipotetico. Tutto questo conta enormemente se il holding period si misura in secondi e il tuo edge si misura in frazioni di un tick.

Ma la maggior parte delle strategie che vediamo in Stratmill — e la maggior parte di quelle che i ricercatori retail e semi-pro fanno girare davvero — tengono posizioni da minuti a giorni. Su quell'orizzonte, ciò che determina se il backtest è onesto non è se hai modellato il 40° trade dentro un dato minuto. È se hai modellato lo spread, il funding rate, la curva di slippage e il fatto che il tuo limit order sta in coda dietro gli ordini degli altri. Puoi sbagliare tutte e quattro sui dati tick e azzeccarle tutte e quattro sulle barre da 1 minuto. Risoluzione e onestà sono ortogonali.

~24Mtrade/giorno, BTCUSDT perp
1,440barre da 1 minuto in quello stesso giorno
0.5–1 tickrumore tipico di bid-ask bounce per print
3–5xtempo di ingegneria per una pipeline tick corretta vs. una pipeline a barre

Quell'ultimo numero è quello che le persone sottopesano. Un backtest a livello tick non è solo "lo stesso backtest con più righe." I trade sulla maggior parte delle exchange arrivano fuori ordine rispetto al tuo timestamp di ingestione, vengono corretti retroattivamente, vengono spezzati su più shard del matching engine e — su diverse venue da cui abbiamo ingerito — di tanto in tanto si duplicano o spariscono del tutto durante una riconnessione. Costruire una pipeline tick che sia davvero più corretta di una pipeline a barre ben fatta, piuttosto che solo più granulare, è un vero progetto di sistemi. La maggior parte dei team non fa quel progetto. Puntano un backtester sul file tick di un vendor e danno per fatto, il che significa aver scambiato un insieme noto e documentato di approssimazioni (OHLCV) con uno sconosciuto e non documentato (qualsiasi cosa la logica di riconciliazione tick del vendor finisca per fare in una giornata storta).

Il rumore che stai comprando

C'è un secondo costo, meno di ingegneria e più di statistica. I singoli print dei trade rimbalzano tra bid e ask — è il bid-ask bounce, un artefatto noto nella letteratura di microstruttura di mercato dagli anni 1980. Se il tuo segnale opera su qualcosa di più veloce di pochi secondi, il backtesting a livello tick può farti vedere struttura in quello che in realtà è solo il bounce. Ho visto un ricercatore trovare un bellissimo pattern di mean-reversion sui dati trade-by-trade che è evaporato nell'istante in cui ha aggregato anche solo a barre da 5 secondi, perché il pattern era il bounce.

Un quant che conosco — ex-market-making, ora alla guida di un piccolo book crypto — me l'ha messa così: "I dati tick sono una lente d'ingrandimento. Se la punti sul tuo edge, benissimo. Se la punti sul tuo rumore, passerai sei mesi a modellare splendidamente il rumore." Ora fa backtest di quasi tutto su barre da 1 secondo o da 1 minuto e scende ai dati tick solo per la domanda specifica "questo limit order avrebbe avuto davvero un fill," che è una domanda di probabilità di fill, non di segnale.

Questa distinzione è l'istinto giusto, ed è quello che la maggior parte dei sostenitori dei dati tick si salta. L'uso onesto dei dati tick non è far girare tutta la strategia su di essi — è usarli in modo chirurgico, per una o due domande a cui i dati a barre non possono davvero rispondere.

Quando i critici hanno ragione

Detto tutto questo, ci sono strategie in cui i dati tick non sono opzionali, e esagererei a fingere il contrario. Se stai facendo qualcosa che assomiglia al market making — quotare entrambi i lati, gestire l'inventario tick per tick, badare alla tua posizione in coda a un livello di prezzo specifico — i dati a barre non possono rappresentare affatto il tuo problema. L'intera economia di quella strategia vive dentro il minuto, non tra i minuti. Lo stesso vale per l'arbitraggio statistico sensibile alla latenza tra venue, dove la domanda è letteralmente "quale trade è avvenuto per primo," e per il market making di opzioni intorno a size grandi, dove poche centinaia di millisecondi di adverse selection dopo un print sono l'intero gioco. In quei regimi, fare backtest sulle barre non è una semplificazione, è un errore di categoria — non stai testando una versione a risoluzione più bassa della tua strategia, stai testando una strategia diversa che per caso condivide il nome con quella vera.

Orizzonte della strategiaCosa nascondono i dati a barreDati tick necessari?
Market making / basato sulla codaProbabilità di fill, adverse selection, posizione in codaSì — non opzionale
Latenza / arb cross-venueSequenza dei trade, quale venue si è mossa per primaSì
Momentum intraday, mean reversion (minuti–ore)Timing del fill dentro la barra, costo dello spreadSolo per la domanda di probabilità di fill, non per il segnale
Swing / multi-giorno, opzioni direzionaliQuasi nulla di materialeNo — le barre bastano e spesso sono più pulite
Se non sai dire, in una frase, a quale domanda i dati tick rispondono e le barre no per la tua strategia specifica, non hai ancora bisogno dei dati tick. Ti serve un modello di fill migliore sulle barre che hai già.

Quindi l'affermazione non è "i dati tick sono cattivi." È che ricorrervi è spesso un modo per evitare una domanda più dura e meno glamour: il mio modello di costi è giusto? La mia ipotesi di fill è giusta? Questo ordine avrebbe avuto davvero un fill, o sto assumendo un fill a un prezzo che il book non mi ha mai davvero offerto? A quelle domande si può rispondere su barre da 1 minuto o persino da 1 secondo se sei onesto su posizione in coda e spread. I dati tick le rendono rispondibili con più precisione, a diverse volte il costo di ingegneria, per strategie in cui quella precisione extra non cambia nulla della conclusione. Spendi lo sforzo extra dove l'orizzonte lo richiede davvero, e saltalo ovunque altrove — è un uso migliore del tempo di un team di ricerca che adottare di default i dati più granulari disponibili perché più fini danno la sensazione di maggior rigore.

dati tickmicrostruttura di mercatobacktestingingegneria dei datifutures crypto
← Tutti gli articoli