Guida pratica per costruire una web app che traccia KPI SaaS come MRR, churn, retention e engagement — dalla modellazione dati e eventi fino a dashboard e alert.
Prima di scegliere grafici o database, decidi per chi è davvero pensata questa app — e su quali decisioni deve far prendere una posizione il lunedì mattina.
Un'app per metriche SaaS di solito serve un piccolo insieme di ruoli, ciascuno con viste indispensabili diverse:
Se provi a soddisfare tutti con ogni metrica dal giorno zero, consegnerai in ritardo — e la fiducia calerà.
“Buono” è avere una sola fonte di verità per i KPI: un posto dove il team concorda sui numeri, usa le stesse definizioni e può spiegare ogni valore riportando gli input (subscription, invoice, eventi). Se qualcuno chiede “perché il churn è aumentato la settimana scorsa?”, l'app dovrebbe aiutarti a rispondere velocemente — senza esportare in tre fogli di calcolo.
Il tuo MVP dovrebbe produrre due esiti pratici:
MVP: un piccolo set di KPI affidabili (MRR, net revenue churn, logo churn, retention), segmentazione di base (piano, regione, mese di coorte) e uno o due indicatori di engagement.
Fase 2: forecasting, analisi di coorte avanzata, experiment tracking, attribuzione multi-prodotto e regole di alerting più profonde.
Un ambito MVP chiaro è una promessa: consegnerai qualcosa di affidabile prima, poi espandi.
Prima di costruire una dashboard di metriche SaaS, decidi quali numeri devono essere “giusti” dal giorno uno. Un set più piccolo e ben definito batte un lungo menu di KPI di cui nessuno si fida. L'obiettivo è rendere il tracciamento del churn, le metriche di retention e l'analisi dell'engagement abbastanza coerenti da far smettere prodotto, finance e sales di discutere la matematica.
Inizia con un set core che risponde alle domande che i founder si pongono settimanalmente:
Se aggiungi analisi di coorte, expansion revenue, LTV o CAC più avanti, va bene — ma non lasciare che questi ritardino l'analitica delle subscription.
Scrivi ogni metrica come una breve specifica: cosa misura, formula, esclusioni e regole temporali. Esempi:
Queste definizioni diventano il contratto dell'app — usale nei tooltip dell'interfaccia e nella documentazione così la tua web app KPI SaaS resta allineata.
Scegli se l'app riporta giornalmente, settimanalmente, mensilmente (molti team partono con giornaliero + mensile). Poi decidi:
La segmentazione rende i KPI azionabili. Elenca le dimensioni da prioritizzare:
Bloccare queste scelte presto riduce lavoro futuro e mantiene consistenti gli alert analitici quando inizi ad automatizzare report.
Prima di calcolare MRR, churn o engagement, ti serve un quadro chiaro di chi paga, a cosa sono iscritti e cosa fanno nel prodotto. Un modello dati pulito evita conteggi doppi e rende più gestibili i casi limite.
La maggior parte delle app metriche SaaS si può modellare con quattro tabelle (o collection):
Se tracci anche le fatture, aggiungi Invoices/Charges per report basati sul cash, rimborsi e riconciliazione.
Scegli ID stabili e rendi esplicite le relazioni:
user_id appartiene a un account_id (molti utenti per account).subscription_id appartiene a un account_id (spesso una subscription attiva per account, ma permetti multipli se la tua pricing lo supporta).event dovrebbe includere event_id, occurred_at, user_id e di solito account_id per supportare analytics a livello account.Evita di usare l'email come chiave primaria; le persone cambiano email e alias.
Modella i cambi di subscription come stati nel tempo. Cattura start/end timestamp e motivazioni quando possibile:
Se hai più di un prodotto, tipo di workspace o regione, aggiungi una dimensione leggera come product_id o workspace_id e includila coerentemente su subscriptions ed events. Questo mantiene semplice l'analisi delle coorti e la segmentazione.
Le metriche di engagement sono affidabili quanto gli eventi che le alimentano. Prima di tracciare “utenti attivi” o “adozione feature”, decidi quali azioni rappresentano davvero progresso per il cliente.
Parti con un piccolo set di eventi decisi che descrivono i momenti chiave del percorso utente. Per esempio:
Mantieni i nomi degli eventi al passato, usa Title Case e rendili sufficientemente specifici perché chiunque legga un grafico capisca cosa è successo.
Un evento senza contesto è difficile da segmentare. Aggiungi proprietà che sai serviranno per le slice nella dashboard:
Sii rigoroso sui tipi (string vs number vs boolean) e sui valori consentiti (es. non mischiare pro, Pro e PRO).
Invia eventi da:
Per l'engagement preferisci eventi backend per le azioni “completate” così le metriche di retention non vengono distorte da tentativi falliti o richieste bloccate.
Scrivi un breve tracking plan e tienilo nel repo. Definisci convenzioni di naming, proprietà richieste per evento e esempi. Questa singola pagina previene derive silenziose che spezzano il tracking del churn e l'analisi delle coorti. Se hai una pagina “Tracking Plan” nella docs dell'app, collegala internamente (ad esempio: /docs/tracking-plan) e tratta gli aggiornamenti come code review.
La tua app metriche SaaS è tanto affidabile quanto i dati che entrano. Prima di creare grafici, decidi cosa ingesti, quanto spesso e come correggi gli errori quando la realtà cambia (rimborsi, modifiche piano, eventi tardivi).
La maggior parte dei team parte da quattro categorie:
Tieni una breve nota “source of truth” per ogni campo (es. “MRR è calcolato dagli subscription items di Stripe”).
Fonti diverse richiedono pattern diversi:
In pratica userai spesso webhooks per il “cosa è cambiato” più una sync notturna per “verifica tutto”.
Atterra gli input raw in uno staging schema prima. Normalizza i timestamp in UTC, mappa gli ID piano a nomi interni e deduplica eventi usando chiavi di idempotenza. Qui gestirai anche particolarità come proration di Stripe o stati “trialing”.
Le metriche si rompono quando arrivano dati tardivi o si correggono bug. Costruisci:
Questa base rende calcoli di churn e engagement stabili e debuggabili.
Un buon DB analitico è progettato per leggere, non per modificare. Il tuo prodotto richiede scritture veloci e consistenza, la metrics app richiede scansioni rapide, slicing flessibile e definizioni prevedibili. Questo spesso significa separare dati raw da tabelle ottimizzate per analytics.
Mantieni un layer “raw” immutabile (spesso append-only) per subscription, invoice ed eventi esattamente come sono accaduti. Questa è la tua fonte di verità quando le definizioni cambiano o emergono bug.
Poi aggiungi tabelle di analytics curate che sono più semplici e veloci da interrogare (daily MRR per cliente, weekly active users, ecc.). Le aggregazioni rendono le dashboard scattanti e mantengono la logica consistente tra i grafici.
Crea fact table che registrano risultati misurabili con un livello di dettaglio spiegabile:
Questa struttura rende più semplici metriche come MRR e retention perché sai sempre cosa rappresenta ogni riga.
Le dimensioni ti aiutano a filtrare e raggruppare senza duplicare testo ovunque:
Con facts + dimensions, “MRR per canale” diventa una semplice join invece di codice custom in ogni dashboard.
Le query analitiche spesso filtrano per tempo e raggruppano per ID. Ottimizzazioni pratiche:
timestamp/date più ID chiave (customer_id, subscription_id, user_id).agg_daily_mrr per evitare di scansionare revenue raw per ogni grafico.Queste scelte riducono il costo delle query e mantengono le dashboard reattive man mano che la tua SaaS cresce.
Questo è il passo in cui la tua app smette di essere “grafici su dati raw” e diventa una fonte di verità affidabile. La chiave è scrivere le regole una volta, poi calcolare sempre nello stesso modo.
Definisci MRR come il valore mensile delle subscription attive per un dato giorno (o a fine mese). Poi gestisci gli aspetti sporchi esplicitamente:
Suggerimento: calcola il revenue usando una “timeline della subscription” (periodi con un prezzo) invece di cercare di rattoppare le invoice dopo.
Il churn non è un numero solo. Implementa almeno questi:
Traccia N-day retention (es. “l'utente è tornato al giorno 7?”) e retention per coorte (raggruppa utenti per mese di signup, poi misura l'attività nelle settimane/mesi successivi).
Definisci un solo evento di activation (es. “created first project”) e calcola:
L'engagement conta solo se riflette valore ricevuto. Inizia scegliendo 3–5 azioni chiave che suggeriscono fortemente che un utente sta ottenendo valore — cose che ti dispiacerebbe se non venissero ripetute.
Le azioni chiave sono specifiche e ripetibili. Esempi:
Evita azioni di vanità come “visitato settings” a meno che non correlino davvero con retention.
Mantieni il modello di punteggio facile da spiegare a un founder in una frase. Due approcci comuni:
Weighted points (ottimo per trend):
Poi calcola per utente (o account) in una finestra temporale:
Thresholds (ottimi per chiarezza):
Mostra sempre l'engagement in finestre standard (ultimi 7/30/90 giorni) e un rapido confronto con il periodo precedente. Questo aiuta a rispondere a “Stiamo migliorando?” senza scavare nei grafici.
L'engagement diventa azionabile quando lo segmenti:
Qui noterai pattern tipo “SMB è attivo ma enterprise rallenta dopo la settimana 2” e collegherai engagement a retention e churn.
Le dashboard funzionano quando aiutano qualcuno a decidere cosa fare dopo. Invece di mostrare ogni KPI, parti con un piccolo set di “metriche decisionali” che rispondono a domande comuni: stiamo crescendo? stiamo trattenendo? gli utenti ricevono valore?
Rendi la prima pagina uno sguardo rapido pensato per il check-in settimanale. Una top row pratica è:
Tieni leggibile: una linea di trend primaria per KPI, un range temporale chiaro e un singolo confronto (es. periodo precedente). Se un grafico non cambia una decisione, rimuovilo.
Quando un numero top-level sembra anomalo, gli utenti dovrebbero poter cliccare per rispondere al “perché?” velocemente:
Qui collegherai metriche finanziarie (MRR, churn) al comportamento (engagement, adozione feature) così i team possono agire.
Preferisci visual semplici: linee per trend, bar per confronti e una cohort heatmap per retention. Evita clutter: limita i colori, etichetta gli assi e mostra valori esatti al passaggio del mouse.
Aggiungi un piccolo tooltip di definizione metrica accanto a ogni KPI (es. “Churn = MRR perso / MRR iniziale per il periodo”) così gli stakeholder non discutono le definizioni in riunione.
Le dashboard sono ottime per l'esplorazione, ma la maggior parte dei team non le guarda tutto il giorno. Alert e report schedulati trasformano la tua app metriche in qualcosa che protegge attivamente il revenue e mantiene tutti allineati.
Inizia con un piccolo set di alert ad alto segnale legati ad azioni che puoi intraprendere. Regole comuni includono:
Definisci le soglie in linguaggio semplice (es. “Allerta se le cancellazioni sono 2× la media a 14 giorni”) e permetti filtri per piano, regione, canale di acquisizione o segmento cliente.
Messaggi diversi vanno in posti diversi:
Permetti agli utenti di scegliere destinatari (individui, ruoli o canali) così gli alert arrivano a chi può rispondere.
Un alert dovrebbe rispondere a “cosa è cambiato?” e “dove guardare dopo?”. Includi:
Troppi alert vengono ignorati. Aggiungi:
Infine, aggiungi report schedulati (daily KPI snapshot, weekly retention summary) con timing consistente e lo stesso “clicca per esplorare” così i team passano rapidamente dalla consapevolezza all'indagine.
Una app metriche SaaS è utile solo se le persone si fidano di ciò che vedono — e la fiducia dipende da controllo degli accessi, gestione dati e un chiaro storico di chi ha cambiato cosa. Tratta questo come una funzionalità prodotto, non come un ripensamento.
Inizia con un modello di ruoli piccolo ed esplicito che riflette il modo di lavorare dei team SaaS:
Tieni i permessi semplici all'inizio: la maggior parte dei team non richiede decine di toggle, ma necessita chiarezza.
Anche se tracci solo aggregati come MRR e retention, probabilmente conserverai identificatori cliente, nomi piano e metadata evento. Di default minimizza i campi sensibili:
Se l'app sarà usata da agenzie, partner o team multipli, l'accesso a livello di riga può essere importante. Per esempio: “Analyst A può vedere solo account appartenenti al Workspace A.” Se non ti serve, non costruirlo subito — ma assicurati che il modello dati non lo impedisca in futuro (es. ogni riga legata a workspace/account).
Le metriche evolvono. Definizioni di “active user” o “churn” cambieranno, e le impostazioni di sync dati verranno regolate. Logga:
Una semplice pagina di audit (es. /settings/audit-log) previene confusione quando i numeri si spostano.
Non serve implementare ogni framework dal giorno uno. Fai le basi presto: accesso least-privilege, storage sicuro, politiche di retention e un modo per cancellare i dati cliente su richiesta. Se i clienti chiederanno SOC 2 o readiness GDPR più avanti, migliorerai una base solida — non riscriverai l'app.
Inizia definendo le decisioni che l'app deve supportare il lunedì mattina (ad es. “Il rischio sul revenue sta aumentando?”).
Un MVP solido di solito include:
Tratta le definizioni come un contratto e rendile visibili nell'interfaccia.
Per ogni metrica, documenta:
Poi implementa quelle regole una sola volta in codice di calcolo condiviso (non separatamente per ogni grafico).
Un set pratico per il day-one è:
Tieni espansione, CAC/LTV, forecasting e attribuzione avanzata per la fase 2 così non ritardi l'affidabilità.
Un modello di base comune e spiegabile è:
Se ti serve riconciliazione e rimborsi, aggiungi .
Modella le subscription come stati nel tempo, non come una singola riga mutabile.
Cattura:
Questo rende le timeline MRR riproducibili ed evita spike di churn “misteriosi” quando la storia viene riscritta.
Scegli un piccolo vocabolario di eventi che rappresentino valore reale (non click di vanità), ad esempio “Created Project”, “Connected Integration” o “Published Report”.
Best practice:
La maggior parte dei team combina tre pattern di ingestione:
Atterra tutto in uno staging prima (normalizza fusi orari, dedup con chiavi di idempotenza) e tieni modi per backfill e reprocess quando regole o dati cambiano.
Separa livelli:
agg_daily_mrr) per dashboard velociPer le prestazioni:
Inizia con una pagina unica che risponde a crescita e rischio in meno di un minuto:
Poi aggiungi percorsi di drill-down che spiegano il “perché”:
Usa un piccolo set di regole high-signal collegate a azioni chiare, ad esempio:
Riduci il rumore con soglie minime, cooldown e raggruppamento.
Ogni alert dovrebbe includere contesto (valore, delta, finestra temporale, segmento principale) e un percorso di drill-down filtrato (es. ).
Usa ID stabili (non email) e rendi esplicite le relazioni (es. ogni evento include user_id e di solito account_id).
date/timestamp, customer_id, subscription_id, user_id)Includi una tooltip con la definizione della metrica su ogni KPI per evitare discussioni.
/dashboards/mrr?plan=starter®ion=eu