How we build every stat you see

Everything we display comes from three sources we keep auditable: Supercell's public API (developer.brawlstars.com), the Brawlify CDN (cdn.brawlify.com), and our own Supabase database, which persists battles and aggregates that the official API doesn't expose past the last 25 matches per player.

Supercell's API is the canonical source for structural data — brawlers, gadgets, star powers, hypercharges, gears and event rotation — but it leaves out critical fields like brawler images, rarity, and long descriptions. We cross-reference those with the Brawlify CDN, which operates independently and sometimes lags Supercell by one to three days. When we detect a new brawler on the official API that doesn't exist on Brawlify yet, we keep a local rarity map (BRAWLER_RARITY_MAP) so the brawler's page renders correctly on launch day.

Our database stores two classes of rows in the meta_stats table: source=user (real battles from premium users who enabled sync) and source=global (automated sampling from the top PRO leaderboards). Every public statistic on the site is computed filtering by source=global, so personal data from any single user never leaks into public pages.

The "PRO" layer of BrawlVision is a set of aggregates computed over recent battles from the world's top players. Every six hours a cron job (meta-poll) queries Supercell's official rankings for eleven countries — the ones that concentrate competitive activity — and builds a deduplicated pool of roughly 2,100 unique players from each top 200.

Over that pool we apply a probabilistic sampler to keep popular (map, mode) combinations from dominating the dataset and masking the rare ones. The probability of accepting an individual battle is p = min(1, (minLive + 1) / (current + 1)), where minLive is the count for the least-represented combination and current is the count for the candidate battle's combination. Under-sampled combinations get higher acceptance; saturated ones stop growing.

The cron iterates up to META_POLL_MAX_DEPTH = 1,000 players per run with a soft 270-second budget so it stays inside the serverless function's 300-second maxDuration. Each response includes an "adaptive" diagnostic block with iteration counts, players sampled, and per-mode counts, so any anomalous sampler behavior is observable in production.

Naive Win Rate (wins / matches) is misleading on small samples: a brawler going 3-0 on a new map shows "100 % WR" without that meaning anything. BrawlVision uses Bayesian smoothing to correct that and return a number that is comparable across brawlers with very different sample sizes.

The formula is WR_bayesian = (wins + α) / (battles + α + β), where α and β are hyperparameters encoding a 50 %-WR prior. In practice α = β = 25, equivalent to "assume 50 prior battles split 50/50 before seeing real data". A brawler with 3 wins and 0 losses goes from naive 100 % to (3 + 25) / (3 + 50) = 52.8 %, much more representative of the actual sampling state.

As the sample grows, the prior's weight decays: with 1,000 battles and 530 wins, the Bayesian WR sits at (530 + 25) / (1,000 + 50) = 52.9 %, essentially identical to the naive 53.0 %. Smoothing only "hurts" when the sample is genuinely small. That is exactly the desired property: penalize noise, not signal.

Comfort Score is BrawlVision's in-house metric answering the question "which brawler are you actually better with than with average?". It is not a raw Win Rate: it combines three components with weights 60/30/10 to cover different dimensions of personal performance.

The main component (60 %) is the player's WR with that brawler, Bayesian-smoothed exactly like the global meta, so a rarely-played brawler doesn't game the ranking. The middle component (30 %) is the difference between that personal WR and the brawler's overall meta WR: a player at 55 % on SHELLY when the global meta sits at 48 % earns more comfort than someone at 55 % on a brawler whose meta is 53 %, because the relative lift is bigger.

The final component (10 %) is normalized usage frequency: all else equal, playing a brawler 100 times counts more than playing it 10, because consistency is rewarded. The exact formulas and weights live in src/lib/analytics/compute.ts and apply identically on every endpoint call, so the ranking is reproducible.

Every public brawler has a "+X.Y%" or "−X.Y%" trend indicator showing how its meta WR has changed in the last 7 days versus the previous 7 (a 14-day window total). The computation runs on source=global with a minimum of MIN_BATTLES_PER_TREND_WINDOW = 3 battles in each half of the window — if either half is below the threshold, we return null and the UI hides the arrow rather than fabricating a low-signal number.

The trend is precomputed every six hours in a small table (public.brawler_trends, one row per brawler) by a pg_cron job. Doing it in the database — instead of in the endpoint response — avoids scanning tens of thousands of rows in the 14-day slice on every ISR refresh. If the precomputed table is more than 12 hours old or empty, the endpoint falls through to a paginated inline route over meta_stats that returns the same answer at a higher cost. Pagination is required because PostgREST silently truncates non-paginated queries to 1,000 rows, which once caused most brawlers to return null due to fake undersampling.

The logic lives duplicated by design: a TypeScript version in src/lib/brawler-detail/trend.ts (detail route) and a SQL version in supabase/migrations/022_*.sql (bulk route). Both use the same threshold, the same window and the same source=global filter. If they ever diverge, the per-brawler detail page and the aggregate page would show different numbers for the same brawler, so any change is applied in both.

How often a piece of data refreshes affects how you should interpret it, so we document it explicitly. Static pages (this one included) use ISR (Incremental Static Regeneration) with a 24-hour revalidation. Pages with dynamic data cache the API response until the relevant job invalidates it.

Brawlers, gadgets and star powers sync from the Supercell API with a 24-hour server cache. The meta-poll (PRO data) runs every 6 hours and produces fresh meta_stats rows. The 7-day trend precomputation runs in pg_cron at "17 */6 * * *" (minute 17 of every sixth hour) to avoid colliding with the meta-poll. The in-game event rotation refreshes every 30 minutes.

Individual battles from premium users who enabled sync are downloaded right after each match in a moving window via the sync cron. Once in our database they feed meta_stats with source=user and are the basis for private analytics in the profile section; they never appear in public aggregates and never mix with source=global.