Read the numbers before you chase the next milestone
The shared handbook: daily vs concurrent players, UTC report days, retention cohorts, a small decision sheet and comparisons that survive a second look.
Sources checked November 7, 2026.
A useful analytics routine ends with a decision, not another chart. Start with three questions: What changed? What else could explain it? What is the smallest useful thing to try next?
Daily players and players at once are different milestones
Daily active users (DAU) count distinct people active during a reporting day. Concurrent players (CCU) count people present at the same moment. Daily peak CCU is the largest reported concurrent count during that day. Neither is interchangeable with sessions: one person can start several sessions.
The growth series uses average DAU over seven complete reporting days, not peak CCU:
- Under 100 daily players: make the first session work and learn from people directly.
- 100–999: build repeatable retention and a reliable operating rhythm.
- 1,000–9,999: separate audiences, channels and release effects.
- 10,000+: protect the player experience while scaling live operations.
These are editorial planning bands, not Roblox eligibility requirements or proven growth thresholds. If you have 1,000 CCU, do not label yourself a 1,000-DAU game. Choose your DAU guide, then use the later guides' operations checklists if concurrency is putting pressure on servers or support. If you have fewer than seven complete days, mark the stage provisional; don't pretend missing days are zero.
LaunchBlip's daily players and daily peak cards help distinguish these. The hourly CCU view and milestone alerts are Pro/Studio features, where Roblox supplies the data; they are not a live outage detector. Engagement (opens in a new tab), performance (opens in a new tab).
Date of play, date of return, date you see the report
Roblox's daily Analytics API buckets are UTC. Your digest delivery timezone does not change the underlying reporting day. Compare complete UTC-day buckets, and use a clearly labeled local timestamp for your release notes.
Retention is anchored to first play date. D1 is the fraction of that day's new players who return the following day; D7 is return on Day 7, and D30 on Day 30. These are exact-day measures, not “returned at any point during the week.” A new cohort cannot already have a D30 outcome. Processing time adds another wait after the observation window. A blank newest cell is not automatically zero retention. Retention (opens in a new tab), API date rules (opens in a new tab).
LaunchBlip currently imports D1 and D7, not D30. Inspect D30 and full cohorts in Creator Hub. Likewise, the existing 3/7-day before/after report cannot settle the D30 outcome of a fresh update. Don't draw that conclusion from the report's elapsed-time badge. For more on cohorts, see How to read your Roblox retention.
Use a small decision sheet
Write this before making a change:
| Field | What to write |
|---|---|
| Observation | Metric, exact date/window, value, comparison, data source |
| Player problem | Something a player experiences, not “the algorithm hates us” |
| Hypothesis | “If we remove X friction, Y should improve because…” |
| Change | One bounded intervention, with a rollback note |
| Primary outcome | One metric whose definition fits the hypothesis |
| Guardrail | A metric or observation that must not worsen |
| Review time | After complete reporting days and the relevant cohort matures |
| Confounders | Ads, event, weekend, outage, traffic source mix, simultaneous releases |
| Decision | Keep, revise, undo, or inconclusive—with reasons |
Example, not a claim about your game: “Players don't see the starter tool. Move it next to the first objective. Primary outcome: first-session progress observed in tests; follow-up: session time and D1. Guardrail: players still understand what they earned. Review after enough comparable new players and mature D1 cohorts.”
LaunchBlip's update marker/report can hold the release date and compare three/seven complete days on paid plans. Free users can keep this sheet alongside Monday digests. A before/after association is a useful clue, not a randomized experiment. Your own release can coincide with a Roblox discovery change.
Make comparisons that survive a second look
- Compare similar weekdays and similar sources. A weekend event versus a quiet weekday mixes schedule and treatment effects.
- Use absolute counts beside percentages. Going from one returning tester to two is a big relative increase but weak evidence of general improvement.
- Don't average daily retention percentages blindly. A cohort with many new players should not have the same weight as one with a handful. Use the source's cohort numerator/denominator or supported aggregate, not DAU as a substitute for new players.
- Don't add device DAU to infer unique total: a person can use more than one device. Don't add daily DAU to claim weekly uniques; that sum is player-days.
- Don't call high session time automatically good. Long menus, idle rewards or confusion can stretch time without producing satisfied returning players.
- Check data availability before diagnosing a collapse. Missing, zero, unavailable, estimated and mature are different states. API statuses may explicitly mark projected or insufficient-sample data. API (opens in a new tab), dashboard (opens in a new tab).
LaunchBlip compares current metrics with a prior seven-day average. That is context, not seasonal adjustment or a statistical test. Its drop alerts are triggers for investigation, not proof that your update caused harm. Free includes stall alerts; paid plans also include drop alerts. Not every metric has a drop rule. A flat metric may simply be stable.
What is a healthy metric?
There is no universal D1/D7/CTR/ARPDAU number that makes every Roblox game healthy. Genre, source, age of the game and audience change the answer. Start with your own comparable cohorts and the current benchmarks visible for your game in Creator Hub. The official dashboard describes similar-player/genre/platform benchmarks and percentile ranges; those ranges are not hard discovery gates. Benchmark sets may change. The numerical example in documentation is an example, not a target for your game. Benchmarks (opens in a new tab).
Performance has some concrete engineering guidance: Roblox's performance page describes a server frame-rate ideal of 60 FPS and CPU time below roughly 16 ms to support 60 FPS. That is a diagnostic direction, not a universal guarantee of good player experience. Check lower percentiles and affected devices, not just averages. Performance (opens in a new tab).
Read the growth funnel in order
Exposure → qualified play → satisfying first session → return → sustainable spending. When exposure changes, find which source changed. When clicks improve but early leaving worsens, check the promise made by your thumbnail. When players return but don't buy, investigate store value and clarity; don't damage the free core loop to force a purchase.
“Qualified play-through” is an acquisition measure. It is not purchase conversion. Payer conversion is the fraction of active users who pay. Likewise, ad spend divided by DAU×D1 is only a rough mixed-audience proxy, not measured cost to acquire a retained customer or ROAS. Use Ads Manager's campaign reporting and attribution definitions for campaign decisions. Acquisition (opens in a new tab), monetization (opens in a new tab), Ads Manager (opens in a new tab).
What LaunchBlip sees—and what it doesn't
LaunchBlip connects through read-only Roblox OAuth, without asking for a game SDK, game scripts or API key. Current core views cover authorized aggregate DAU, D1/D7, session/playtime, sessions, Robux, payers and available peak CCU. Delivery and report features depend on plan. Email availability is not promised in these guides.
LaunchBlip does not watch an individual player's screen, know why someone left, buy ads, change your thumbnails, moderate your community or install missing funnel events. Creator Hub remains the place for native acquisition, first-session, benchmarks, D30, performance and detailed cohorts that LaunchBlip does not show. Manual playtests work without analytics code.
Bring both kinds of evidence together: the numbers show where to look, and a real player shows what happened there.