Historical playtime and retention correction

The first analytics implementation used analytics_play_intervals for every period. Production capture began September 13 at 00:35:50.952 UTC, so all-time, 1D, 7D and 1M all displayed the same new hours. The existing account lifetime and session counters were omitted from the CDC column allowlist.

Time sources

• All-time headline: sum of current accounts' lifetime_playtime_seconds. Do not add session counters or intervals; those measures overlap.
• All-time world detail: retained sessions' playtime_seconds, by world. Deleted sessions cannot be assigned to worlds, so this does not reconcile to the account lifetime total. This limitation is visible above the atlas.
• Date ranges: union of recorded foreground intervals, clipped to the range. Historical session totals must never be assigned to session creation dates.
• Quick ranges carry explicit partial coverage; the UI marks incomplete historical coverage with an asterisk and a start-time tooltip.

Production CDC migration

The existing connector's two selected mappings were replaced, preserving the old raw tables while new snapshots ran. No Neon restart or source row rewrite. The publication now additionally includes user.lifetime_playtime_seconds and play_sessions.user_id,playtime_seconds. The CDC role has SELECT on those columns, with the existing ctid permission retained for snapshot cursors.

New destinations: yumina_raw.user_time_v2 and yumina_raw.play_sessions_time_v2. Other mappings remain unchanged. The API requires a paused pipe before EACH mapping edit; removal automatically resumes the pipe, requiring another pause before addition. Both new tables completed their snapshots and resumed CDC before applying 004_historical_playtime.sql. Old raw tables are retained for rollback investigation, not read by current canonical account/usage views.

Apply 004 only after both new mappings are Running, column types and populated totals are verified, and the analytics reader can read the allowlisted raw tables. The importer already has raw database SELECT. The worker detects both new canonical time views before publishing historical-playtime coverage. Production helper phases and reconciliation outputs are in the ignored local admin-analytics setup directory; credentials remain in DPAPI storage.

Retention

Active people retains its existing meaningful-action definition: play, Studio, community, or reward activity. Signup-month cohorts and calendar-month returns are unchanged.

The play view restores legacy Activated (3+) and Engaged (10+) ENTRY intensity. First play anchors the windows. Qualify in the first day, seven days, or 30 days for daily, weekly or monthly views respectively. Any later play message counts as a return. Recorded send/regenerate/continue usage rows count as messages; Studio and standalone-game activity are excluded from these play cohorts. This is not a positive-token threshold and includes BYOK play.

D1 and D7 are exact-day returns, W1 is days 7–13, and play M1 is days 30–59. Header badges show D1, D7 and M1 together, weighted by people in complete cohorts since April. Hiding a curve does not silently change the header population. Incomplete windows are null, not zero. Cohort eligibility waits until the entire entry window is observed; this avoids partial initial-week populations.

Atlas and flow

The Mushie flow always uses the expanded rendering. The compact toggle and SVG height cap are removed.

Desktop atlas opens with sparse shared-audience groups, cover previews and token share. Tags label groups but never determine membership. No-edge worlds are explicitly grouped for browsing, not presented as sharing an audience. Selecting a group opens at most twelve cover nodes. Selecting a world places it with the strongest available shared-player neighbors. The ranked list retains all metrics and sorting. Group totals never sum overlapping player counts. The source report remains a bounded top-500 catalog and top-3000 pair graph; the displayed catalog coverage is explicit. Missing edges are not proof that two audiences have no overlap below the reporting threshold.

Validation

Warehouse integration fixtures test historical version deduplication, deleted accounts, no double-counting with intervals, date-range isolation, and the 3+/10+ entry / single-message return rule. UI helper fixtures test sparse graph membership, disconnected worlds, deterministic grouping and 500-world coverage. Production read-only report builds verify actual counter totals and cohort results before deployment. Root typecheck/build and live snapshot checks are required. Browser visual verification is not performed without the user's explicit request, per repository instructions.