Nel corso degli ultimi 12 mesi ho avuto modo di verificare che chi fa una mappa per una testata italiana ha, oggi, due alternative. La prima è abbonarsi a uno strumento proprietario (tipo Datawrapper o Flourish, che dal 2022 è dentro Canva) e imparare a usarlo. La seconda è commissionare la grafica a uno studio esterno. Mi spiazza pensare che per chi vuole fare elaborazioni geospaziali complesse esiste quello strumento magnifico che è QGIS, mentre chi ha bisogno semplicemente di pubblicare una webmap in velocità si trova invischiato in un groviglio di software proprietari e sistemi chiusi. Che schifo.

Da mesi con zornade produco mappe e visualizzazioni per alcune redazioni con cui collaboro, e ogni volta mi tocca fare il lavoro, sporco ma estremamente ripetitivo, dei join spaziali. A un certo punto la domanda è diventata ovvia: invece di rifare i join spaziali per la centesima volta, perché non costruire lo strumento che vorrei usare, con i geodati italiani già caricati dentro?

Cosa fa

Studio è una webapp in cui carichi dei dati (CSV, Excel, GeoJSON), li abbini alla geografia italiana, scegli una visualizzazione (mappa, grafico, tabella, scrollytelling), applichi il tema della redazione (font, colori, logo) e pubblichi un embed da incollare nel sito.

Si carica un foglio “comune - valore” per ottenere una coropletica corretta in pochi secondi, perché il join su comune (o provincia, o regione, o CAP) lo fa lo strumento, non l’utente. Dietro ci sono i geodati che costruiamo come lavoro principale: i confini amministrativi ISTAT, le 9.228 zone CAP subcomunali (i CAP non sono poligoni ufficiali, ce li siamo ricostruiti, ma questa è un’altra storia che ho già raccontato), i prezzi immobiliari OMI semestrali dal 2015 al 2025, il rischio territoriale, il potenziale solare per edificio. È il motivo per cui una redazione dovrebbe scegliere questo e non Flourish: non l’interfaccia, ma il fatto che i dati italiani sono già pronti per la mappa.

Sopra ci ho agganciato i cataloghi aperti, in modo che il dato si possa cercare senza uscire dall’app: gli open data italiani (dati.gov.it, i portali di regioni e comuni), gli open data europei di data.europa.eu (un catalogo che a fine giugno 2026 conta circa 1.7 milioni di dataset federati), le statistiche Eurostat (più di 8’000 dataset) e le query a OpenStreetMap via Overpass per i punti di interesse (scuole, ospedali, porti, telecamere, eccetera). Si trova il dato, lo si carica, lo si mappa. Senza scaricare tre file, riproiettarli e pulirli a mano.

Perché software libero, e perché AGPL

Qui voglio essere esplicito, che la scelta di licenza non è un dettaglio legale da nascondere in fondo. Il repository di Studio sarà pubblicato sotto GNU AGPL v3: ovvero copyleft integrale. Vuol dire che chiunque faccia girare una versione modificata su un proprio server è tenuto a renderne disponibile il codice. È la stessa posizione che tengo sul resto di quello che faccio, ed è una posizione che cerco di mantenere in modo coerente: l’infrastruttura con cui si raccontano i dati pubblici dovrebbe essere ispezionabile, come i dati pubblici stessi.

C’è anche una ragione più immediata. Uno strumento editoriale chiuso è una preghiera sulla buona fede di chi lo distribuisce. Flourish era un prodotto indipendente, poi è stato comprato; Datawrapper è solido oggi, ma il prezzo del piano Custom (5.990 dolla l’anno per dieci utenti, mica cotiche) lo decide qualcun altro e lo può cambiare domani.

Lo stack su cui è costruito riflette la stessa logica. Sono tutte librerie a licenza permissiva, scelte una per una controllando la licenza sul registro ufficiale: MapLibre GL JS (BSD) per le mappe, Observable Plot e Apache ECharts per i grafici, Scrollama per lo scrollytelling, i tile vettoriali in formato PMTiles serviti come file statici.

Cosa distingue Studio dai concorrenti

Intanto, lo ripeto, che è open source. Gli utenti potranno o usare la versione già pronta e servita da me, che costerà comunque meno di possere una VPS propria oppure, appunto, selfhostarlo aggratis. I dettagli li deciderò più avanti.

Sulla pura ricchezza di tipi di grafico, sull’animazione, sulla rifinitura dell’interfaccia, le differenze che contano per chi lavora sui dati italiani sono tre.

• La prima l’ho detta: i geodati italiani con join automatico. È l’unica cosa che gli altri non possono replicare scaricando una libreria, perché non è codice ma il dataset che mantengo io.

• La seconda è che l’embed è pensato per durare. Quello che si pubblica è uno snapshot statico su CDN, non una pagina che a ogni apertura chiama un’API a consumo che un domani può cambiare prezzo o spegnersi. Una mappa incorporata in un articolo del 2026 deve funzionare anche nel 2031, quando di quell’articolo non si ricorda più nessuno tranne chi lo cerca su Google (o, meglio, su DuckDuckGo o Brave).

• La terza è il time slider sui dati che abbiamo già storicizzati. Una mappa dei prezzi OMI che scorre dal 2015 al 2025 con il tasto play è il tipo di cosa che, con i dati italiani sparsi su portali diversi, normalmente costa giorni di pulizia. Qui la serie storica è già dentro.

Sotto tutto questo c’è una scelta architetturale che si vede poco ma conta: ogni visualizzazione è un documento JSON dichiarativo, separato dal rendering. Lo stesso documento produce la versione interattiva e quella statica (per la stampa, per l’email, per chi ha JavaScript disattivato). È la parte noiosa e invisibile che rende lo strumento estendibile invece che uno scaldabagno.

Come lo sto costruendo

Per ora Studio non è pubblico per scelta. Lo sto sviluppando internamente, usandolo per produrre mappe vere insieme ad alcune redazioni e a un piccolo gruppo di data journalist a noi vicini. Ogni mappa che esce su una testata è un collaudo, e ogni feedback diretto vale oro.

L’idea è arrivare a maturità e pubblicare il repository entro la fine dell’estate. Non metto una data al giorno perché sappiamo tutto come vanno queste cose (e preferisco aprire qualcosa che funziona piuttosto che rispettare una scadenza che mi son dato da solo). Quando il codice sarà su GitHub sotto AGPL lo annuncerò qui, con i suoi limiti dichiarati in chiaro.

Extra: un progetto vicino che vale la pena seguire

Se questo tema vi interessa, c’è un gruppo di lavoro parallelo che consigliamo di tenere d’occhio: l’Associazione onData. onData fa advocacy per l’apertura dei dati pubblici come bene comune, ma soprattutto produce strumenti aperti e funzionali. La loro organizzazione su GitHub ha 139 repo pubbliche, e dentro ci sono cose che fanno felice chiunque si occupi di dati. Sono anche tra i promotori della campagna datiBeneComune (insieme ad ActionAid e Transparency International Italia), che spinge la pubblica amministrazione a pubblicare come open data cose che oggi restano chiuse.

Lo segnaliamo perché lavoriamo sullo stesso terreno da angoli diversi: loro spingono perché i dati siano aperti e maneggiabili, noi proviamo a renderli facili da mappare. Le due cose vanno a braccetto. Uno strumento per fare mappe italiane non serve a niente se i dati italiani restano dietro un PDF, e aprire i dati serve di più se poi qualcuno li sa raccontare.

Iscriviti ora

• Il 12 giugno NLnet ha annunciato che sospende tutte le sue open call “per fare il punto”.

• Il 16 giugno il Parlamento europeo ne ha discusso in plenaria senza approvare nulla.

Quindi a inizio mese abbiamo assistito a un annuncio in pompa magna, una pausa di riflessione e un dibattito inconcludente, nell’ordine. Ho allora deciso di leggere il documento sulla strategia open source pubblicato dalla comiissione europea e analizzarlo, e ho scoperto che dice cose diverse da quelle che le conferenze stampa lasciano intendere.

Condividi zornade

Cosa ci sta davvero nel pacchetto

Il Technological Sovereignty Package, presentato a inizio giugno, contiene quattro iniziative distinte che dalla stampa sono state erroneamente messe sullo stesso piano. Due (il Chips Act 2.0 e il Cloud and AI Development Act, CADA) sono proposte legislative: ovvero se vengono approvate da Parlamento e Consiglio diventano vincolanti. Le altre due (la Strategia Open Source e la roadmap sull’energia) sono invece comunicazioni: atti di indirizzo, desideri, sogni evanescenti. Il sospetto è che abbiano una funzione meramente cosmetica, perchè la prima cosa da tenere a mente quando si legge “la strategia farà”, “la strategia garantirà” è che una circolare non fa e non garantisce un bel niente.

Detto questo, il documento adotta esplicitamente il principio public money, public code: la frase compare letteralmente nel testo (”guided by the ‘public money, public code’ principle”). public money, public code è la campagna che la Free Software Foundation Europe porta avanti dal 2017, cioè da nove anni. La FSFE stessa l’ha accolta come “potenzialmente un passo avanti importante”. Verifichiamo.

Iscriviti ora

I numeri nudi e crudi

La Commissione mette la firma su una cifra importante: l’UE spende 264 miliardi di euro l’anno “mostly on US proprietary IT products and services”. A questo punto uno si aspetta di leggere quanto la Commissione intenda allocare per invertire la rotta, tuttavia il documento non porta nessuno stanziamento nuovo complessivo per l’open source. Le cifre che cita sono quasi tutte allocazioni di programmi già esistenti, rietichettate come prova d’impegno: NGI (190 milioni dal 2018), il middleware Simpl (156 milioni), OpenEuroLLM (20 milioni), Destination Earth (150 milioni). L’unica voce nuova, legata al fiore all’occhiello della strategia (il cosiddetto Open Internet Stack), sono 41.3 milioni di Horizon Europe per il biennio 2026-2027.

Facciamo il conto: 41.3 milioni su due anni, contro 264 miliardi l’anno di spesa fanno lo 0.016%. Persino se si accetta la cifra di “2 miliardi in sette anni”, che gira sulla stampa ma che non compare in nessuno dei documenti ufficiali, si arriva allo 0.1%. Qualsiasi delle due cifre si prenda, l’ordine di grandezza è quasi lo stesso: lo stanziamento per i beni comuni digitali è circa un millesimo di quello che si spende per sviluppare teconologie private, ovvero una cifra assolutamente impercettibile.

La FSFE lo dice nel modo più diretto: la leva non è lo stanziamento, è
riallocare la spesa esistente. “Spostare anche solo metà dei 264 miliardi dal
lock-in proprietario al software libero darebbe una spinta reale alla sovranità.” Ed è qui, come visto, che la strategia incontra il suo limite più serio.

La differenza tra “could” e “shall”

Riallocare la spesa pubblica significa una cosa sola: cambiare le regole del procurement (cioè di come le pubbliche amministrazioni comprano software). Il documento lo riconosce con lucidità, addirittura ammettendo che i bandi europei sono “storicamente disegnati attorno alle caratteristiche dei fornitori proprietari”.

E come propone di risolverlo? Con un “principio open source first” che, nel testo, è scritto al condizionale: “could revert this trend”. Il CADA, dice il documento, “promotes“ l’uso di componenti open source. La pagina ufficiale del CADA conferma: “promoting open source solutions to reinforce resilience”. Promuovere, non imporre. E una nota della comunicazione chiude ogni ambiguità: gli atti del pacchetto “do not regulate how contracting authorities and contracting entities procure“: non regolano come si acquista.

Tradotto: l’unico meccanismo che potrebbe davvero spostare denaro pubblico verso il software libero resta affidato a linee guida e best practice, con una clausola di salvaguardia ampia (si può sempre scegliere altro “dove sicurezza, riservatezza o vincoli legali lo richiedano”, che è esattamente la motivazione con cui da vent’anni si giustifica la predilezione per i fornitori proprietari). Tutta la sovranità software dell’Europa, nel 2026, sta nella differenza tra “could” e “shall”.

Il programma che volevano chiudere

E veniamo al punto che tiene insieme le tre date dell’inizio. Lo strumento di punta della strategia si chiama Open Internet Stack. Cos’è? Lo dice NLnet, nel comunicato del 12 giugno: “La prossima fase di NGI sarà la sua transizione nel cosiddetto Open Internet Stack, che fa parte del pacchetto sulla sovranità tecnologica.” L’Open Internet Stack, cioè, è NGI con un nome nuovo.

NGI è la Next Generation Internet, lanciata nel 2016, che attraverso NLnet e altri consorzi ha finanziato l’ossatura dei commons digitali europei. In seno a NGI sono stati siluppati (tra gli altri) KiCad, PeerTube, Nextcloud, Pixelfed, toolchain per chip aperti, progetti di crittografia post-quantistica.

Nel luglio 2024 la Commissione aveva comunque proposto di eliminare NGI dalla bozza del programma di lavoro di Horizon Europe 2025. Lo documentarono allora The Register ed EDRi; il consorzio OW2 chiese pubblicamente di rivedere la decisione. Solo la mobilitazione della comunità tenne in vita le call. Adesso lo stesso programma, sopravvissuto al tentativo di chiusura, viene messo in vetrina come prova della nuova vocazione sovranista dell’Europa.

In tutto questo, come detto, NLnet ha annunciato il 12 giugno una pausa dei suoi grant. Da un punto di vista operativo è una scelta legittima, dopo dieci anni e oltre diecimila domande ci sta un periodo di valutazione prima di ripartire sotto un nuovo ombrello. Il direttore della strategia di NLnet la motiva così, ed è credibile.

Ma sul piano politico il tempismo è sospetto: nell’esatto momento in cui Bruxelles celebra la sovranità digitale, le open call sono chiuse “fino a dopo l’estate”, mentre la domanda è ai massimi storici (2.500 candidature nei soli primi cinque mesi del 2026).

Come parla il potere quando vuole evitare i numeri

Vale la pena fermarsi su come è stata raccontata. Ursula von der Leyen: “Non possiamo permetterci di dipendere da altri per le tecnologie che mantengono in funzione i nostri ospedali, le nostre reti energetiche, i nostri servizi”. Henna Virkkunen, la vicepresidente titolare del dossier: “Viviamo in un mondo in cui geopolitica e tecnologia sono inseparabili”.

Sono frasi che uniscono ciò che il dispositivo tiene accuratamente separato. La sovranità di cui parlano (ospedali, reti, servizi) è fatta soprattutto di cloud, hardware e capitale industriale: ed è lì che il pacchetto mette gli strumenti veri, le proposte legislative, il capitale (a luglio parte il bando per le Gigafactory dell’IA, e si lavora con la BEI a una “capacità di equity su scala”). Al software libero, citato nella stessa frase, tocca lo strumento più debole: una comunicazione senza obblighi e con 41.3 milioni di copertura.

Cosa significa per chi costruisce

Lo stack su cui poggia mezzo mondo geospaziale civile (PostGIS, QGIS, GDAL, e
progetti finanziati proprio da NGI come Mapterhorn, Panoramax, OpenStreetMap) è reale, prezioso e cronicamente sottofinanziato, mentre la strategia che dovrebbe sostenerlo, per ora, è solo un indirizzo. Cosa servirebbe perché diventasse altro è abbastanza chiaro, e sta scritto in negativo nel documento stesso: obblighi di procurement invece di preferenze; linee di bilancio dedicate e con nome, invece di un collage di programmi preesistenti; e continuità di erogazione, invece di una pausa proprio quando la domanda è più alta.

La sovranità sui dati e sul software si misura in due diritti: quello di staccare la spina quando un fornitore esterno ti tiene per il collo, e quello, più prosaico, di tenere aperto il rubinetto che paga chi quel software lo scrive e lo mantiene. Per ora l’Europa ha messo nero su bianco il primo, e in pausa il secondo.

Tutte le cifre di questo articolo sono verificate sui documenti primari
(COM(2026) 503 e allegati, factsheet FS/26/1189, comunicati NLnet e FSFE),
scaricati e archiviati. Se trovi un errore, scrivici: lo correggiamo.

Leggi l'articolo completo

Installare Google Analytics su un sito significa fare una scelta per conto degli utenti senza chiedergli niente. Nessuno ci pensa davvero perché GA è lì da sempre, è gratuito, funziona. Ma fermarsi un momento a capire cosa succede esattamente, e poi decidere con più consapevolezza, ha senso.

Questa guida prova a spiegare com’è fatto il problema, quali alternative esistono, e come si fa concretamente il passaggio perdendo il meno possibile lungo la strada.

Cosa succede quando qualcuno visita un sito con GA

Ogni volta che un browser carica un sito con lo script di Google Analytics, manda una richiesta ai server di Google. In quella richiesta ci sono: l’URL che l’utente sta visitando, il referrer (da dove viene), il tipo di dispositivo, il browser, la risoluzione dello schermo, la lingua del sistema, e un identificativo persistente che permette a Google di riconoscere lo stesso utente su siti diversi nel tempo.

Questi dati non vengono usati solo per dare le statistiche nella dashboard. Vengono aggregati con tutto quello che Google già sa di quella persona dal resto del web: le ricerche su Google, i video su YouTube, le email su Gmail se le usa, i siti di tutto il resto del mondo che hanno GA installato. Il risultato è un profilo comportamentale che diventa sempre più preciso e che viene venduto agli inserzionisti sotto forma di targeting pubblicitario.

Il costo non è in denaro. Gli utenti pagano con i propri dati ogni volta che visitano il sito.

Lo si può leggere nei bilanci di Alphabet, scritto chiaro. La divisione che include Search, Maps e la rete pubblicitaria vale circa 270 miliardi di dollari all’anno. Quella cifra esiste perché miliardi di persone vengono osservate su miliardi di siti, e i loro comportamenti vengono trasformati in previsioni sui loro acquisti futuri. Shoshana Zuboff ci ha scritto un libro di 700 pagine chiamandolo “capitalismo della sorveglianza”: l’idea è che l’esperienza umana è diventata la materia prima di un’industria estrattiva, esattamente come il petrolio. Chi installa GA sul proprio sito è un fornitore non pagato di quella materia prima.

Un singolo sito, da solo, cambia poco nell’economia complessiva della sorveglianza digitale. Ma chi costruisce qualcosa per altri ha spesso una posizione su come gli utenti dovrebbero essere trattati, almeno in teoria. Vale la pena allineare gli strumenti a quella posizione.

Cosa serve davvero da uno strumento di analytics

Prima di guardare le alternative, è utile chiedersi cosa si stia effettivamente usando di GA. Nella maggior parte dei casi, la risposta è molto meno di quello che la piattaforma offre.

Le domande a cui si vuole rispondere sono probabilmente queste: quante persone visitano il sito? Da dove arrivano (motori di ricerca, social, direct, referral)? Quali pagine leggono di più? In che paesi e città si trovano? Con che browser e dispositivo navigano?

Queste cose non richiedono il tracciamento individuale. Non serve sapere che “questo specifico utente è tornato tre volte questa settimana, la prima via Google e le altre due via direct”. Servono aggregati: sessioni totali, sorgenti di traffico, pagine più popolari. Sono informazioni completamente diverse, e per raccoglierle non serve profilare nessuno.

L’unico caso in cui il tracciamento individuale diventa genuinamente utile è quando c’è un funnel di conversione complesso, un e-commerce, o campagne pubblicitarie da ottimizzare a livello di segmento. In quel caso GA o qualcosa di equivalente è necessario, e questa guida potrebbe non essere quella giusta. Per tutti gli altri, le alternative privacy-friendly danno tutto quello che conta.

Le alternative che funzionano

Plausible Analytics è probabilmente il punto di partenza più sensato per chi viene da GA. È open source, nato in Estonia nel 2019, disponibile sia come SaaS (9 euro al mese fino a 10.000 pageview, poi a scalare) che come versione self-hosted gratuita. Non usa cookie, non costruisce profili individuali, non cede dati a terze parti. I server sono in Europa. Per determinare sessioni uniche usa un hash giornaliero basato su IP e user-agent che viene scartato dopo 24 ore: non c’è niente di persistente da qualche parte.

Lo script pesa circa 1 kilobyte. GA4 pesa 45. Vale la pena tenerlo a mente per chi ha la performance tra le priorità.

Fathom Analytics è simile a Plausible nel modello ma con una storia leggermente diversa, fondata in Canada. Più cara (14 dollari al mese), ma con qualche feature in più sul fronte dei custom events. Il codice è closed source, però la privacy policy è verificabile e il modello di business è trasparente.

Umami è un’alternativa open source che si può self-hostare completamente gratuitamente. Ha una dashboard pulita, supporta eventi custom, ed è scritta in Next.js quindi è semplice da deployare su qualsiasi host che supporti Node. Con un server o un account su Railway o Render, Umami gira in dieci minuti.

Matomo è la soluzione più ricca di funzionalità tra le alternative open source. È praticamente un GA self-hosted: ha segmentazioni, funnel, heatmap, session recordings. È anche la più pesante da installare e mantenere. Ha senso quando si migra da GA con la necessità reale di funzionalità avanzate, altrimenti è un cannone per sparare a una mosca.

Come si fa il passaggio in pratica

Il passaggio da GA a Plausible (prendo Plausible come esempio perché è quello con cui ho più esperienza diretta, ma i principi valgono per tutte le alternative) si fa in tre fasi.

Prima: esportare da GA quello che si vuole conservare. Lo storico non è portabile su Plausible, i dati non sono compatibili. Quello che si può fare è esportare i report rilevanti da GA prima di spegnerlo, così si ha un riferimento per confrontare i numeri dei prossimi mesi. GA permette di esportare in CSV da qualsiasi vista.

Seconda: installare Plausible in parallelo per un periodo. Conviene non spegnere GA subito. Lasciare girare entrambi per due o quattro settimane permette di confrontare i numeri e capire le differenze. Plausible tende a riportare meno sessioni di GA per via di come esclude il traffico dei bot, ma i trend sono coerenti. Quando i dati sembrano affidabili, si spegne GA.

Terza: rimuovere lo snippet di GA dall’HTML e dai tag manager. Questo è il passaggio che molti dimenticano o rimandano. Chi usa Google Tag Manager deve ricordarsi di rimuovere o disabilitare il tag GA da lì: non basta toglierlo dall’HTML se GTM è ancora attivo e configurato per iniettarlo.

Il problema di Firefox (e come risolverlo)

C’è un dettaglio tecnico che vale la pena conoscere prima di iniziare, perché altrimenti ci si ritrova a guardare dati incompleti senza capire perché.

Firefox attiva di default la Enhanced Tracking Protection. Tra i domini che blocca per default c’è plausible.io, perché compare nelle liste dei tracker usate da Firefox (non perché Plausible faccia tracking invasivo, ma perché le liste sono conservative e bloccano tutto quello che assomiglia a un dominio di analytics). Risultato: circa il 20% degli utenti, quelli su Firefox con impostazioni di default, non viene tracciato.

La soluzione è il proxy: invece di far caricare lo script direttamente da plausible.io, lo si fa passare attraverso il proprio dominio. Il browser vede una richiesta al sito, non a un dominio nelle sue liste di blocco, e tutto funziona.

Su Netlify il modo più semplice è usare il file public/_redirects. Si aggiungono queste due righe prima del catch-all SPA:

/js/pa.js  https://plausible.io/js/pa-TUOHASH.js  200
/api/event  https://plausible.io/api/event  200

L’hash nell’URL dello script si trova nella dashboard di Plausible sotto Settings → Goals and custom events → Script snippet. È un hash specifico per il sito.

Nell’HTML, invece di caricare lo script da plausible.io, lo si carica da /js/pa.js:

<script async src="/js/pa.js"></script>

Poi bisogna dire allo script dove mandare gli eventi, perché di default li manda a plausible.io invece che al proxy locale. Si crea un file separato (non inline, per non incappare in problemi con la Content Security Policy) con questo contenuto:

window.plausible = window.plausible || function() {
  (window.plausible.q = window.plausible.q || []).push(arguments)
};
window.plausible.init({ endpoint: '/api/event' });

E lo si include nell’HTML subito dopo lo script principale:

<script async src="/js/pa.js"></script>
<script src="/js/plausible-init.js"></script>

Due cose non documentate in modo ovvio che fanno perdere tempo:

Netlify: usa _redirects, non netlify.toml. Le regole di redirect verso URL esterni devono stare in public/_redirects. Se si mettono in netlify.toml, Netlify le ignora silenziosamente quando _redirects esiste. Non lo dice da nessuna parte in modo chiaro, lo si capisce solo testando con curl e vedendo che arriva HTML invece del contenuto del proxy.

L’opzione si chiama endpoint, non apiHost. Se si scrive apiHost, le pageview vengono comunque tracciate ma gli eventi custom no, e non si capisce subito il perché.

Su Vercel il meccanismo è identico ma la sintassi va in vercel.json:

{
  "rewrites": [
    { "source": "/js/pa.js", "destination": "https://plausible.io/js/pa-TUOHASH.js" },
    { "source": "/api/event", "destination": "https://plausible.io/api/event" }
  ]
}

Su Cloudflare Workers si può fare la stessa cosa con un worker che fa il proxy delle due route. Plausible ha una guida dettagliata nella loro documentazione.

La CSP, se presente

Se il sito ha una Content Security Policy configurata, ci sono alcune cose da verificare.

Con il proxy attivo, plausible.io non serve più nella script-src né nella connect-src. Si può rimuovere del tutto se c’era. Gli script vengono caricati dal proprio dominio, quindi 'self' è sufficiente.

L’unica accortezza è il file di init: deve essere un file esterno servito dal proprio dominio, non uno script inline. Se lo si mette inline (<script>window.plausible.init(...)</script>), la CSP lo blocca in assenza di 'unsafe-inline' nella script-src. Un file separato caricato via src non ha questo problema.

Cosa cambia nella dashboard

La prima cosa che si nota passando a Plausible è che i numeri sembrano più bassi di GA. GA ha una tendenza a gonfiare le sessioni includendo traffico di bot, sessioni di spam referral e ricariche di pagina spurie, e Plausible filtra in modo più aggressivo. Se si osservano i trend nel tempo invece dei numeri assoluti, le curve si comportano in modo coerente.

La seconda cosa è la semplicità. Plausible non ha una sidebar con quaranta voci. Ha una pagina con: visitatori unici, pageview, bounce rate, durata media, sorgenti di traffico, pagine più viste, dispositivi, paesi. Tutto in una schermata. Ci vuole letteralmente un decimo del tempo per trovare quello che serve rispetto alla navigazione di GA4.

Il banner cookie, in molti casi, non è più necessario. Plausible non usa cookie di tracciamento, quindi in molte interpretazioni del GDPR non rientra nell’obbligo del consenso per i cookie analitici. Prima di toglierlo del tutto è bene consultare la propria situazione specifica, perché le regole variano per giurisdizione e caso d’uso, ma nella maggior parte degli scenari si può farne a meno.

Vale la pena, in concreto

Il tempo per la migrazione dipende dalla complessità del sito. Per un sito statico o una SPA semplice, si contano un paio d’ore tra installazione, configurazione del proxy su Netlify o Vercel, e verifica che tutto funzioni. Se ci sono eventi custom configurati su GA da ricreare su Plausible, va aggiunto un po’ di tempo in più per rimappare la logica.

Il costo è 9 euro al mese per la versione SaaS fino a 10.000 pageview. Per siti più grandi, i prezzi scalano in modo lineare. La versione self-hosted è gratuita e il codice è su GitHub con licenza AGPL.

Quello che si ottiene in cambio, oltre alla questione etica: dati più puliti, una dashboard in cui si trovano le cose, nessun cookie banner forzato, GDPR più semplice da gestire, zero dipendenza da Google per un pezzo dell’infrastruttura.

Fare questo passaggio da soli cambia poco nell’economia complessiva della sorveglianza digitale. Ma per chi tiene a trattare bene le persone che usano quello che costruisce, è un passo che ha senso fare e che costa meno di quanto sembra.

Se l’articolo ti è stato utile, condividerlo con qualcuno che costruisce siti è il modo più diretto per supportare questo lavoro:

Condividi

Link utili

• Plausible Analytics — sito ufficiale, prezzi, demo

• Plausible su GitHub — codice sorgente (licenza AGPL)

• Guida al proxy per Netlify — documentazione ufficiale

• Guida al proxy per Vercel

• Guida al proxy per Cloudflare Workers

• Umami — analytics open source self-hosted

• Fathom Analytics — alternativa closed source privacy-first

• Matomo — analytics open source completo

Puoi iscriverti alla newsletter per capire come fare servizi web senza vendere l’anima a Larry Page:

Iscriviti ora

Il 4 marzo abbiamo pubblicato visura-api, un servizio REST open source per estrarre dati catastali dal portale SISTER dell’Agenzia delle Entrate. In soldoni: un browser headless che si autentica via SPID, naviga il portale per te e ti restituisce visure catastali in JSON. Niente click, niente PDF.

Il punto è questo. In Italia c’è un oligopolio di intermediari che rivende l’accesso ai dati catastali a quasi un euro a richiesta. Dati che SISTER fornisce gratuitamente. visura-api dimostra che non servono intermediari.

A un mese dal rilascio siamo a 628 stelle e 73 fork su GitHub. Il post su LinkedIn ha raccolto 873 reazioni e 71 commenti, parecchi da professionisti del settore. La domanda più gettonata: “ma è legale?”. Sì. SISTER è un servizio pubblico, il progetto usa le credenziali personali dell’utente e non aggira nessun blocco. Servizi identici esistono da anni, solo che sono chiusi e a pagamento.

Ah, la licenza è passata da GPL-3.0 a AGPL-3.0 per chiudere il cosiddetto “SaaS loophole”: se qualcuno prende il codice, lo modifica e lo espone come servizio, è obbligato a rilasciare le modifiche. Copyleft fino in fondo.

Repository GitHub · Articolo tecnico sul blog

Zone CAP v2: da Voronoi a 3,4 milioni di particelle catastali

A settembre 2025 avevamo pubblicato il primo dataset gratuito delle zone CAP subcomunali in Italia. Funzionava, ma i confini erano linee rette generate con diagrammi di Voronoi. Geometricamente corrette, territorialmente un po’ a caso.

La versione 2, uscita il 13 marzo, parte dalle particelle catastali. Lo script assegna un CAP a ciascuna delle 3,4 milioni di particelle incrociando cinque fonti: OpenStreetMap, OpenAddresses, Foursquare OS Places, stradari pubblici e catasto. Risultato: 97,1% di accuratezza validata su Reggio Emilia (era 84,3% nella versione precedente). 576 zone multicap ricostruite in 37 città.

Il dataset si scarica in GeoPackage, GeoJSON e Shapefile, senza registrazione.

Su LinkedIn il post ha raccolto 431 reazioni e 27 commenti. Un contributore ha già integrato i dati in un pacchetto Laravel per la geografia ISTAT. Un ingegnere geospaziale ha fatto notare, giustamente, che i CAP non sono poligoni territoriali ma associazioni virtuali ai civici. Ed è esattamente per questo che Poste Italiane non ha mai pubblicato mappe ufficiali.

Articolo con metodologia completa · Download gratuito

59 milioni di persone mappate pixel per pixel

Il 20 marzo abbiamo rilasciato il dataset di popolazione italiana più granulare che si trovi in giro. Risoluzione ~30 metri, prodotto fondendo il pattern spaziale dell’HRSL (Meta + Columbia University) con i totali di WorldPop R2025A constrained.

In pratica è un GeoTIFF da 678 MB in cui ogni pixel di 30×30 metri contiene una stima delle persone residenti in quel quadratino. Il metodo è una fusione dasymetrica a tre fasi: si usa l’HRSL come superficie di pesi per redistribuire i conteggi WorldPop a risoluzione più alta, poi si proietta dal 2020 al 2025 usando i rapporti di crescita spazialmente espliciti.

Fonti, codice e metodologia sono tutti nel repository GitHub. Su LinkedIn il post ha raccolto 280 reazioni. Un commento che mi è rimasto impresso: “Andrebbe fatta una statua a chiunque crei dataset e li renda open”.

Articolo sul blog · Download GeoTIFF

La mega-sfida degli edifici

Quale dataset di building footprints conviene usare per l’Italia? Il 19 marzo abbiamo pubblicato un confronto sistematico su 22 aree campione con 18 grafici. I cinque contendenti: OSM, Microsoft ML Buildings, Overture Maps, GlobalBuildingAtlas dell’Università di Monaco e il dataset della Protezione Civile.

In breve: Overture raggiunge un F1 di 0,88, GBA segue a 0,84, Microsoft crolla a 0,26. Però la completezza, l’IoU, la distanza dei centroidi e la distanza di Hausdorff raccontano storie diverse a seconda che si guardi il centro di Roma o la Toscana rurale. Vale la pena leggersi l’analisi per intero.

Analisi completa con grafici

Sulla piattaforma

Marzo è stato denso anche per app.zornade.com. Un po’ di cose, in ordine.

Edifici 3D. Se tieni premuto Ctrl, le impronte degli edifici si sollevano dalla mappa. Sono semitrasparenti, si attivano quando zoomi abbastanza. Non cambia la vita, ma aiuta un botto a orientarsi tra le particelle in centro città.

Redesign neumorphic dark. Abbiamo rifatto tutta la grafica con ombre doppie, neumorfismo scuro e testo più leggibile. Tutto più pulito. E sì, meglio del liquid glass.

Mappa satellite. Un click e si passa dalla mappa scura alla vista aerea con le immagini ESRI. I colori delle particelle si leggono comunque bene. L'abbiamo aggiunta perché ci è stato fatto notare che con la Positron DarkMatter di Carto poi era difficile orientarsi. A tutti i geometri che usano la nostra app: prego.

Gamification. Abbiamo assegnato a tutti gli utenti username e avatar casuali, con una classifica basata su XP. C'è già chi domina il podio (complimenti c4chale) e chi ha aperto un ticket perché a parità di XP il posto più alto dovrebbe andare a chi ha più segnalazioni. Aveva ragione, corretto.

Sul blog

A marzo abbiamo pubblicato dieci articoli di riferimento. Tre coprono i fondamentali del catasto italiano (rendita catastale, quotazioni OMI, foglio-particella-subalterno), gli altri sette espandono il catalogo di guide ai dataset GIS.

• 24 mar · Rendita Catastale: Come si Calcola

• 24 mar · Quotazioni OMI: Mappa Prezzi Immobili

• 24 mar · Foglio, Particella e Subalterno

• 20 mar · Popolazione Italia 30m

• 19 mar · Confronto Edifici Italia

• 16 mar · CAP Italia Download

• 16 mar · Categorie Catastali Tabella

• 16 mar · Shapefile Italia Download

• 13 mar · Zone CAP Italia v2

• 4 mar · visura-api

Cosa arriva ad aprile

A fine aprile integriamo i dati ministeriali sul reddito in base ai CAP. E stiamo mettendo mano al meccanismo ETL delle particelle, che è una ristrutturazione seria della pipeline. Speriamo di non rompere niente.

Se non l’hai ancora fatto, la piattaforma è su app.zornade.com. Tutto il codice e i dataset di questa newsletter sono open source e scaricabili gratuitamente.

A maggio.

zornade