Cicha zmiana w danych sportowych: własne pulpity i agenci, którzy sami piszą zapytania

Większość szumu wokół technologii sportu w 2026 roku pochodzi z prognoz rynkowych i ogłoszeń sponsorskich. Samo narzędziownictwo jest cichsze i opowiada konkretniejszą historię: zespoły analityczne przenoszą pulpity z chmur dostawców i dają agentom AI bezpośredni dostęp do bazy danych, a potem kłócą się o rachunek.

Dwa wydania open source z września zarysowują pierwszą połowę tej zmiany. Oba są do samodzielnego hostowania. Oba zakładają, że dane już gdzieś są. Żaden nie jest produktem sportowym w tym sensie co aplikacja dla kibica.

To instalacja pod tablicami wyników.

Pulpity GA4, które hostujesz sam

8 września firma konsultingowa Adaca opublikowała na GitHubie Adaca Analytics na licencji MIT. To warstwa pulpitów do samodzielnego hostowania dla Google Analytics 4, działająca na Cloudflare Workers, jak podaje repozytorium projektu. Mechanika liczy się bardziej niż opis. Dzienne agregacje są pobierane albo z GA4 Data API, albo z eksportu BigQuery i trafiają do bazy D1, którą operator ma, czytamy w README. Dane w czasie rzeczywistym zostają po stronie Google. Pulpity składa się z konfigurowalnych widżetów na siatce, sześć gotowych jest w zestawie, a do własnych służy kreator w czterech krokach.

Repozytorium twierdzi, że każda liczba daje się rozwinąć: źródła, strony i kraje mają osobne strony ze swoim trendem i podziałami, wstępnie policzonymi, żeby ładowały się w jednym zapytaniu.

Na pulpit przypada jeden filtr, zapisane segmenty oraz linki do udostępniania tylko do odczytu, które mogą przypiąć filtr. Porównanie działa względem poprzedniego okresu, zeszłego roku albo dowolnego przedziału, z rozbiciem godzinnym dla bieżącego dnia i licznikiem odwiedzających na żywo. Podsumowania tygodniowe i miesięczne oraz alerty o ruchu wychodzą mailem lub przez Slacka. Konfiguracja jest celowo bez fajerwerków. Operator zakłada konto usługi Google z dostępem Viewer do usługi GA4, pobiera klucz JSON i naciska Deploy to Cloudflare. To rozwidla repozytorium, tworzy D1 i KV, pyta o klucz i wdraża Workera wraz z jego cronem. Z przodu wchodzi Cloudflare Access albo wbudowane Basic Auth, bo logowania nie ma. Potem rusza pierwsze uzupełnianie danych, na które patrzysz.

Dla organizacji sportowych prowadzących kilka serwisów w ligach, drużynach czy regionach argument jest taki: kontrola. Baza D1, którą masz, brak umowy analitycznej rozliczanej od stanowiska i wsparcie eksportu BigQuery dla tych, którzy już przesyłają GA4 do hurtowni.

Haczyk jest operacyjny. Samodzielne hostowanie oznacza, że odpowiadasz za cron, warstwę logowania i migracje.

Middleware analityczny wewnątrz aplikacji

Pięć dni później, 13 września, na GitHubie pojawił się osobny projekt Plainoldanalytics. To doczepiana biblioteka analityki webowej dla aplikacji w Go, opisana w README jako bliska duchem Umami, Plausible czy PostHog, ale osadzona w twojej aplikacji, a nie uruchamiana obok niej. Pakiet rdzeniowy jest niezależny od magazynu: jego import nigdy nie ściąga backendu. Programista wybiera pakiet magazynu, na przykład pamięciowy albo DuckDB, i jednym wywołaniem konstruktora dostaje działający Storage oraz podłączenie Analytics. Ruch jest zrzucany na dysk mniej więcej raz na sekundę, a wywołanie Close przy zamykaniu zrzuca wszystko, co zostało w buforze.

Biblioteka ustawia właściwości klucza i wartości przy każdym żądaniu, po których może filtrować wbudowany pulpit, i traktuje osobno właściwość użytkownika, żeby cały ruch jednej osoby pokazywał się razem.

Trasy z parametrami ścieżki są domyślnie zapisywane jako parametry, a gdy liczy się dosłowna trasa, dostępny jest wrapper UseRequestPath. Jest wywołanie Exclude dla tras, których nie należy logować w ogóle, oraz adaptery dla gin i chi, a także opcjonalny skrypt nagrywania sesji przeglądarki. Dla klubu czy federacji prowadzącej w Go sprzedaż biletów, obsługę członków albo serwisy treściowe to różnica między skryptem zewnętrznym na każdej stronie a jedną linijką middleware w routerze. Żaden z tych projektów nie jest platformą analityki sportowej. Oba usuwają dostawcę z drogi między zdarzeniem a liczbą.

Spór o architekturę: kto wykonuje zapytanie

Trudniejsze pytanie leży wyżej niż narzędzia, a Starburst zmierzył się z nim we wpisie z 11 września zatytułowanym "An Analysis of Two Architectures for Agentic Data Analysis". Założenie: agenci coraz częściej uzupełniają lub zastępują analizę danych prowadzoną przez człowieka, podejmując pytania z pytaniami dodatkowymi i wieloma rundami analizy na jednym lub kilku zbiorach danych. Przykład Starbursta to sklep spożywczy pytający, czy promocja jajek z zeszłego tygodnia była opłacalna. Odpowiedź wymaga wiedzy, czy wyprzedaż przyciągnęła klientów, którzy inaczej by nie przyszli, czy nowi klienci wrócili, co jeszcze było w tym samym koszyku i jak opłacalne są te produkty. Pytania sportowe mają ten sam kształt: czy push streamingowy przyniósł nowych subskrybentów, czy zostali, co jeszcze kupili.

Wpis rozkłada opcje podawania danych agentowi. Opcja 0 to wyciągnięcie surowych danych i wysłanie ich.

Starburst nazywa to niepraktycznym poza nietypowymi okolicznościami, bo agenci rozliczani za element danych potrafią uczynić terabajty zaporowo drogimi.

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.

Opcja 1 to danie agentowi bezpośredniego dostępu do bazy i pozwolenie mu pisać własny SQL, iteracyjnie, aż dojdzie do wniosku. Planowaniem zapytań zajmuje się silnik bazy; agent tylko nadzoruje. Starburst zauważa, że literatura wskazuje tu realne ryzyko: agenci potrafią być znacznie bardziej wymagający niż ludzie i zalać system zapytaniami spekulacyjnymi, doprecyzowując cel. Wniosek wpisu to podział pracy. Twierdzi, że minie sporo czasu, zanim agenci przetworzą terabajty danych strukturalnych z takim poziomem optymalizacji, jaki mają elitarne systemy bazodanowe budowane przez dekady badań. Do tego czasu ciężar zostaje na silniku.

Co z tego wynika

Czytane razem, te trzy elementy wskazują ten sam kierunek. Warstwa zbierania jest wbudowywana w aplikację. Warstwa prezentacji przenosi się na infrastrukturę, którą kontroluje operator. A warstwa analizy trafia do agentów, którzy odpytują bazy bezpośrednio, zamiast dostawać zrzuty. Nic z tego nie pojawia się w nagłówkach prognoz rynkowych. To ta część technologii sportu, która decyduje, czy liczba na ekranie jest poprawna, jak szybko dociera i kto płaci za tokeny.