Vuoi anche tu delle Analytics per il tuo sito senza pagare Google? Allora Umami è la scelta per te.
Il tuo sito perde il 30-50% del traffico nei report di Google Analytics, sei a rischio multe GDPR e stai regalando i dati dei tuoi visitatori a un'azienda di advertising. C'è un'alternativa: si chiama Umami, si installa con un file di 20 righe e ti dà l'80% delle informazioni che ti servono davvero.
Il numero che ti mentono
Apri GA4. Guarda le visite di questa settimana.
Ora moltiplica per 1.5-1.7.
Quello è il numero vero.
Tre filtri si sovrappongono senza che tu lo sappia:
- Consenso cookie: in UE il 40-60% rifiuta → non viene contato
- Ad-blocker: bloccano il 25-45% delle richieste GA
- Campionamento: sopra certe soglie, GA4 smette di contare ogni evento e stima
Nessun avviso. Nessuna barra di errore. Solo numeri che sembrano giusti ma non lo sono.
Il costo "gratuito"
GA4 è gratis. Il prezzo è:
- I tuoi dati → alimentano il targeting pubblicitario di Google
- La tua compliance → banner, DPA, DPIA, valutazioni: $5.000-18.000/anno
- La tua performance → 45 KB + dipendenze che rallentano i Core Web Vitals
- La tua libertà → dati su server USA, soggetti al CLOUD Act
Nel 2022 il Garante italiano ha dichiarato GA4 non conforme. Non sei solo: 8 paesi UE hanno fatto lo stesso.
L'alternativa: 2 KB, zero cookie, dati tuoi
Umami è analytics open-source (MIT) che gira sul tuo server.
| Umami | GA4 | |
| Cookie | Nessuno | Sì |
| Script | ~2 KB | ~45 KB + deps |
| GDPR | Conforme out of the box | Banner + DPA + DPIA |
| Dati | Sul tuo server | Su server Google |
| Campionamento | Mai | Sì |
| Costo reale | ~$5/mese (VPS) | $5.000+/anno (compliance) |
| Traffico perso | ~0% | 30-50% |
Cosa ti dà: visite, pageview, bounce rate, referral, paese, dispositivo, eventi custom, session replay, heatmap, API REST, multi-sito.
Cosa non ti dà: remarketing Google Ads, attribution enterprise. Se ti servono, GA4 resta l'opzione. Per il 90% dei siti, basta e avanza.
Installazione
Hai un VPS con Docker? Perfetto.
L'installazione è descritta passo per passo nella documentazione ufficiale — in pratica:
- Clona il repo (o usa l'immagine Docker pre-built)
- Crea un .env con password e secret
- docker compose up -d
- Accedi su http://localhost:3000 con admin / umami
- Cambia subito la password
Per HTTPS, metti un reverse proxy (Caddy, Nginx, Cloudflare Tunnel) davanti al port 3000. Caddy lo fa in 3 righe con certificato automatico.
Se vuoi la via più semplice: Railway, Render o Northflank hanno deploy one-click con free tier.
Il docker-compose.yml ufficiale è già nel repo GitHub — non devi scriverlo tu.
Configurare i tuoi siti (2 minuti)
Questa è la parte che ti fa sentire stupido GA4.
1. Nella dashboard: Settings → Websites → Add Website
- Nome: Il mio blog
- URL: https://tuosito.com
- Clicca Create
2. Copia lo snippet che ti mostra:
<script defer src="https://analytics.tuosito.com/script.js" data-website-id="abc123"></script>
3. Incollalo prima di </head> nel tuo sito.
4. Fatto.
Entro 30 secondi vedi la prima visita (la tua).
Evento custom?
<button onclick="umami.track('download_pdf')">Scarica</button>
Niente "event parameter mapping", niente wizard da 47 minuti.
Backup (una riga)
docker compose exec -T umami-db pg_dump -U umami umami | gzip > backup-$(date +%F).sql.gz
In crontab, una volta a settimana. Pesi pochi MB.
Il test che ti cambia la prospettiva
Non "migrare". Aggiungi lo snippet di Umami accanto a GA4 per una settimana.
Confronta i numeri.
La differenza non è che Umami sia più accurato. È che GA4 ti stava nascondendo metà dei visitatori e tu non lo sapevi.
Il tuo sito ha già i dati. Li stai guardando da dietro un vetro appannato.
docker compose up -d e togli il vetro.
Perché Umami è GDPR-compliant (e GA4 no)
Non è una questione di "impostazioni" o "configurazione". È architettura.
Cosa fa tecnicamente Umami
Cosa fa tecnicamente Umami | Come | Perché conta per il GDPR |
| Nessun cookie, nessun ID persistente nel browser | Session ID calcolata server-side (hash di IP + UA + salt mensile) | Nessun "storage di informazioni" nel dispositivo → ePrivacy non si applica |
| IP mai memorizzato | Usato in memoria per geolocalizzazione, poi scartato | L'IP è dato personale (Art. 4.1). Non lo conservi → non lo "tratti" |
| Salt rotante | Mensile (sessioni), orario (visite) | Non puoi collegare "l'utente di ieri" a "quello di oggi" → non è identificativo persistente |
| Nessun cross-site tracking | L'hash è scoped al tuo website ID | Non costruisci profili, non insegui l'utente |
| Self-hosted | Nessun trasferimento extra-EEU | Elimina il problema Schrems II / CLOUD Act |
| Rispetta DNT (opt-in) | data-do-not-track="true" | Buone pratiche |
Perché GA4 non può fare lo stesso
GA4 per design deve:
- Impostare cookie di persistenza (per sessioni multi-giorno)
- Memorizzare un Client ID univoco e permanente
- Trasferire i dati a server Google negli USA
- Condividere i dati con il suo ecosistema advertising
Nessuna di queste cose è opzionale. È il modello di business.
Il punto tecnico che i legali ignorano
La sessionKey di Umami è tecnicamente un identificatore pseudonimo (hash di IP + UA + salt). In teoria, sotto l'Art. 4(3) GDPR, un "qualsiasi identificatore" a cui si può collegare un individuo è dato personale.
Ma in pratica:
- Il salt cambia ogni giorno → non è persistente
- Non è univoco a livello globale → due visitatori dallo stesso IP + UA lo stesso giorno condividono la chiave
Il caveat (onestà intellettuale)
Se attivi Session Replay o mandi dati PII negli eventi custom (es. nomi, email), la compliance svanisce. Per la configurazione default (pageview + eventi anonimi), sei a posto.
Cosa ti serve nella privacy policy: una riga. "Questo sito utilizza un sistema di analytics self-hosted che non raccoglie dati personali e non utilizza cookie." Fatto. Niente banner, niente DPA, niente DPIA.
