Come costruire una dashboard admin GDPR in solitaria

Uno sviluppatore solista ha bisogno di metriche tanto quanto un team di 50 persone. Forse anche di più. Quando sei l'unico a gestire il backend, il frontend, il marketing e il supporto, non puoi permetterti di indovinare cosa sta succedendo. Hai bisogno di vedere: quanti utenti sono attivi, quali funzioni vengono utilizzate, se il backend regge il carico, se la pipeline vocale si blocca.

Ho costruito una dashboard admin completa per TAMSIV, un sistema di avvisi email per incidenti critici e un tracciamento analytics conforme al RGPD. Ecco come tutto questo si articola e perché ogni componente è indispensabile quando operi da solo.

Punti chiave da ricordare:
- Una dashboard admin non è un lusso — è vitale per uno sviluppatore solista in produzione
- GA4 con Consent Mode permette di essere conforme al RGPD senza sacrificare le metriche
- Gli avvisi email (AlertService) rilevano i problemi prima degli utenti
- Il cookie consent a 3 toggle con versioning è il minimo RGPD in Europa
- Il doppio tracciamento (GA4 + Supabase) copre le metriche web E le metriche di business

Perché uno sviluppatore solista ha bisogno di una dashboard admin?

La risposta breve: perché non hai un team SRE, nessun product manager, nessun analista. Sei tutto questo insieme. E senza visibilità su ciò che accade nella tua app, prendi decisioni alla cieca.

Prima della dashboard, scoprivo i problemi attraverso i feedback degli utenti (quando si prendevano la briga di scrivere). Un crash della pipeline vocale poteva rimanere invisibile per ore. Un picco di iscrizioni passava inosservato. Una funzionalità che nessuno utilizzava continuava a costarmi tempo di manutenzione.

La dashboard admin ha cambiato tutto questo. Accessibile a /admin/dashboard su tamsiv.com, mi offre una visione in tempo reale di tutto ciò che conta:

• Utenti: Iscrizioni giornaliere, utenti attivi (DAU/WAU/MAU), retention
• Funzionalità: Utilizzo del dittafono, creazione di attività/memo/eventi, gamification
• Infrastruttura: Latenza WebSocket, tasso di errore STT, fallback LLM attivati
• Business: Conversioni Free → Pro, ricavi RevenueCat, tasso di disiscrizione

Come costruire una dashboard admin con Recharts e Supabase?

La dashboard è costruita con Recharts, una libreria di grafici React basata su D3.js. Perché Recharts? Perché si integra nativamente con React, supporta il SSR (importante per Next.js), e il rendering è pulito senza configurazioni complesse.

L'architettura è semplice:

1. Dati: Tutto proviene da Supabase tramite funzioni RPC. Ogni grafico ha la sua RPC che aggrega i dati lato server.
2. Schede di statistiche: Nella parte superiore della dashboard, le schede mostrano i KPI in tempo reale (utenti totali, attivi oggi, attività create, ecc.).
3. Grafici temporali: Curve di iscrizioni giornaliere, utilizzo per funzionalità, istogrammi di retention.
4. Tabelle: Elenco degli ultimi eventi (iscrizioni, errori, avvisi).

Un punto importante: le RPC Supabase utilizzano parametri con il prefisso p_ (convenzione del progetto). Ad esempio, p_start_date, p_end_date, p_metric_type. Queste RPC eseguono i calcoli di aggregazione direttamente in PostgreSQL — molto più performante che recuperare migliaia di righe lato client.

La dashboard è protetta da una verifica del ruolo admin a livello del middleware Next.js. Solo gli utenti con il ruolo admin in Supabase Auth possono accedervi.

Cos'è l'AlertService e perché è critico in produzione?

La dashboard è per quando sei davanti al tuo schermo. Ma gli incidenti non aspettano che tu apra la dashboard. L'AlertService è il mio sistema di monitoraggio automatico che mi invia un'email quando succede qualcosa di anomalo.

Ecco gli avvisi configurati:

• Fallback LLM attivato: Quando il modello principale (tramite OpenRouter) fallisce e il fallback prende il sopravvento. Questo indica un problema con il provider o un picco di carico.
• Errori ripetuti pipeline vocale: Se lo STT o il TTS falliscono più di X volte in Y minuti, ricevo un'email. Questo può indicare un guasto di Deepgram o un problema di quota OpenAI.
• Rate limiting eccessivo: Se un utente o un IP attiva ripetutamente il rate limiter, potrebbe trattarsi di un abuso o di un bot.
• Fallimento dell'iscrizione: Se il flusso di iscrizione (email o QR code) fallisce per più utenti, probabilmente c'è un bug.

Le email vengono inviate tramite Resend, un servizio di email transazionali semplice e affidabile. Ogni avviso viene anche registrato in una tabella Supabase per la cronologia — posso trovare la cronologia degli incidenti nella dashboard admin.

Come implementare GA4 con il Consent Mode RGPD?

Il RGPD (Regolamento Generale sulla Protezione dei Dati) è non negoziabile per un sito europeo. Ciò significa: nessun tracciamento senza consenso esplicito. Google Analytics 4 supporta nativamente il Consent Mode, un meccanismo che adatta il suo comportamento in base al consenso dell'utente.

Ecco come funziona in tamsiv.com:

1. Inizializzazione in modalità "denied": GA4 viene caricato all'avvio del sito, ma con analytics_storage: 'denied' e ad_storage: 'denied'. Nessun dato viene raccolto.
2. Consenso esplicito: Quando l'utente accetta i cookie analytics nel banner, il consenso viene aggiornato tramite gtag('consent', 'update', { analytics_storage: 'granted' }).
3. Modellazione: Con il Consent Mode, Google utilizza la modellazione per stimare i dati degli utenti che non hanno acconsentito. Ottieni tendenze affidabili anche se il 50% dei visitatori rifiuta il tracciamento.

Il tag GA4 (G-VVLHW673V3) viene inizializzato una sola volta, al primo caricamento della pagina. Il consenso viene persistito in un cookie first-party e ripristinato ad ogni visita. Se l'utente cambia idea, può modificare le sue preferenze nel banner dei cookie accessibile dal footer.

Come progettare un cookie consent conforme al RGPD?

Il banner dei cookie di TAMSIV ha 3 toggle, ognuno con un ruolo preciso:

• Necessari (sempre attivi, non disattivabili): Sessione auth, preferenze di lingua, consenso ai cookie stesso. Senza questi cookie, il sito non funziona.
• Analytics (disattivati di default): GA4, metriche di navigazione Supabase. Attivi solo dopo il consenso.
• Marketing (disattivati di default): Previsti per il futuro (retargeting, pixel pubblicitari). Disattivati per ora perché non utilizzati.

Un punto spesso trascurato: il versioning del consenso. Se la politica dei cookie cambia (aggiunta di un nuovo tracker, modifica delle finalità), il banner deve riapparire per tutti gli utenti, anche quelli che hanno già acconsentito. Ho implementato questo con un numero di versione memorizzato nel cookie di consenso. Quando la versione cambia, il banner viene visualizzato di nuovo.

Perché utilizzare un doppio tracciamento GA4 + Supabase?

GA4 è eccellente per le metriche web standard: visualizzazioni di pagina, frequenza di rimbalzo, fonti di traffico, conversioni. Ma ci sono metriche che GA4 non può catturare, o non abbastanza finemente:

• Percorso di conversione dettagliato: Il percorso esatto di un visitatore dalla landing page all'iscrizione, con le interazioni intermedie (clic CTA, apertura FAQ, cambio di lingua).
• Metriche di business: Numero di attività create tramite web vs app mobile, tasso di completamento delle attività, attività di gamification.
• Attribuzione multi-dispositivo: Un utente che scopre il sito su desktop e scarica l'app su mobile. GA4 non fa questo collegamento. Supabase, con l'UUID di auth, sì.

Il tracciamento Supabase funziona con un UUID anonimo per visitatore (generato al primo caricamento, memorizzato nel localStorage). Ogni interazione significativa viene registrata in una tabella Supabase. Quando il visitatore si iscrive, l'UUID anonimo viene collegato al suo account auth — il che permette di ricostruire il percorso completo, dal primo clic all'iscrizione.

Questo doppio tracciamento mi offre due letture complementari: GA4 per le tendenze macro (da dove provengono i visitatori, quali pagine performano) e Supabase per gli insight micro (qual è il percorso tipico che porta a una conversione).

Quali metriche seguire in priorità per un'app mobile?

Quando inizi, sei tentato di misurare tutto. Cattiva idea — ti perdi nei dati senza agire. Ecco le metriche che seguo in priorità nella dashboard TAMSIV:

1. DAU (Daily Active Users): Il battito dell'app. Se diminuisce, qualcosa non va.
2. Tasso di retention G1/G7/G30: Quanti utenti tornano. Questa è la metrica più importante per un prodotto di produttività.
3. Tasso di completamento della prima attività: I nuovi utenti riescono a creare la loro prima attività? Se no, l'onboarding ha un problema.
4. Conversione Free → Pro: Il nervo della guerra. Quanti utenti gratuiti diventano a pagamento, e dopo quanti giorni di utilizzo.
5. Tasso di errore della pipeline vocale: La percentuale di conversazioni vocali che falliscono. Deve rimanere sotto il 2%.

Ognuna di queste metriche ha il suo grafico nella dashboard, con una tendenza su 7 giorni e 30 giorni. Un sistema di soglie colorate (verde/arancione/rosso) mi permette di vedere a colpo d'occhio se tutto va bene.

Come gli avvisi email hanno salvato la mia produzione?

Esempio concreto: un sabato sera, ho ricevuto un'email "Fallback LLM attivato — 12 volte in 15 minuti". Il modello principale su OpenRouter era sovraccarico. Senza avviso, l'avrei scoperto lunedì guardando le metriche. Grazie all'avviso, ho verificato che il fallback funzionasse correttamente (funzionava) e ho potuto comunicare proattivamente se necessario.

Un altro esempio: un picco di rate limiting su un IP specifico. Indagando, ho scoperto uno script automatizzato che tentava di creare account in massa. Il rate limiter aveva fatto il suo lavoro, ma l'avviso mi ha permesso di bloccare l'IP e di rafforzare la protezione.

L'AlertService è la mia rete di sicurezza. Non sostituisce il monitoraggio (uso anche i log Railway per il backend), ma mi avvisa degli incidenti più critici senza che io debba monitorare attivamente.

FAQ

È necessaria una dashboard admin fin dal lancio?

Non necessariamente dal giorno 1, ma appena hai utenti in produzione, sì. L'ho costruita qualche settimana prima del lancio e mi ha salvato più volte. Al minimo, configura gli avvisi email — è più urgente della dashboard visiva.

GA4 è compatibile con il RGPD senza consenso?

No. Anche con il Consent Mode in modalità "denied", GA4 invia ping anonimi a Google. Per essere al 100% conforme, devi mostrare un banner cookie e caricare GA4 solo dopo il consenso, oppure utilizzare il Consent Mode che adatta il comportamento. Il Consent Mode è la soluzione raccomandata da Google e accettata dalla maggior parte delle DPA europee.

Perché Recharts piuttosto che Chart.js o D3 direttamente?

Recharts è un wrapper React attorno a D3. Il vantaggio: i grafici sono componenti React dichiarativi, non codice imperativo. È più naturale in un progetto Next.js. Chart.js funziona anche, ma richiede più codice di integrazione con React.

Quanto costa il sistema di avvisi email con Resend?

Il piano gratuito di Resend include 3000 email al mese. Per gli avvisi (qualche decina al mese in funzionamento normale), è ampiamente sufficiente. Il costo è quindi zero per un piccolo progetto in produzione.

Il tracciamento Supabase non è un doppione di GA4?

No, misurano cose diverse. GA4 eccelle sul traffico web (fonti, comportamento, conversioni). Supabase misura il comportamento nell'app (attività create, funzionalità utilizzate, percorsi multi-dispositivo). I due sono complementari, non ridondanti.