Come costruiamo ogni statistica

Tutto ciò che mostriamo proviene da tre fonti che manteniamo verificabili: l'API pubblica di Supercell (developer.brawlstars.com), il CDN di Brawlify (cdn.brawlify.com) e il nostro database Supabase, che persiste battaglie e aggregati che l'API ufficiale non espone oltre le ultime 25 partite per giocatore.

L'API di Supercell è la fonte canonica per i dati strutturali — brawler, gadget, abilità stellari, overdrive, equipaggiamenti e rotazione eventi — ma omette campi critici come immagini dei brawler, rarità e descrizioni lunghe. Incrociamo questi campi con il CDN di Brawlify, che opera in modo indipendente e a volte ritarda da uno a tre giorni rispetto a Supercell. Quando rileviamo un brawler nuovo nell'API ufficiale che ancora non esiste su Brawlify, manteniamo una mappa locale di rarità (BRAWLER_RARITY_MAP) perché la pagina del brawler renderizzi correttamente al lancio.

Il nostro database memorizza due classi di righe in meta_stats: source=user (battaglie reali di utenti premium che hanno attivato la sync) e source=global (campionamento automatico delle classifiche PRO). Ogni statistica pubblica è calcolata filtrando su source=global, per evitare che dati personali di un singolo utente trapelino nelle pagine pubbliche.

Il livello "PRO" di BrawlVision è un insieme di aggregati calcolati sulle battaglie recenti dei migliori giocatori al mondo. Ogni sei ore un cron job (meta-poll) interroga le classifiche ufficiali di Supercell per undici paesi — quelli che concentrano l'attività competitiva — e costruisce una pool dedduplicata di circa 2.100 giocatori unici dal top 200 di ciascuno.

Su questa pool applichiamo un sampler probabilistico per impedire che le combinazioni (mappa, modalità) popolari dominino il dataset e mascherino quelle rare. La probabilità di accettare una battaglia individuale è p = min(1, (minLive + 1) / (current + 1)), dove minLive è il conteggio della combinazione meno rappresentata e current quello della combinazione candidata. Le combinazioni sotto-campionate ricevono più peso; quelle sature smettono di crescere.

Il cron itera fino a META_POLL_MAX_DEPTH = 1.000 giocatori per esecuzione con budget flessibile di 270 secondi per restare entro il maxDuration di 300 s della funzione serverless. Ogni risposta include un blocco "adaptive" con conteggi di iterazioni, giocatori interrogati e conteggi per modalità, perché qualsiasi comportamento anomalo del sampler resti osservabile in produzione.

Il Win Rate ingenuo (vittorie diviso partite) inganna quando le partite sono poche. Un brawler con 3 vittorie e 0 sconfitte su una mappa nuova sfoggia un 100% che non significa nulla. BrawlVision applica uno smoothing bayesiano per correggere quella distorsione e restituire un numero confrontabile tra brawler con campioni molto diversi.

La formula è WR_bayesiano = (vittorie + α·μ) / (battaglie + α). Il parametro α pesa quante partite immaginarie aggiungiamo e μ è il risultato che assegniamo loro. Usiamo α = 30, che equivale a sommare 30 battaglie precedenti prima di guardare i dati reali.

Fino a settembre 2026 quelle partite immaginarie valevano il 50%, ed era il valore sbagliato. La nostra tabella conserva una sola riga per battaglia, quella del giocatore sondato, che appartiene alla top 200 del suo paese e vince il 71,4% delle sue partite (61.400 vittorie su 85.970 battaglie nella finestra di 14 giorni, misurato il 7 settembre 2026). Restringere verso il 50% dati centrati sul 71,4% trascinava verso il basso qualunque casella con poche partite, e più piccolo era il campione, più la trascinava. Oggi μ vale 0,714, la base che abbiamo misurato.

Il peso del prior cala man mano che il campione cresce. Con 1.000 battaglie e 530 vittorie il risultato resta a (530 + 21,42) / 1.030 = 53,5%, molto vicino al 53,0% grezzo. Con 3 battaglie e 3 vittorie resta a 74,0% invece del 100% ingenuo. Lo smoothing pesa solo quando il campione è davvero piccolo.

Il Win Rate che pubblichiamo mescola due cose. Una è quanto è forte un brawler, l’altra è contro chi gli è capitato di giocare. Un brawler che compare soprattutto in scontri favorevoli esce in alto senza che questo dica molto del suo kit. La forza depurata separa le due cose e stima quanto spesso quel brawler vincerebbe contro un avversario di livello medio.

Il calcolo è un modello Bradley-Terry stimato con MM sulla tabella degli scontri degli ultimi 14 giorni. Ogni coppia di brawler viene simmetrizzata prima di entrare nella stima, perché le nostre righe si registrano sempre dal lato del giocatore sondato e quel lato parte in vantaggio. Misurato sulle coppie con almeno 30 duelli in ciascuna direzione, il Win Rate di A contro B sommato a quello di B contro A dà una mediana del 138%, dove un dato simmetrico darebbe 100%. Contando ogni duello una volta da ciascun lato, quel vantaggio entra a favore di entrambi e si annulla. Il risultato si pubblica come Win Rate atteso contro il brawler mediano della stima, quindi su questa scala il 50% è il pareggio.

La cifra depura la composizione degli avversari e il vantaggio medio del campionamento. Non depura chi usa il brawler. Né meta_stats né meta_matchups conservano un identificatore di giocatore, quindi sottrarre il livello di chi gioca è impossibile con i dati che abbiamo; servirebbe registrare la classifica del giocatore sondato al momento dell’acquisizione. Per questo le liste del sito restano ordinate per Win Rate osservato e la forza sta accanto. Ed è sempre per questo che il Win Rate osservato si aggira sul 72% e non sul 50%. Il campione è composto da partite di giocatori della top 200 di undici paesi, che vincono circa il 72% di quelle che giocano, per cui su quella scala un 72% descrive un brawler qualunque. Pubblichiamo la forza solo dei brawler con almeno 400 duelli registrati contro 20 avversari diversi; sotto quella soglia omettiamo la cifra invece di mostrare un numero che non regge.

Il Comfort Score è la metrica interna di BrawlVision per rispondere "con quale brawler giochi davvero meglio della media?". Non è un Win Rate puro: combina tre componenti con pesi 60/30/10 per coprire dimensioni diverse della performance personale.

La componente principale (60 %) è il WR del giocatore con quel brawler, smoothed bayesianamente come il meta globale, perché un brawler giocato di rado non distorca il ranking. La componente intermedia (30 %) è la differenza tra questo WR personale e il WR meta del brawler in generale: un giocatore al 55 % su SHELLY quando il meta globale è al 48 % guadagna più comfort di uno al 55 % su un brawler con meta 53 %, perché il guadagno relativo è maggiore.

La componente finale (10 %) è la frequenza d'uso normalizzata: a parità di tutto il resto, giocare un brawler 100 volte conta più che 10, perché la coerenza viene premiata. Le formule esatte e i pesi vivono in src/lib/analytics/compute.ts e si applicano identicamente a ogni chiamata di endpoint, perché il ranking sia riproducibile.

Ogni brawler pubblico ha un indicatore di tendenza "+X,Y%" o "−X,Y%" che misura come il suo WR meta è cambiato negli ultimi 7 giorni rispetto ai 7 precedenti (finestra totale di 14 giorni). Il calcolo gira su source=global con un minimo di MIN_BATTLES_PER_TREND_WINDOW = 3 battaglie in ciascuna metà della finestra — se una delle due metà non raggiunge la soglia, restituiamo null e l'UI nasconde la freccia invece di inventare un numero a basso segnale.

La tendenza è precalcolata ogni sei ore in una piccola tabella (public.brawler_trends, una riga per brawler) tramite un job pg_cron. Farlo nel database — invece che nella risposta dell'endpoint — evita di scansionare decine di migliaia di righe della finestra 14 giorni a ogni refresh ISR. Se la tabella precalcolata è vecchia più di 12 ore o vuota, l'endpoint cade su una rotta inline paginata su meta_stats che restituisce la stessa risposta a costo maggiore. La paginazione è necessaria perché PostgREST tronca silenziosamente le query non paginate a 1.000 righe, cosa che una volta ha fatto ritornare null alla maggior parte dei brawler per falsa sotto-campionatura.

La logica vive duplicata by design: una versione TypeScript in src/lib/brawler-detail/trend.ts (rotta dettaglio) e una SQL in supabase/migrations/022_*.sql (rotta bulk). Entrambe usano la stessa soglia, la stessa finestra e lo stesso filtro source=global. Se divergessero, la pagina individuale e quella aggregata mostrerebbero numeri diversi per lo stesso brawler, quindi ogni cambio si applica a entrambe.

Quanto spesso un dato si aggiorna influenza come interpretarlo, quindi lo documentiamo esplicitamente. Le pagine statiche (questa inclusa) usano ISR (Incremental Static Regeneration) con revalidazione di 24 ore. Le pagine con dati dinamici cachano la risposta dell'API finché il job rilevante non la invalida.

Brawler, gadget e abilità stellari si sincronizzano dall'API Supercell con cache server di 24 ore. Il meta-poll (dati PRO) gira ogni 6 ore e produce righe meta_stats fresche. La precomputazione delle tendenze 7d gira in pg_cron a "17 */6 * * *" (minuto 17 di ogni sesta ora) per non scontrarsi con il meta-poll. La rotazione eventi in-game si rinfresca ogni 30 minuti.

Le battaglie individuali di utenti premium con sync attiva sono scaricate subito dopo ogni partita in una finestra mobile via cron di sync. Una volta nel nostro database, alimentano meta_stats con source=user e sono la base delle analisi private nella sezione profilo; non appaiono mai in aggregati pubblici e non si mescolano mai a source=global.