Skip to content
Topics and reading paths

Game analysis

A public-data evidence ledger for Roblox research

A defensible analysis preserves the path from source to decision. A small evidence ledger is enough: one row per material claim with the source URL, Universe ID, observation time, metric definition, value, coverage, inference, limitation, and next action. It supports the [MARPLA methodology](/en/resources/methodology) and keeps a refreshed catalog from silently rewriting the original evidence.

Focused deep dive

Concepts and tools in this topic 7
Original MARPLA conceptual illustration: A public-data evidence ledger for Roblox research
Original conceptual diagram. Not a product interface or measured results.

Store claims, not screenshots alone

A screenshot can preserve visible context, but it may omit source time, filters, missing points, or the underlying identifier. Store the machine-readable value or exported row when available, then use the screenshot as presentation evidence. Distinguish “Roblox public counter,” “MARPLA derived value,” and “authorized owner metric.” Add a status such as observed, inferred, hypothetical, or verified.

The claim should be narrow enough to falsify. “Universe 123 was observed at 420 CCU at 20:00 UTC” is reproducible. “The game is viral” is an interpretation that needs a definition and supporting windows. A decision row should explain what changed because of the evidence: monitor until Friday, request owner data, or pass.

Worked example: recording an update lead

A public game updated on September 10. MARPLA observations show a matched Friday peak of 900 CCU versus 600 the prior Friday, with 83% last-hour coverage and a 40,000 Visits increment. The ledger stores the Universe ID, both windows, source pages, timestamps, coverage, and the arithmetic: +300 CCU and +50%. The observation is “higher public concurrency after the update.”

The inference is “the update may have contributed.” The limitation lists unknown acquisition mix, regional composition, and other campaigns. The decision is “play-test the changed feature and request source-segmented D1 from the owner.” When new evidence arrives, add a row rather than overwriting the first one; the history shows why the conclusion changed.

Minimum fields for every material claim

Use a stable claim ID so links, screenshots, exports, and later corrections stay connected.

  1. Record Universe ID, source URL, observed-at time, and retrieval time.
  2. Write the metric name, unit, definition, period, and filters.
  3. Store value, denominator, coverage, and missing-data status.
  4. Separate observation, inference, and limitation.
  5. Attach the resulting action, owner, due date, and verification status.

Evidence that cannot be audited

Do not cite a live page without recording the value and time you used. Avoid replacing missing data with zero, copying a rounded chart label as an exact number, or combining windows with different time zones. A source URL alone does not establish that the page supported the claim on the observation date.

Derived fields need their model or formula version. Owner exports need permission, filters, and privacy handling. Corrections should preserve the superseded row and explain the reason. The ledger is not a promise that public data is complete; it makes incompleteness visible and keeps decisions proportionate.

Decision record

Review the ledger at decision time, not only during collection. Confirm that each material claim has a source, timestamp, definition, status, limitation, and action. A row without a decision impact can remain research context, but it should not inflate confidence.

Primary sources

Put this into practice in MARPLA

MARPLA tool diagram: Start analyzing a game

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.

Open the tool

Discussion0

Loading comments…