Wie wir jede Statistik aufbauen

Alles, was wir anzeigen, kommt aus drei Quellen, die wir prüfbar halten: die öffentliche Supercell-API (developer.brawlstars.com), das Brawlify-CDN (cdn.brawlify.com) und unsere eigene Supabase-Datenbank, die Kämpfe und Aggregate persistiert, die die offizielle API jenseits der letzten 25 Matches pro Spieler nicht offenlegt.

Die Supercell-API ist die kanonische Quelle für strukturelle Daten — Brawler, Gadgets, Star Powers, Hypercharges, Gears und Event-Rotation — lässt aber kritische Felder wie Brawler-Bilder, Seltenheit und lange Beschreibungen aus. Diese Felder kreuzen wir mit dem Brawlify-CDN, das unabhängig läuft und manchmal ein bis drei Tage hinter Supercell hinterherhinkt. Wenn ein neuer Brawler in der offiziellen API auftaucht, der bei Brawlify noch nicht existiert, halten wir eine lokale Seltenheits-Map (BRAWLER_RARITY_MAP), damit die Brawler-Seite am Launch-Tag korrekt rendert.

Unsere Datenbank speichert zwei Klassen von Zeilen in meta_stats: source=user (echte Kämpfe von Premium-Nutzern, die Sync aktiviert haben) und source=global (automatisches Sampling der Top-PRO-Ranglisten). Jede öffentliche Statistik wird mit Filter source=global berechnet, damit persönliche Daten einzelner Nutzer niemals in öffentliche Seiten lecken.

Die "PRO"-Schicht von BrawlVision sind Aggregate über aktuelle Kämpfe der besten Spieler weltweit. Alle sechs Stunden befragt ein Cron-Job (meta-poll) die offiziellen Supercell-Ranglisten für elf Länder — die mit der konzentriertesten Wettkampfaktivität — und baut eine deduplizierte Pool von etwa 2.100 einzigartigen Spielern aus jedem Top 200.

Auf dieser Pool wenden wir einen probabilistischen Sampler an, damit beliebte (Map, Modus)-Kombinationen den Datensatz nicht dominieren und seltene maskieren. Die Akzeptanzwahrscheinlichkeit eines einzelnen Kampfs ist p = min(1, (minLive + 1) / (current + 1)), wobei minLive die Anzahl der unterrepräsentiertsten Kombination und current die der Kandidaten-Kombination ist. Untersample-Kombinationen bekommen mehr Gewicht, gesättigte hören auf zu wachsen.

Der Cron iteriert bis zu META_POLL_MAX_DEPTH = 1.000 Spieler pro Lauf mit einem weichen 270-Sekunden-Budget, um innerhalb der 300-s maxDuration der Serverless-Funktion zu bleiben. Jede Antwort enthält einen "adaptive"-Diagnoseblock mit Iterationszählern, befragten Spielern und Modi-Counts, damit jedes anomale Sampler-Verhalten in Produktion beobachtbar bleibt.

Die naive Win Rate (Siege / Matches) ist bei kleinen Stichproben irreführend: ein Brawler mit 3-0 auf einer neuen Map zeigt "100 % WR", ohne dass das etwas bedeutet. BrawlVision verwendet Bayesian-Smoothing zur Korrektur und gibt eine Zahl zurück, die zwischen Brawlern mit sehr unterschiedlichen Stichprobengrößen vergleichbar ist.

Die Formel ist WR_bayesian = (wins + α) / (battles + α + β), wobei α und β Hyperparameter sind, die einen 50 %-WR-Prior kodieren. In der Praxis α = β = 25, äquivalent zu "50 vorherige Kämpfe 50/50 annehmen, bevor reale Daten gesehen werden". Ein Brawler mit 3 Siegen und 0 Niederlagen geht von naiv 100 % auf (3 + 25) / (3 + 50) = 52,8 %, viel repräsentativer für den realen Sampling-Stand.

Wenn die Stichprobe wächst, sinkt das Gewicht des Priors: bei 1.000 Kämpfen und 530 Siegen liegt der Bayesian WR bei (530 + 25) / (1.000 + 50) = 52,9 %, nahezu identisch zum naiven 53,0 %. Smoothing "schmerzt" nur, wenn die Stichprobe wirklich klein ist. Genau die gewünschte Eigenschaft: Rauschen bestrafen, nicht Signal.

Comfort Score ist die hauseigene Metrik von BrawlVision für die Frage "mit welchem Brawler spielst du tatsächlich besser als der Durchschnitt?". Es ist keine reine Win Rate: er kombiniert drei Komponenten mit Gewichten 60/30/10 für verschiedene Dimensionen persönlicher Leistung.

Die Hauptkomponente (60 %) ist die Spieler-WR mit diesem Brawler, Bayesian-geglättet wie das Global-Meta, damit ein selten gespielter Brawler das Ranking nicht verzerrt. Die mittlere Komponente (30 %) ist die Differenz zwischen dieser persönlichen WR und der gesamten Meta-WR des Brawlers: ein Spieler bei 55 % auf SHELLY, wenn das Global-Meta bei 48 % liegt, gewinnt mehr Comfort als jemand bei 55 % auf einem Brawler mit Meta 53 %, weil der relative Lift größer ist.

Die letzte Komponente (10 %) ist die normalisierte Nutzungsfrequenz: bei sonst gleichen Bedingungen zählt es mehr, einen Brawler 100 Mal zu spielen als 10 Mal, weil Konstanz belohnt wird. Die genauen Formeln und Gewichte leben in src/lib/analytics/compute.ts und gelten identisch bei jedem Endpoint-Aufruf, damit das Ranking reproduzierbar ist.

Jeder öffentliche Brawler hat einen Trend-Indikator "+X,Y%" oder "−X,Y%", der zeigt, wie sich seine Meta-WR in den letzten 7 Tagen gegenüber den vorherigen 7 verändert hat (insgesamt 14-Tage-Fenster). Die Berechnung läuft auf source=global mit minimal MIN_BATTLES_PER_TREND_WINDOW = 3 Kämpfen pro Fensterhälfte — wenn eine der Hälften unter der Schwelle liegt, geben wir null zurück und die UI versteckt den Pfeil, statt eine schwache Zahl zu erfinden.

Der Trend wird alle sechs Stunden in einer kleinen Tabelle (public.brawler_trends, eine Zeile pro Brawler) per pg_cron-Job vorberechnet. Das in der DB statt in der Endpoint-Antwort zu tun vermeidet, bei jedem ISR-Refresh zehntausende Zeilen des 14-Tage-Slices zu scannen. Wenn die vorberechnete Tabelle älter als 12 Stunden oder leer ist, fällt der Endpoint auf eine paginierte Inline-Route über meta_stats zurück, die dieselbe Antwort zu höheren Kosten liefert. Pagination ist nötig, weil PostgREST nicht-paginierte Queries lautlos auf 1.000 Zeilen kürzt — was einmal die Mehrheit der Brawler null zurückgeben ließ wegen falscher Untersample.

Die Logik existiert dupliziert by design: TypeScript-Version in src/lib/brawler-detail/trend.ts (Detail-Route) und SQL-Version in supabase/migrations/022_*.sql (Bulk-Route). Beide nutzen denselben Schwellenwert, dasselbe Fenster und denselben source=global-Filter. Wenn sie auseinanderlaufen, würden Detail- und Aggregat-Seite verschiedene Zahlen für denselben Brawler zeigen, also wird jede Änderung in beiden angewandt.

Wie oft eine Datenkomponente aktualisiert wird, beeinflusst, wie du sie interpretieren solltest, also dokumentieren wir das explizit. Statische Seiten (diese eingeschlossen) nutzen ISR (Incremental Static Regeneration) mit 24-Stunden-Revalidation. Seiten mit dynamischen Daten cachen die API-Antwort, bis der entsprechende Job sie invalidiert.

Brawler, Gadgets und Star Powers synchronisieren von der Supercell-API mit 24-Stunden-Server-Cache. Der meta-poll (PRO-Daten) läuft alle 6 Stunden und produziert frische meta_stats-Zeilen. Die 7-Tage-Trend-Vorberechnung läuft in pg_cron auf "17 */6 * * *" (Minute 17 jeder sechsten Stunde), um nicht mit dem meta-poll zu kollidieren. Die In-Game-Event-Rotation wird alle 30 Minuten erneuert.

Einzelne Kämpfe von Premium-Nutzern mit aktivierter Sync werden direkt nach jedem Match in einem gleitenden Fenster über den sync-cron heruntergeladen. In unserer DB speisen sie meta_stats mit source=user und sind die Basis privater Analysen im Profilbereich; sie tauchen nie in öffentlichen Aggregaten auf und mischen sich nie mit source=global.