Der leise Datenwandel in der Sporttechnik: selbst gehostete Dashboards und Agenten, die die Abfragen schreiben

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

Zwei Open-Source-Veröffentlichungen aus dem September skizzieren die erste Hälfte dieses Wandels. Beide laufen selbst gehostet. Beide setzen voraus, dass die Daten irgendwo schon existieren. Keines ist ein Sportprodukt in der Art einer Fan-App.

Sie sind die Verrohrung unter den Anzeigetafeln.

GA4-Dashboards, die Sie selbst hosten

Am 8. September veröffentlichte eine Softwareberatung namens Adaca auf GitHub Adaca Analytics unter der MIT-Lizenz. Es ist eine selbst gehostete Dashboard-Schicht für Google Analytics 4, die laut dem Repository des Projekts 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, heißt es im README. Echtzeitdaten bleiben auf Googles Seite. Die Dashboards werden aus konfigurierbaren Widgets auf einem Raster zusammengesetzt, sechs Dashboards sind ab Werk dabei, dazu ein Vier-Schritt-Baukasten für eigene.

Das Repository behauptet, dass jede Zahl durchklickbar ist: Quellen, Seiten und Länder bekommen jeweils Detailseiten mit eigenem Trend und Aufschlüsselungen, 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, mit stündlichem Detail für den aktuellen Tag und einer Live-Besucherzahl. Wöchentliche und monatliche Zusammenfassungen plus Verkehrswarnungen 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 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 Sie zusehen.

Für Sportorganisationen mit mehreren Properties über Ligen, Teams oder regionale Seiten hinweg lautet das Argument Kontrolle: eine D1-Datenbank, die Ihnen 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. Selbst hosten heißt, Sie besitzen 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 ansteckbare Webanalytik-Bibliothek für Go-Anwendungen, im README beschrieben als im Geist ähnlich zu Umami, Plausible oder PostHog, aber eingebettet in Ihre App 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 Verkehr wird etwa einmal pro Sekunde auf die Platte geschrieben, und ein Close-Aufruf beim Herunterfahren schreibt alles weg, was noch im Puffer steht.

Die Bibliothek setzt Schlüssel- und Werteigenschaften auf jede Anfrage, nach denen das eingebaute Dashboard filtern kann, und sie behandelt eine Benutzereigenschaft gesondert, damit der gesamte Verkehr zu einem Nutzer zusammen erscheint.

Routen mit Pfadparametern werden standardmäßig als Parameter erfasst, mit einem UseRequestPath-Wrapper, 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 und ein optionales Skript zur Aufzeichnung von Browsersitzungen. Für einen Verein oder Verband, der Ticket-, Mitglieder- oder Inhaltsservices 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, und 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, weil Agenten, die pro Datenelement abrechnen, Terabytes unbezahlbar teuer machen können.

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, iterierend, 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 argumentiert, dass es noch eine Weile dauern wird, 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.