Google Analytics 4 + Claude Code: Analisi del Comportamento Utente via MCP con il Server Ufficiale Google

Hai keyword in posizione 5 con CTR del 12%. Ottimo. Ma il bounce rate di quelle pagine è 85%.

Search Console ti dice come le persone arrivano al tuo sito. Screaming Frog ti dice cosa trovano dal punto di vista tecnico. Ma nessuno dei due ti dice cosa succede dopo il click. Quanto tempo restano? Dove cliccano? Convertono? Quello è il dominio di Google Analytics — e fino a oggi, per incrociare questi dati servivano export, fogli di calcolo e un paio d'ore di lavoro manuale.

A luglio 2025, Google ha rilasciato il server MCP ufficiale per GA4. Non un progetto community, non un wrapper di terze parti: un server mantenuto dal team di Google Analytics, con accesso diretto alla Data API e alla Admin API. A marzo 2026 è arrivato alla versione 0.2.0, con 1.500 stelle su GitHub e il supporto completo per Claude Code.

In questo articolo analizzo come funziona, i 7 tool che espone, e soprattutto come si integra con gli altri server MCP che uso già — Search Console e Screaming Frog — per chiudere il cerchio dell'analisi SEO. Il terzo pilastro di uno stack che sto costruendo pezzo per pezzo.

Google Analytics 4 via MCP: il pezzo mancante dello stack

Nei due articoli precedenti — Screaming Frog MCP per l'audit tecnico on-site e

Search Console MCP per i dati SERP — ho costruito un sistema che analizza due terzi del quadro. Mancava il terzo: il comportamento dell'utente dopo l'atterraggio.

GA4 è lo strumento che colma quel vuoto. Non perché sia l'unica piattaforma di analytics — ce ne sono decine — ma perché è quella che il 90% dei siti usa, e perché Google l'ha resa accessibile via MCP in modo nativo.

La logica a tre pilastri è questa: Screaming Frog dice cosa c'è sul sito, Search Console dice come viene trovato, GA4 dice cosa succede dopo il click. Con i tre server MCP attivi, Claude incrocia tutto in un'unica conversazione.

La differenza rispetto a usare la dashboard di GA4 è la stessa che ho descritto per Search Console: non è un problema di accesso ai dati, ma di velocità nel fare le domande giuste. GA4 ha report potenti, ma navigarli richiede dimestichezza con un'interfaccia che Google cambia ogni sei mesi. Il server MCP bypassa l'interfaccia e ti dà accesso diretto ai dati attraverso il linguaggio naturale.

I 7 tool disponibili: mappa delle funzionalità

Il server MCP ufficiale di Google espone 7 tool organizzati in due blocchi: amministrazione e reporting. È un set più snello rispetto ai 12 di Search Console, ma il tool run_report da solo copre l'intero spettro della GA4 Data API — dimensioni, metriche, filtri, ordinamento, fino a 250.000 righe per query.

Amministrazione

Reporting

Il vero cavallo di battaglia è run_report. Supporta qualsiasi combinazione di dimensioni GA4 (pagePath, sessionSource, deviceCategory, country, firstUserMedium...) con qualsiasi metrica (sessions, engagedSessions, bounceRate, averageSessionDuration, conversions, totalRevenue...). Più filtri, ordinamento e paginazione.

In pratica, tutto quello che puoi costruire nella sezione Explore di GA4 è accessibile via run_report — ma senza dover costruire il report a mano. Dici a Claude "mostrami le top 10 landing page per tasso di engagement, segmentate per device, nell'ultimo mese" e il modello compone la query API corretta.

Setup: da Google Cloud al primo report

Il setup è più strutturato rispetto a quello di Search Console MCP. Google usa il sistema Application Default Credentials (ADC), che richiede la CLI gcloud e un progetto Google Cloud configurato. Non è complesso, ma richiede attenzione a ogni passaggio.

Requisiti

Passaggi chiave

1. Crea (o seleziona) un progetto su Google Cloud Console. Abilita due API: Google Analytics Data API e Google Analytics Admin API.
2. Crea credenziali OAuth 2.0 (tipo "applicazione desktop"). Scarica il file JSON del client — ti servirà nel passaggio successivo.
3. Autenticati con gcloud CLI: esegui gcloud auth application-default login con gli scope analytics.readonly e cloud-platform, specificando il client-id-file appena scaricato. Il browser si apre, autorizzi, e gcloud salva le credenziali localmente.
4. Configura Claude Code: aggiungi il server MCP nel file settings.json con command "pipx", args ["run", "analytics-mcp"], e le variabili d'ambiente GOOGLE_APPLICATION_CREDENTIALS (path al file credenziali generato da gcloud) e GOOGLE_PROJECT_ID.
5. Testa: chiedi a Claude "elenca le proprietà GA4 disponibili" — se get_account_summaries risponde, il setup è completo.

Tempo stimato per il setup iniziale: 20-30 minuti. Le autenticazioni successive sono automatiche finché il token non scade. Se hai già un progetto Google Cloud configurato per il server MCP di Search Console, il tempo si dimezza — devi solo abilitare le API GA4 aggiuntive.

Un dettaglio importante: il server è read-only. Non può modificare la configurazione di GA4, creare proprietà o inviare eventi. Può solo leggere dati. Questo è un vincolo di sicurezza ragionevole — non vuoi che un prompt sbagliato modifichi la tua configurazione di analytics.

Cosa GA4 mostra che Search Console non mostra

Prima di entrare nei workflow, è utile chiarire dove finisce Search Console e dove inizia GA4. I due strumenti sono complementari, non sovrapposti — ma la linea di confine non è ovvia per tutti.

Il punto cieco di Search Console è tutto quello che succede dopo che l'utente atterra sul sito. Il punto cieco di GA4 è tutto quello che succede prima — quali keyword, quali posizioni, quale CTR. Insieme coprono l'intero percorso.

Esempio concreto: Search Console mi dice che la keyword "consulente SEO Brescia" ha posizione media 15 e CTR dello 0,8%. Dato utile, ma incompleto. Quel 0,8% di utenti che clicca, cosa fa? Resta 10 secondi e rimbalza? Legge la pagina intera e poi va sui contatti? Senza GA4, queste domande restano senza risposta.

Workflow 1: quali landing page convertono e quali rimbalzano

Il primo workflow che testo con GA4 MCP è l'analisi delle landing page per tasso di engagement. Non tutte le pagine che ricevono traffico sono pagine che funzionano. Alcune hanno bounce rate superiore all'80% — il che significa che l'utente arriva, guarda e se ne va.

Con il server MCP, chiedo a Claude: "mostrami le landing page con più sessioni, con bounce rate, durata media sessione e conversioni, ultimo mese." Il modello chiama run_report con le dimensioni landingPage e le metriche sessions, bounceRate, averageSessionDuration, conversions. Risultato in 10 secondi, ordinato e leggibile.

Il dato che cerco è il disallineamento tra traffico e engagement. Pagine con molte sessioni e bounce rate alto sono pagine dove la promessa della SERP (title + meta description) non corrisponde a quello che l'utente trova. Pagine con poche sessioni ma engagement altissimo sono gemme nascoste che meritano più visibilità.

Nella dashboard GA4, costruire questa vista richiede un report personalizzato nella sezione Explore: scegliere dimensioni, aggiungere metriche, configurare filtri, ordinare. Non è difficile, ma richiede 5-10 minuti e familiarità con un'interfaccia che cambia regolarmente. Con il server MCP, è una domanda in linguaggio naturale.

Workflow 2: da dove arriva il traffico che converte

Il secondo workflow è l'analisi per fonte di acquisizione. Non tutto il traffico è uguale: chi arriva da Google organico ha un intento diverso da chi arriva da un post LinkedIn o da un referral. GA4 traccia queste differenze, e il server MCP le rende interrogabili.

Chiedo a Claude: "confronta il tasso di engagement e le conversioni per sessionSource e sessionMedium, ultimo mese." Il modello compone la query con le dimensioni appropriate e restituisce una vista che rivela pattern immediati.

Per un sito come il mio — un sito professionale con un obiettivo chiaro (generare contatti) — la domanda non è quante sessioni ho, ma quante di quelle sessioni si trasformano in qualcosa. Una sorgente che genera 50 sessioni con 3 contatti vale più di una che ne genera 500 con zero interazione.

Questo tipo di analisi è la base del content ROI. Se so che il traffico organico da keyword informazionali ha engagement rate del 60% ma zero conversioni dirette, mentre le keyword transazionali convertono al 5%, posso decidere dove investire tempo. Non è un insight nuovo — è un insight che prima richiedeva mezz'ora di spreadsheet e ora richiede una domanda.

Workflow 3: l'incrocio GSC + GA4 — dalla keyword al comportamento

Questo è il workflow dove avere entrambi i server MCP attivi fa la differenza più grande. L'incrocio tra dati di ricerca e dati di comportamento è il tipo di analisi che ogni SEO specialist vuole fare ma che richiede troppo tempo con gli strumenti tradizionali.

Il flusso è questo: chiedo a Claude di identificare le keyword con più impression ma CTR basso da Search Console. Poi chiedo di incrociare le landing page corrispondenti con i dati GA4 per capire se il problema è nella SERP (title/description poco efficaci) o nella pagina stessa (contenuto che non soddisfa l'intento).

La distinzione è operativa: se il bounce rate è basso ma il CTR è basso, il problema è il title tag. Se il CTR è decente ma il bounce rate è alto, il problema è il contenuto. Senza l'incrocio dei due dataset, non puoi distinguere i due scenari.

Esempio sul mio sito: Search Console mi dice che la pagina /consulente-seo-brescia ha 371 impression e CTR dello 0,81% con posizione media 15. Posizione non ottimale, ma il CTR è basso anche rispetto a quella posizione. GA4 può dirmi cosa fa chi ci arriva: se rimbalza, ho un problema di contenuto. Se resta e interagisce, il problema è puramente di posizionamento SERP e devo lavorare su authority e backlink, non sul contenuto.

Fare questo incrocio manualmente significa: export CSV da Search Console, report personalizzato in GA4, export CSV, merge su foglio di calcolo usando la URL come chiave di join, filtri, ordinamento. Con i due server MCP attivi nella stessa sessione Claude, l'intero processo diventa una conversazione di 90 secondi.

Workflow 4: monitoraggio real-time dopo la pubblicazione

Il tool run_realtime_report è il più sottovalutato del set. Ogni volta che pubblico un nuovo articolo o lancio una nuova landing page, i primi minuti di dati real-time sono preziosi: mi dicono se il tracking funziona, se qualcuno sta arrivando, e da quale canale.

Con il server MCP, chiedo a Claude: "quante sessioni attive adesso sulla pagina X?" Il modello chiama run_realtime_report con un filtro sulla dimensione unifiedPagePathScreen e mi restituisce il dato al volo. Nessun tab di GA4 da navigare, nessun report da configurare.

Il caso d'uso più frequente nel mio workflow è la verifica post-deploy: pubblico una pagina, condivido il link su LinkedIn, e dopo 15 minuti chiedo a Claude quante sessioni sta generando. Se il numero è zero e il post ha già impression, so che c'è un problema di tracking o di redirect da indagare subito — non il giorno dopo, quando il dato storico sarà disponibile.

Il real-time non è un vezzo. È un early warning system che ti permette di intervenire quando il problema è piccolo, non quando ha già compromesso giorni di dati.

Il confronto: GA4 dashboard vs GA4 via MCP

GA4 è uno strumento potente ma con un'interfaccia che divide la community. Chi viene da Universal Analytics fatica con la nuova logica basata su eventi. Chi lo usa da zero ha una curva di apprendimento ripida. Il server MCP non risolve la complessità di GA4 — la aggira.

Il limite più rilevante del server MCP è l'assenza di funnel exploration e path analysis. La GA4 Data API non li espone, e quindi il server MCP non può accedervi. Per queste analisi, la dashboard resta insostituibile.

L'altro limite è la visualizzazione: la dashboard di GA4 mostra trend, grafici, anomalie visive. Il server MCP restituisce numeri. Per un'analisi esplorativa dove non sai cosa cerchi, la dashboard è spesso più efficiente. Per un'analisi mirata dove sai esattamente quale domanda fare, il server MCP è un ordine di grandezza più veloce.

Il sistema completo: tre MCP per l'analisi SEO end-to-end

Con il server GA4 MCP, lo stack conversazionale che sto costruendo arriva al terzo pilastro. Ecco come si incastrano.

• Screaming Frog MCP: audit tecnico on-site — struttura, errori, contenuto, link interni. Risponde a: "cosa c'è di rotto o migliorabile sul sito?"
• Search Console MCP: dati SERP — keyword, posizioni, CTR, indicizzazione. Risponde a: "come viene trovato il sito su Google?"
• GA4 MCP: comportamento utente — sessioni, engagement, conversioni, fonti. Risponde a: "cosa succede dopo il click?"
• Claude Code: orchestra i tre dataset e produce insight che nessun tool, da solo, può generare

Esempio di workflow integrato:

1. Search Console MCP identifica 15 keyword con posizione media 8-15 e CTR sotto la media del sito.
2. Per ciascuna, GA4 MCP rivela il comportamento post-click: 5 hanno engagement rate sopra il 70% (il contenuto funziona, serve salire in SERP), 7 hanno bounce rate sopra l'80% (il contenuto non soddisfa l'intento), 3 hanno sessioni ma zero scroll (la pagina ha problemi tecnici).
3. Per le 3 con problemi tecnici, Screaming Frog MCP verifica: LCP superiore a 4 secondi, immagini non ottimizzate, layout shift.
4. Claude produce una lista prioritizzata: prima i fix tecnici (rapido, alto impatto), poi l'ottimizzazione contenuti (medio termine), poi il lavoro di authority (lungo termine).

Questo flusso, fatto manualmente, richiede un'intera giornata di lavoro tra tre strumenti diversi. Con i tre server MCP attivi nella stessa sessione, diventa una conversazione di 10-15 minuti. Il fattore di accelerazione non è 2x o 5x. È un ordine di grandezza.

Il nodo Windows e altre considerazioni pratiche

Una nota di onestà. Il server GA4 MCP ha un problema noto su Windows: timeout ricorrenti (issue #73 su GitHub). Se lavori su Windows, come faccio io, potresti incontrare errori -32001 Request timed out durante le query più complesse.

Il team Google sta lavorando sulla risoluzione — la versione 0.2.0 ha migliorato la stabilità — ma è un fattore da considerare. Se il timeout è un blocco, l'alternativa è eseguire il server MCP in un container Docker o tramite WSL. Non è ideale, ma funziona.

Altro punto: il server usa pipx come runtime, che aggiunge una dipendenza rispetto ai server MCP basati su Node.js (come quello di Search Console). Se non hai Python e pipx già configurati, il setup iniziale è più lungo. Non è un deal-breaker, ma è tempo reale che va messo in conto.

Limiti, rischi e quando non usare questo setup

Limiti tecnici

• Read-only: il server non può modificare la configurazione di GA4, creare proprietà o inviare eventi. Solo lettura dati.
• Nessun funnel o path analysis: la GA4 Data API non espone questi report. Per le analisi di percorso utente, la dashboard resta necessaria.
• Nessun report audience: segmenti e audience non sono accessibili via API. Puoi filtrare per dimensioni (device, country, source) ma non per audience personalizzate.
• Stato sperimentale: Google lo marca come "experimental". L'API di reporting è stabile, ma il server MCP stesso potrebbe subire breaking changes.
• Timeout su Windows: issue nota, non risolta completamente. Workaround: Docker o WSL.

Limiti operativi

• Costo: Claude Code Max a $100/mese. Per il server MCP in sé non ci sono costi aggiuntivi (il progetto Google Cloud è gratuito, la Data API ha limiti generosi).
• Curva di apprendimento: richiede familiarità con gcloud CLI, OAuth ADC e concetti GA4. Non è un setup per chi non ha mai usato Google Analytics.
• Nessuna visualizzazione: il server restituisce dati tabellari. Per analisi esplorative dove i grafici sono essenziali, la dashboard è superiore.

Quando non usarlo

Non serve se il tuo sito ha poco traffico e poche pagine. La dashboard GA4 è più che sufficiente per un check settimanale su 10 pagine. Non serve se le tue analisi sono prevalentemente visuali — trend, grafici, anomalie. E non serve se non hai le competenze per interpretare i dati di GA4: automatizzare l'estrazione non automatizza la comprensione.

Per chi è adatto e prerequisiti di competenza

Profili ideali

• SEO specialist che lavorano con dati cross-platform: chi già incrocia GSC e GA4 in spreadsheet avrà il beneficio maggiore — il server MCP elimina la fase di export/merge.
• Consulenti con portfolio multi-sito: poter interrogare le proprietà GA4 di più clienti nella stessa sessione conversazionale è un acceleratore enorme per il reporting.
• Team che integrano analytics nel workflow SEO: la possibilità di avere SF MCP + GSC MCP + GA4 MCP nella stessa sessione crea un command center integrato.
• Chi pubblica contenuti frequentemente: il monitoring real-time post-pubblicazione è un caso d'uso immediato e ad alto valore.

Prerequisiti

• Familiarità con GA4: devi conoscere la differenza tra sessioni e sessioni con engagement, tra bounce rate GA4 e bounce rate Universal Analytics, tra dimensioni ed eventi.
• Comfort con il terminale: Claude Code è CLI. gcloud è CLI. pipx è CLI. Se il terminale ti spaventa, questo setup non fa per te.
• Google Cloud basics: creare un progetto, abilitare API, configurare OAuth. Non serve essere un DevOps, ma serve non avere paura della console GCP.

Il terzo pilastro: dallo stack all'ecosistema

Con il server GA4 MCP, lo stack conversazionale per la SEO ha raggiunto un punto di maturità interessante. Non perché sia completo — mancano ancora pezzi, e ne parlerò nei prossimi articoli — ma perché copre l'intero ciclo: tecnica on-site, visibilità in SERP, comportamento utente.

La visione che sto costruendo non è "sostituire i tool con l'AI." È rendere i tool interoperabili attraverso un'interfaccia comune. Screaming Frog, Search Console e GA4 esistevano già come strumenti eccellenti. Il protocollo MCP li trasforma da silos separati in un sistema nervoso che Claude può interrogare come un'unica fonte di verità.

Non è il futuro. È il presente, per chi decide di investire il tempo nel setup. Il vantaggio competitivo di oggi diventa lo standard di domani. Chi inizia adesso ha un margine; chi aspetta, dovrà rincorrere.

Se ti interessa esplorare come integrare GA4 MCP nel tuo workflow, o hai bisogno di supporto per configurare lo stack completo, contattami. Questo è esattamente il tipo di integrazione su cui lavoro con i miei clienti.