Come capire se le statistiche calcistiche sono adatte a un backtest?
Confronta le partite attese con quelle presenti, verifica definizioni e duplicati, misura i dati mancanti per stagione e controlla che ogni informazione fosse disponibile prima della decisione simulata. Solo dopo applica la regola a un periodo successivo, tenuto separato dallo sviluppo.
- N/D non significa zero.
- Una quota registrata dopo la decisione non può simulare quel prezzo d’ingresso.
- Un archivio ordinato non dimostra che una strategia sia redditizia.
Possesso, tiri, expected goals e risultati storici diventano utili soltanto quando sappiamo che cosa misurano, quali partite coprono e quando erano disponibili. Questa guida mostra un controllo riproducibile prima del backtest: i numeri dell’esempio sono inventati a scopo didattico e non rappresentano un dataset reale o risultati di GSO Radar.
1. Definisci che cosa rappresenta una riga
Prima di contare le osservazioni, scrivi l’unità di analisi. Nell’esempio una riga rappresenta una partita, un mercato e una sola quota selezionata secondo una regola temporale prestabilita. In un archivio di quote aggiornate ogni minuto, invece, più righe della stessa partita possono essere corrette: non vanno cancellate soltanto perché hanno lo stesso identificativo dell’evento.
Servono identificativi stabili per partita, competizione e stagione. I nomi delle squadre possono cambiare formato tra fornitori; un collegamento basato solo sul nome rischia di unire eventi diversi. Conserva anche il file originale, la versione importata e la regola con cui abbini gli identificativi.
2. Controlla definizioni e copertura della fonte
Due fornitori possono classificare diversamente tiri, assist o grandi occasioni. Anche gli expected goals dipendono dal modello che li produce. Prima di mescolare le colonne, confronta il dizionario dei dati, l’unità di misura e le eventuali revisioni: un’etichetta identica non garantisce un significato identico.
Il repository pubblico StatsBomb Open Data, ospitato da Hudl, distingue competizioni e stagioni, partite, eventi e formazioni; i dati 360 sono presenti solo per alcune partite. È un esempio concreto del perché la copertura vada verificata per ogni tipo di dato. La documentazione della fonte serve a interpretare l’archivio; non certifica una strategia di betting.
3. Esempio completo: da 1.012 righe a 965 eventi utilizzabili
Il dataset sintetico completo e il codice Python sono scaricabili nelle fonti in fondo alla pagina. Esegui python3 riproduci-audit-qualita-dati.py --generate per rigenerare il CSV e ricostruire i conteggi. Nessuna riga è un evento reale. Costruiamo un archivio didattico con 1.000 eventi attesi, identificati da M0001 a M1000. Sono tutti presenti, ma l’importazione contiene 1.012 righe: 12 sono copie identiche aggiuntive. Dopo aver rimosso queste sole copie restano 1.000 eventi distinti. La copertura iniziale degli eventi è quindi del 100%.
Per il test scelto richiediamo una statistica calcolata esclusivamente sulle partite precedenti e una quota disponibile entro l’orario della decisione. La statistica manca per M0001–M0030: 30 eventi. L’unica quota conservata è troppo tardiva per M0026–M0035: 10 eventi. M0026–M0030 appartengono a entrambi i gruppi, quindi gli eventi con due problemi sono 5.
Gli esclusi distinti sono 30 + 10 − 5 = 35, non 40. Restano 1.000 − 35 = 965 eventi utilizzabili secondo queste regole, pari al 96,5% dell’universo atteso. Il calcolo descrive la completezza per questo test: non è una percentuale di affidabilità delle previsioni.
| Controllo | Conteggio | Interpretazione |
|---|---|---|
| Eventi attesi | 1.000 | Universo definito prima del test |
| Righe importate | 1.012 | Comprendono 12 copie identiche aggiuntive |
| Eventi dopo la deduplicazione | 1.000 | Tutti gli eventi attesi sono presenti |
| Statistica richiesta mancante | 30 | M0001–M0030 |
| Quota oltre l’orario limite | 10 | M0026–M0035 |
| Entrambi i problemi | 5 | M0026–M0030: contare una sola esclusione per evento |
| Eventi esclusi distinti | 35 | 30 + 10 − 5 |
| Eventi utilizzabili | 965 · 96,5% | 965 ÷ 1.000 × 100 |
4. Un dato mancante non è uno zero
Zero tiri significa che sono stati rilevati zero tiri; N/D significa che il valore non è disponibile. Sostituire automaticamente N/D con zero inventa un’osservazione e può alterare medie e classifiche. Nell’esempio abbiamo scelto l’esclusione perché quella variabile è obbligatoria: non è una regola universale per ogni analisi.
La percentuale complessiva può nascondere differenze. Immaginiamo che i 1.000 eventi siano divisi in due stagioni da 500: 28 dei 30 valori mancanti sono nella stagione A e 2 nella B. Nel file gli ID non sono cronologici: M0029–M0030 appartengono a B e M0501–M0502 ad A, mantenendo 500 eventi per stagione. Le percentuali di valori mancanti per quella statistica sono 5,6% e 0,4%, contro il 3% complessivo. Occorre capire perché una stagione è meno coperta prima di confrontarle.
Conserva una colonna per ciascun problema e un indicatore finale di inclusione. Questo permette di distinguere cause sovrapposte e di verificare quali squadre, stagioni o competizioni vengono escluse più spesso. Non cambiare le esclusioni dopo aver osservato quali partite producono perdite.
5. Il timestamp deve precedere la decisione
Se la decisione simulata è alle 18:00 UTC, una quota registrata alle 17:58 può superare il controllo temporale; una registrata alle 18:02 no. L’orario deve essere confrontabile: conserva il fuso originale e una conversione coerente, inclusa l’ora legale. Verifica anche che la partita non fosse già iniziata se stai simulando una decisione pre-match.
Un timestamp scritto nel file, da solo, non prova la disponibilità storica. Bisogna distinguere l’orario dell’evento, quello di pubblicazione del dato e quello di acquisizione; una statistica corretta retroattivamente potrebbe non coincidere con ciò che si conosceva allora. Usa solo informazioni la cui disponibilità al momento della decisione è documentabile.
La quota di chiusura può servire come confronto successivo, ma non come prezzo d’ingresso precedente. Anche una quota registrata in tempo non garantisce che l’importo ipotizzato fosse eseguibile: disponibilità, liquidità, limiti e costi richiedono controlli separati.
6. Separa sviluppo e verifica nel tempo
Dopo l’audit, ordina gli eventi per data e riserva un periodo successivo alla verifica. Per esempio, puoi definire il metodo sulla stagione A e applicarlo alla B senza ritoccare i parametri in base ai risultati della B. Per ogni partita, medie e indicatori devono utilizzare soltanto informazioni disponibili fino a quel momento.
La documentazione di scikit-learn sui problemi comuni mostra perché le trasformazioni apprese dai dati devono essere stimate sul campione di sviluppo. Se scegli di imputare un valore mancante, anche la media usata per sostituirlo va calcolata senza consultare il futuro. Lo stesso vale per normalizzazione e selezione delle variabili.
La separazione temporale riduce un errore di progettazione, ma non garantisce un buon risultato. Gli incontri non sono necessariamente equidistanti nel tempo: definisci esplicitamente gli intervalli e verifica la comparabilità dei periodi, senza trattare automaticamente un numero uguale di righe come una durata uguale.
7. Che cosa conservare nel rapporto di qualità
Il rapporto deve permettere a un’altra persona di ricostruire il passaggio dall’archivio originale al campione finale. Per l’esempio, il controllo minimo è ritrovare 12 copie aggiuntive, 35 esclusioni distinte e 965 eventi ammessi, con le stesse regole. Conserva anche gli eventi esclusi e il motivo: cancellarli senza traccia impedisce la verifica.
- Fonte, condizioni d’uso, data di acquisizione, versione del file e dizionario delle colonne.
- Universo atteso, identificativi, criterio di deduplicazione e numero di eventi presenti.
- Valori mancanti per variabile e stagione, problemi sovrapposti e motivi di esclusione.
- Orario della decisione, provenienza delle quote e trattamento delle correzioni retroattive.
- Date dei periodi di sviluppo e verifica, trasformazioni applicate e regole bloccate prima del test.
Che cosa possiamo concludere dall’esempio
Possiamo verificare che i conteggi siano coerenti e capire perché alcuni eventi non soddisfano i requisiti. Non abbiamo calcolato un rendimento né dimostrato un vantaggio statistico. Un dataset completo può sostenere un’ipotesi sbagliata; un backtest favorevole può dipendere dal caso o da prezzi non eseguibili. L’audit rende controllabile il punto di partenza, poi servono una verifica separata e una rappresentazione completa del rischio.
Domande frequenti
Quali statistiche sono migliori per il betting?
Non esiste una lista universale. Devono avere una relazione motivata con l’ipotesi, una definizione stabile e copertura sufficiente.
Si possono unire dati di fornitori diversi?
Sì, ma soltanto dopo aver confrontato definizioni, identificativi, copertura e modalità di aggiornamento.
Perché 30 dati mancanti e 10 quote tardive producono solo 35 esclusioni?
Nell’esempio 5 eventi hanno entrambi i problemi. Per contare gli eventi distinti si calcola 30 + 10 − 5 = 35: ogni partita viene esclusa una sola volta.
Il 96,5% di copertura dimostra che il modello funziona?
No. Significa soltanto che 965 dei 1.000 eventi attesi soddisfano i requisiti dell’esempio. Non misura l’accuratezza delle previsioni o la redditività.
Contenuto informativo. Non costituisce consulenza, previsione certa o invito al gioco. Il gioco con vincite in denaro è vietato ai minori di 18 anni e può causare dipendenza.