Cómo construimos cada estadística que ves

Toda la información que mostramos viene de tres fuentes que mantenemos auditables: la API pública de Supercell (developer.brawlstars.com), la CDN de Brawlify (cdn.brawlify.com) y nuestra propia base de datos en Supabase, que persiste batallas y agregados que la API oficial no expone más allá de las últimas 25 partidas por jugador.

La API de Supercell es la fuente canónica para la información estructural —brawlers, gadgets, star powers, hypercharges, gears y rotación de eventos— pero deja fuera elementos críticos como las imágenes de los brawlers, la rareza y las descripciones largas. Para esos campos cruzamos con la CDN de Brawlify, que opera independientemente y a veces se actualiza con un retraso de uno a tres días respecto a Supercell. Cuando detectamos un brawler nuevo en la API oficial que aún no existe en Brawlify, mantenemos un mapa local de rareza (BRAWLER_RARITY_MAP) para que la página del brawler se sirva igual el día del lanzamiento.

Nuestra base de datos guarda dos clases de filas en la tabla meta_stats: source=user (batallas reales de usuarios premium que activaron sincronización) y source=global (muestreo automático de los rankings de top jugadores PRO). Toda estadística pública que ves en el sitio se calcula filtrando por source=global, para que no se filtre información personal de un usuario individual hacia las páginas públicas.

La capa "PRO" de BrawlVision son agregados calculados sobre las batallas recientes de los mejores jugadores del mundo. Cada seis horas, un cron job (meta-poll) consulta los rankings oficiales de Supercell para once países —los que concentran la actividad competitiva— y construye una pool deduplicada de aproximadamente 2 100 jugadores únicos del top-200 de cada uno.

Sobre esa pool aplicamos un sampler probabilístico para evitar que las combinaciones (mapa, modo) más populares dominen el dataset y enmascaren a las menos frecuentes. La probabilidad de aceptar una batalla individual es p = min(1, (minLive + 1) / (current + 1)), donde minLive es el número actual de batallas registradas en la combinación con menos representación y current es el número en la combinación de la batalla candidata. Las combinaciones poco vistas reciben más peso, y las saturadas dejan de crecer.

El cron itera hasta META_POLL_MAX_DEPTH = 1000 jugadores por ejecución con un presupuesto blando de 270 segundos para no exceder el maxDuration de 300 s de la función serverless. Cada respuesta del endpoint incluye un bloque "adaptive" con métricas de iteraciones, jugadores consultados y conteos por modo, para que cualquier comportamiento anómalo del sampler quede observable en producción.

El Win Rate ingenuo (victorias / partidas) es engañoso cuando hay pocas partidas: un brawler con 3-0 en un mapa nuevo tiene "100 % WR" sin que eso signifique nada. BrawlVision usa Bayesian smoothing para corregir esa distorsión y devolver un número que se pueda comparar entre brawlers con muestras muy distintas.

La fórmula es WR_bayesian = (wins + α) / (battles + α + β), donde α y β son hiperparámetros que codifican una creencia previa centrada en 50 % de WR. En la práctica, α = β = 25, lo que equivale a "asumir 50 batallas previas con resultado 50/50 antes de ver datos". Un brawler con 3 wins y 0 losses pasa de 100 % naive a (3 + 25) / (3 + 50) = 52.8 %, que es mucho más representativo del estado real del muestreo.

A medida que la muestra crece, el peso del prior decae: con 1 000 batallas y 530 wins, el WR bayesiano queda en (530 + 25) / (1 000 + 50) = 52.9 %, prácticamente idéntico al naive 53.0 %. El smoothing solo "duele" cuando la muestra es genuinamente pequeña. Esa es exactamente la propiedad deseada: penalizar el ruido, no la señal.

El Comfort Score es el indicador propio de BrawlVision para responder a la pregunta "¿con qué brawler juegas mejor que con la media?". No es un Win Rate puro: combina tres componentes con pesos 60/30/10 para cubrir distintas dimensiones del rendimiento personal.

El componente principal (60 %) es el WR del jugador con ese brawler, ajustado por Bayesian smoothing igual que el meta global, para que un brawler jugado pocas veces no domine el ranking. El componente intermedio (30 %) es la diferencia entre ese WR personal y el WR meta del brawler en general: un jugador con 55 % en SHELLY cuando el meta global está en 48 % gana más comfort que uno que tiene 55 % en un brawler con 53 % de meta, porque la mejora relativa es mayor.

El componente final (10 %) es la frecuencia de uso normalizada: a igualdad del resto, jugar un brawler 100 veces vale más que jugarlo 10, porque la consistencia se valora. Las fórmulas exactas y los pesos viven en src/lib/analytics/compute.ts y se aplican igual en cada llamada al endpoint, para que el ranking sea reproducible.

Cada brawler público tiene un indicador de tendencia "+X.Y%" o "−X.Y%" que mide cómo ha cambiado su WR meta en los últimos 7 días respecto a los 7 anteriores (una ventana de 14 días en total). El cálculo se hace sobre source=global, con un mínimo de MIN_BATTLES_PER_TREND_WINDOW = 3 batallas en cada mitad de la ventana —si una de las dos mitades no llega al umbral, devolvemos null y la UI no muestra flecha, en lugar de inventar un número con poca señal.

La tendencia se precomputa cada seis horas en una tabla pequeña (public.brawler_trends, una fila por brawler) mediante un job pg_cron. Hacerlo en la base de datos —y no en la respuesta del endpoint— evita escanear las decenas de miles de filas del slice de 14 días en cada ISR refresh. Si la tabla precomputada lleva más de 12 horas sin actualizarse o si está vacía, el endpoint cae en una ruta inline paginada sobre meta_stats que da la misma respuesta a costa de ser más lenta. La paginación es necesaria porque PostgREST trunca silenciosamente las queries no paginadas a 1 000 filas, lo que en su día provocó que la mayoría de brawlers retornaran null por falsa insuficiencia de muestra.

La lógica vive duplicada por diseño: una versión TypeScript en src/lib/brawler-detail/trend.ts (ruta de detalle) y una versión SQL en supabase/migrations/022_*.sql (ruta bulk). Ambas usan el mismo umbral, la misma ventana y el mismo filtro source=global. Si en algún momento divergen, la página individual del brawler y la página agregada darían números distintos para el mismo brawler, así que cualquier cambio se aplica en las dos.

La cadencia con la que se refresca cada dato influye en cómo lo interpretas, así que la documentamos explícitamente. Las paginas estáticas (incluida esta) usan ISR (Incremental Static Regeneration) con revalidación cada 24 horas. Las páginas con datos dinámicos cachean la respuesta del API hasta que el job correspondiente la invalida.

Los brawlers, gadgets y star powers se sincronizan desde la API de Supercell con un cache de servidor de 24 horas. El meta-poll (datos PRO) ejecuta cada 6 horas y produce filas frescas en meta_stats. La precomputación de tendencias 7d corre en pg_cron a "17 */6 * * *" (los minutos 17 de cada sexta hora) para no chocar con el meta-poll. La rotación de eventos del juego se refresca cada 30 minutos.

Las batallas individuales de usuarios premium que activan sincronización se descargan inmediatamente después de cada partida en una ventana móvil, gracias al cron de sync. Una vez en nuestra base, contribuyen a meta_stats con source=user y son la base de los análisis privados de la sección de perfil; nunca aparecen en agregados públicos ni se mezclan con source=global.