Un backtest ha restituito un rendimento annualizzato del 20%. Ha usato 8 anni di dati, 1.640 operazioni e una suddivisione walk-forward pulita. Poi abbiamo sostituito lo storico attuale del fornitore con i valori registrati all’epoca e il vantaggio è sceso al 3%.
Il dato sorprendente non era il rendimento iniziale, ma i 17 punti percentuali che dipendevano da dati rivisti. Questo tipo di senno di poi può annidarsi nelle pubblicazioni economiche, nei fondamentali aziendali, nella composizione degli indici e persino in campi di mercato apparentemente semplici. I dati storici ti dicono cosa afferma oggi la fonte. Un dataset point-in-time ti dice cosa avrebbe potuto sapere la tua strategia in quel momento.
Perché i dati storici possono cambiare dopo un evento?
Alcuni valori vengono prima stimati e poi corretti. Una statistica economica pubblicata di venerdì potrebbe essere rivista il mese successivo. Un’azienda può rettificare un dato sugli utili. Un fornitore di dati può correggere una rilevazione errata, colmare un intervallo mancante o sostituire un valore provvisorio con quello definitivo. Un database che conserva solo il valore più recente fa sembrare che tutte queste modifiche fossero già valide fin dall’inizio.
Questo è importante se una strategia classifica le aziende in base ai ricavi dichiarati o opera sul mercato dopo una pubblicazione di dati programmata. Se vede il dato corretto con mesi di anticipo, il backtest le ha fornito informazioni che non erano disponibili sul mercato al momento della decisione. Il calcolo del segnale può essere impeccabile, ma il dato in ingresso appartiene comunque alla versione sbagliata dello storico.
C’è una trappola facile da non vedere: un campo chiamato date spesso indica il periodo a cui si riferisce un valore, non quando è diventato disponibile. Una riga sui ricavi trimestrali contrassegnata con 31 marzo potrebbe essere stata pubblicata solo a maggio. L’etichetta riguarda il periodo di attività dell’azienda, non l’insieme di informazioni disponibili alla strategia.
Quale timestamp dovrebbe usare un backtest?
Tieni separati il periodo di riferimento del valore e il momento in cui è diventato disponibile. Quando possibile, conserva anche l’ora di pubblicazione e quella di acquisizione. Una strategia poteva usare un valore solo dopo che era stato pubblicato e ricevuto dal sistema; se i due orari differiscono, per una ricostruzione prudenziale usa quello più tardivo.
| Timestamp | Che cosa descrive | A cosa serve |
|---|---|---|
| Tempo di riferimento | Il periodo o l’evento a cui si riferisce il valore | Raggruppa le osservazioni in base a ciò che viene misurato |
| Ora di pubblicazione | Quando la fonte ha pubblicato questa versione | Impedisce che un dato pubblicato compaia prima che esistesse |
| Ora di acquisizione | Quando il sistema ha ricevuto la versione | Registra ritardi di consegna e integrazioni retroattive tardive |
Per esempio, supponiamo che le vendite trimestrali di un’azienda coprano il periodo da gennaio a marzo, vengano comunicate l’8 maggio alle 16:15 ora della costa orientale e arrivino nel tuo archivio di ricerca alle 16:17. Una strategia che decide alla chiusura dell’8 maggio non può usare quel rapporto se la decisione alla chiusura è stata presa alle 16:00. Una strategia che decide la mattina successiva può farlo. La sola data di fine trimestre non basta a rispondere a nessuna delle due domande.
Come posso verificare se il risultato dipende dalle revisioni?
Esegui la stessa strategia 2 volte: una con la versione dei dati disponibile al momento di ciascuna decisione storica e una con lo storico più recente, comprensivo di revisioni. Mantieni invariati ipotesi di esecuzione, universo e codice. La differenza misura la sensibilità alle revisioni; non è un nuovo confronto tra strategie.
Poi verifica da dove nasce lo scarto. La performance cambia nei giorni di pubblicazione? Le differenze maggiori si concentrano in poche aziende che hanno rettificato i dati o in osservazioni corrette? La strategia opera prima dell’ora di pubblicazione pertinente? Una breve verifica dei singoli eventi spesso spiega più di un altro grafico dei rendimenti cumulativi.
Questi numeri sono un esempio, non una penalità valida per tutti. Il dato utile è un confronto a coppie per la tua strategia, mantenendo per quanto possibile le stesse operazioni e gli stessi costi. Se la versione rivista ottiene un risultato molto migliore, scopri quali campi e date spiegano la differenza prima di fidarti del risultato in evidenza del backtest.
Che cosa dovrebbe registrare una verifica dei dati point-in-time?
Parti dai campi che la tua strategia usa davvero. Per ciascuno, individua la fonte, il significato del timestamp, la politica di revisione e la possibilità di recuperare le versioni precedenti. Chiedi al fornitore come vengono rappresentate le correzioni: righe sovrascritte, nuove righe per ogni versione o un registro di controllo separato. La dicitura «storico» nella pagina del prodotto non chiarisce la questione.
- Conserva ogni versione con il timestamp di pubblicazione o di prima disponibilità.
- Associa le feature alle decisioni usando l’ora di disponibilità, non le etichette del periodo.
- Conserva uno snapshot congelato o la versione della fonte per poter riprodurre le esecuzioni.
- Segnala i valori arrivati in ritardo, rivisti o privi di uno storico affidabile.
Mantieni l’ambito della verifica concreto. Se la tua strategia usa solo operazioni e barre degli exchange, le revisioni dei dati economici potrebbero non essere rilevanti. Le correzioni delle barre e le integrazioni retroattive dei fornitori possono comunque contare, soprattutto quando un segnale dipende da un mercato poco liquido o da una finestra temporale precisa.
Quando non è disponibile uno storico point-in-time
Non trattare di nascosto il valore di oggi come se fosse quello di ieri. Indica il campo come limite, escludilo dalle affermazioni che dipendono dalla sua disponibilità storica oppure applica un ritardo prudenziale e mostra quanto cambia il risultato. Un dato sostitutivo ritardato può essere utile per la ricerca, purché il ritardo sia esplicito e il limite venga riportato insieme al risultato.
Il compito del backtest è ricostruire una decisione usando l’insieme di informazioni disponibile in quel momento. Se i tuoi dati mostrano solo la versione più recente, il risultato ha un limite preciso: può verificare la strategia sullo storico ricostruito oggi, ma non può stabilire esattamente che cosa avrebbe potuto vedere un agente storico.
← Tutti gli articoli
