Sportanalytik frisst ihre eigene Datenpipeline

Apple hat eine App namens Sports. Das ist der ganze Name. Slate hat sie am 10. Juni besprochen, als die Weltmeisterschaft begann. Die App tut fast nichts: Teamnamen und Logos, Bilanzen, Spielzeiten, Ergebnisse. Kein Newsfeed, kein Streaming-Leitfaden, kein Scrollen im TikTok-Stil.

Die Besprechung ist ein nützliches Gegengewicht dazu, wie Sporttechnologie üblicherweise verkauft wird. In denselben Wochen, in denen dieser Text entstand, erschien auch eine Reihe von Entwicklerwerkzeugen für die Analytik-Infrastruktur. In der Lücke zwischen beiden Geschichten liegt die interessante Arbeit.

Was Apple tatsächlich ausgeliefert hat

Der Rezensent von Slate beschreibt ein Produkt, das um die Subtraktion herum gebaut ist. Die App enthält keine Schlagzeilen und keine Streaming-Leitfäden, obwohl man den Sender eines Spiels sieht, wenn man darauf tippt. Wettquoten erscheinen standardmäßig auf der Ergebnistafel und lassen sich mit einem einzigen Schalter dauerhaft abschalten. Werbung gibt es kaum, gelegentlich Werbung für Apple TV oben auf einer Seite. Nutzer wählen aus, welche Ligen und Teams auf der Startseite und in der Seitenleiste erscheinen. Die Ergebnisse dieser Teams können Live Activities auf dem Sperrbildschirm speisen, müssen es aber nicht.

Die Geschwindigkeitsbehauptung in dieser Besprechung ist konkret und überprüfbar. Der Autor schreibt, er habe während der Stanley-Cup-Playoffs die automatischen Updates zu den Pittsburgh Penguins abschalten müssen, weil die App Entwicklungen zeigte, bevor sein Streaming-Paket nachzog. Dieselbe Erfahrung berichtet er bei NFL-, College-Football- und College-Basketball-Spielen. Die Abdeckung reicht bis zu WM-Spielen, MLS, NWSL und rund 30 weiteren Fußballligen sowie Herren- und Damentennis und der LPGA Tour, mit einfachen Box Scores, Ranglisten und Kaderlisten hinter einem Tipp.

Apple kündigte die App im Winter 2024 an. Slate zitiert die Formulierung eines Apple-Managers zum Start: Das Unternehmen habe die App entwickelt, um Sportfans das zu geben, was sie wollen, nämlich schnellen Zugriff auf Ergebnisse und Statistiken.

"We created Apple Sports to give sports fans what they want — an app that delivers incredibly fast access to scores and stats."

Das ist ein Datenproblem, das als Designproblem verkleidet ist. Jedes Ergebnis auf diesem Bildschirm ist ein Feed, eine Zuordnung zwischen Ligen und Teams und ein Latenzbudget. Apple kann diese Kosten tragen. Die meisten Organisationen, die etwas Ähnliches bauen, können das nicht. Deshalb erschien im selben Zeitraum eine Gruppe von Veröffentlichungen für jene, die die Pipeline selbst zusammenbauen müssen.

Das alte Analytics auf GA4-Daten neu aufbauen

Ein Beispiel ist adaca-analytics, am 8. September auf GitHub von Adaca veröffentlicht, einer Softwareberatung. Es ist eine selbst gehostete Dashboard-Schicht für Google Analytics 4, die auf Cloudflare Workers läuft. Tägliche Zusammenfassungen aus der GA4 Data API oder einem BigQuery-Export landen in einer D1-Datenbank, die der Betreiber besitzt. Echtzeitdaten bleiben bei Google. Das Repository liefert sechs Dashboards ab Werk mit, dazu einen vierstufigen Baukasten für eigene. Jede Kennzahl öffnet sich in eine Detailseite mit eigenem Verlauf und Aufschlüsselungen, vorberechnet, damit sie in einem einzigen Roundtrip laden.

Die betrieblichen Details zählen mehr als die Funktionsliste. Die Einrichtung verlangt ein Google-Dienstkonto mit Viewer-Zugriff auf die GA4-Property und dessen JSON-Schlüssel. Das Deployment forkt das Repository, richtet D1 und KV ein, fordert den Schlüssel an und deployt den Worker samt Cron-Job. Es gibt keine Anmeldung, deshalb rät die README, Cloudflare Access oder die eingebaute Basic Auth davorzusetzen. Die lokale Entwicklung läuft über npm install, eine .dev.vars-Datei mit dem Dienstkonto-JSON in einer Zeile, Typgenerierung, eine Datenbankmigration und einen Dev-Server. CI besteht aus vier Prüfungen: Build, Typecheck, Lint und Test. Die Lizenz ist MIT.

Das Versprechen ist laut Repository die Wiederherstellung einer Produktform, die GA4 verdrängt hat: Dashboards mit Drill-down, gespeicherten Segmenten, schreibgeschützten Freigabelinks, die einen Filter festhalten können, Vergleich mit der vorigen Periode oder dem Vorjahr, wöchentlichen und monatlichen Zusammenfassungen sowie Verkehrswarnungen per E-Mail oder Slack.

Analytik als Middleware, nicht als Plattform

Eine zweite Veröffentlichung setzt auf die entgegengesetzte Architekturentscheidung. Plainoldanalytics, am 13. September auf GitHub eingestellt, ist nachträglich anbaubare Webanalytik für Go-Anwendungen. Die README beschreibt es als im Geist ähnlich zu Umami, Plausible oder PostHog, aber in die eigene App eingebettet statt daneben gehostet. Das Kernpaket ist speicherunabhängig und weiß nichts von einem Backend, sodass ein Import nie eines mitzieht. Man wählt ein Speicherpaket oder implementiert das Storage-Interface und übergibt es dem Konstruktor.

Die Nutzung ist bewusst klein gehalten. Ein memory_store-Konstruktor liefert sowohl einen Storage als auch die Verdrahtung, und ein Aufruf von analytics.Middleware umhüllt einen vorhandenen Router. Das Dashboard wird unter einem selbst gewählten Pfad eingehängt. Ein Script-Tag ermöglicht die Erfassung von Ereignissen auf der Clientseite, einschließlich optionaler Sitzungsaufzeichnung und Aufrufen wie plainoldanalytics.track('signup', {plan: 'pro'}). Der Verkehr wird etwa einmal pro Sekunde auf die Platte geschrieben, und ein Close-Aufruf beim Herunterfahren leert den Puffer. Adapter gibt es für gin und chi. Die README zeigt, wie man die Middleware auf eine Routengruppe beschränkt, damit das Dashboard selbst nicht als Verkehr erfasst wird.

Zwei kleine Details deuten darauf hin, dass hier jemand geschrieben hat, der Analytik im Produktivbetrieb betrieben hat. Anfragen können Schlüssel-Wert-Eigenschaften tragen, nach denen die Oberfläche filtern kann. Die Nutzereigenschaft wird gesondert behandelt und zeigt den gesamten Verkehr, der mit diesem Nutzer verbunden ist. Routen lassen sich vollständig von der Protokollierung ausnehmen. Pfadparameter werden so aufgezeichnet, wie sie sind. Wer einen Handler mit UseRequestPath umhüllt, zeichnet stattdessen die wörtliche Route auf. Das zählt, wenn man Dateien unter einem Platzhalter ausliefert und nicht will, dass jede URL zu einer eigenen Zeile wird.

Die Agentenfrage unter alldem

Starburst veröffentlichte am 11. September eine Analyse zweier Architekturen für agentische Datenanalyse. Sie benennt das Problem, um das die obigen Werkzeuge kreisen. Das Szenario ist eine Supermarktkette, die fragt, ob die Eier-Aktion der letzten Woche profitabel war. Diese Frage lässt sich nicht allein aus den Eierverkäufen beantworten. Sie braucht Rückfragen: ob die Aktion Kunden brachte, die sonst nicht gekommen wären, ob neue Kunden wiederkamen, was sonst in diesen Transaktionen steckte, wo diese Artikel im Laden stehen und wie profitabel sie sind.

Starburst legt zwei praktische Wege dar, einem Agenten Daten zuzuführen. Der erste, vom Autor Option 0 genannt und außer in ungewöhnlichen Fällen ausdrücklich nicht empfohlen, extrahiert Rohdaten und schickt sie dem Agenten als Dateien oder direkte Leitung. Der Agent übernimmt die Verarbeitung selbst. Der Einwand sind Kosten und Leistung: Terabytes an etwas zu senden, das pro Datenelement abrechnet, wird teuer, und der Agent erledigt Arbeit, die eine Datenbankmaschine besser kann.

Der zweite gibt dem Agenten direkten Zugang zur Datenbank, sodass er sein eigenes SQL schreibt und seine Anfragen schrittweise verfeinert. Die Datenbank tut, wofür sie optimiert ist, und der Agent beaufsichtigt. Starburst merkt an, die Literatur markiere hier ein echtes Risiko: Agenten können weit anspruchsvoller sein als menschliche Nutzer und ein System mit spekulativen Abfragen überlasten, während sie sich einer Antwort nähern. Die Branche konzentriere sich inzwischen darauf, solche Arbeitslasten zu unterstützen.

Eine Grenze in dem Text ist es wert, wiederholt zu werden. Der Autor schreibt, es werde eine Weile dauern, bis Agenten Terabytes strukturierter Daten mit derselben Optimierung verarbeiten können wie die heute am Markt befindlichen Datenbanksysteme, die auf Jahrzehnten der Forschung beruhen. Bis dahin behält die Datenbank das schwere Ende.

Warum das eine Sportgeschichte ist

Sport ist der härteste Verbraucherfall für diesen Stack, weil der Wert eines Ergebnisses in Sekunden verfällt und das Publikum in Schüben eintrifft: eine WM-Gruppenphase, ein Playoff-Lauf, ein Sonntagnachmittag mit einem Dutzend gleichzeitiger Spiele. Der Rezensent von Slate führt an, die App sei schnell genug, um Ergebnisse zu verraten, bevor ein Streaming-Feed nachkommt. Das ist keine Leistung der Oberfläche. Es ist eine Pipeline, die Dutzende Ligen zusammenführen, sie den vom Nutzer gewählten Teams zuordnen und Aktualisierungen innerhalb eines Latenzfensters auf einen Sperrbildschirm schieben muss.

Apple kann das finanzieren. Alle anderen, die ein Fanprodukt, ein Wettprodukt oder eine Vereins-App betreiben, bauen es aus Teilen zusammen. Die im September veröffentlichten Teile sind offen über die Kompromisse: die Datenbank selbst besitzen und Drill-down ohne Anbieter bekommen, die Analytik in den eigenen Prozess einbetten und die Plattform überspringen oder dem Agenten Abfragezugriff geben und akzeptieren, dass er mehr Fragen stellt als je ein menschlicher Analyst. Die App ohne Funktionen ist der leichte Teil. Die Zahl auf den Bildschirm zu bringen, bevor es der Stream tut, ist das Produkt.