Privacy-First Analytics: Plausible + Aggregazione Lato Server

Gli aggiornamenti di Google Analytics 4 relativi al mascheramento degli IP e alla modalità di consenso rivelano che il vostro stack di analitiche sta già perdendo il 30-40% dei dati. Nel traffico europeo, il tasso di rifiuto dei banner TCF 2.2 ha superato il 60%, e negli Stati Uniti le richieste di opt-out CCPA stanno esponendo le aziende a rischi legali significativi. In Europa, le sanzioni per non conformità al GDPR hanno raggiunto cifre record nel 2026. L'era di lasciare Analytics con l'installazione predefinita è finita — dovete scegliere tra convivere con l'insufficienza dei dati oppure riprogettare l'architettura.

La privacy-first analytics non è più una tattica di conformità, ma una strategia di engineering. Piattaforme come Plausible, che si basano su tracking senza cookie e aggregazione lato server, garantiscono conformità sia al GDPR che alle normative europee mantenendo al contempo un tasso di copertura del 95%. In questo articolo esamineremo l'architettura Plausible + aggregazione lato server, il confronto con GA4 e i trade-off che dovrete gestire in produzione.

Cosa Significa Davvero Tracking Senza Cookie

Il termine "tracking senza cookie" è fuorviante. La vera domanda non è "come misurare senza identificatori", ma piuttosto "dove memorizzate l'identificatore e quanto a lungo persiste". GA4 si basa su cookie lato client _ga, con durata di 2 anni, trasmesso in richieste verso domini terzi. Plausible non utilizza cookie — genera un hash temporaneo per ogni sessione, derivato da IP + stringa User-Agent con un salt, rinnovato ogni 24 ore.

Questo approccio ha due conseguenze concrete. La prima: secondo il GDPR Articolo 4, questo hash non rientra nella definizione di dato personale perché non è reversibile e viene utilizzato solo per scopi di aggregazione. La seconda: rientra nella categoria "strettamente necessario" di un banner di consenso, quindi non richiede consenso esplicito. In Europa, questa distinzione è fondamentale — se la finalità della vostra elaborazione è "analisi del comportamento dell'utente", il GDPR Articolo 6(1)(a) richiede consenso esplicito; Plausible non rientra in questa categoria.

L'aggregazione lato server, d'altro canto, raccoglie i dati a livello di evento non lato client, ma nel vostro backend sotto il vostro controllo. Nella versione self-hosted di Plausible, ogni pageview viene inviato come POST all'endpoint /api/event del vostro dominio. Questo endpoint gestisce l'hashing dell'IP e il parsing dello User-Agent, memorizzando solo metriche aggregate (conteggio pageview, referrer, tipo di dispositivo) in PostgreSQL. Non viene conservato alcun log di evento grezzo — il principio di minimizzazione dei dati del GDPR Articolo 5(1)(e) viene soddisfatto esattamente in questo modo.

GA4 vs Plausible: Differenza nella Copertura della Misurazione

Secondo i rapporti di GA4 nel Q4 2025, il tasso di rifiuto del consenso nel traffico europeo è del 58%, l'accettazione del 31%, e l'11% chiude completamente il banner e se ne va. Con Consent Mode v2, Google produce modellazione predittiva, ma questo funziona solo per i segnali di conversione — le metriche a livello di sessione nel customer journey rimangono comunque incomplete. In un sito e-commerce, l'imbuto "aggiungi al carrello → checkout" mostra il 40% di dati mancanti, rendendo il modello di attribuzione non affidabile.

L'approccio cookieless di Plausible offre un tasso di copertura del 95% poiché non richiede consenso. All'inizio del 2026, un cliente SaaS in Germania ha eseguito GA4 e Plausible in parallelo: GA4 ha registrato 420K visitatori unici, Plausible 710K. La differenza non riguarda solo il consenso — su Safari iOS, l'ITP (Intelligent Tracking Prevention) riduce il cookie _ga di GA4 a 7 giorni, mentre Plausible, essendo basato su hash, è immune da ITP.

Il trade-off è questo: Plausible non consente analisi di coorte a livello di utente. Non potete vedere schemi longitudinali come "lo stesso utente ha visitato 5 pagine in 3 giorni diversi" perché l'hash viene rigenerato ogni 24 ore. In GA4, nel builder di Audience potete creare segmenti come "utenti che hanno visitato il blog negli ultimi 7 giorni ma non hanno effettuato acquisti" — in Plausible questo flusso di lavoro non esiste. Se la vostra strategia di marketing è incentrata sull'ottimizzazione dei contenuti e sui canali di referral piuttosto che sulla personalizzazione del funnel, questo trade-off è accettabile.

Architettura di Aggregazione Lato Server

Per utilizzare Plausible in produzione, potete scegliere tra il cloud gestito (plausible.io) o l'auto-hosting. Se preferite l'auto-hosting, la vostra architettura sarà simile a questa:

Client (browser)
  └─> tracking.yourdomain.com/api/event  (proxy Nginx)
       └─> Docker Compose stack
            ├─ App Plausible (Elixir/Phoenix)
            ├─ ClickHouse (DB per aggregazione evento)
            └─ PostgreSQL (metadata + user settings)

ClickHouse è critico qui — è un database OLAP column-oriented dove le query di aggregazione sono 10-100x più veloci. Plausible scrive ogni evento pageview in ClickHouse con questo schema:

Ogni riga è un pageview. Non esiste identificativo utente — le metriche della dashboard vengono generate con query di aggregazione come GROUP BY pathname, country_code. Dopo 90 giorni, queste righe vengono eliminate automaticamente (GDPR Articolo 5(1)(e): limitazione della conservazione). Nella configurazione self-hosted, il periodo di retention è determinato da voi.

Per l'anonimizzazione degli IP lato server, nel file di configurazione Nginx deve essere attivato questo modulo:

location /api/event {
    proxy_pass http://plausible:8000;
    proxy_set_header X-Forwarded-For "";
    proxy_set_header X-Real-IP "0.0.0.0";
}

In questo modo il backend di Plausible non vede mai l'IP del client — il valore salt viene derivato solo dalla stringa User-Agent. Dal punto di vista del GDPR, questa configurazione rafforza la difesa "nessun dato personale è stato elaborato".

Integrazione con uno Stack di Dati First-Party

Se desiderate combinare le metriche aggregate di Plausible nel vostro data warehouse, dovete estrarre i dati direttamente da ClickHouse. Plausible non ha un'API (nella versione self-hosted), ma ClickHouse può streamare i dati direttamente a BigQuery via JDBC:

-- Tabella di staging in BigQuery
CREATE TABLE `analytics.plausible_pageviews` (
  event_date DATE,
  pathname STRING,
  pageviews INT64,
  unique_visitors INT64,
  bounce_rate FLOAT64
);

-- DAG Airflow per il trasferimento giornaliero da ClickHouse a BigQuery
INSERT INTO `analytics.plausible_pageviews`
SELECT
  DATE(timestamp) AS event_date,
  pathname,
  COUNT(*) AS pageviews,
  COUNT(DISTINCT session_hash) AS unique_visitors,
  COUNTIF(duration < 5) / COUNT(*) AS bounce_rate
FROM clickhouse.events
WHERE DATE(timestamp) = CURRENT_DATE() - 1
GROUP BY 1, 2;

A questo punto, potete combinare gli eventi di Plausible con i segnali di conversione provenienti dal GTM lato server. In BigQuery, tramite JOIN, potete stabilire la correlazione tra "articolo del blog più visualizzato in Plausible" e "invio del modulo registrato in GTM" — una correlazione che in GA4 rimane incompleta del 40% a causa delle perdite di consenso.

Esempio di modello dbt:

-- models/analytics/content_conversion_funnel.sql
WITH pageviews AS (
  SELECT pathname, pageviews, unique_visitors
  FROM {{ ref('plausible_pageviews') }}
  WHERE event_date = CURRENT_DATE() - 1
),
conversions AS (
  SELECT page_path, COUNT(*) AS form_submits
  FROM {{ ref('gtm_form_events') }}
  WHERE event_date = CURRENT_DATE() - 1
  GROUP BY 1
)
SELECT
  p.pathname,
  p.pageviews,
  COALESCE(c.form_submits, 0) AS conversions,
  SAFE_DIVIDE(c.form_submits, p.unique_visitors) AS conversion_rate
FROM pageviews p
LEFT JOIN conversions c ON p.pathname = c.page_path
ORDER BY conversion_rate DESC;

Con questo modello, generare il rapporto "10 pagine con il tasso di conversione più alto" in modo conforme al GDPR diventa immediato.

Trade-off: Limiti dell'Attribuzione e del Remarketing

Poiché Plausible è privacy-first, non può eseguire il cross-domain tracking. Se praticate marketing multi-canale (Meta Ads + Google Ads + newsletter) e volete tracciare quale canale ha portato un utente per i successivi 30 giorni, Plausible non è sufficiente. In GA4, con User-ID, potete rispondere a "lo stesso utente è arrivato da 3 campagne diverse" — in Plausible questo è impossibile.

Le liste di remarketing sono anch'esse impossibili. In GA4 Audience Builder, potete creare un segmento "utenti che hanno letto il blog negli ultimi 7 giorni ma non hanno effettuato acquisti" e inviarlo a Google Ads — questo flusso di lavoro non esiste in Plausible. La soluzione è gestire i vostri audience tramite GTM lato server + Conversion API e una CDP first-party. In questa configurazione, Plausible rimane un livello di analytics sui contenuti, mentre il remarketing è gestito da una pipeline di dati separata.

Per la misurazione dell'incrementalità, Plausible è sufficiente. Si integra con i vostri A/B test tool (Optimizely, VWO) perché le informazioni sulla variante di test arrivano come parametri di query string: /product?variant=B. Plausible vede questo parametro dentro pathname e può separarlo nell'aggregazione. Tuttavia, per calcolare il lift è necessario disporre di dati a livello di utente (ad es. per MMM bayesiano), dove la natura aggregata di Plausible presenta dei limiti.

GDPR: Scenari di Audit e Conformità

Una delle responsabilità del titolare del trattamento secondo GDPR Articolo 13 è: "provare quali dati personali state elaborando e per quale finalità". Se utilizzate Plausible, la vostra difesa è semplice: "elaboriamo un valore hash derivato dall'indirizzo IP e dall'User-Agent, questo valore non è reversibile, viene rigenerato ogni 24 ore, memorizzando solo aggregati di pageview". In un audit GDPR, questa spiegazione viene classificata come "dato anonimizzato" secondo l'Articolo 4.

Se ricevete una richiesta di cancellazione dei dati (GDPR Articolo 17), in Plausible potete rispondere "nessun dato personale è memorizzato su di voi" — poiché i dati sono aggregati a livello di sessione. Con GA4, sareste costretti a invocare l'API di eliminazione dati per cancellare Client ID, User-ID e altri identificatori — un processo che impiega 60 giorni. Con Plausible, non esiste alcun processo.

Per la conformità a TCF 2.2: lo script di tracking di Plausible rientra nella categoria "strettamente necessario", quindi non richiede integrazione con un CMP (Consent Management Platform). Con GA4, invece, il Purpose 1 ("Store and/or access information") richiede consenso esplicito — un consenso che nel traffico europeo viene rifiutato dal 58% degli utenti. Plausible elimina completamente questo requisito di consenso.

Checklist per la Configurazione in Produzione

Se installate Plausible self-hosted, seguite questi step:

1. Configurazione DNS: create il sottodominio tracking.yourdomain.com, installate un certificato SSL (Let's Encrypt).
2. Docker Compose: scaricate il file docker-compose.yml dal repo GitHub ufficiale di Plausible, configurate le variabili di ambiente SECRET_KEY_BASE e DATABASE_URL.
3. Tuning di ClickHouse: nel file /etc/clickhouse-server/config.xml, impostate max_memory_usage al 60% della RAM del vostro server (es. 19200000000 per 32GB).
4. Reverse proxy Nginx: aggiungete rate limiting (limit_req_zone $binary_remote_addr zone=tracking:10m rate=10r/s;) — protezione DDoS.
5. Script di tracking: inserite questo snippet nel vostro frontend:

<script defer data-domain="yourdomain.com" src="https://tracking.yourdomain.com/js/script.js"></script>

6. Retention policy: configurate il TTL in ClickHouse (eliminazione automatica dopo 90 giorni):

ALTER TABLE events MODIFY TTL timestamp + INTERVAL 90 DAY;

7. Backup: utilizzo giornaliero di pg_dump per PostgreSQL, e clickhouse-backup per ClickHouse.

In produzione, per un traffico medio di 1M pageview/mese, l'infrastruttura richiesta è: 2 vCPU, 8GB RAM, 50GB SSD. Il costo su AWS è ~$80/mese, su Hetzner ~$30/mese. Con Plausible managed cloud lo stesso traffico costa $99/mese — l'auto-hosting