La svolta silenziosa dei dati nello sport tech: dashboard self-hosted e agenti che scrivono le query

Quasi tutto il rumore attorno alla tecnologia sportiva nel 2026 arriva da previsioni di mercato e annunci di sponsorizzazioni. Gli strumenti veri sono più silenziosi e raccontano una storia più precisa: i team di analisi spostano le dashboard fuori dai cloud dei fornitori e danno agli agenti AI accesso diretto al database. Poi discutono sulla bolletta.

Due rilasci open source di settembre delineano la prima metà di questo spostamento. Entrambi sono self-hosted. Entrambi partono dal presupposto che i dati esistano già da qualche parte. Nessuno dei due è un prodotto sportivo nel senso in cui lo è un'app per i tifosi.

Sono le tubature sotto i tabelloni.

Dashboard GA4 che ospiti tu stesso

L'8 settembre una società di consulenza software chiamata Adaca ha pubblicato Adaca Analytics su GitHub, con licenza MIT. È uno strato di dashboard self-hosted per Google Analytics 4 che gira su Cloudflare Workers, secondo il repository del progetto. La meccanica conta più del messaggio promozionale. I rollup giornalieri vengono prelevati dall'API GA4 Data oppure da un export BigQuery, e finiscono in un database D1 di proprietà di chi lo gestisce, dice il README. I dati in tempo reale restano dalla parte di Google. Le dashboard si compongono da widget configurabili su una griglia, con sei dashboard incluse di serie e un builder in quattro passaggi per quelle personalizzate.

Il repository sostiene che ogni numero è navigabile in profondità: fonti, pagine e paesi hanno ciascuno pagine di dettaglio con il proprio andamento e le proprie ripartizioni, precalcolate in modo da caricarsi in un solo round trip.

C'è un filtro per dashboard, segmenti salvati e link di condivisione in sola lettura che possono fissare un filtro. Il confronto avviene con il periodo precedente, con l'anno scorso o con qualsiasi intervallo, con dettaglio orario per il giorno corrente e un conteggio dei visitatori in tempo reale. I riepiloghi settimanali e mensili più gli avvisi di traffico partono via email o Slack. La configurazione è volutamente poco appariscente. Chi gestisce crea un account di servizio Google con accesso Viewer sulla proprietà GA4, scarica la sua chiave JSON e preme Deploy to Cloudflare. Così fa il fork del repository, prepara D1 e KV, chiede la chiave e distribuisce il Worker con il suo cron. Davanti va Cloudflare Access oppure la Basic Auth integrata, perché non c'è un login. Poi il primo backfill parte mentre guardi.

Per le organizzazioni sportive che gestiscono più proprietà tra campionati, squadre o siti regionali, il vantaggio è il controllo: un database D1 che possiedi, nessun contratto di analytics per singolo utente e il supporto all'export BigQuery per chi già porta GA4 in un warehouse.

Il rovescio della medaglia è operativo. Il self-hosting significa che il cron, lo strato di autenticazione e le migrazioni sono tuoi.

Middleware di analytics dentro l'app

Cinque giorni dopo, il 13 settembre, è comparso su GitHub un altro progetto chiamato Plainoldanalytics. È una libreria di web analytics aggiuntiva per applicazioni Go, descritta nel suo README come simile nello spirito a Umami, Plausible o PostHog, ma incorporata nella tua app invece che eseguita accanto. Il pacchetto principale è indipendente dallo storage: importarlo non tira mai dentro un backend. Gli sviluppatori scelgono un pacchetto di storage, come un memory store o DuckDB, e ottengono sia uno Storage funzionante sia il cablaggio di Analytics con una sola chiamata al costruttore. Il traffico viene scaricato su disco circa una volta al secondo, e una chiamata Close allo spegnimento scarica tutto ciò che è ancora in buffer.

La libreria imposta proprietà chiave e valore su ogni richiesta, su cui la dashboard integrata può filtrare, e tratta in modo speciale una proprietà utente, così tutto il traffico legato a un singolo utente compare insieme.

Le rotte con parametri di percorso vengono registrate come parametri per impostazione predefinita, con un wrapper UseRequestPath disponibile quando conta la rotta letterale. C'è una chiamata Exclude per le rotte che non devono essere registrate affatto, più adattatori per gin e chi, e uno script opzionale di registrazione della sessione del browser. Per un club o una federazione che gestisce servizi di biglietteria, iscrizioni o contenuti in Go, questa è la differenza tra uno script di terze parti su ogni pagina e una riga di middleware nel router. Nessuno dei due progetti è una piattaforma di analisi sportiva. Entrambi tolgono un fornitore dal percorso tra l'evento e il numero.

Il dibattito sull'architettura: chi esegue la query

La domanda più difficile sta sopra gli strumenti, e Starburst l'ha affrontata in un post sul blog dell'11 settembre intitolato "An Analysis of Two Architectures for Agentic Data Analysis". La premessa: gli agenti stanno sempre più integrando o sostituendo l'analisi umana dei dati, assumendo domande con domande di follow-up e più cicli di analisi su uno o più dataset. L'esempio pratico di Starburst è un negozio di alimentari che chiede se la promozione sulle uova della settimana scorsa sia stata redditizia. Rispondere significa sapere se la vendita ha attirato clienti che altrimenti non sarebbero venuti, se i nuovi clienti sono tornati, cos'altro c'era nello stesso carrello e quanto siano redditizi quegli articoli. Le domande sportive hanno la stessa forma: la spinta allo streaming ha portato nuovi abbonati, sono rimasti, cos'altro hanno comprato.

Il post espone le opzioni per alimentare un agente con i dati. L'opzione 0 è estrarre i dati grezzi e inviarli.

Starburst la definisce impraticabile al di fuori di circostanze insolite, perché gli agenti che fanno pagare per singolo dato possono rendere i terabyte proibitivi per costo.

Questi svantaggi dell'opzione 0 ne riducono la praticità al punto che non è una buona opzione in pratica. Per questo la chiamo "opzione 0": non è qualcosa che consiglierei al di fuori di specifiche circostanze insolite.

L'opzione 1 è dare all'agente accesso diretto al database e lasciargli scrivere il proprio SQL, iterando finché non raggiunge una conclusione. Il motore del database gestisce la pianificazione delle query; l'agente si limita a sovrintendere. Starburst osserva che la letteratura segnala un rischio reale: gli agenti possono essere molto più esigenti degli umani e possono sopraffare un sistema con query speculative mentre affinano il loro obiettivo. La conclusione del post è una divisione del lavoro. Sostiene che passerà un po' di tempo prima che gli agenti elaborino terabyte di dati strutturati allo stesso livello di ottimizzazione dei sistemi di database d'élite costruiti su decenni di ricerca. Fino ad allora, il motore si tiene il lavoro pesante.

A cosa porta tutto questo

Letti insieme, i tre pezzi indicano la stessa direzione. Lo strato di raccolta viene incorporato nell'applicazione. Lo strato di presentazione viene spostato su infrastrutture che chi gestisce controlla. E lo strato di analisi viene affidato ad agenti che interrogano direttamente i database invece di ricevere dump. Nulla di tutto questo compare nelle previsioni di mercato dei titoli. È la parte della tecnologia sportiva che decide se il numero sullo schermo è giusto, quanto in fretta arriva e chi paga i token.