View di monitoraggio

Le view di monitoraggio risiedono nello schema public del progetto Supabase playroll_supa_new. Esistono affinché tester e investitori possano rispondere a domande operative senza dover unire (join) le tabelle grezze degli upload.

Per le descrizioni rivolte all'utente finale (audience, colonne, quando usare quale) consulta le pagine delle dashboard:

• VC reporting: Dashboards → Supabase Views → VC View
• Supporto tester: Dashboards → Supabase Views → Tester Views

Questa pagina documenta il contratto e le convenzioni.

View implementate

View	Audience	Granularità
investor_daily_recording_kpis_vc_view	VC	Una riga per activity_day
support_player_upload_summary	Tester	Una riga per player
support_recording_sessions	Tester	Una riga per sessione di registrazione
support_recording_files	Tester	Una riga per artefatto caricato
playroll_users_view	Tester (lookup identità)	Una riga per utente

Helper operativi consumati dalle view di cui sopra e usati direttamente per query ad-hoc:

View	Scopo
daily_upload_stats	File/utenti/sessioni/byte giornalieri per file type.
session_completion_status	Per sessione: expected_chunks vs uploaded_chunks, conteggi mp4/csv/ogg, is_complete.
complete_triplets	Per (user, session, chunk_dir): indica se la tripletta mp4+csv+json è completamente presente.
upload_summary_by_user	Rollup più vecchio per-utente (campo games come stringa). Preferire support_player_upload_summary.

Convenzioni di naming

• Suffisso _vc_view — rivolto agli investitori. Granularità giornaliera di default. Colonne cumulative dove utili.
• Prefisso support_* — rivolto ai tester. Granularità per player o per sessione. Include colonne di identità (display_name, steam_id, discord_username) così che i tester possano cercare con qualunque identificativo fornito da un player.

Principi dei KPI

• I KPI per gli investitori usano di default la granularità giornaliera.
• Le ore rilevanti per il pagamento provengono da known_valid_current_recorded_*, non da known_recorded_* grezzi. Il qualificatore "valid current" significa che la sessione ha soddisfatto il contratto di upload MP4+CSV.
• Il contratto "current" degli artefatti richiesti è MP4 + CSV. Il contratto "future" è MP4 + CSV + JSON. Entrambi sono tracciati affiancati nelle view (has_current_required_pair, has_future_required_triplet) così che il rollover dello schema possa essere effettuato per fasi.
• Le colonne size_bytes sono espresse in byte. Il codice applicativo dovrebbe rispecchiare questo nome (es. size_bytes, non size).
• Una sessione pure-v2 caricata e completa contiene MP4, CSV e JSON (contratto della tripletta).
• I conteggi grezzi degli upload e i conteggi delle sessioni sono distinti — non sommarli mai.

Lavoro aperto

• Confermare lo stato terminale finale di recording_sessions e il vocabolario dei motivi di fallimento affinché uploadability_status / block_reason siano stabili.
• Decidere se le view debbano essere SQL pure o materializzate con una pianificazione di refresh, una volta che i volumi giornalieri cresceranno.
• Dismettere upload_summary_by_user in favore di support_player_upload_summary una volta migrati i consumer.