The Data

Deduped and analysis-ready: date, mode, map, player, primary hero + role, result, K/D/A, damage, healing, MVP/SVP. Humans only, best source per game (full lobby detail where we have it, feed otherwise).

Everything, raw: matches, match_players (incl. bots), hero_lines (per-hero playtime within each game), rank_seasons, players. Claude Code and Claude desktop can query SQLite directly.

Every account's rank arc across seasons (peak tier + rank score). Cross-platform ranks are separate ladders — compare with care.

• Bots are excluded from all player stats (is_bot=1 rows exist in the DB — filter them, or use games.csv which already did).
• Draws are neutral, on every page (Alan's motion, ratified 7/21/26; applied site-wide 8/1/26 — before that date only the Hero Lab used it, so older screenshots of the main site read ~3-4 points lower): win rate = wins ÷ (wins + losses); draws stay visible in W-L-D records but don't count against you. Per-game rates are different on purpose — kills/game, MVP rate and attendance still divide by every game played, because a draw is still a game you turned up for. In odds math (±EXP on the Hero Lab) a draw scores half a win — Elo standard. Don't silently drop draws from the record itself — a prior version of our numbers was ~7 points wrong from mishandling them.
• Dedupe by source. In the raw DB most games have TWO rows per player (source='lobby' and source='feed'). Lobby is authoritative (full stats); feed only for kills/deaths/result. Never sum across both — games.csv has already picked one per game.
• Primary hero = most playtime that game (from hero_lines), never the hero someone ended on. Feed-only games fall back to the first hero listed.
• Feed-only games: 12 right now, out of 688 customs. A feed-only game carries real teams, results and K/D — so it counts in records, Elo, the odds ledger and the strength model — but has no damage, healing or per-hero playtime, because the match-detail API (rivalsmeta, a live NetEase proxy) hadn't served that match when we harvested. A retry job backfills them; blank cells are missing data, never zeros. When this number is 0, every custom on record has full 12-player detail.
• team is a within-match label only. Lobby rows use 1/2, feed rows use tracker's 0/1 — either way it just groups teammates inside one match; team numbers mean nothing across matches or sources.
• Custom games = mode='custom-game'. The 10 free-for-all matches are excluded from every per-player stat, not just win rates — games played, K/D, kills/game, MVP and SVP totals all skip them, because an FFA scores the winner's team as a win and everyone else as a draw, which would quietly inflate draw counts and deflate losses. Consequence to know: the site headline says 688 customs but no individual's games-played can exceed 678, and a couple of MVP totals are lower than a raw DB query returns (Donovan 4 rather than 6).
• Two different date ranges live on this site at once. Records, win rates, Elo, arcs and the odds ledger run through the newest night. Anything hero-level — the tier list, per-hero win rates, damage/heal per 10, role splits, the Role Rooms — stops at the last night we have full 12-player detail for (meta.detailThrough). Right now those two dates are the same night (2026-08-21), so the gap is zero and the two windows agree — but check this number rather than assuming, because the gap reopens any week the match-detail API lags. Don't compare a player's "last 90 days" record against their "last 90 days" Iron Man numbers and expect the same denominator.
• 40-bomb totals count every 40-kill game; the per-hero breakdown can't. A game needs hero detail to attribute the bomb to a hero, so the by-hero table can cover fewer bombs than the total (currently 12 customs lack hero detail, so the gap is that small). The totals are the honest number; the hero split is indicative.
• Void lobbies are quarantined (rule added 7/29/26): 6 matches recorded zero activity — not one kill, death or assist across every row — because the lobby aborted or was re-hosted, yet the game still handed out a match id and a result. Five lasted 1–12 seconds with a full 9-player lobby; one was a 258-second solo. They're re-labelled mode='void-lobby', so they're excluded from every stat but still auditable. Single-player customs with real stats are kept — the test is activity, not headcount.
• Win rate ≠ skill. Teams are deliberately balanced every week, so raw win rates carry teammate bias — that's why the site rates skill with Elo, four lenses, and (since 8/1/26) the strength model described below, never win% on its own.

We pick the teams every week, and we pick them to be fair. That quietly breaks win rate: balance a weaker player onto a strong side and their win% climbs toward 50, split the best players apart and theirs falls toward 50. Everyone converges on 50% and the number stops measuring the player. Pair ("chemistry") win rates are worse, because who you're paired with is exactly the thing being chosen.

So the site also publishes data/strength.json — one rating per player from a Bradley-Terry model (ridge-penalised logistic regression, the same family as chess ratings, generalised to teams) fit across every decisive custom at once. Each player's rating is estimated in the presence of their teammates and their opponents, so placement cancels out. It also composes, which means it can price a line-up that has never been played.

Fields: strength (points, 0 = lobby average), lo/hi (90% bootstrap range), trueWin (win% if we swapped an average player for this one), rawWin (plain win rate), bias (rawWin − trueWin: positive = the balancer has been flattering you). Also current (a recent-form rating, null when someone has too few recent games — that is an honest "unranked", not a zero), recentGames, halfLife/ridge/calShrink (the fitted hyperparameters — confidence is shrunk because the raw model overstates blowouts), regimeEqual/regimeUneven/regimePooled (accuracy and forward log-loss split by even vs bot-padded lobbies, where 0.693 is a coin flip and lower is better), and caveats — the model stating its own limits in plain English, including where it has no discrimination at all. Built by data/strength_model.py. Group beliefs about never-played comps live in that script's priors.json alongside it in the repo (not published here, since it is an input rather than a result).

Paste this prompt with the CSV (or point Claude Code at the URLs) and it inherits our conventions instead of re-learning our old bugs:

I'm analyzing my friend group's Marvel Rivals data from marvelgooners.com/data/ (games.csv; full SQLite at rivals.db).
Rules the numbers must follow:
- One row per player per game (already deduped). mode='custom-game' = our Friday customs; 'competitive' = solo ranked; exclude other modes unless asked.
- Win rate = wins / (wins+losses). Draws are NEUTRAL (excluded from the denominator, but report them in records as W-L-D). Per-game rates (kills/game, MVP rate, attendance) DO include draws.
- Teams were deliberately balanced, so win rate is confounded by placement — if you want player strength, fit a Bradley-Terry model on team compositions rather than averaging win rates.
- Blank damage/healing = missing lobby detail (newest games), NOT zero — exclude those games from damage/heal averages.
- primary_hero is playtime-based. hero_role: Tank / DPS / Healer.
- Win rate is a TEAM outcome (teams are re-balanced weekly to be fair) — don't present it as individual skill without saying so.
- Cross-platform ranked ladders aren't comparable (PC and console queue separately).
Sanity anchors to verify your load: 688 custom games, 18 tracked players, record runs 2025-02-09 → 2026-08-27.

• "What's my win rate by hero, minimum 10 games, customs only?"
• "Which map do I win most on, and does it depend on my role?"
• "Build my form curve — rolling 30-game win rate over time."
• "When X and Y are on the same team, who else being there changes the result most?"
• "Re-derive the site's tank tier list and tell me if Cap is really 3rd."