How we approach living game data

The hardest thing about game data is not collecting it. It is that the thing you measured yesterday may not exist today.

A balance patch changes a number. A seasonal rotation swaps a map out. An event adds an item and removes it three weeks later. A developer silently adjusts a drop rate and mentions it in no patch notes at all. Any of these can turn an accurate page into a misleading one without anybody touching the page.

Every fact has a version

The single most useful discipline is refusing to store a fact without also storing what it was true of. A statistic is not "this brawler wins 54% of matches" — it is "this brawler won 54% of matches, in this mode, in this rank band, over this window, on this game version." Strip any of that away and you have a number that will eventually be quoted back in a context where it is wrong.

This has consequences for how the underlying systems are built. Game version belongs in the data model, not in a footnote. Recomputing after a patch has to be a routine operation rather than a manual scramble. And when a patch invalidates a dataset, the honest thing to show is that it has been invalidated — not a stale number with a fresh-looking timestamp.

Freshness has to be visible

Readers of live-game content have been trained to be suspicious, and they are right to be. The remedy is not to claim to be current. It is to show, on the page, what the data covers and when it was last computed, and to let the reader judge whether that is good enough for what they are about to do.

• Say what the data covers: which mode, which region, which rank band, which window.
• Say when it was last updated, in a form that does not require trusting the publisher.
• Say which game version it reflects, and make it obvious when a newer one has shipped.
• Distinguish measured data from editorial judgement. Both are legitimate; conflating them is not.

A number without a window, a version and a source is not data. It is a rumour with better typography.

Sourcing, and knowing which kind you have

Game information arrives through several routes and they are not equally reliable. Official patch notes and developer communication are authoritative but incomplete — they routinely omit changes. Values read directly from the game are strong evidence but can be misread. Aggregated play data is powerful in volume and misleading in small samples. Community testing is often excellent and occasionally confidently wrong. Datamined content describes what exists in a build, which is not the same as what will ship.

None of these should be presented as though they carry the same weight. Where something is unreleased or unconfirmed, it should be labelled as such rather than folded into the same table as shipped facts.

Corrections are part of the product

On a fast-moving live game, being wrong occasionally is not a sign of a broken process — it is a certainty. What distinguishes a resource worth using is what happens next: whether there is a way to report the error, whether the fix propagates everywhere the wrong value was shown, and whether the correction is visible rather than quietly swapped in.

Silent edits are the failure mode here. A reader who acted on the old value deserves to know it changed, and a resource that rewrites its own history is one nobody can calibrate against.

What this rules out

This approach has costs, and they are worth stating plainly. Presenting uncertainty honestly makes a page look less authoritative than a competitor willing to state a guess as fact. Recomputing on every patch is more engineering than publishing a table once. Labelling small samples as small samples means sometimes saying "we do not know yet."

We think that trade is correct. The alternative earns attention once and loses the reader the first time the number turns out to be from three patches ago.