VC View

ActivePermanentSource: Supabase (playroll_supa_new)

Server-side, authoritative KPIs for investors. Backed by SQL views in the public schema, suffixed _vc_view. Numbers here reflect what landed on the server, not what the client emitted as telemetry — they are the ground truth for payment-relevant hours and dataset growth.

investor_daily_recording_kpis_vc_view

One row per activity_day. The view is the single investor-facing KPI surface today.

Column	Type	Meaning
activity_day	date	Day of activity.
dataset_start_day	date	First day with any recorded activity in the dataset.
active_players	bigint	Distinct players with at least one session that day.
total_sessions_seen	bigint	All sessions observed by the server, regardless of upload state.
sessions_with_uploads	bigint	Sessions with at least one uploaded artifact.
valid_current_sessions	bigint	Sessions meeting the current required-artifact contract (MP4 + CSV pair).
valid_future_triplet_sessions	bigint	Sessions meeting the future triplet contract (MP4 + CSV + JSON). Used to track readiness for schema rollover.
partial_upload_sessions	bigint	Sessions with some but not all required artifacts.
uploaded_files	numeric	Total artifacts uploaded that day.
mp4_files / csv_files / json_files / ogg_files	numeric	Per-type artifact counts.
uploaded_size_bytes / uploaded_size_gb / uploaded_size_pretty	bigint / numeric / text	Daily upload volume.
sessions_with_known_duration	bigint	Sessions for which a measured duration is recorded.
known_recorded_seconds / known_recorded_hours	bigint / numeric	Recorded duration for sessions with a known duration.
known_valid_current_recorded_seconds / ..._hours	bigint / numeric	Recorded duration restricted to valid_current_sessions. The payment-relevant figure.
cumulative_known_recorded_seconds / ..._hours	numeric	Running total since dataset_start_day.
duration_coverage_pct_for_valid_current_sessions	numeric	Fraction of valid_current_sessions for which a duration is known.

What this view answers

• How many hours of validated gameplay have we accumulated to date? → cumulative_known_recorded_hours (last row).
• How many players were active yesterday/this week? → active_players.
• What fraction of recorded sessions made it through the upload contract? → valid_current_sessions / total_sessions_seen.
• How close are we to triplet readiness? → valid_future_triplet_sessions / valid_current_sessions.

Relationship to OTEL dashboards

The Audience OTEL dashboard reports DAU and version distribution from client-emitted events. Numbers here will not match Audience exactly: this view counts players whose sessions reached Supabase; Audience counts users whose clients emitted any telemetry. The two metrics drift apart for offline-but-active clients and for clients that emit telemetry without producing a recording.

For investor reporting, prefer this view. For engineering-visibility into the recording funnel, prefer Audience and Capture Pipeline (client).

KPI principles

• Daily granularity by default.
• Payment-relevant hours come from known_valid_current_recorded_*, not from raw known_recorded_* (which includes sessions that did not satisfy the upload contract).
• size_bytes columns are bytes; size_gb is the convenience conversion.
• The dataset of record is public.recording_sessions + public.s3_uploads; this view is a presentation layer over those tables.

Open work

• Confirm the final recording_sessions terminal status / failure-reason vocabulary.
• Decide whether the view should be materialized on a refresh schedule once daily volumes grow.