Aplikacje sportowe stały się ciężkie. Analityka za nimi skomplikowała się jeszcze bardziej

Technologia sportowa jest sprzedawana jako historia danych. Propozycje trafiające do redakcji w tym miesiącu mówią o AI na rynkach sportowych, dashboardach wzrostu fanów i analityce wydajności. To warstwa marketingowa. Warstwa inżynieryjna wygląda inaczej i jest łatwiejsza do zbadania, ponieważ większość z niej trafia do użytku jako open source, raporty z programów bug bounty lub notatki produktowe.

Rozważmy najbardziej widoczny przykład konsumencki. Slate opublikował w czerwcu tekst argumentujący, że aplikacja Sports Apple jest najlepszą aplikacją, jaką firma wyprodukowała w ostatnich latach, właśnie dlatego, że praktycznie nic nie robi. Aplikacja, nazwana po prostu „Sports”, nie zawiera nagłówków wiadomości, przewodników streamingowych i prawie żadnej reklamy. Recenzent Slate zauważa, że wyświetla nazwy i logotypy drużyn, rekordy, godziny meczów i wyniki, a także stronę z tabelą. Kursy bukmacherskie pojawiają się na tablicy wyników, ale przełącznik w ustawieniach usuwa je na stałe.

To jest cały produkt. Ciekawą częścią dla każdego, kto pracuje w danych sportowych, jest to, dlaczego czuje się szybko: aplikacja jest wąska z projektu, więc potok danych za nią nigdy nie musi godzić feedów, treści redakcyjnych i inwentarza wideo w tym samym widoku.

Tablica wyników to łatwa część

Autor Slate opisuje personalizację jako idealną: wybierasz ligi i drużyny, pojawiają się na stronie głównej i w pasku bocznym, a ich wyniki mogą pojawiać się jako Live Activities na ekranie blokady. Zasięg sięga daleko poza Mundial do MLS, NWSL i około 30 innych lig piłkarskich, a także męskiego i żeńskiego tenisa oraz LPGA Tour. Kliknięcie meczu otwiera podstawową statystykę, listę liderów lub skład.

Aplikację ogłoszono zimą 2024 roku. Slate cytuje przedstawiciela Apple, który wtedy przedstawił założenie: „Stworzyliśmy Apple Sports, aby dać fanom sportu to, czego chcą, aplikację zapewniającą niesamowicie szybki dostęp do wyników i statystyk”. Brak ram agentic, brak obietnic przybliżania fanów do akcji.

W tej powściągliwości kryje się przydatna lekcja. Większość własności sportowych ma teraz lata akumulowanych funkcji. Recenzent Slate wyróżnia oficjalną aplikację Major League Baseball, kiedyś ulubioną, za otaczanie wyników i wideo dodatkami, oraz aplikację ESPN za pchanie swojej oferty live TV i feedu w stylu TikTok zwanego „Verts” nad sekcją wyników. Tarcie nie jest problemem danych. To problem produktu przebrany za problem danych.

To jest miejsce, gdzie hydraulika staje się ciekawa, a publiczny rejestr w tym miesiącu jest wyjątkowo bogaty.

8 września firma konsultingowa Adaca opublikowała Adaca Analytics, warstwę dashboardów do samodzielnego hostingu dla Google Analytics 4 i BigQuery, działającą na Cloudflare Workers. Zgodnie z README projektu na GitHubie, dzienne rollupy z GA4 Data API lub eksportu BigQuery trafiają do bazy D1, którą operator posiada, podczas gdy dane w czasie rzeczywistym pozostają aktywne na Google. Repozytorium zawiera sześć dashboardów i czterostopniowy konstruktor do tworzenia własnych.

Szczegóły ważą więcej niż pitch. Każda liczba na dashboardzie otwiera się na stronę szczegółową z własnym trendem i podziałami, wyliczoną z wyprzedzeniem, aby ładować się w jednej rundzie. Jest jeden filtr dla całego dashboardu, zapisane segmenty i linki udostępniania tylko do odczytu, które mogą przypiąć filtr. Porównania działają wobec poprzedniego okresu, zeszłego roku lub dowolnego okna. Ustawienie wymaga utworzenia konta serwisowego Google z dostępem Viewer do własności GA4, pobrania jego klucza JSON, a następnie wdrożenia na Cloudflare, które forkuje repozytorium i provisionuje D1 oraz KV. README jest wyraźne, że nie ma logowania, i mówi operatorom, aby umieścili Cloudflare Access lub wbudowany Basic Auth przed wdrożeniem. Projekt jest na licencji MIT.

Odczytaj to w kontekście sportu i kształt problemu staje się jasny. Klub, liga lub nadawca, który chce własnego widoku analitycznego, składa go teraz z towarowych części: runtime worker, mała baza, konto serwisowe z dostępem tylko do odczytu i zadanie cron. Droga część to nie silnik zapytań. To model dostępu i dyscyplina operacyjna.

Gdy sprawdzenie tokena brakuje

Tom's Hardware raportował 28 września, że nastolatek używający pseudonimu Faav znalazł nieautoryzowany endpoint w wewnętrznej platformie analitycznej Titan Microsoft. Raport mówi, że bot, który zbudował, zwany Antares, znalazł URL endpointu, który zwrócił błąd wymagający VPN. Antares następnie wyliczył subdomeny i znalazł jedną na hoście Azure Cloud, wraz z plikiem Swagger/OpenAPI listującym cztery trasy. Trzy wymagały uwierzytelnienia Azure Active Directory. Jedna nie, i nazywała się /v2/Query. Akceptowała surowy SQL.

Zgodnie z raportem, Faav użył Wayback Machine, aby znaleźć wersję 2023 strony logowania z plikiem konfiguracyjnym Apache Superset, który opisywał schemat bazy, w tym 56 definicji tabel. Endpoint odrzucił jego zapytania z powodu braku JWT, więc uruchomił Antares przeciwko niemu przez 10 dni bez sukcesu. Wtedy zauważył, że odpowiedzi serwera sugerowały, że podpis cyfrowy tokena nie jest sprawdzany, przedstawił token twierdzący o dostępie administratora i został wpuszczony. Pojedyncze SHOW DATABASES zwróciło 25 000 rekordów danych pracowników, plus rekordy organizacji, dashboardy i wykresy.

Kopiąc dalej, znalazł źródło danych dla analityki Bing. Licząc wiersze w tabelach, Tom's Hardware raportuje, że policzył dostęp do 17 000 000 000 000 rekordów łącznie. Zgłosił problem do programu bug bounty Microsoft i otrzymał 5 000. W swoim wpisie na blogu napisał: „AI i intuicja ludzka skomponowały się tutaj. Antares wykonało dziesięć dni pracy, których nie musiałem [...] Jego wytrwałość, plus jedna ludzka intuicja, sprawiły, że to odkrycie było możliwe.”

Dwie rzeczy warto oddzielić tutaj. Pierwsza to sama luka: endpoint akceptujący surowy SQL i nieweryfikujący podpisu tokena. Druga to metoda odkrycia. Brute-force wyliczanie subdomen było zautomatyzowane. Wgląd, że sprawdzenie podpisu brakowało i że sfałszowane twierdzenie administratora zadziała, nie było.

Starburst opublikowała analizę 11 września, która ramuje ten sam konflikt od strony architektury. Post przechodzi przez dwa sposoby karmienia agenta AI w przedsiębiorstwie: wyciągnąć dane i przekazać, lub dać agentowi bezpośredni dostęp do bazy i pozwolić mu pisać własne zapytania. Pierwsza opcja, którą autor oznacza jako „opcja 0”, szybko staje się droga, ponieważ agenci, którzy pobierają opłaty za przetworzony element danych, nie mogą otrzymywać terabajtów. Autor nazywa to niepraktycznym poza nietypowymi okolicznościami.

Druga opcja pozwala silnikowi bazy danych robić to, do czego jest zoptymalizowany, podczas gdy agent wysyła kolejne lub równoległe żądania. Zauważa też realne ryzyko: agenci mogą być znacznie bardziej wymagający niż użytkownicy ludzcy i mogą przytłoczyć bazę spekulatywnymi zapytaniami podczas doskonalenia skupienia. Przykład ze sklepu spożywczego w poście jest dobrą ilustracją, dlaczego pytanie jest trudne. Zapytanie, czy promocja na jajka była opłacalna, wymaga danych transakcyjnych z jednego systemu, danych lojalnościowych i demograficznych z innego oraz ciągu pytań o skład koszyka i powtórne wizyty.

To ma ten sam kształt co problem analityki sportowej. Bilety, streaming, gadżety, telemetria aplikacji i dane obiektów znajdują się w różnych systemach, a ważne zapytania obejmują je wszystkie. Tekst Starburst argumentuje, że nowoczesne systemy bazodanowe coraz lepiej radzą sobie z obciążeniami agentic, ale agenci nie dopasują się do optymalizacji długo dostrojonych silników bazodanowych na terabajtach danych strukturalnych przez jakiś czas.

Ciche narzędzia to te, na które warto patrzeć

Z dala od warstwy enterprise, dwa mniejsze projekty pokazują, gdzie idą narzędzia. Plainoldanalytics, opublikowany na Hacker News 13 września, to samodzielnie hostowany middleware analityczny dla aplikacji Go. Jego README opisuje go jako podobny duchem do Umami, Plausible lub PostHog, ale osadzony w samej aplikacji. Pakiet rdzeniowy jest agnostyczny względem przechowywania, więc jego import nigdy nie wciąga backendu; operatorzy wybierają pakiet przechowywania, taki jak DuckDB lub magazyn w pamięci, lub implementują interfejs samodzielnie. Ruch spłukuje na dysk mniej więcej raz na sekundę, a middleware zapisuje parametry ścieżki, chyba że trasa jest owinięta, aby zarejestrować ścieżkę dosłowną. Istnieją adaptery dla gin i chi.

DataZen, opublikowany 29 sierpnia, idzie w drugą stronę: lokalny klient desktopowy do pracy między bazami. Jego strona lista PostgreSQL, MySQL, SQLite i Redis jako wbudowane, z opcjonalnymi sterownikami dla MongoDB, ClickHouse, DuckDB i SQL Server. Oferuje SQL w języku naturalnym, jednowyborczą diagnozę błędów, wizualizację EXPLAIN, workflow w YAML i wbudowany serwer MCP, który udostępnia zapytania, inspekcję schematu i workflow jako narzędzia dla agentów, takich jak Claude Desktop, Cursor i Cline. Strona stwierdza, że poświadczenia są szyfrowane AES-256-GCM i przechowywane w keychainie OS, że tylko kontekst schematu i zapytań jest wysyłany do dostawcy AI, i że pełny kod źródłowy jest dostępny pod GPLv3. Zauważa też, że nie jest wymagane konto i nie jest obsługiwana żadna chmurowa usługa bazodanowa.

Połączenie tych czterech ujawnia wzorzec, który prognozy rynkowe mają tendencję do wygładzania. Warstwa skierowana na konsumenta konsoliduje się wokół radykalnej prostoty, jak pokazuje aplikacja Sports Apple. Warstwa pod spodem fragmentuje się na małe, audytowalne, samodzielnie hostowane komponenty, które operatorzy mogą badać i kontrolować. A rejestr bezpieczeństwa, jak pokazuje przypadek Microsoft, zależy mniej od tego, czy organizacja kupiła platformę analityczną, niż od tego, czy sprawdziła podpis na tokenie.

Nic z tego nie pojawia się na wykresie szacowania rynku. Pojawia się w momencie, gdy wdrożenie idzie źle.