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, gwiezdne moce, hiperdoładowania, wyposażenie 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 podzielone przez mecze) myli, gdy meczów jest mało. Brawler z 3 zwycięstwami i 0 porażek na nowej mapie świeci wynikiem 100%, który nic nie znaczy. BrawlVision stosuje wygładzanie bayesowskie, żeby poprawić to zniekształcenie i zwrócić liczbę porównywalną między brawlerami o bardzo różnych próbach.

Wzór to WR_bayesian = (zwycięstwa + α·μ) / (bitwy + α). Parametr α waży, ile wyobrażonych meczów dokładamy, a μ to wynik, który im przypisujemy. Używamy α = 30, co odpowiada dodaniu 30 wcześniejszych bitew przed spojrzeniem na prawdziwe dane.

Do września 2026 te wyobrażone mecze były warte 50% i była to błędna wartość. Nasza tabela przechowuje jeden wiersz na bitwę, wiersz sondowanego gracza, który należy do top 200 swojego kraju i wygrywa 71,4% swoich meczów (61 400 zwycięstw na 85 970 bitew w oknie 14 dni, zmierzone 7 września 2026). Ściąganie ku 50% danych wyśrodkowanych na 71,4% ciągnęło w dół każdą komórkę z niewielką liczbą meczów, a im mniejsza była próba, tym mocniej. Dziś μ wynosi 0,714, czyli tyle, ile zmierzyliśmy.

Waga rozkładu a priori maleje wraz ze wzrostem próby. Przy 1000 bitew i 530 zwycięstwach wynik wypada na (530 + 21,42) / 1030 = 53,5%, bardzo blisko surowych 53,0%. Przy 3 bitwach i 3 zwycięstwach wypada na 74,0% zamiast naiwnych 100%. Wygładzanie waży tylko wtedy, gdy próba jest naprawdę mała.

Win Rate, który publikujemy, miesza dwie rzeczy. Jedną jest to, jak dobry jest brawler, drugą to, na kogo trafiał. Brawler, który pojawia się głównie w korzystnych starciach, wychodzi wysoko, choć niewiele to mówi o jego zestawie umiejętności. Skorygowana siła rozdziela obie rzeczy i szacuje, jak często ten brawler wygrywałby przeciwko przeciwnikowi o średnim poziomie.

Obliczenie to model Bradley-Terry dopasowany metodą MM na tabeli starć z ostatnich 14 dni. Każda para brawlerów jest symetryzowana przed wejściem do dopasowania, ponieważ nasze wiersze zapisujemy zawsze od strony sondowanego gracza, a ta strona ma przewagę. Mierzone na parach z co najmniej 30 pojedynkami w każdą stronę, Win Rate A przeciwko B dodany do Win Rate B przeciwko A daje medianę 138%, podczas gdy dane symetryczne dałyby 100%. Przy liczeniu każdego pojedynku raz z każdej strony ta przewaga wchodzi na korzyść obu i znosi się. Wynik publikujemy jako oczekiwany Win Rate przeciwko medianowemu brawlerowi z dopasowania, więc w tej skali 50% oznacza remis.

Liczba odejmuje skład przeciwników i średnią przewagę próbkowania. Nie odejmuje tego, kto gra danym brawlerem. Ani meta_stats, ani meta_matchups nie przechowuje identyfikatora gracza, więc odjęcie poziomu grającego jest niemożliwe przy danych, które mamy; trzeba by zapisywać ranking sondowanego gracza w momencie pobrania. Dlatego listy w serwisie nadal porządkujemy według obserwowanego Win Rate, a siła stoi obok. I dlatego też obserwowany Win Rate wynosi około 72%, a nie 50%. Próbę stanowią mecze graczy z top 200 z jedenastu krajów, którzy wygrywają blisko 72% rozegranych spotkań, więc w tej skali 72% opisuje zwyczajnego brawlera. Siłę publikujemy tylko dla brawlerów z co najmniej 400 zapisanymi pojedynkami przeciwko 20 różnym przeciwnikom; poniżej tego progu pomijamy liczbę zamiast pokazywać wartość, która się nie broni.

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 gwiezdne moce 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.