Jak budujemy każdą statystykę

Wszystko, co wyświetlamy, pochodzi z trzech źródeł, które trzymamy audytowalne: publiczne API Supercella (developer.brawlstars.com), CDN Brawlify (cdn.brawlify.com) i nasza własna baza Supabase, która utrwala walki i agregaty, których oficjalne API nie udostępnia poza ostatnimi 25 meczami na gracza.

API Supercella to kanoniczne źródło danych strukturalnych — brawlery, gadżety, star powery, hypercharge, gearsy i rotacja eventów — ale pomija krytyczne pola jak obrazy brawlerów, rzadkość i długie opisy. Te pola krzyżujemy z CDN Brawlify, który działa niezależnie i czasem opóźnia się o jeden do trzech dni względem Supercella. Gdy wykrywamy nowego brawlera w API, którego jeszcze nie ma w Brawlify, trzymamy lokalną mapę rzadkości (BRAWLER_RARITY_MAP), żeby strona brawlera renderowała się poprawnie w dniu premiery.

Nasza baza przechowuje dwie klasy wierszy w meta_stats: source=user (prawdziwe walki użytkowników premium z włączoną sync) i source=global (automatyczne próbkowanie z rankingów PRO). Każda publiczna statystyka jest liczona z filtrem source=global, by dane osobowe pojedynczego użytkownika nigdy nie wyciekły na strony publiczne.

Warstwa "PRO" BrawlVision to agregaty liczone na ostatnich walkach najlepszych graczy świata. Co sześć godzin cron job (meta-poll) odpytuje oficjalne rankingi Supercella dla jedenastu krajów — tych z największą aktywnością competitive — i buduje deduplikowaną pulę około 2 100 unikalnych graczy z top 200 każdego.

Na tej puli stosujemy probabilistyczny sampler, by popularne kombinacje (mapa, tryb) nie zdominowały datasetu i nie maskowały rzadkich. Prawdopodobieństwo akceptacji pojedynczej walki to p = min(1, (minLive + 1) / (current + 1)), gdzie minLive to liczba najmniej reprezentowanej kombinacji, a current liczba kombinacji walki kandydata. Niedopróbkowane kombinacje dostają większą wagę, nasycone przestają rosnąć.

Cron iteruje do META_POLL_MAX_DEPTH = 1 000 graczy na uruchomienie z miękkim budżetem 270 sekund, by mieścić się w maxDuration 300 s funkcji serverless. Każda odpowiedź zawiera blok diagnostyczny "adaptive" z liczbą iteracji, sprawdzonymi graczami i licznikami per tryb, by anomalie samplera były obserwowalne w produkcji.

Naiwny Win Rate (zwycięstwa / mecze) wprowadza w błąd przy małych próbach: brawler 3-0 na nowej mapie pokazuje "100 % WR" bez znaczenia. BrawlVision używa Bayesian smoothing, by to skorygować i zwracać liczbę porównywalną między brawlerami o bardzo różnych rozmiarach próby.

Wzór: WR_bayesian = (wins + α) / (battles + α + β), gdzie α i β to hiperparametry kodujące wcześniejsze przekonanie wyśrodkowane na 50 % WR. W praktyce α = β = 25, równoważne "załóż 50 wcześniejszych walk 50/50 zanim zobaczysz prawdziwe dane". Brawler z 3 wins i 0 losses przechodzi z naiwnego 100 % na (3 + 25) / (3 + 50) = 52,8 %, znacznie bardziej reprezentatywne dla rzeczywistego stanu próbkowania.

Wraz ze wzrostem próby waga prior​a spada: przy 1 000 walk i 530 wins WR bayesowski wynosi (530 + 25) / (1 000 + 50) = 52,9 %, niemal identycznie jak naiwne 53,0 %. Smoothing "boli" tylko wtedy, gdy próba jest naprawdę mała. To dokładnie pożądana właściwość: karać szum, nie sygnał.

Comfort Score to wewnętrzna metryka BrawlVision odpowiadająca na pytanie "z którym brawlerem grasz naprawdę lepiej niż średnia?". To nie jest czysty Win Rate: łączy trzy komponenty z wagami 60/30/10, pokrywając różne wymiary osobistej formy.

Główny komponent (60 %) to WR gracza z tym brawlerem, wygładzony bayesowsko jak meta globalna, by rzadko grany brawler nie zawyżał rankingu. Komponent średni (30 %) to różnica między tym osobistym WR a metą WR brawlera ogółem: gracz z 55 % na SHELLY przy globalnej mecie 48 % zyskuje więcej comfort niż gracz z 55 % na brawlerze z metą 53 %, bo względny lift jest większy.

Komponent końcowy (10 %) to znormalizowana częstość użycia: przy reszcie równej granie brawlerem 100 razy waży więcej niż 10, bo konsystencja jest nagradzana. Dokładne wzory i wagi żyją w src/lib/analytics/compute.ts i są stosowane identycznie przy każdym wywołaniu endpointa, by ranking był powtarzalny.

Każdy publiczny brawler ma wskaźnik trendu "+X,Y%" lub "−X,Y%", który mierzy, jak jego meta WR zmienił się w ciągu ostatnich 7 dni względem poprzednich 7 (łącznie okno 14 dni). Obliczenie działa na source=global z minimum MIN_BATTLES_PER_TREND_WINDOW = 3 walk w każdej połowie okna — jeśli któraś z połówek jest poniżej progu, zwracamy null i UI ukrywa strzałkę zamiast wymyślać liczbę o słabym sygnale.

Trend jest preliczany co sześć godzin w małej tabeli (public.brawler_trends, jeden wiersz na brawlera) przez job pg_cron. Robienie tego w bazie zamiast w odpowiedzi endpointa unika skanowania dziesiątek tysięcy wierszy 14-dniowego wycinka przy każdym odświeżeniu ISR. Jeśli prelliczona tabela jest starsza niż 12 godzin lub pusta, endpoint przechodzi na paginowaną trasę inline po meta_stats, która zwraca tę samą odpowiedź wyższym kosztem. Paginacja jest konieczna, bo PostgREST cicho ucina niepaginowane zapytania do 1 000 wierszy, co kiedyś sprawiło, że większość brawlerów zwracała null z fałszywego niedopróbkowania.

Logika żyje zduplikowana z premedytacją: wersja TypeScript w src/lib/brawler-detail/trend.ts (trasa szczegółów) i wersja SQL w supabase/migrations/022_*.sql (trasa zbiorcza). Obie używają tego samego progu, tego samego okna i tego samego filtru source=global. Jeśli się rozjadą, strona pojedynczego brawlera i strona zbiorcza pokażą różne liczby dla tego samego brawlera, więc każda zmiana idzie w obie.

Jak często dane się odświeżają wpływa na ich interpretację, więc dokumentujemy to wprost. Strony statyczne (w tym ta) używają ISR (Incremental Static Regeneration) z rewalidacją co 24 godziny. Strony z danymi dynamicznymi cache​ują odpowiedź API, dopóki odpowiedni job jej nie unieważni.

Brawlerzy, gadżety i star powery synchronizują się z API Supercella z 24-godzinnym cache serwera. Meta-poll (dane PRO) działa co 6 godzin i produkuje świeże wiersze meta_stats. Preliczanie trendów 7d działa w pg_cron na "17 */6 * * *" (minuta 17 co szóstej godziny), by nie kolidować z meta-poll. Rotacja eventów w grze odświeża się co 30 minut.

Pojedyncze walki użytkowników premium z włączoną sync są pobierane zaraz po każdym meczu w przesuwanym oknie przez cron sync. Po dotarciu do naszej bazy zasilają meta_stats z source=user i są podstawą prywatnych analiz w sekcji profilu; nigdy nie pojawiają się w agregatach publicznych i nigdy nie mieszają z source=global.