Der stille Datenwandel im Sporttech: Self-Hosted-Dashboards und Agenten, die SQL schreiben

Der meiste Lärm rund um Sporttechnik im Jahr 2026 kommt aus Marktprognosen und Sponsoring-Meldungen. Die eigentlichen Werkzeuge sind leiser und erzählen eine konkretere Geschichte: Analytikteams holen ihre Dashboards aus den Clouds der Anbieter und geben KI-Agenten direkten Datenbankzugriff. Danach streiten sie über die Rechnung.

Zwei Open-Source-Releases aus dem September skizzieren die erste Hälfte dieses Wandels. Beide sind self-hosted. Beide setzen voraus, dass die Daten irgendwo schon existieren. Keines ist ein Sportprodukt im Sinne einer Fan-App.

Sie sind die Verrohrung unter den Anzeigetafeln.

GA4-Dashboards, die man selbst hostet

Am 8. September veröffentlichte die Softwareberatung Adaca das Projekt Adaca Analytics auf GitHub unter der MIT-Lizenz. Es handelt sich um eine self-hosted Dashboard-Schicht für Google Analytics 4, die laut Repository auf Cloudflare Workers läuft. Die Mechanik zählt mehr als der Werbetext. Tägliche Rollups werden entweder über die GA4 Data API oder über einen BigQuery-Export geholt und landen in einer D1-Datenbank, die der Betreiber besitzt, so das README. Echtzeitdaten bleiben bei Google. Dashboards bestehen aus konfigurierbaren Widgets auf einem Raster. Sechs Dashboards sind ab Werk dabei, dazu ein Vier-Schritt-Baukasten für eigene.

Laut Repository lässt sich jede Zahl durchklicken: Quellen, Seiten und Länder bekommen jeweils Detailseiten mit eigenem Trend und Aufschlüsselungen. Diese sind vorberechnet, sodass sie in einem einzigen Roundtrip laden.

Es gibt einen Filter pro Dashboard, gespeicherte Segmente und schreibgeschützte Freigabelinks, die einen Filter festhalten können. Der Vergleich läuft gegen die Vorperiode, das Vorjahr oder ein beliebiges Fenster. Dazu kommen stündliche Details für den aktuellen Tag und eine Live-Besucherzahl. Wöchentliche und monatliche Zusammenfassungen sowie Traffic-Alerts gehen per E-Mail oder Slack raus. Die Einrichtung ist bewusst nüchtern. Ein Betreiber legt ein Google-Dienstkonto mit Viewer-Zugriff auf die GA4-Property an, lädt dessen JSON-Schlüssel herunter und drückt auf Deploy to Cloudflare. Das forkt das Repository, richtet D1 und KV ein, fragt nach dem Schlüssel und deployt den Worker mit seinem Cron. Cloudflare Access oder eingebaute Basic Auth kommen davor, denn eine Anmeldung gibt es nicht. Dann läuft der erste Backfill, während man zuschaut.

Für Sportorganisationen mit mehreren Properties über Ligen, Teams oder regionale Seiten hinweg lautet das Argument Kontrolle: eine D1-Datenbank, die einem gehört, kein Analytikvertrag pro Arbeitsplatz und BigQuery-Export-Unterstützung für alle, die GA4 ohnehin in ein Warehouse leiten.

Der Haken ist betrieblich. Self-Hosting heißt, man besitzt den Cron, die Auth-Schicht und die Migrationen.

Analytik-Middleware in der App

Fünf Tage später, am 13. September, erschien ein separates Projekt namens Plainoldanalytics auf GitHub. Es ist eine Webanalytik-Bibliothek für Go-Anwendungen, die im README als im Geist ähnlich zu Umami, Plausible oder PostHog beschrieben wird, aber in die App eingebettet statt daneben betrieben. Das Kernpaket ist speicherunabhängig: Wer es importiert, zieht nie ein Backend mit hinein. Entwickler wählen ein Speicherpaket, etwa einen Memory Store oder DuckDB, und bekommen aus einem einzigen Konstruktoraufruf sowohl einen funktionierenden Storage als auch die Analytics-Verdrahtung. Der Traffic wird etwa einmal pro Sekunde auf die Platte geschrieben. Ein Close-Aufruf beim Herunterfahren schreibt alles weg, was noch im Puffer steht.

Die Bibliothek setzt Key- und Value-Properties auf jede Anfrage, nach denen das eingebaute Dashboard filtern kann. Sie behandelt eine User-Property gesondert, damit der gesamte Traffic zu einem Nutzer zusammen erscheint.

Routen mit Pfadparametern werden standardmäßig als Parameter erfasst. Ein UseRequestPath-Wrapper steht bereit, wenn die wörtliche Route zählt. Es gibt einen Exclude-Aufruf für Routen, die gar nicht protokolliert werden sollen, dazu Adapter für gin und chi sowie ein optionales Skript zur Aufzeichnung von Browsersitzungen. Für einen Verein oder Verband, der Ticket-, Mitglieder- oder Content-Services in Go betreibt, ist das der Unterschied zwischen einem Fremdskript auf jeder Seite und einer Middleware-Zeile im Router. Keines der beiden Projekte ist eine Sportanalytik-Plattform. Beide entfernen einen Anbieter aus dem Weg zwischen dem Ereignis und der Zahl.

Der Architekturstreit: Wer die Abfrage ausführt

Die schwierigere Frage liegt über den Werkzeugen. Starburst hat sie in einem Blogbeitrag vom 11. September mit dem Titel "An Analysis of Two Architectures for Agentic Data Analysis" aufgegriffen. Die Prämisse: Agenten ergänzen zunehmend die menschliche Datenanalyse oder ersetzen sie. Sie übernehmen Fragen mit Rückfragen und mehreren Analyse-Runden über einen oder mehrere Datensätze. Starbursts durchgerechnetes Beispiel ist ein Lebensmittelgeschäft, das fragt, ob die Eier-Aktion der letzten Woche profitabel war. Um das zu beantworten, muss man wissen, ob die Aktion Kunden brachte, die sonst nicht gekommen wären, ob neue Kunden wiederkamen, was sonst im selben Warenkorb lag und wie profitabel diese Artikel sind. Sportfragen haben dieselbe Form: Hat der Streaming-Vorstoß neue Abonnenten gebracht? Sind sie geblieben? Was haben sie sonst gekauft?

Der Beitrag legt Optionen vor, wie man einem Agenten Daten zuführt. Option 0 ist, Rohdaten zu extrahieren und hinüberzuschicken.

Starburst nennt das außerhalb ungewöhnlicher Umstände unpraktisch. Agenten, die pro Datenelement abrechnen, können Terabytes unbezahlbar teuer machen.

These disadvantages of option 0 reduce its practicality to the point where it is not a good option in practice. This is why I'm calling it "option 0" — it is not something that I would recommend outside of specific unusual circumstances.

Option 1 besteht darin, dem Agenten direkten Zugriff auf die Datenbank zu geben und ihn sein eigenes SQL schreiben zu lassen. Er iteriert, bis er zu einem Ergebnis kommt. Die Datenbank-Engine übernimmt die Abfrageplanung; der Agent schaut nur zu. Starburst merkt an, dass die Literatur hier ein echtes Risiko sieht: Agenten können weit anspruchsvoller sein als Menschen und ein System mit spekulativen Abfragen überlasten, während sie ihren Fokus schärfen. Das Fazit des Beitrags ist eine Arbeitsteilung. Es wird noch eine Weile dauern, bis Agenten Terabytes strukturierter Daten auf demselben Optimierungsniveau verarbeiten wie Elite-Datenbanksysteme, die auf Jahrzehnte Forschung gebaut sind. Bis dahin behält die Engine die schwere Arbeit.

Was dabei herauskommt

Zusammen gelesen zeigen die drei Teile in dieselbe Richtung. Die Sammlungsschicht wird in die Anwendung eingebettet. Die Präsentationsschicht wandert auf Infrastruktur, die der Betreiber kontrolliert. Und die Analyseschicht wird Agenten übergeben, die Datenbanken direkt abfragen, statt Dumps zu erhalten. Nichts davon taucht in den Schlagzeilen der Marktprognosen auf. Es ist der Teil der Sporttechnik, der entscheidet, ob die Zahl auf dem Bildschirm stimmt, wie schnell sie ankommt und wer die Tokens bezahlt.