Collegare Google Analytics a Claude Code

Google Analytics sa quante persone visitano il tuo sito, da dove arrivano e quali pagine leggono. Il problema non è che il dato manchi: è che per tirarlo fuori devi entrare in una dashboard, scegliere un intervallo di date, capire quale rapporto ti serve e ricordarti dove stava la scorsa volta.

Con un collegamento MCP l’agente da terminale interroga Analytics al posto tuo. Tu scrivi “com’è andato luglio rispetto a giugno”, lui prende i numeri, li mette in un file e te lo lascia sul disco. Non è magia e non è un’analisi al posto tuo: è la parte noiosa del lavoro, tolta di mezzo.

In questa ricetta colleghiamo una proprietà GA4 a Claude Code e prepariamo una cartella di lavoro dove finiranno i report. Il metodo vale identico per Codex e per qualunque altro agente che parli MCP: cambia il file dove si dichiara il server, non il resto.

Ingredienti

• una proprietà Google Analytics 4 già attiva su un sito che raccoglie dati;
• un account Google Cloud, che è una cosa diversa da Analytics e va attraversata una volta sola: è il passaggio più noioso di tutta la ricetta e gli dedichiamo il passo 5;
• Claude Code già installato e funzionante;
• Python disponibile sul computer, che serve a far girare il server;
• mezz’ora, di cui una buona metà dentro le schermate di Google e almeno cinque minuti passati ad aspettare che un permesso si propaghi.

La mezz’ora la paghi una volta e basta. Il secondo sito che collegherai ti costerà due minuti, e il motivo è spiegato nel passo 5.

Se Claude Code è ancora una parola nuova, parti da Claude Code: cos’è, come funziona e cosa può fare e torna qui dopo.

Chi fa cosa: tu e l’agente

Prima di cominciare, una cosa che cambia il modo di leggere il resto.

Questa guida contiene comandi da scrivere. Non è detto che li debba scrivere tu: in una sessione normale la ricetta la dai in mano all’agente e gli chiedi di configurare lui, dicendoti quali pezzi restano a te. È il gesto che il libro racconta dall’inizio, applicato a un caso vero: tu decidi e verifichi, la messa in opera la fa lui.

Solo che qui la divisione non è una preferenza, è una barriera fisica. Alcuni passaggi l’agente non può farli, e conviene sapere quali prima di iniziare e non a metà strada.

Quello che deve fare una persona. Tutto quello che sta dentro le pagine web di Google, cioè i passi 5, 6 e 7. Creare il progetto Cloud, attivare le due API, creare l’account di servizio, scaricare la chiave, autorizzare quell’indirizzo dentro Analytics, leggere l’ID della proprietà. L’agente vive nel terminale: non ha il tuo browser, non è dentro il tuo account Google, e non deve esserci. Sono i clic che spendi una volta sola.

Quello che può fare l’agente. Tutto il resto, cioè i passi 1, 3, 4, 8, 9, 10 e 12. Creare le cartelle, installare il server, mettere la chiave al posto giusto con i permessi giusti, scrivere .mcp.json e CLAUDE.md, controllare che il collegamento risponda, fare il primo report e trasformarlo in PDF.

Se scegli questa strada, la richiesta da dargli è più o meno questa. Aprilo nella cartella del marketing e incolla:

Leggi la guida che trovi a questo indirizzo e configurami il collegamento MCP
a Google Analytics per questa cartella: [incolla qui l'indirizzo di questa pagina]

Dati che ho già: la proprietà GA4 è 123456789, e la chiave del service account
è il file ~/Downloads/nome-del-file-scaricato.json.

Prima di toccare qualsiasi cosa, elencami i passaggi che devo fare io a mano
nelle schermate di Google, perché tu non puoi farli. Poi fai la tua parte,
spiegandomi ogni comando prima di eseguirlo, e fermati quando è il momento di
verificare insieme che il collegamento funzioni.

Le tre richieste in fondo non sono cortesia. Elencami cosa devo fare io evita di scoprire a metà che manca un permesso. Spiegami ogni comando ti tiene dentro le decisioni invece di guardare scorrere del testo. Fermati alla verifica è la regola del libro: si controlla il risultato, non ci si fida del resoconto.

Anche delegando, però, leggi i passi 5 e 6 con attenzione. Sono i tuoi, e sono quelli dove ci si perde.

1. Prepara l’area di lavoro prima di tutto il resto

Questa è la parte che si tende a saltare, ed è quella che decide se fra tre mesi ritroverai qualcosa.

I dati del sito non vanno nella cartella del sito. Sono due lavori diversi: uno produce pagine, l’altro produce numeri sulle pagine. Se li mescoli, ogni volta che apri l’agente per correggere un titolo ti trovi in mezzo ai CSV, e ogni volta che chiedi un report l’agente ha davanti anche il codice del sito, che qui non gli serve.

Crea una cartella accanto a quella del sito, con un nome che dica cosa contiene:

Lavori/
├── mio-sito/                 il sito
└── mio-sito-marketing/       i dati sul sito
    ├── dati/                 esportazioni grezze, CSV e JSON
    ├── report/               i report leggibili, in Markdown
    │   └── mensili/
    └── domande/              le domande che rifarai ogni mese

Tre cartelle, e ognuna ha una regola sola:

• in dati/ finisce quello che esce da Analytics così com’è. I nomi dei file cominciano con la data, 2026-08-08-pagine.csv, e non si sovrascrivono mai: se rifai l’esportazione, cambia la data;
• in report/ finisce quello che leggi tu, scritto nella tua lingua;
• in domande/ finiscono le richieste che funzionano, salvate come file di testo. È la cartella che ti fa risparmiare più tempo di tutte, e ci arriviamo al passo 10.

2. Cos’è un server MCP, in parole normali

MCP sta per Model Context Protocol, e in pratica è una presa elettrica.

L’agente da solo sa leggere e scrivere file sul tuo computer, e basta. Non sa niente di Google Analytics, del tuo gestionale o della tua casella di posta. Un server MCP è un piccolo programma che sta in mezzo: da una parte parla con il servizio esterno, dall’altra si presenta all’agente con un elenco di cose che sa fare. L’agente legge quell’elenco e capisce che, oltre ai file, adesso può anche chiedere “dammi le sessioni degli ultimi sette giorni”.

Due conseguenze pratiche, che tornano utili più avanti:

1. il server gira sul tuo computer, come programma tuo. Non è un servizio a cui ti iscrivi;
2. l’agente non ha le tue password. Le credenziali le ha il server, e l’agente può solo chiedergli le cose che il server dichiara di saper fare. Se il server sa solo leggere, l’agente non può scrivere.

3. Dove tenere i server, e perché conta

Alcuni strumenti sono già dentro l’agente e non richiedono niente. Gli altri li aggiungi tu, e arrivano in due forme diverse. La differenza sembra tecnica ma decide come sarà fatta la tua macchina fra un anno.

I server confezionati. Sono programmi pubblicati come pacchetti, e si installano con un comando solo. Quello ufficiale di Analytics è di questi: al passo 4 scrivi una riga e lui si sistema da solo, in una sua cartella nascosta che non devi né conoscere né gestire. Si aggiorna con un comando, si disinstalla con un comando.

I server da costruire. Sono progetti da scaricare da GitHub e compilare. Restano una cartella sul tuo disco, e quella cartella deve stare da qualche parte per sempre: se la sposti, ogni configurazione che la nominava smette di funzionare.

Per i secondi conviene decidere un posto una volta sola. La convenzione che usiamo qui è una cartella MCP nella cartella utente:

~/MCP/
├── mcp-gsc/            Search Console
├── mcp-google-ads/     Google Ads
└── mcp-email/          posta

Tre motivi, e valgono anche se per ora ne hai uno solo:

• un server serve a più progetti. Lo stesso collegamento vale per tutti i siti che segui. Copiarlo dentro dieci progetti significa aggiornarlo dieci volte, e dimenticarsene nove;
• il percorso non cambia più. Nei file di configurazione scriverai /Users/tuonome/MCP/..., e quel percorso resta valido anche se il progetto lo sposti o lo rinomini;
• sai sempre cosa hai installato. Un ls ~/MCP ti dice quali servizi esterni possono essere raggiunti dagli agenti su questa macchina. È la domanda che ti farai fra sei mesi, quando qualcosa smette di funzionare.

La cartella MCP non è un progetto e non va su GitHub. È attrezzatura della macchina, come le applicazioni.

4. Installa il server di Google Analytics

Google pubblica un server MCP ufficiale per Analytics. Si installa con pipx, che scarica il programma e lo tiene isolato dal resto del sistema:

pipx install analytics-mcp

Se pipx non c’è, su macOS si installa prima con brew install pipx.

Alla fine pipx ti dice che il programma è disponibile. Segnati il percorso, che ti servirà fra due passi:

which google-analytics-mcp

Esiste anche la forma pipx run analytics-mcp, che scarica il server ogni volta invece di installarlo. Funziona, ma la prima esecuzione si costruisce un ambiente da zero e ci mette una ventina di secondi: è un’attesa che pagheresti a ogni apertura dell’agente. Meglio installarlo.

Il server non fa niente di visibile e non va lanciato a mano: resta in attesa che qualcuno gli parli, e ci pensa l’agente ad avviarlo quando serve.

5. Attiva le API in Google Cloud

Qui arriva la parte antipatica, ed è giusto dirlo prima invece di far scoprire al lettore che si è impantanato.

Ti servirà un account Google Cloud. Non è quello di Analytics: è un’altra cosa, con un’altra console, un’altra logica e un vocabolario suo. Non ti costa niente per quello che stiamo facendo, ma va attraversato una volta, e i passaggi sono cinque o sei in fila senza che nessuno ti dica perché.

Il motivo per cui esiste questo giro è ragionevole, e sapendolo si sopporta meglio. Analytics, in quanto sito, ti fa vedere i rapporti a schermo. Il tuo computer che chiede gli stessi numeri via programma è un’altra cosa, e Google vuole sapere quale programma sta chiedendo e per conto di chi. Il progetto Cloud risponde alla prima domanda, l’account di servizio del passo 6 risponde alla seconda.

Si fa una volta, e poi vale per tutto il resto

Questa è la cosa più importante di tutta la sezione, e in giro non la dice quasi nessuno.

Quello che stai per costruire non è il collegamento a una proprietà. È l’infrastruttura di accesso ai dati Google della tua macchina. Una volta in piedi, la riusi per:

• tutte le altre proprietà Analytics, presenti e future. Un sito nuovo fra otto mesi non richiede niente di tutto questo: due clic dentro Analytics e basta;
• Search Console, che ha un server MCP suo ma usa lo stesso progetto Cloud e lo stesso account di servizio. Cambia solo l’API da attivare e il posto dove autorizzarlo;
• Google Ads, e in generale ogni servizio Google che si lascia interrogare da un programma.

È il motivo per cui conviene farlo con un po’ di ordine adesso, anche se ti sembra sproporzionato per un sito solo. Non stai aprendo una porta: stai mettendo la serratura a cui poi darai altre chiavi.

Un consiglio pratico che ti risparmia confusione fra sei mesi: chiama il progetto Cloud con un nome che dica cosa contiene, tipo mcp-google-marketing, e non progetto-1 o il nome del sito. Dentro ci finiranno anche Search Console e Ads, e un nome legato a un sito solo diventerà bugiardo.

I passaggi

Vai su console.cloud.google.com e crea un progetto, se non ne hai già uno. Poi apri API e servizi → Libreria.

La libreria contiene cinquecento voci e nessuna è quella che ti serve in evidenza. Scrivi google analytics api nel campo di ricerca.

Fra i risultati devi attivarne due, e servono entrambe:

• Google Analytics Data API, che dà i numeri: sessioni, utenti, pagine. Senza questa non esce nessun report;
• Google Analytics Admin API, che dà l’elenco delle proprietà a cui hai accesso. Senza questa il collegamento funziona lo stesso, ma l’agente non sa quali siti esistono e devi dettargli il numero della proprietà ogni volta.

Apri ciascuna delle due e clicca Abilita. Quando è fatto, la scheda mostra la spunta verde API abilitata al posto del pulsante.

Il progetto Cloud, per essere chiari, è solo un contenitore amministrativo. Non raccoglie dati, non tocca il tuo sito e non ha niente a che vedere con la proprietà Analytics: serve a Google per sapere a chi attribuire le chiamate e per contarle. Con i volumi di un sito normale non arriverai mai a pagare qualcosa.

6. Crea l’account di servizio e dagli accesso alla proprietà

Un account di servizio (service account) è un utente che non è una persona. Ha un indirizzo email che finisce per iam.gserviceaccount.com, non ha una password, e si autentica con un file di chiave. Serve esattamente a questo: dare accesso a un programma senza dargli le tue credenziali.

In Google Cloud, sotto IAM e amministrazione → Account di servizio, creane uno. Chiamalo con un nome che dica a cosa serve. Vale lo stesso ragionamento del progetto: siccome questo account servirà anche per Search Console e per Ads, google-marketing invecchia meglio di ga4-lettura.

Non assegnargli nessun ruolo su Cloud: la schermata te lo chiede e si può saltare. I permessi non si danno qui, si danno dentro Analytics fra due paragrafi. È la parte che confonde di più: su Cloud questo account non deve poter fare niente.

Poi apri l’account appena creato, vai su Chiavi → Aggiungi chiave → Crea nuova chiave, scegli JSON e salva il file.

Dove salvarlo conta. Non nella cartella del progetto: in una cartella nascosta dedicata alle credenziali, fuori da qualunque repository.

mkdir -p ~/.credentials
mv ~/Downloads/nome-del-file-scaricato.json ~/.credentials/ga4-service-account.json
chmod 600 ~/.credentials/ga4-service-account.json

L’ultimo comando toglie il permesso di lettura a chiunque non sia tu.

Adesso il passaggio che si dimentica sempre, e senza il quale tutto il resto non serve a niente: quell’account non ha ancora accesso ai tuoi dati.

Apri il file della chiave e copia il valore di client_email. Puoi farlo dal terminale:

grep client_email ~/.credentials/ga4-service-account.json

Poi vai su analytics.google.com, scegli la proprietà, apri Amministrazione → Gestione accessi alla proprietà, clicca il + e incolla quell’indirizzo. Assegna il ruolo Visualizzatore, che è sola lettura, e conferma.

Il ruolo Visualizzatore è una scelta, non un dettaglio. È il livello più basso che esiste, e significa che nessun agente potrà mai modificare una configurazione di Analytics, cancellare un rapporto o cambiare un filtro. Anche se glielo chiedi.

Aspetta cinque o dieci minuti prima di provare. La propagazione dei permessi in Google non è istantanea, e quasi tutti i “non funziona” della prima volta sono in realtà “non ha ancora finito”.

7. Trova l’ID della proprietà

Non è il codice di misurazione che sta nelle pagine del sito, quello che comincia per G-. È un numero di nove o dieci cifre.

In Analytics: Amministrazione → Dettagli proprietà. In alto a destra trovi ID proprietà, con accanto l’icona per copiarlo. Copialo: lo scriverai una volta in un file e poi non ti servirà più ricordarlo.

Negli esempi che seguono useremo 123456789 al posto dell’ID vero: dove lo vedi, metti il tuo.

8. Dichiara il server nel progetto

Ci siamo. Apri il terminale nella cartella del marketing, quella creata al passo 1:

cd ~/Lavori/mio-sito-marketing

Poi registra il server:

claude mcp add ga4 \
  --scope project \
  -e "GOOGLE_APPLICATION_CREDENTIALS=/Users/tuonome/.credentials/ga4-service-account.json" \
  -- /Users/tuonome/.local/bin/google-analytics-mcp

Quattro cose da leggere in questo comando:

• ga4 è il nome con cui chiamerai il collegamento. Tienilo corto: lo scriverai nelle richieste;
• --scope project dice che il collegamento vale in questa cartella e non altrove. È il motivo per cui il passo 1 veniva prima: il progetto delimita cosa l’agente può raggiungere. Aprendo l’agente nella cartella del sito, il collegamento ad Analytics semplicemente non c’è;
• -e passa il percorso della chiave come variabile d’ambiente;
• l’ultimo pezzo è il programma da avviare, quello che ti ha detto which al passo 4.

I percorsi vanno scritti assoluti e per esteso, con /Users/tuonome/ davanti: la scorciatoia ~ qui non viene espansa.

Il comando scrive un file .mcp.json nella cartella. Puoi anche crearlo a mano, ed è utile sapere che aspetto ha, perché è lo stesso in tutti i progetti:

{
  "mcpServers": {
    "ga4": {
      "command": "/Users/tuonome/.local/bin/google-analytics-mcp",
      "args": [],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/Users/tuonome/.credentials/ga4-service-account.json"
      }
    }
  }
}

Dentro c’è il percorso della chiave, non la chiave. Questo file può stare tranquillamente su GitHub: chi lo legge sa che esiste un collegamento ad Analytics, non può usarlo.

Se lo stai facendo fare all’agente

Questo passo è il suo. Ti dirà che sta per lanciare claude mcp add, oppure ti proporrà direttamente il contenuto di .mcp.json: sono la stessa cosa, il comando quel file lo scrive e basta.

Due controlli che vale la pena fare tu, perché sono gli errori tipici e si vedono a occhio:

• il percorso della chiave è assoluto? Se leggi ~/.credentials/... invece di /Users/tuonome/.credentials/..., il collegamento fallirà all’avvio;
• dentro il file c’è un percorso e non una chiave? Se vedi righe che cominciano per -----BEGIN PRIVATE KEY-----, fermalo: quel contenuto non va in un file di configurazione, e men che meno in un repository.

Fatto questo, digli di verificare, che è il passo qui sotto. E falla eseguire a lui la verifica, non accontentarti che dica di averla fatta.

Se di siti ne segui più d’uno

--scope project è la scelta giusta finché il sito è uno. Quando diventano cinque o sei, la stessa riga finisce copiata in cinque o sei cartelle, e il giorno che cambi qualcosa devi ricordarti tutte.

A quel punto conviene dichiararlo una volta sola per l’utente:

claude mcp add ga4 --scope user -e "..." -- /Users/tuonome/.local/bin/google-analytics-mcp

Così il collegamento c’è in qualunque cartella tu apra l’agente, e a decidere su quale sito lavorare è il CLAUDE.md del progetto, che vediamo al passo 10. È il posto giusto dove tenere quell’informazione: la proprietà è una cosa del progetto, il collegamento è una cosa della macchina.

Attenzione a cosa stai scegliendo, però: con lo scope utente ogni sessione, in qualunque cartella, può interrogare tutte le proprietà a cui l’account di servizio ha accesso. Se fra quelle ci sono dati di clienti, valutalo prima.

9. Controlla che sia collegato

Avvia l’agente nella cartella del marketing:

claude

La prima volta ti chiede se ti fidi dei server MCP dichiarati nel progetto. Rispondi di sì solo perché quel file l’hai scritto tu: è una domanda che ha senso, e su un progetto scaricato da internet la risposta giusta sarebbe guardare prima cosa c’è dentro.

Poi scrivi:

/mcp

Deve comparire ga4 con lo stato connected. Se dice failed, salta al fondo dell’articolo: le tre cause possibili sono lì.

Ora la prova vera, che non è la connessione ma il permesso:

Elenca le proprietà GA4 a cui hai accesso.

Se compare la tua proprietà, i due pezzi combaciano: il server parla con Google e Google riconosce l’account di servizio.

10. Scrivi le regole una volta sola

L’agente adesso può leggere i dati. Non sa ancora quale proprietà guardare, né come deve rispondere. Se glielo dici a voce ogni volta, lo dirai ogni volta.

Crea un file CLAUDE.md nella cartella del marketing. È il file che l’agente legge da solo all’avvio:

# Area marketing di mio-sito

Questa cartella contiene i dati sul sito, non il sito.

Proprietà GA4: 123456789
Se una richiesta non nomina la proprietà, usa questa e dillo nella risposta.

Dove vanno le cose:
- dati/ esportazioni grezze, nome file AAAA-MM-GG-cosa.csv
- report/ report leggibili in Markdown
- domande/ le richieste ricorrenti

Come rispondere:
- il sito è nuovo e i numeri sono piccoli. Con numeri piccoli le percentuali
  mentono: "+300%" può voler dire da 1 a 4. Scrivi sempre i valori assoluti
  accanto alle variazioni;
- niente confronti con medie di settore: non ne abbiamo;
- se un dato sembra sbagliato, scrivi che sembra sbagliato invece di sistemarlo.

L’ultima riga vale più delle altre. Un agente che riceve un numero strano ha una tendenza naturale a raccontartelo in modo plausibile. Chiedergli esplicitamente di segnalare l’anomalia invece di smussarla cambia il tipo di risposta che ti arriva.

11. Le prime domande

Adesso puoi chiedere a parole tue. Qualche esempio che funziona:

Gli screenshot che seguono sono presi su un altro sito, con qualche anno di traffico alle spalle. Il sito di questo libro è nato da pochi giorni e un report sui suoi numeri non mostrerebbe niente di leggibile: la forma del risultato si capisce meglio dove i dati ci sono davvero.

Quante sessioni e quanti utenti attivi negli ultimi 30 giorni?
Mostrami i numeri giorno per giorno.

Le dieci pagine più viste degli ultimi 90 giorni, con il titolo della pagina
e non solo il percorso.

Da dove arriva la gente? Canale predefinito, ultimi 30 giorni, numeri assoluti.

E il salto di qualità, che è il motivo per cui abbiamo creato la cartella domande/: le richieste buone si salvano.

Quando una domanda ti ha dato la risposta giusta, mettila in un file. Per esempio domande/report-mensile.md:

Fai il report di luglio 2026 per la proprietà GA4 123456789.

Voglio, in questo ordine:
1. utenti attivi, sessioni e visualizzazioni del mese, con il confronto sul mese
   precedente in valore assoluto e in percentuale;
2. le dieci pagine più viste, con il titolo della pagina;
3. da dove arrivano le persone, con i numeri assoluti;
4. quanti tornano e quanti sono nuovi;
5. tre cose che noti e che meritano un controllo, una riga ciascuna.

Salva il risultato in report/mensili/2026-07.md e chiudi scrivendo il periodo
esatto interrogato e la data di oggi.

Il mese dopo apri l’agente e scrivi: esegui domande/report-mensile.md per agosto. La domanda l’hai formulata una volta e la riusi per anni.

Nota l’ultima riga della richiesta. Chiedere all’agente di scrivere quale periodo ha interrogato trasforma il report da “un testo con dei numeri” in un documento verificabile: fra sei mesi saprai se quei 1.340 erano sette giorni o trenta.

12. Che forma dare al risultato

Il Markdown va benissimo per te, che lo apri in un editor. Per gli altri no, e qui si apre una scelta che conviene fare con la testa invece che per abitudine.

Prima però una regola che vale per qualunque formato tu scelga: il Markdown resta la fonte. PDF, pagina web, foglio di calcolo sono cose che si rigenerano in un secondo, il testo con i tuoi ragionamenti no. Se cancelli il sorgente e tieni solo il prodotto finito, la prossima correzione la fai a mano.

Il PDF, per chi non apre il terminale

È la forma giusta quando il report deve arrivare a un cliente, a un socio o a un consiglio direttivo: si allega a una email, si stampa, si archivia, e fra due anni si apre ancora.

La conversione si fa con due programmi da riga di comando: pandoc, che trasforma il Markdown, e weasyprint, che stampa. Su macOS:

brew install pandoc weasyprint

Poi, sempre nella cartella del marketing:

pandoc report/mensili/2026-07.md \
  --pdf-engine=weasyprint \
  --css=report/stile-pdf.css \
  --metadata title="Report di luglio 2026" \
  -o report/mensili/2026-07.pdf

Il file report/stile-pdf.css è un foglio di stile che decidi tu una volta: colori, caratteri, come vengono le tabelle. Chiedi all’agente di scrivertelo la prima volta e poi non lo tocchi più.

Il comando conviene metterlo nel CLAUDE.md, così l’agente esporta da solo quando glielo chiedi, senza che tu debba ricordare la sintassi di pandoc.

Ecco che aspetto ha il risultato. È un report vero su venti giorni di traffico, prodotto con questo procedimento: la prima pagina apre con la sintesi in sei righe e i numeri principali a confronto con il periodo precedente.

La seconda pagina mette i grafici, e sotto una riga che dice cosa si vede.

Guarda la sintesi in cima alla prima pagina, perché è la parte che vale. Non dice soltanto che le sessioni salgono: dice che salgono mentre le conversioni scendono, e che il calo viene quasi tutto da un canale solo. Quello non è un numero, è una frase che ti fa aprire un’altra domanda. Un’esportazione da Analytics non te la dà, e nemmeno un agente a cui chiedi solo i numeri: gliela devi chiedere, come nella richiesta del passo 11.

La dashboard, se preferisci navigare

Un PDF è fermo. Se i numeri li guardi tu e ti interessa girarci intorno, ordinare una tabella, passare da un mese all’altro, la forma giusta è una pagina web: un file .html che apri con doppio clic e che si comporta come una piccola dashboard.

È una cosa che puoi chiedere all’agente a parole tue:

Con i dati del report che hai appena fatto, costruiscimi una pagina
report/dashboard-2026-07.html che apra con doppio clic.

Voglio: i tre numeri principali in grande, un grafico delle sessioni giorno
per giorno, e la tabella delle pagine più viste ordinabile cliccando sulle
intestazioni.

Un file solo, senza librerie da scaricare da internet, e i dati scritti dentro
il file. Deve funzionare anche offline.

Le due righe finali sono la parte che conta. Un file autosufficiente lo apri fra un anno e funziona ancora; uno che dipende da mezzo internet, il giorno che quella libreria sparisce ti si presenta bianco.

Due avvertenze oneste, perché è facile aspettarsi la cosa sbagliata.

Non si aggiorna da sola. È una fotografia dei dati del momento in cui l’hai generata. Per rinfrescarla si richiede all’agente, che rifà l’interrogazione e riscrive il file. Va benissimo, purché tu sappia che il numero che vedi ha la data di quando è stato chiesto: fatti scrivere quella data dentro la pagina.

Non provare a farla collegare a Analytics da sola. Sembra il passo successivo naturale, ed è invece l’errore che vanifica tutto: perché una pagina web interroghi Analytics da sé, le credenziali devono stare dentro la pagina, cioè dentro un file che chiunque la apra può leggere. La tua chiave finirebbe in chiaro. Il collegamento ai dati resta dove l’abbiamo messo, nel terminale, e la pagina riceve numeri già pronti.

Cosa questo collegamento non fa

Vale la pena essere chiari, perché è facile aspettarsi più di quello che c’è.

Non installa Analytics sul sito. Se il sito non ha il codice di monitoraggio, non ci sono dati da leggere e nessun collegamento li inventa.

Non modifica niente. Con il ruolo Visualizzatore l’agente legge e basta. Non può creare eventi, cambiare filtri o toccare la configurazione.

Non vede Search Console e non vede gli annunci. Sono servizi diversi, con server MCP diversi, e vanno aggiunti a parte. La buona notizia è che il lavoro grosso l’hai già fatto: stesso progetto Cloud, stesso account di servizio, stessa chiave. Per Search Console ti restano da attivare un’API e da autorizzare quell’indirizzo dentro Search Console, e sono cinque minuti.

Non fa marketing. Ti dice che le visite alla pagina X sono calate. Perché siano calate, e cosa farne, resta lavoro tuo. È esattamente la divisione del lavoro di cui parla il libro: all’IA la messa in opera, a te decidere, descrivere e rispondere del risultato.

Domande frequenti

/mcp dice failed. Cosa guardo?

Nell’ordine, perché sono le tre cause quasi sempre:

1. il percorso della chiave è sbagliato. Deve essere assoluto e senza ~. Controlla con ls -l /Users/tuonome/.credentials/ga4-service-account.json: se il file non esiste, il terminale te lo dice;
2. pipx non è raggiungibile. Prova a lanciare pipx run analytics-mcp a mano nel terminale. Se fallisce lì, fallisce anche dentro l’agente;
3. le API non sono attive nel progetto Google Cloud. Torna al passo 5.

Si collega ma dice che non ha accesso alla proprietà

È il permesso dentro Analytics, non la configurazione. O l’account di servizio non è stato aggiunto alla proprietà, oppure è stato aggiunto da meno di dieci minuti. Ricontrolla che l’indirizzo in Gestione accessi sia identico al client_email del file di chiave, carattere per carattere.

Devo rifare tutto Google Cloud per il prossimo sito?

No, ed è la ragione per cui vale la pena farlo bene la prima volta. Progetto Cloud, API attivate, account di servizio e chiave sono infrastruttura della macchina, non del sito: si fanno una volta.

Per una proprietà nuova restano solo due gesti, quelli del passo 6: incollare l’indirizzo dell’account di servizio in Gestione accessi alla proprietà con ruolo Visualizzatore, e scrivere l’ID della proprietà nel CLAUDE.md del progetto. Due minuti.

E lo stesso account di servizio serve anche per Search Console e per Google Ads: cambia l’API da attivare nella libreria e il posto dove autorizzare quell’indirizzo, il resto è già in piedi.

Posso collegare più proprietà?

Sì, ed è il caso normale se segui più siti. Lo stesso account di servizio va aggiunto come Visualizzatore in ognuna delle proprietà. Poi, in ogni cartella di progetto, l’agente lavora sulla proprietà che gli dici tu nel CLAUDE.md: un sito per cartella, così non si confonde.

Funziona anche con Codex?

Sì. Il server MCP è lo stesso e le credenziali pure: cambia il file dove si dichiara il collegamento, che in Codex è ~/.codex/config.toml invece di .mcp.json. Il concetto, la chiave e i permessi in Analytics non cambiano.

I miei dati finiscono a un’azienda di IA?

I numeri che l’agente legge passano nella conversazione, quindi sì: quello che chiedi e quello che ti risponde transita dal modello, come qualunque altra cosa scrivi in chat. Sono dati aggregati di traffico, non dati personali dei visitatori, ma è bene saperlo prima e non dopo. Se lavori su una proprietà di un cliente, è una cosa da concordare con lui.

Da dove continuare

Se le cartelle e i percorsi sono ancora terreno incerto, il posto giusto è Iniziamo a usare il terminale: la ricetta di oggi dà per scontato che cd in una cartella sia un gesto automatico, e conviene che lo diventi davvero.

Per capire cosa succede quando l’agente decide da solo quale strumento usare, c’è Claude Code: cos’è, come funziona e cosa può fare.

Puoi anche iscriverti agli aggiornamenti per ricevere le prossime ricette.

Fonti ufficiali

• Server MCP ufficiale di Google Analytics
• Google Analytics Data API
• Google Analytics Admin API
• Account di servizio in Google Cloud
• Gestione degli accessi in Google Analytics
• MCP in Claude Code
• Model Context Protocol