La sports analytics divora la sua stessa pipeline di dati

Apple ha un'app che si chiama Sports. Il nome è tutto. Slate l'ha recensita il 10 giugno, mentre il Mondiale entrava nel vivo, e ha trovato un prodotto che non fa quasi nulla: nomi e loghi delle squadre, record, orari delle partite, punteggi. Nessun feed di notizie, nessuna guida allo streaming, nessuno scorrimento in stile TikTok.

La recensione è un contrappeso utile a come viene di solito venduta la tecnologia sportiva. Nelle stesse settimane sono usciti anche diversi strumenti per sviluppatori dedicati all'idraulica dell'analytics, e il divario tra le due storie è il punto in cui si trova il lavoro interessante.

Cosa ha consegnato davvero Apple

Il recensore di Slate descrive un prodotto costruito sulla sottrazione. L'app non contiene titoli di giornale né guide allo streaming, anche se toccando una partita si vede il canale che la trasmette. Le quote scommesse compaiono sul tabellone per impostazione predefinita e si possono disattivare in modo permanente con un solo interruttore. La pubblicità è quasi assente, con occasionali promo di Apple TV in cima a una pagina. Gli utenti scelgono quali campionati e quali squadre appaiono nella home e nella barra laterale, e i punteggi di quelle squadre possono alimentare le Attività in tempo reale sulla schermata di blocco, oppure no.

L'affermazione sulla velocità contenuta in quella recensione è precisa e verificabile. L'autore dice di aver dovuto disattivare gli aggiornamenti automatici dei Pittsburgh Penguins durante i playoff della Stanley Cup, perché l'app mostrava gli sviluppi prima del suo pacchetto di streaming. Riferisce la stessa esperienza con partite NFL, di college football e di college basketball. La copertura si estende alle partite del Mondiale, alla MLS, alla NWSL e a circa 30 altri campionati di calcio, più il tennis maschile e femminile e l'LPGA Tour, con box score essenziali, classifiche e rose a un tocco di distanza.

Apple ha annunciato l'app nell'inverno del 2024. Slate cita la presentazione fatta da un dirigente Apple al lancio: l'azienda "ha creato Apple Sports per dare agli appassionati di sport quello che vogliono, un'app che offre un accesso incredibilmente rapido a punteggi e statistiche".

"Abbiamo creato Apple Sports per dare agli appassionati di sport quello che vogliono, un'app che offre un accesso incredibilmente rapido a punteggi e statistiche."

È un problema di dati travestito da problema di design. Ogni punteggio su quella schermata è un feed, una mappatura tra campionati e squadre e un budget di latenza. Apple può permettersi quel costo. Quasi tutte le organizzazioni che costruiscono qualcosa di simile no, ed è per questo che nello stesso periodo è uscito un gruppo di rilasci destinati a chi la pipeline deve montarla da sé.

Ricostruire il vecchio Analytics sui dati di GA4

Prendiamo adaca-analytics, pubblicato su GitHub l'8 settembre da Adaca, una società di consulenza software. È uno strato di dashboard self-hosted per Google Analytics 4, gira su Cloudflare Workers e porta rollup giornalieri dalla Data API di GA4 o da un export BigQuery in un database D1 di proprietà dell'operatore. I dati in tempo reale restano su Google. Il repository include sei dashboard pronte all'uso più un builder in quattro passaggi per quelle personalizzate. Ogni numero in evidenza si apre in una pagina di dettaglio con il proprio andamento e le proprie ripartizioni, precalcolate per caricarsi in un solo round trip.

I dettagli operativi contano più dell'elenco delle funzioni. La configurazione richiede un service account Google con accesso Viewer sulla proprietà GA4 e la sua chiave JSON. Il deployment fa il fork del repository, predispone D1 e KV, richiede la chiave e distribuisce il Worker con il suo cron job. Non c'è login, quindi il README dice di mettergli davanti Cloudflare Access o la Basic Auth integrata. Lo sviluppo locale passa da npm install, un file .dev.vars che contiene il JSON del service account su una riga, la generazione dei tipi, una migrazione del database e un dev server. La CI ha quattro cancelli: build, typecheck, lint e test. La licenza è MIT.

La proposta, nelle parole del repository, è riportare in vita una forma di prodotto che GA4 ha spazzato via: dashboard con drill-down, segmenti salvati, link di condivisione in sola lettura che possono fissare un filtro, confronto con il periodo precedente o con l'anno scorso, riepiloghi settimanali e mensili e avvisi di traffico via email o Slack.

L'analytics come middleware, non come piattaforma

Un secondo rilascio punta sulla scommessa architetturale opposta. Plainoldanalytics, pubblicato su GitHub il 13 settembre, è analytics web aggiuntivo per applicazioni Go. Il README lo presenta come simile nello spirito a Umami, Plausible o PostHog, ma incorporato nella tua app invece che ospitato accanto a essa. Il pacchetto principale è agnostico rispetto allo storage e non sa nulla di alcun backend, quindi importarlo non ne trascina mai uno dentro. Si sceglie un pacchetto di storage, oppure si implementa l'interfaccia Storage e la si passa al costruttore.

L'uso è volutamente minimo. Un costruttore memory_store restituisce sia uno Storage sia il cablaggio, e una chiamata analytics.Middleware avvolge un router esistente. La dashboard si monta su un percorso a scelta. Un tag script abilita la cattura degli eventi lato client, inclusa la registrazione opzionale della sessione e chiamate come plainoldanalytics.track('signup', {plan: 'pro'}). Il traffico viene riversato su disco circa una volta al secondo, e una chiamata Close allo spegnimento svuota il buffer. Esistono adattatori per gin e chi, e il README mostra come limitare il middleware a un gruppo di rotte, così che la dashboard stessa non venga registrata come traffico.

Due piccoli dettagli suggeriscono che il codice l'abbia scritto qualcuno che ha gestito analytics in produzione. Le richieste possono portare proprietà chiave/valore su cui l'interfaccia può filtrare, e la proprietà utente riceve un trattamento speciale, mostrando tutto il traffico legato a quell'utente. Le rotte possono essere escluse del tutto dalla registrazione. I parametri di percorso vengono registrati così come sono, ma avvolgere un handler con UseRequestPath registra la rotta letterale. Questo conta quando si servono file sotto un carattere jolly e non si vuole che ogni URL diventi una riga a sé.

La questione degli agenti che sta sotto a tutto

Starburst ha pubblicato l'11 settembre un'analisi di due architetture per l'analisi dati agentica, e nomina il problema attorno a cui girano gli strumenti di cui sopra. Lo scenario è una catena di supermercati che chiede se la promozione sulle uova della settimana scorsa sia stata redditizia. A quella domanda non si risponde dalle sole vendite di uova. Servono approfondimenti: se la promozione abbia portato clienti che altrimenti non sarebbero venuti, se i nuovi clienti siano tornati, cos'altro ci fosse in quelle transazioni, dove stiano quegli articoli nel negozio e quanto siano redditizi.

Starburst espone due modi pratici per alimentare un agente. Il primo, che l'autore chiama "opzione 0" e che esplicitamente non consiglia al di fuori di circostanze insolite, estrae i dati grezzi e li spedisce all'agente come file o tramite un tubo diretto, lasciando che l'agente faccia da sé l'elaborazione. L'obiezione è di costo e prestazioni: mandare terabyte a qualcosa che fattura per singolo dato diventa costoso, e l'agente fa un lavoro che un motore di database fa meglio.

Il secondo dà all'agente accesso diretto al database, così scrive il proprio SQL e affina le richieste in modo iterativo. Il database fa ciò per cui è ottimizzato, e l'agente supervisiona. Starburst nota che la letteratura segnala qui un rischio reale, cioè che gli agenti possono essere molto più esigenti degli utenti umani e sommergere un sistema di query speculative mentre restringono il campo verso una risposta. Sostiene però che ora il settore è concentrato nel supportare questi carichi di lavoro.

C'è un limite nell'articolo che vale la pena ripetere. L'autore scrive che passerà ancora un po' di tempo prima che gli agenti possano elaborare terabyte di dati strutturati con lo stesso livello di ottimizzazione dei sistemi di database presenti oggi sul mercato, costruiti su decenni di ricerca. Fino ad allora, il database si tiene la parte pesante.

Perché questa è una storia di sport

Lo sport è il caso di consumo più difficile per questo stack, perché il valore di un punteggio si esaurisce in pochi secondi e il pubblico arriva a ondate: una fase a gironi del Mondiale, una corsa ai playoff, una domenica pomeriggio con una dozzina di partite in contemporanea. Il recensore di Slate fa notare che l'app è abbastanza veloce da rovinare il risultato prima che il feed dello streaming recuperi. Non è un risultato di interfaccia. È una pipeline che deve riconciliare decine di campionati, mapparli sulle squadre scelte da un utente e spingere gli aggiornamenti su una schermata di blocco entro una finestra di latenza.

Apple può finanziarla. Tutti gli altri che gestiscono un prodotto per tifosi, un prodotto di scommesse o l'app di un club la montano pezzo per pezzo, e i pezzi pubblicati a settembre sono schietti sui compromessi: possiedi il database e ottieni il drill-down senza un fornitore, incorpora l'analytics nel tuo processo e salta la piattaforma, oppure dai all'agente l'accesso alle query e accetta che farà più domande di qualsiasi analista umano. L'app senza funzioni è la parte facile. Portare il numero sullo schermo prima dello streaming è il prodotto.