Game analysis
Comparable peers and matched windows for Roblox analysis
A comparison is a model of a question. Peer rules and time windows determine what the ranking means before any metric is calculated. Use this method with [MARPLA comparison](/en/resources/compare-roblox-games) or the broader [fair-comparison guide](/en/resources/compare-games-fairly).
Focused deep dive
Define comparability before seeing the result
Choose dimensions tied to the decision: genre and core loop, lifecycle stage, audience scale, monetization model, target geography, supported devices, and release or update cadence. Not every dimension must match, but every mismatch needs a reason. For discovery research, a new simulator may need peers launched within a similar period. For infrastructure planning, scale and session behavior may matter more than genre.
Then align the windows. Use the same time zone, weekday mix, duration, and data-coverage rule. Cumulative counters such as Visits, favorites, and votes should be compared by increments over matched windows. CCU needs matching hours because regional peaks can reverse a ranking. Owner retention needs equally mature cohorts; yesterday’s new users do not yet have a complete D7 outcome.
Worked example: two apparent winners
Game A has 1,200 CCU on Saturday at 20:00 UTC and 800 a week earlier at the same time: +400, or +50%. Game B has 300 CCU on Tuesday at 08:00 UTC and 150 in the prior snapshot: +150, or +100%. Ranking only percentage crowns B; ranking only current level crowns A. Neither comparison is fair if the hours and day types differ.
After matching Saturday 20:00 windows, B is 240 now and 200 before: +40, or +20%. The answer depends on the question. A added more concurrent users and also grew faster in the matched window. B may still be a more interesting early-stage candidate if it is much younger, but that is a separate age-normalized analysis, not a hidden change to the first ranking.
Build a comparison specification
Save the specification beside the result so a later refresh uses the same rules.
- Write the decision and primary comparison metric.
- Set peer inclusion and exclusion rules before sorting.
- Choose time zone, duration, day types, and minimum coverage.
- Report current level, absolute change, and percentage change.
- Run a sensitivity check by removing the weakest peer match.
Where rankings become misleading
Do not compare a launch spike with a mature baseline, lifetime totals across different ages, or local evening for one audience with overnight hours for another. Avoid selecting peers after seeing which group makes the preferred candidate win. If a result disappears after one reasonable peer change, report it as sensitive.
Public comparability does not create private comparability. Two games with similar CCU may differ in paid acquisition, retention, payer mix, server cost, and team obligations. Use the public ranking to choose what to inspect next, not as a substitute for diligence.
Decision record
Publish or save the peer list, inclusion rule, exclusions, window, time zone, and coverage threshold beside the ranking. Add a sensitivity result showing whether one reasonable peer substitution or window shift changes the conclusion.
Primary sources
Put this into practice in MARPLA
Select a game in Analysis and inspect its sources and score components. Use them to choose your next research question rather than treating the score as a verdict on success.
- Start analyzing a gamePublic analysis helps you explore a game's audience, activity and rating.Step-by-step guide →
- Understand scores and riskScores help you choose projects for a closer look.Step-by-step guide →



Discussion0
Loading comments…