Methodology

What Bloxism collects

• Player counts. How many people are inside each tracked experience, read on a schedule and stored. Every reading is kept, so a game has a history rather than a single current number.
• Item data. Names, stats, rarities and art for the games with a documented database, plus trade values where a game has a value system with a stated unit.
• Codes, updates and events, harvested from each game's own sources and dated.
• Marketplace observations. Roblox catalog items with their official price, supply and lowest current resale listing, each stamped with the time it was read.

How each number is presented

• Unavailable is shown as unavailable. When a value cannot be read, the surface says so and gives the last successful sync time, rather than showing a zero.
• Freshness travels with the number. Every analytics surface shows when it last synced, so a delayed reading is not mistaken for a live one.
• Derived figures are labelled. Anything calculated rather than observed — including low-confidence Bloxism Scores — is marked.

Data catalog

Every metric we publish, where it comes from, and what it can't tell you. Measured means read directly from a source; derived means computed from data we recorded; estimated means modelled, and labelled as such wherever it appears.

Collection pipeline

A scheduled job sweeps every game that is due by its tracking tier roughly every 10minutes — the busiest games refresh at that cadence, quieter ones lapse less often so we don't hammer the API for numbers that barely move. Art, creator and event data refresh about every 2 hours. Raw snapshots stay at full resolution for 10 days and are then rolled up to hourly peaks, so a recorded peak survives exactly while storage stays bounded.

Where player counts come from

Concurrent players, visits, favorites and ratings are read from Roblox's public APIs and captured as a timestamped snapshot on our sync schedule. For games that span multiple places, concurrent players are summed across those places. We store every snapshot, so the historical charts and trends are built from our own recorded observations — not a single overwritten value.

Metric methodologies

How “trending” is defined

A weighted trend score drives this board: 24-hour percentage growth scaled by a popularity factor, so a large game gaining 15% outranks a tiny one that merely doubled. Games under 1,000 concurrent players are excluded to prevent noise. Needs at least 24 hours of history to populate.

Trending is deliberately notjust current player count — a weighted score rewards genuine momentum while a minimum-players floor stops a tiny game from topping the chart on a percentage fluke. See every chart's exact rule on the charts pages.

How movers qualify

Before any game appears as a “gainer”, “faller” or “breakout” — on the homepage, the charts or a game's analytics — its data has to pass every one of these checks. A game that fails isn't hidden from the site; it just can't be presented as a mover until its data supports the claim.

• Real audience at BOTH ends — the historical baseline the movement is measured from, and the current count, each need at least 1,000 concurrent players. A percentage is only as trustworthy as its denominator: a game that jumped from 3 players to 71,000 is not “up 2,000,000%” — the baseline of 3 is noise, so it can't present as a mover no matter how big it is now.
• Sample density — at least 12 snapshots inside the 24-hour movement window. A change computed from a couple of readings can't rank on a chart.
• History span — at least 48 hours of recorded history. A game we started tracking this morning has no honest baseline yet.
• Freshness — the latest snapshot must be at most 90 minutes old. Stale data can't claim to describe what's happening now.
• Live state — a player count below 5% of the game's 7-day average is classified, not just flagged. A crash or maintenance closure is excluded from the fallers chart (an outage is not a trend) and reported under its own state instead. See live state below.

Live state: what a collapsed player count means

A game's current player count is compared against its trailing 7-day average. When it falls far below that average, the interesting question is not whether to exclude it from movement rankings — it always is — but what we are actually able to claim.

Bloxism samples on a schedule, and a single low reading is genuinely ambiguous: the game may be down, or the Roblox API may have returned nothing that minute. So one reading never asserts an outage. The states below are ordered by how much each one claims, and a game is only described as a likely outage once 2 consecutive readings agree.

Unusual drop

Player count is at 3% of its 7-day average. That is a real drop, not an outage — scheduled events and time-of-day both produce it.

Investigating

Player count has fallen to 3% of its 7-day average on a single reading. One reading cannot separate an outage from a failed data fetch, so it is held out of movement rankings until the next snapshots agree.

Likely outage

Player count has stayed below 5% of its 7-day average across 2 consecutive readings. Treated as an outage or maintenance closure, and excluded from movement rankings rather than shown as a faller.

Recovering

Player count collapsed earlier in the recorded window and has climbed back to 3% of its 7-day average.

Games in the Investigating and Likely outage states are held out of the gainer and faller boards. A Recovering or Unusual drop game is genuinely moving and stays on them.

Data-quality and anomaly handling

Live APIs occasionally return a bad reading — a value that spikes far above a game's normal range for one collection interval and then snaps straight back. Left alone, a single bad reading would poison a peak, a record or a percentage change. So every player-count observation is scored by a versioned anomaly detector (currently 2026-07-19.1) and marked valid, suspect or excluded.

• Nothing is deleted. Suspicious history is preserved in full; it is only withheld from public calculations — current values, changes, peaks, records, the Bloxism Score, movers and exports all read valid observations only.
• We measure against the local range, not a single neighbour. A reading is only flagged when it sits far above the robust median of the hours around it, so genuine sustained growth (which lifts that median with it) is never mistaken for a spike.
• Impossible values are excluded outright — a negative count, or anything beyond 5,000,000 concurrent players (well past any real Roblox experience).
• Borderline cases are held for review, not hidden forever. A large jump that is still elevated at the edge of our history could be a real surge, so it is marked suspect and withheld until more data confirms it either way.

Estimated session length

For games we don't have creator-authorized analytics for, we estimate how long an average session lasts from our own recorded observations. If a game holds L concurrent players on average and gains λ new visits per minute, the average time a player spends in the game is L ÷ λ. That is a standard queueing result (Little's Law), applied to two numbers we already record.

• It is an estimate, and labelled one.We call it “estimated session length”, never “average playtime” — only a creator-authorized analytics connection could report that, and we don't claim to have one.
• It needs real growth to measure. No estimate is shown without positive visit growth, at least a day of history and enough observations — and each estimate carries a confidence label reflecting how much history backs it.
• Bad inputs are withheld, not published. Anomalous observations are already excluded from every public metric, and a result outside a plausible band (under a minute, or over ten hours) means the inputs are wrong, so we show nothing at all.

Stability labels

A game's stability label buckets its 7-day volatility — the standard deviation of recorded player counts divided by their mean (0 = perfectly flat, capped at 1): very stable (0–0.05), stable (0.05–0.15), variable (0.15–0.35), volatile (0.35 and above). The label only appears once our recorded history reaches back a full seven days and at least three snapshots fall inside the window. A coefficient measured over three days is not a seven-day figure, and on a short series a single event dominates it — so until then the label, and the stability input to the Bloxism Score, stay unset rather than guess.

Known limitations

• We only know what we recorded. Peaks, changes and averages describe our observation window — a game that was bigger before we started tracking it will not show that here.
• Snapshots, not a live feed.Movement between syncs isn't captured, so a very brief spike can be missed entirely.
• Roblox's numbers are Roblox's.Visits and votes are lifetime counters we read from their public API; we can correct for obvious faults but we can't audit their accuracy.
• Estimates are models.Anything marked “estimated” is derived from an assumption we state openly, and is withheld entirely when the inputs can't support it.

Methodology version 2026-07-19 · anomaly detection 2026-07-19.1. Thresholds on this page are rendered from the same constants the calculations use, so they cannot drift apart.