Analytics self-hosted su VPS: quale scegliere

Quale strumento di analisi web self-hosted conviene eseguire su un VPS?

L’analisi web self-hosted si divide in due famiglie. Scegliere quella sbagliata incide più della scelta del prodotto sbagliato. Una famiglia esegue un piccolo script nel browser del visitatore e memorizza i dati riportati dallo script. L’altra legge il log degli accessi che il web server scrive già. Tutto il resto, incluso il database e la memoria necessaria, dipende da questa scelta.

La risposta breve per un server di piccole dimensioni. GoatCounter e Medama funzionano con 1 GB, perché ciascuno è costituito da un solo processo che usa un solo file. Umami aggiunge un container Postgres e offre una dashboard leggibile anche da chi non ha competenze tecniche. Plausible Community Edition e Rybbit usano entrambi ClickHouse, quindi pianifica almeno 2 GB di RAM. Matomo è il prodotto completo e richiede un server dimensionato in base al traffico. GoAccess non aggiunge nulla alla pagina, perché legge un log già esistente.

Tag script o log del server: cosa può vedere ciascuno

Un tag script misura i browser. La pagina viene caricata, lo script viene eseguito e invia una richiesta al collector. Qualsiasi problema interrompa questa catena è invisibile: JavaScript disabilitato, una filter list che blocca la richiesta, una richiesta al collector non riuscita oppure un crawler che non esegue gli script.

Un parser dei log misura le richieste. Il web server scrive una riga per ogni richiesta, indipendentemente dall'installazione di altri componenti, quindi i dati sono già sul disco. Rileva ogni crawler e ogni accesso a un file che non contiene alcun tag script. Non può vedere cosa è successo all'interno del browser e non può rilevare una pagina fornita dalla cache del browser o da una CDN (content delivery network) davanti al server, perché quella richiesta non ha mai raggiunto il server.

I due numeri non coincideranno e nessuno dei due è necessariamente errato. Matomo può usare entrambi i metodi e documenta quali dati l'importazione dei log non fornisce rispetto al tracker JavaScript: risoluzione dello schermo e titoli delle pagine, eventi, content tracking, heatmap, registrazioni delle sessioni e analisi dei moduli. Questo è il costo del conteggio delle richieste invece dei browser.

Il traffico dei bot costituisce l'altra metà della differenza. I conteggi basati sui log includono i crawler, a meno che non vengano filtrati, e su un sito ordinario la quota dei crawler è abbastanza elevata da modificare le conclusioni. GoAccess e l'importazione dei log di Matomo filtrano entrambi i bot conosciuti. Nessuno dei due può filtrare un crawler che falsifica il proprio user agent. Per questo è opportuno associare qualsiasi conteggio basato sui log a blocco dei crawler AI sul server e leggere il log dopo il blocco, non prima.

GoAccess: analisi dei log disponibili

Installalo dal repository Debian e Ubuntu ufficiale del progetto, perché i pacchetti delle distribuzioni sono in ritardo rispetto alle release.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

Indica quindi il log come input e scrivi un report statico.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

Il comando non riesce con Permission denied per un utente normale, perché su Ubuntu il log di nginx appartiene a root e al gruppo adm. Aggiungi il tuo utente a quel gruppo con sudo usermod -aG adm $USER, quindi esegui il logout e accedi di nuovo, perché l'appartenenza ai gruppi viene letta al login. Esegui id e verifica che adm compaia nell'elenco prima di riprovare.

Un report basato soltanto sul log attivo include solo le righe che logrotate non ha ancora spostato. Le richieste di ieri si trovano in access.log.1 e quelle precedenti sono compresse, quindi una vista settimanale deve leggere anche i file ruotati.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

È disponibile anche una modalità live, --real-time-html, che aggiorna la pagina tramite WebSocket. Questa modalità richiede una seconda porta e una regola proxy dedicata. Per la maggior parte dei siti è sufficiente un report orario generato da cron, con una superficie da proteggere più ridotta.

GoatCounter: un binario Go e un file SQLite

GoatCounter viene distribuito come binario compilato staticamente, quindi non è necessario installare un runtime. Scarica una build dalla pagina delle release ed eseguila, oppure usa l'immagine.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

Eseguito come binario, goatcounter serve resta in ascolto sulla porta 8080 e crea il database SQLite in ./goatcounter-data/db.sqlite3. Crea il primo sito dalla riga di comando invece di usare la procedura guidata web quando l'istanza è già dietro un proxy.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

Può gestire direttamente il certificato con goatcounter serve -listen=:443 -tls=tls,rdr,acme, usando ACME (automatic certificate management environment). Questa modalità è utile su un server che non esegue altri servizi. Se nginx o Caddy gestisce già la porta 443, lascia GoatCounter sulla porta 8080 e inoltra le richieste tramite proxy. Lo script di tracciamento ha dimensioni di circa 3.5K, secondo il dato fornito dal progetto, ed è disponibile anche un pixel di tracciamento per le pagine che non eseguono JavaScript. Se SQLite diventa il limite su un sito molto trafficato, lo stesso binario supporta PostgreSQL con goatcounter serve -db 'postgresql+dbname=goatcounter'. I backup consistono nella copia di un file: è questo il principale vantaggio di questa architettura.

Medama: un singolo container che dichiara 256 MB

Medama è l'opzione più recente basata su un singolo binario. Per progettazione non usa cookie e il progetto dichiara un tracker inferiore a 1 KB, oltre a piccoli siti eseguiti su macchine virtuali con 256 MB di memoria. Si tratta delle dichiarazioni pubblicate dal progetto, non di valori misurati per questa guida.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

Il comando ufficiale pubblica la porta come 8080:8080. Il prefisso di loopback indicato sopra è intenzionale e la sezione sul reverse proxy spiega il motivo. Il primo accesso usa admin con la password CHANGE_ME_ON_FIRST_LOGIN, e il nome di quella password è l'istruzione.

Esiste una modalità di errore documentata che può trarre in inganno. L'accesso funziona solo tramite HTTPS o su localhost. Se configuri il proxy prima del certificato, il modulo rifiuta una password corretta senza stampare il motivo. Completa prima la configurazione di TLS (transport layer security), quindi accedi.

Umami: PostgreSQL e una dashboard riconoscibile

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

Avvia l'applicazione sulla porta 3000 con un container PostgreSQL affiancato. La documentazione indica PostgreSQL v12.14 come versione minima e Node.js 18.18 o successiva se invece compili dai sorgenti. È disponibile un'immagine precompilata, docker.umami.is/umami-software/umami:postgresql-latest, che richiede DATABASE_URL impostata su un database già in esecuzione.

Il primo accesso usa admin con la password umami. Cambiala prima di puntare il DNS al server, perché l'istanza è raggiungibile da Internet non appena il record risolve e il proxy risponde. Per i dettagli di Compose, i file di ambiente e la policy di riavvio, consulta uno stack Docker Compose su un VPS invece di copiare uno stack che non hai letto.

L'ingombro è quello di un processo Node più Postgres. È maggiore rispetto a un singolo binario e molto minore rispetto a qualsiasi soluzione che esegua ClickHouse.

Plausible Community Edition: ClickHouse determina la RAM minima

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

La versione v3.2.1 è quella corrente ad agosto 2026 e il comando clone la fissa intenzionalmente. Lo stack comprende tre componenti: l'applicazione, Postgres per gli account e le impostazioni e ClickHouse per i dati degli eventi. SECRET_KEY_BASE deve essere una stringa di almeno 64 byte, come quella prodotta dalla chiamata openssl.

I requisiti di Plausible indicano almeno 2 GB di RAM, in modo che ClickHouse e l'applicazione non vengano terminati dall'out of memory killer, e una CPU che supporti SSE 4.2 o NEON, richiesto da ClickHouse. Conviene verificare il secondo requisito prima dell'acquisto. È una delle differenze pratiche da considerare quando si sceglie tra un VPS ARM e uno x86. ClickHouse usa inoltre tutta la memoria che considera disponibile. Su un server condiviso, imposta quindi un limite come descritto in limitare la memoria dei container in Compose.

BASE_URL deve corrispondere esattamente all'URL pubblico. Se il valore non è corretto, l'accesso viene eseguito ma l'applicazione reindirizza all'host sbagliato. Il cookie di sessione viene quindi scritto per un dominio diverso da quello aperto nel browser e si torna al modulo di accesso senza alcun messaggio di errore.

Il file Compose fornito non pubblica alcuna porta, perché prevede l'uso di un proxy davanti all'applicazione. Aggiungi un override che pubblichi la porta predefinita dell'applicazione soltanto sull'interfaccia di loopback.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo: il prodotto completo e il server richiesto

Matomo funziona con PHP e MySQL o MariaDB. Questo significa che si adatta al classico stack web, non a uno stack di container. È anche l'unico strumento qui considerato che pubblica indicazioni sull'hardware in base al volume di traffico.

[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

Questi sono i requisiti minimi pubblicati da Matomo ad agosto 2026, non misurazioni eseguite per questa guida. Fino a 100,000 visualizzazioni di pagina al mese richiede 2 core CPU, 2 GB di RAM e 50 GB di SSD; un unico server ospita sia l'applicazione sia il database. A 1M/month servono 8 GB di RAM e 250 GB di disco. A 10M/month Matomo raccomanda due server. L'ultima riga mostra il server del database: 16 GB di RAM e 400 GB di disco. Confrontate questi valori del disco con le opzioni basate su un singolo file binario, in cui l'intero dataset è contenuto in un unico file SQLite.

L'archiviazione dei report è l'aspetto che sorprende più spesso. Per impostazione predefinita, Matomo genera i report quando qualcuno apre il dashboard. Con la crescita dei dati, il dashboard diventa quindi più lento e alla fine va in timeout. La correzione documentata consiste nel disattivare l'archiviazione avviata dal browser nelle impostazioni generali e nell'eseguire invece l'archiver tramite cron, usando l'utente proprietario dei file Matomo e avviando il comando dalla directory di Matomo.

php console core:archive --url=https://analytics.example.com

Matomo conserva inoltre le tabelle dei log grezzi accanto alle tabelle dei report elaborati e può eliminare i dati grezzi e i report meno recenti secondo una pianificazione. Attivate questa funzione durante l'installazione, non quando il disco è già pieno. Matomo può anche importare i log degli accessi del server. È quindi l'unico prodotto qui considerato che copre entrambe le famiglie contemporaneamente.

Rybbit e gli stack più recenti

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit è un progetto recente con una dashboard moderna. Lo script di configurazione scrive il file di ambiente e avvia lo stack con Docker Compose. Utilizza ClickHouse e include Caddy come server web autonomo. Caddy occupa la porta 443 e richiede un certificato per il dominio passato allo script. Su un server in cui nginx utilizza già la porta 443, lo script non potrà mettersi in ascolto su quella porta. In questo caso, usa la procedura manuale basata su Compose del progetto e pubblicalo dietro il proxy esistente. La documentazione indica almeno 2 GB di RAM, test eseguiti su Ubuntu 24 LTS e ARMv8.2-A o versione successiva sui sistemi ARM, a causa dei requisiti di ClickHouse.

La considerazione da fare per qualsiasi progetto giovane è semplice: le funzionalità vengono aggiunte rapidamente, ma altrettanto rapidamente possono arrivare modifiche incompatibili. Fissa un tag, leggi le note di rilascio prima di eseguire il pull e crea prima un backup del database.

Conservazione dei dati e crescita dello spazio su disco: misurale sul tuo server

La crescita dello spazio su disco dipende da ciò che lo strumento salva per ogni evento. GoatCounter aggrega gli accessi in contatori, quindi il relativo file cresce più in base al numero di pagine distinte e di giorni che al volume grezzo. Umami e Matomo salvano una riga per ogni evento, mentre Matomo aggiunge le tabelle dei report elaborati a quelle dei dati grezzi. ClickHouse salva gli eventi per colonna e li comprime in modo aggressivo. Per questo Plausible gestisce volumi che metterebbero in difficoltà un database basato su righe.

Questa guida non indica un valore in megabyte per milione di visualizzazioni di pagina, perché non ne ha misurato uno sul tuo traffico. Rileva il valore direttamente. Adatta i nomi del servizio e dell'utente al tuo file Compose.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

Annota il valore, aspetta una settimana, rilevalo di nuovo e dividi la differenza per le visualizzazioni di pagina riportate dal dashboard per quella settimana. Questo valore riflette il tuo sito e il relativo filtraggio dei bot, quindi è più utile di qualsiasi media pubblicata. Imposta quindi un limite di conservazione dei dati mentre il valore è ancora contenuto. Un disco pieno arresta tutti i servizi sul VPS, non soltanto l'analisi, ed è il motivo principale per cui conviene mantenere il volume del database in un percorso che df -h monitorerà. Questo rischio richiede maggiore attenzione su un server che contiene già dati voluminosi, perché un server fotografico self-hosted esaurirà lo spazio su disco molto prima che qualsiasi database di analisi si avvicini al limite.

Comportamento dietro un reverse proxy su un sottodominio

Posiziona il collector su un sottodominio del sito che misura, ad esempio stats.example.com. In questo modo la richiesta al collector è considerata first-party e non viene bloccata dalle regole del browser che limitano le richieste third-party.

Associa l'applicazione all'interfaccia loopback quando pubblichi la porta del container. Docker inserisce le proprie regole firewall prima di ufw, quindi un container pubblicato come -p 3000:3000 è raggiungibile da Internet anche se ufw status indica che la porta è negata. Esegui il test da un'altra macchina con curl http://SERVER_IP:3000 per ottenere la dashboard. Se la porta è pubblicata come -p 127.0.0.1:3000:3000, lo stesso test restituisce Connection refused e soltanto il proxy può raggiungerla.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Gli header di forwarding sono indispensabili in questo caso. Senza X-Forwarded-For, ogni visita risulta provenire da 127.0.0.1: il report per paese resta vuoto e il numero di visitatori unici tende a ridursi a uno. Ogni progetto stabilisce quale header considera attendibile e con quale impostazione, quindi consulta una volta la documentazione relativa al proxy invece di dare per scontato il comportamento. Caddy imposta autonomamente questi header e un Caddyfile per lo stesso scopo richiede due righe.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

Se non hai ancora scelto un proxy, il confronto tra nginx, Caddy e Traefik spiega quale soluzione è adatta a un singolo server con pochi sottodomini.

Ti serve ancora un banner per i cookie se esegui i servizi sul tuo server?

Il self-hosting cambia chi conserva i dati. Non cambia ciò che la legge stabilisce sui dati. È importante distinguere due regole. La regola del consenso prevista dalla direttiva ePrivacy riguarda la memorizzazione o la lettura di qualsiasi dato sul dispositivo del visitatore. Uno strumento che non imposta cookie e non scrive nulla nel local storage non rientra in quello specifico requisito. Il GDPR riguarda invece il trattamento dei dati personali. Un indirizzo IP è un dato personale, quindi servono comunque una base giuridica, un limite di conservazione e una risposta quando qualcuno chiede quali dati conservi su di lui.

Plausible, Umami, GoatCounter e Medama non impostano cookie per impostazione predefinita. I dati derivati da ciascun prodotto variano in base al progetto e possono cambiare tra una versione e l'altra. Consulta quindi la documentazione sulla privacy del progetto, non un riepilogo. Matomo include l'anonimizzazione degli IP e un endpoint per l'opt-out, che devi abilitare nell'interfaccia di amministrazione.

Le autorità di regolamentazione arrivano a conclusioni diverse nei vari Paesi. La CNIL francese, per esempio, pubblica le condizioni in presenza delle quali la misurazione dell'audience può essere esente dal consenso. Questa sezione è un riepilogo informativo e non costituisce consulenza legale. Per un sito reale con utenti reali, consulta un avvocato nella tua giurisdizione.

Un aspetto spesso trascurato è che anche un access log costituisce un dato personale. GoAccess non aggiunge alcuno script alla pagina, ma tratta comunque gli indirizzi IP. Le statistiche basate sui log non sono quindi automaticamente escluse dalle regole.

Blocco degli annunci e perché i numeri diminuiranno

Le liste di filtri verificano il nome host e il modello dell'URL. Un prodotto di analytics in hosting è facile da identificare perché tutti lo caricano dallo stesso nome host noto. Spostare il collector su un sottodominio proprio rimuove quel nome host dalla richiesta. Servire lo script da un percorso scelto da te rimuove il nome file noto. Entrambe le modifiche cambiano gli elementi su cui una lista deve eseguire la corrispondenza.

Questo articolo non dichiara un tasso di rilevamento perché non ne ha misurato uno. La percentuale di visitatori che blocca una determinata configurazione dipende dal pubblico. Il pubblico degli sviluppatori blocca molto più di un pubblico generico. Misura invece il divario del tuo sito. Nella stessa settimana, conta con GoAccess le richieste delle pagine HTML nel log degli accessi e confrontale con le pageview riportate dal tuo strumento basato su script. La differenza corrisponde, sul tuo sito, alle visite bloccate più le pagine servite dalla cache.

Prevedi che i totali cambino il giorno in cui passi da un prodotto in hosting. Considera inoltre che una parte di questa variazione potrebbe non avere alcun rapporto con il blocco. I prodotti non definiscono allo stesso modo una pageview, non concordano sul fatto che un cambio di route all'interno di una single-page application conti come una pageview e usano criteri diversi per stabilire quando termina una sessione. Confronta le tendenze su più settimane prima di concludere che il traffico è diminuito.

Quale strumento scegliere per ogni sito

• Un sito personale o un blog con circa 50.000 visualizzazioni di pagina al mese o meno: GoatCounter o Medama su un VPS da 1 GB, con backup costituiti da una copia dei file.
• Un sito in cui non è possibile aggiungere uno script, oppure con un pubblico che blocca gli script in modo sistematico: GoAccess sui log esistenti, eseguito secondo una pianificazione.
• Un sito di una piccola azienda il cui pannello deve essere consultato da un'altra persona: Umami, con il relativo container Postgres.
• Un sito per cui servono obiettivi e funnel, su un server con almeno 2 GB di RAM: Plausible Community Edition oppure Rybbit, se si preferisce un pannello più recente e si accetta un progetto ancora giovane.
• Molti siti, molti account utente oppure la necessità di conservare i dati grezzi secondo una propria policy di retention: Matomo, dimensionato in base alle indicazioni pubblicate sopra.

Inizia con lo strumento più semplice che risponde alla domanda effettiva. In seguito, passare da GoatCounter a Plausible richiede un sottodominio e comporta la perdita di parte dello storico. Passare da Matomo a un altro strumento richiede invece una migrazione che probabilmente sarà complessa. Se stai ancora decidendo cos'altro installare sullo stesso server, la panoramica più ampia sul self-hosting illustra cosa può essere eseguito insieme a questo strumento. Se invece ti serve il tracing a livello di richiesta di un'applicazione, anziché il conteggio dei visitatori, un servizio di observability self-hosted è lo strumento adatto.

FAQ

L'analisi self-hosted elimina la necessità di un banner per i cookie?

No, e le due questioni sono separate. La regola sul consenso prevista dalla direttiva ePrivacy riguarda la memorizzazione o la lettura di dati sul dispositivo del visitatore. Di conseguenza, uno strumento che non imposta cookie e non scrive nulla nel local storage non rientra in quello specifico requisito. Il GDPR è una norma diversa e disciplina il trattamento dei dati personali. Un indirizzo IP è un dato personale, quindi serve comunque una base giuridica e un limite di conservazione anche senza cookie. Con il self-hosting, i dati vengono trasferiti sul tuo server e tu diventi il soggetto responsabile del trattamento. Verifica le indicazioni dell'autorità di controllo competente e chiedi consulenza legale per il tuo caso.

Quanta RAM richiede l'analisi self-hosted su un VPS?

Il requisito principale è il datastore, non la dashboard. GoatCounter e Medama vengono eseguiti come un unico processo e usano un solo file. La documentazione di Medama indica che i siti di piccole dimensioni possono funzionare su macchine con 256 MB. Umami aggiunge un container Postgres accanto a un'applicazione Node. Plausible Community Edition e Rybbit usano entrambi ClickHouse, ed entrambi i progetti indicano almeno 2 GB. Le indicazioni ufficiali di Matomo partono da 2 core CPU e 2 GB di RAM per un massimo di 100,000 visualizzazioni di pagina al mese.

Perché i numeri del mio sistema di analisi self-hosted sono inferiori a quelli dello strumento che ho sostituito?

Le cause sono due, ed entrambe sono reali. Le liste di filtri bloccano alcune richieste al collector, quindi ogni strumento basato su script perde queste visite. Inoltre, i prodotti contano in modo diverso: la definizione di visualizzazione di pagina e il momento in cui termina una sessione variano da uno strumento all'altro. Confronta una settimana di richieste di pagine HTML nel log degli accessi con la stessa settimana di visualizzazioni di pagina registrate dallo script. La differenza comprende le visite bloccate e le pagine servite dalla cache. È una misura ricavata dal tuo sito, non una percentuale pubblicata da altri.

Posso eseguire Plausible o Rybbit su un VPS ARM?

Entrambi usano ClickHouse, che richiede SSE 4.2 su x86 o NEON su ARM. I requisiti di Plausible lo specificano esattamente, mentre la documentazione di Rybbit indica che i sistemi ARM richiedono ARMv8.2-A o versioni successive. I core server ARM attuali soddisfano questo requisito, quelli più vecchi no. Il problema si manifesta quando ClickHouse rifiuta di avviarsi con un errore relativo al set di istruzioni, non come un errore nel log dell'applicazione. Su una macchina ARM di piccole dimensioni, gli strumenti che usano un singolo file evitano il problema, perché nessuno di essi esegue ClickHouse.

Devo analizzare i log del server invece di usare uno script di tracciamento?

Usa l'analisi dei log quando non puoi aggiungere uno script, quando il tuo pubblico usa molti strumenti di blocco o quando vuoi un conteggio che includa i crawler. GoAccess legge un log che il server scrive già, quindi non aggiunge peso alla pagina e non richiede un database. Perdi tutto ciò che avviene nel browser e non rilevi le pagine servite da una CDN o dalla cache del browser, perché la richiesta non raggiunge mai il server. Molti siti usano entrambe le soluzioni e le considerano due misurazioni diverse.