Il pitch sui dati nello sport tech incontra una domanda più scomoda: chi tiene le chiavi

La tecnologia sportiva ha passato anni a vendere la stessa promessa: più dati, risposte più rapide, decisioni più intelligenti. I titoli delle ricerche di mercato che arrivano sulla scrivania ogni settimana si appoggiano a tassi di crescita e acronimi. La realtà ingegneristica è più disordinata. Nel pacchetto di questa settimana ci sono due documenti da leggere insieme, perché descrivono modi opposti di dare a un agente IA i numeri su cui le organizzazioni sportive dicono sempre più di lavorare.

L'11 settembre Starburst ha pubblicato un'analisi di due architetture per l'analisi dei dati con agenti. Il pezzo è scritto per i team dati aziendali, non per club o leghe, ma l'esempio che usa è volutamente banale: un negozio di alimentari che chiede se la promozione sulle uova della settimana scorsa sia stata redditizia. Rispondere significa sapere se la promozione ha portato clienti che altrimenti non sarebbero entrati, se i nuovi clienti sono tornati, cos'altro è stato comprato nella stessa transazione, dove stanno quegli articoli nel negozio e quanto sono redditizi. È una catena di domande di seguito su più di un set di dati. Ed è la stessa forma di problema che affronta un'organizzazione sportiva quando chiede perché una campagna di sponsorizzazione ha mosso le vendite dei biglietti.

Opzione 0: spedire i dati al modello

Il primo approccio, che Starburst chiama opzione 0, consiste nell'estrarre le tabelle rilevanti e inviare i dati grezzi all'agente come file o tubo diretto, lasciando che l'agente faccia la propria elaborazione. L'azienda è netta sui compromessi. Spedire terabyte di dati a un agente può diventare proibitivo quando l'agente viene pagato per ogni elemento ricevuto o elaborato. Starburst dice che gli svantaggi prestazionali riducono la praticabilità di questa opzione al punto da non renderla buona, ed è per questo che porta l'etichetta di opzione 0 invece di opzione 1.

Per le squadre sportive l'aritmetica è comunque poco attraente. Una singola partita genera ora dati di tracciamento, eventi derivati dal video, registri di biglietteria, transazioni di merchandising e telemetria dell'app, e il numero di persone che fanno domande su questi dati è piccolo. Pagare per riga per spostarli in un modello non è una voce di bilancio che molti reparti analitici possono difendere.

Il secondo approccio è quello che Starburst raccomanda. Dare all'agente accesso diretto al sistema di database e lasciargli scrivere il proprio SQL, iterando mentre affina il focus. Il motore del database fa ciò per cui è costruito, elaborando dati locali con piani di query ottimizzati, mentre l'agente supervisiona e invia richieste successive o parallele finché non ha qualcosa che valga la pena restituire. Starburst riconosce il difetto noto: gli agenti possono essere molto più esigenti degli umani e possono sopraffare un database con query speculative mentre lavorano.

L'industria dei database è concentrata nel sostenere i carichi di lavoro agentici in futuro, e i sistemi di database moderni sono sempre più capaci di gestire questo tipo di elaborazione dati scalabile in modo efficiente.

Questo è l'argomento in una frase, ed è un argomento di vendita oltre che di ingegneria. Starburst vende sistemi di database. Anche così, il punto su dove vive l'ottimizzazione è difficile da contestare: gli agenti migliorano, ma non stanno per elaborare terabyte di dati strutturati in modo efficiente come motori costruiti su decenni di ricerca sulle query.

Come si presenta davvero l'attrezzatura

Due progetti open source nel pacchetto di questa settimana mostrano come si assembla l'impianto nel segmento più piccolo. Adaca Analytics, pubblicato su GitHub l'8 settembre con licenza MIT, ricostruisce le vecchie dashboard di Google Analytics sopra i dati GA4. I riepiloghi giornalieri dall'API GA4 o da un export BigQuery finiscono in un database D1 di proprietà dell'operatore, mentre i dati in tempo reale restano su Google. Sei dashboard arrivano già pronte, ogni numero si apre in una pagina di dettaglio con il proprio andamento e le proprie disaggregazioni, e tutto gira su Cloudflare Workers dietro Cloudflare Access o Basic Auth integrato. Non c'è login.

Plainoldanalytics, pubblicato su GitHub il 13 settembre, prende la strada opposta: analisi web aggiuntiva incorporata in un'applicazione Go. È agnostico rispetto allo storage, quindi importare il pacchetto principale non tira mai dentro un backend, ed esistono adattatori per gin e chi. Il traffico viene scaricato su disco circa una volta al secondo, e gli operatori possono impostare proprietà chiave e valore per richiesta, escludere route dalla registrazione o registrare percorsi di route letterali invece dei parametri di percorso.

Nessuno dei due progetti è un prodotto sportivo. Entrambi sono rilevanti perché mostrano che l'assunto predefinito si sta spostando: i dati restano dove l'operatore li ha messi, e il livello di analisi è qualcosa che esegui invece di qualcosa che affitti.

La questione della privacy che nessuno mette a benchmark

DataZen, un client di database local-first pubblicato su Hacker News il 29 agosto, enuncia il problema direttamente: dove vanno i miei dati? Lo strumento esce con licenza GPLv3, non richiede account e supporta PostgreSQL, MySQL, SQLite e Redis per impostazione predefinita, con driver opzionali per MongoDB, ClickHouse, DuckDB e SQL Server. Include un server MCP integrato così agenti come Claude, Cursor e Cline possono interrogare i database tramite il Model Context Protocol, e può agire anche come client MCP. Le credenziali sono cifrate AES-256-GCM nel portachiavi del sistema operativo, e il progetto dichiara che solo lo schema e il contesto delle query vengono condivisi con il fornitore di IA configurato dall'utente.

Quest'ultima distinzione è quella su cui le organizzazioni sportive dovrebbero informarsi. Schema e contesto delle query non sono la stessa cosa dei dati grezzi, ma non sono nemmeno nulla. Uno schema rivela cosa misura un club: quali attributi dei tifosi conserva, come segmenta gli acquirenti di biglietti, cosa traccia sul carico dei giocatori. In uno sport dove i dati sugli infortuni e le trattative contrattuali stanno nello stesso patrimonio della biglietteria, i metadati sono commercialmente sensibili di per sé.

Il dossier non ci dice cosa abbia effettivamente implementato un club o una lega, e il materiale dei fornitori dietro le previsioni di mercato non è prova di adozione. Quello che mostra è una spaccatura. Un campo sostiene che gli agenti debbano guidare il database e che i motori moderni possano assorbire il carico. L'altro costruisce strumenti che tengono i dati in locale e mandano fuori solo il contesto. La tecnologia sportiva erediterà la risposta che i suoi team dati sceglieranno, e la scelta si sta facendo ora, nei repository open source invece che nei comunicati stampa.