Mi capita a volte di vedere clienti che aprono GA4, guardano il canale Direct occupare una fetta enorme del traffico, e concludono che il sito ha semplicemente tanti utenti fedeli che digitano l’indirizzo a memoria. Nella maggior parte dei casi non è così. Il traffico diretto è la categoria in cui Google Analytics fa confluire tutto quello che non riesce ad attribuire a una fonte precisa, e dietro quella fetta si nascondono spesso campagne che stanno funzionando, contenuti citati altrove, condivisioni sui social, che semplicemente non vengono tracciati come tali.
Le analisi di acquisizione dovrebbero dirci da dove arrivano davvero i visitatori e con cosa interagiscono. Quando il direct cresce in modo anomalo, quella capacità di lettura si azzera: le decisioni su budget e contenuti finiscono per basarsi su un pezzo di realtà che in GA4 non esiste più. In questo articolo vediamo cosa genera davvero il traffico direct in Google Analytics 4, come distinguere le cause reali da quelle apparenti, e come ridurne l’impatto sui dati.
Ho aggiornato questo articolo a luglio 2026 con le cause di traffico direct emerse più di recente, incluso il traffico da assistenti AI.
Che cos'è il traffico diretto in Google Analytics 4?
Vediamo innanzitutto cosa si intende per traffico diretto in Google Analytics 4.
La definizione standard ci dice che si tratta del traffico generato dai visitatori che arrivano sul nostro sito web dopo aver digitato la URL direttamente nel loro browser.
In altre parole, i visitatori che non utilizzano i motori di ricerca, i social media o altre fonti esterne per raggiungere una pagina del sito.
Ma il traffico diretto può anche riferirsi alle visite al sito che per vari motivi Google non è stato in grado di attribuire ad alcuna fonte specifica. Come succede quando un utente clicca su un link in un annuncio di Facebook che non include parametri di tracciamento, e che quindi GA4 non è in grado di categorizzare correttamente a livello di sorgente.
Quindi, in questo articolo, ci rifaremo al traffico diretto in Google Analytics in riferimento alle visite al sito web di cui non si conosce la fonte di traffico o la fonte di riferimento non è tracciata correttamente.
Il traffico diretto può essere un segno di buona conoscenza del brand, oppure un segno di scarsa ottimizzazione nei tracciamenti. Dipende dai casi.
Google cerca di ridurre automaticamente al minimo il traffico diretto nei suoi rapporti. Per esempio: se un utente visita il sito tramite una ricerca organica e ritorna tramite un accesso diretto una settimana dopo, entrambe le sessioni saranno attribuite alla ricerca organica iniziale. Ma questo avviene solo per un determinato periodo di tempo stabilito da Google, il tempo di attribuzione. Se l’utente ritorna sul sito, magari digitando direttamente l’indirizzo nella barra di ricerca del suo browser successivamente al limite di tempo di attribuzione, la visita sarà registrata come direct.
Come visualizzare il traffico diretto in Google Analytics 4
- Pagina di destinazione
- Fonte del primo utente
- Media della sessione e altre dimensioni
Per un’analisi più mirata, in Esplora puoi costruire modelli di report personalizzati e isolare il traffico diretto secondo i parametri che ti interessano davvero.
A cosa è dovuto il traffico direct in Google Analytics?
Ora che abbiamo capito meglio cos’è il traffico diretto, vediamo quali sono le motivazioni che stanno alla base di questa classificazione da parte di Google. Ci sono diversi fattori che possono contribuire al traffico diretto:
- In-App browser di Meta
- Inserimento facilitato della URL, inserimento manuale di indirizzi o segnalibri
- Codice di tracciamento mancante o non funzionante
- Link da documenti non html
- Passaggio e link HTTP a HTTPS
- Dark social (condivisioni non tracciabili)
- Traffico da assistenti AI senza referrer
- Problemi di configurazione di GA4
- Problemi di attribuzione da parte di GA4 (ebbene si, anche GA4 a volte fallisce)
- Redirect 301/302 che eliminano i parametri di tracciamento
Il famigerato "in-app browser" di Meta
Capita spesso che vengano lanciate campagne Meta con ottimi risultati sulla piattaforma pubblicitaria, clic, coinvolgimento, conversioni segnalate, e poi si apre GA4 e non si trova quasi nulla di tutto questo: metà degli acquisti risulta senza fonte, la voce facebook / cpc è quasi vuota, mentre (direct) / (none) è molto più alto del normale.
La causa è il browser in-app di Meta: Facebook e Instagram non aprono i link cliccati nell’app in Chrome o Safari, ma li caricano dentro un browser interno all’app stessa. Quando questo succede, il referrer viene eliminato perché la richiesta parte da un contesto app e non da un browser standard, e i parametri fbclid o UTM si perdono nei reindirizzamenti o nei caricamenti dinamici della pagina. Se l’utente torna più tardi sul sito tramite Safari o Chrome, magari digitando l’indirizzo o da una scheda salvata, GA4 registra quella visita come una sessione diretta completamente nuova, senza nessun collegamento con l’annuncio che l’ha originata.
Il risultato pratico è che le campagne Meta generano vendite reali che nei report restano invisibili, e chi guarda solo GA4 per decidere dove spostare budget rischia di tagliare proprio i canali che stanno funzionando meglio.
Inserimento guidato della URL, inserimento manuale degli indirizzi o segnalibri
Ho raggruppato queste casistiche perché sono il motivo primario per cui Google Analytics cataloga il traffico come direct. E per quanto riguarda GA4, non c’è modo di evitarlo.
Per comprendere meglio, proviamo a pensare a cosa potrebbe succedere nella pratica: un utente arriva sul sito per la prima volta tramite una ricerca organica e visita il sito. In questo caso la visita viene catalogata come Organic Search (o ricerca organica).
Tempo dopo vuole nuovamente accedere al sito. Questa volta, inizia a scrivere il nome del sito nella barra di ricerca. Il browser, utilizzando i cookie e i dati della cache, riempie automaticamente la barra con la URL del sito. A questo punto all’utente basta premere Invio sulla tastiera per entrare nella pagina già visitata. In questo caso Google tratterà questa visita come sessione diretta. Lo stesso vale per l’inserimento manuale dell’indirizzo, ad esempio se ha inserito il sito tra i preferiti per tornarci in seguito.
Fin qui siamo nelle situazioni in cui la catalogazione come direct è effettivamente corretta. Vediamo ora alcune cause che generano traffico diretto ma che in realtà non lo sono.
Codice di tracciamento mancante o non funzionante
Una causa comune di traffico diretto in Google Analytics è la (parziale o totale) mancanza del codice di monitoraggio o il suo mancato funzionamento.
In fase di sviluppo del sito è necessario porre la massima attenzione e fare in modo che tutte le pagine includano il codice di monitoraggio di Google Analytics. Idealmente, il codice Javascript per il tracciamento dovrebbe trovarsi nel tag body, ma non tutti i siti sono configurati in questo modo.
Un ottimo modo per inserire il codice nel modo corretto e automaticamente in tutte le pagine del sito è quello di utilizzare Google Tag Manager, che consente di gestire in un unico punto centralizzato tutti gli script di tracciamento (GA4, Google Ads, Pixel di Meta, ecc…), oltre ad offrire moltissime altre funzionalità.
Senza il codice di monitoraggio, Google Analytics non può tracciare la provenienza dell’utente.
Quindi, se per esempio un utente arriva su una pagina nella quale il codice di tracciamento è assente e poi passa a una seconda pagina nella quale il codice è presente, Google Analytics 4 non ha altra scelta che attribuirlo come traffico diretto, perché la provenienza da una pagina senza codice non consente di rilevarne la visita: in questo modo la pagina di atterraggio verrà definita come referrer della seconda pagina visitata.
Link da documenti non html
I link incorporati nei documenti creati con Word, Documenti Google o documenti in formato PDF, normalmente non trasmettono insieme alla URL le informazioni sul referrer.
Pertanto, per impostazione predefinita, ogni utente che visita il sito tramite uno di questi link sarà classificato come direct.
In un certo senso questo è inevitabile e costituirà sempre una parte del traffico diretto. Tuttavia, ove possibile, è consigliabile creare link in queste risorse non HTML aggiungendo i parametri UTM.
Questo consente a Google di raccogliere i dati di riferimento anche se provengono da una fonte non tracciabile, come i documenti non HTML.
HTTP – HTTPS
Si tratta di situazioni ormai rarissime (e che quindi ben difficilmente possono impattare sulla quantità di traffico direct), ma che ti racconto ugualmente poiché in qualche raro caso potrebbe verificarsi.
Se un utente che sta navigando un sito accessibile con protocollo sicuro (HTTPS) segue un link che porta ad una pagina del nostro sito a cui si accede ancora con protocollo non sicuro (HTTP), i dati di riferimento del sito di partenza non vengono trasmessi. Pertanto, tutte le sessioni di questo tipo sul nostro sito (quello senza HTTPS) verranno catalogate come traffico diretto anziché come referral.
Questo fa parte del modo in cui è stato progettato il protocollo HTTPS e non può essere evitato.
Dark social (condivisioni non tracciabili)
Il dark social si riferisce fondamentalmente alle condivisioni social che, per vari motivi, non possono essere attribuite correttamente. Per esempio potrebbe trattarsi di link condivisi su Facebook Messenger, WhatsApp o anche via e-mail: una fetta di condivisioni ormai enorme, che sfugge quasi del tutto ai canali social tracciabili di default.
Non sempre però il traffico proveniente da queste sorgenti, in assenza di altri parametri, viene attribuito al traffico diretto. In alcune circostanze potrebbe essere attribuito al traffico referral.
Poiché si tratta di una forma di comunicazione e condivisione di link sempre più utilizzata, è necessario tenerne conto e anche in questo caso utilizzare i parametri UTM quando possibile.
Traffico da assistenti AI senza referrer
Negli ultimi mesi continuo a ricevere la stessa domanda da chi gestisce siti con contenuti tecnici o editoriali: come isolo in GA4 il traffico che arriva da ChatGPT o Perplexity? La risposta pratica, fino a poco tempo fa, era che non si poteva isolare del tutto, perché finiva mescolato al resto.
Il meccanismo è lo stesso che abbiamo visto per il browser in-app di Meta. Quando un utente clicca un link dentro un’app di chat AI, soprattutto su mobile, il referrer spesso non viene trasmesso al browser di destinazione: l’app lo elimina, o il link viene aperto tramite copia e incolla. GA4, senza un referrer riconoscibile, non ha altra scelta che catalogare quella sessione come diretta, anche se in realtà l’utente è arrivato sul sito perché il contenuto è stato citato o linkato in una risposta generata da un’intelligenza artificiale.
Il 13 maggio 2026 Google ha introdotto in GA4 un canale nativo dedicato, AI Assistant, che riconosce automaticamente le sessioni provenienti da ChatGPT, Gemini e Claude e le separa dal resto, senza bisogno di configurazioni manuali o pattern regex. È un passo avanti concreto rispetto a un anno fa, ma resta parziale su tre punti: Perplexity non rientra ancora tra le fonti riconosciute e continua a comparire come referral tradizionale, la classificazione non è retroattiva (il traffico precedente al 13 maggio resta dove era già catalogato, spesso nel direct), e soprattutto tutto il traffico AI che arriva senza referrer, il caso più comune su mobile, continua a confluire nel direct esattamente come prima.
Ignorare questo aspetto porta a leggere una parte del traffico diretto come se si trattasse di utenti fedeli che digitano l’URL a memoria (o che la trovano suggerita e pre-compilata da parte del browser), quando in realtà si tratta di persone che arrivano al nostro sito grazie ad una citazione dentro una risposta AI. È una distinzione che cambia la valutazione di quali contenuti stanno davvero funzionando, e merita di essere tenuta d’occhio separatamente dal resto del direct, magari con un gruppo di canali personalizzato dedicato, di cui parliamo più avanti in questo articolo.
Problemi di tracciamento o raccolta dei dati
Nonostante le questioni che abbiamo elencato, possiamo molto probabilmente affermare che buona parte del traffico diretto non è dovuto a un utente che ha digitato l’URL nella barra del proprio browser. Una grossa fetta di quel traffico direct è quasi certamente una classificazione di GA4 basata sull’assenza di dati di riferimento, e quindi sull’impossibilità di comprendere correttamente la sorgente della visita.
Questa assenza ha in pratica due origini diverse: da un lato ci sono i dati di riferimento che vengono persi durante il percorso, per esempio a causa di redirect o implementazioni scorrette dei tracciamenti, dall’altro ci sono i casi in cui GA4 non riesce proprio ad attribuire correttamente la fonte anche quando i dati ci sarebbero, per limiti dello strumento stesso. Vediamo entrambi i casi in dettaglio.
Se la maggior parte del traffico del tuo sito è diretto, non c’è da esserne fieri: non si tratta automaticamente del riconoscimento di un brand molto forte, è molto più probabile che indichi una implementazione di GA4 o Tag Manager con problemi di tagging.
Problemi di configurazione di GA4 che generano traffico direct
Oggigiorno il tracciamento dei dati avviene sempre più spesso grazie a tool come Google Tag Manager, che facilitano il compito a chi implementa i tracciamenti per le varie piattaforme, che si tratti di GA4, Google Ads, Meta Ads e così via. Continuo a imbattermi in contenitori dove il tag di configurazione GA4 è agganciato a un trigger sbagliato, per esempio un evento custom invece del caricamento della pagina, così le prime interazioni dell’utente restano fuori dal tracciamento, e quando il tag finalmente si attiva GA4 non ha più modo di recuperare la sorgente originale della sessione.
A volte il problema non è nel tagging ma nella configurazione della proprietà GA4 stessa, per esempio impostazioni di raggruppamento dei canali lasciate ai valori predefiniti su un sito con flussi di traffico particolari. Scoprire questo tipo di errore non è quasi mai immediato, e spesso serve un occhio esperto per individuare il punto critico e risolverlo.
Problemi di attribuzione da parte di GA4 (ebbene si, anche GA4 a volte fallisce)
Può succedere che, pur impostando correttamente i tracciamenti tramite tool come Google Tag Manager, GA4 non esegua correttamente le attribuzioni ai vari canali di acquisizione.
Non sempre questo è sintomo di una errata configurazione dello strumento: a volte è proprio GA4 che non ce la fa. Altre volte possono verificarsi bug o cambi nella gestione dei dati sulla piattaforma.
In queste situazioni bisogna procedere diversamente, per esempio indicando direttamente a Google qual è la corretta attribuzione: bisogna cioè bloccare l’attribuzione automatica e sovrascrivere le informazioni native che vengono inviate a GA4 con specifiche decise da noi, in modo che GA4 non debba fare altro che fidarsi di quello che gli abbiamo inviato.
La prima implementazione da fare, come vedremo tra poco, è l’uso corretto dei parametri UTM: in questo modo siamo noi a dire a Google Analytics come catalogare la sorgente della visita. In aggiunta, è possibile impostare un proprio Gruppo di canali personalizzato per istruire GA4 verso un’attribuzione più corretta rispetto alle nostre esigenze.
Redirect 301/302 che eliminano i parametri di tracciamento
Può succedere che per una pagina venga impostato un redirect verso una nuova pagina, per esempio perché la seconda sostituisce la prima, o per molte altre ragioni.
Ma se il redirect non trasferisce i parametri di tracciamento alla nuova pagina, il tracking verrà perso inesorabilmente, e non sarà possibile rilevare l’attribuzione corretta per quella visita.
Come ridurre l'impatto del traffico direct
Dopo aver analizzato i motivi principali per cui una parte del traffico verso un sito può essere catalogato erroneamente come “direct”, vediamo ora come possiamo ridurre al minimo l’impatto di queste errate attribuzioni.
Come abbiamo visto, il traffico diretto è sostanzialmente inevitabile. E non è detto che sia necessariamente una cosa negativa, perché il traffico diretto potrebbe indicare che le persone conoscono il sito e lo cercano intenzionalmente, anche se dobbiamo ammettere che questi casi non sono così frequenti, tranne, come abbiamo già detto, per gli utenti di ritorno che arrivano al sito iniziando a scriverne il nome sulla barra degli indirizzi ed utilizzano il suggerimento del browser.
Se dovessimo definire una regola generale per indicare un range ragionevole per il traffico diretto, potremmo pensare ad una percentuale compresa tra il 5% e il 20% del traffico registrato da Google Analytics. Se questa percentuale viene superata, è possibile che ci sia qualcosa da sistemare nel sistema di tracciamento nel suo complesso, o in qualche elemento del sito.
Di seguito elenchiamo alcune possibili ottimizzazioni per ridurre il traffico diretto e ottenere migliori informazioni:
- Implementare i parametri UTM
- Migrare ad HTTPS
- Evitare vanity URL
- Controllare il codice di Google Analytics
- Bloccare il traffico interno
- Creare in GA4 il proprio Gruppo di canali personalizzato
Implementare i parametri UTM
Iniziamo con l’operazione più ovvia e che dovrebbe essere una pratica standard per i marketer.
Il tracciamento delle campagne, noto anche come parametri di tracciamento UTM, consente di aggiungere una serie di informazioni speciali alla URL presente nel link che porta al nostro sito che aiutano Google ad identificare in modo preciso la sorgente di quella visita (oltre che il rendimento delle campagne a pagamento).
In questo modo, Google Analytics potrà raccogliere i dati relativi alla fonte e al mezzo di provenienza della visita estraendo le informazioni direttamente dai parametri UTM presenti nel link. In questo modo, per i link che non possono essere tracciati diversamente, possiamo assicurarci che siano attribuiti al canale giusto.
I parametri UTM principali sono i seguenti:
- utm_source: identifica la sorgente (per esempio “google”)
- utm_medium: identifica il mezzo all’interno della sorgente (per esempio “cpc” per campagne a pagamento oppure “organic” per provenienze dai risultati di ricerca)
- utm_campaign: identifica il nome della campagna quando si tratta di advertising
Nell’autunno del 2023, con il rilascio della versione 17 di iOS, Apple ha introdotto la Link Tracking Protection dando il via ad una ulteriore problematica: la rimozione da parte del browser di tutti i sistemi nativi di tracciamento utilizzati dalle varie piattaforme presenti nei link, i cosiddetti sistemi di auto tagging:
- gclid -> per Google Ads
- dclid -> per la Rete Display di Google
- fbclid -> per Facebook Ads
- twclid -> per gli Annunci Twitter
- msclklid -> per gli Annunci Microsoft (Bing)
- mc_eid -> per l’email marketing tramite Mailchimp
- igshid -> per Instagram
Questo significa che il codice di tracciamento inserito automaticamente dalle varie piattaforme viene rimosso dal link che viene aperto, eliminando, quindi, la possibilità per Google di comprendere la reale fonte della visita al sito.
Fortunatamente, per ora, non vengono eliminati i parametri UTM, che diventano così l’unico modo certo per attribuire una visita al sito alla fonte corretta.
NB: Firefox, nelle settimane successive all’uscita della Link Tracking Protection di Apple, ha già introdotto nel proprio browser alcune limitazioni che imitano quanto implementato nella LTP, e molto probabilmente altri browser, a breve, seguiranno la stessa strada.
Diventa quindi fondamentale non dimenticare l’uso dei parametri UTM in tutti i nostri link sparsi per il web se vogliamo che l’attribuzione alla fonte del traffico possa avvenire in modo corretto.
Suggerimento
Per generare correttamente i parametri UTM da inserire in un link per il quale vogliamo che la sorgente venga riconosciuta in modo preciso da Google Analytics, consigliamo di utilizzare UTM Builder, messo a disposizione da Google.
Suggerimento
E se hai bisogno di approfondire come impostare i parametri UTM e come Google utilizza i dati che rileva da questi parametri, puoi accedere a questo documento di supporto.
Migrare ad HTTPs
Come abbiamo detto, stiamo parlando di situazioni ormai rarissime: i siti web, nella stragrande maggioranza, sono oggi raggiungibili attraverso il protocollo HTTPS, quindi attraverso un canale sicuro di comunicazione.
Nel caso in cui si stia però analizzando il traffico di un sito che non è ancora stato configurato per il protocollo HTTPS, questo può influire sul modo in cui Google Analytics traccia il traffico, in particolare quando si tratta di tracciare il traffico di referral, quindi quello proveniente da altri siti.
Quando un utente clicca su un link da un sito web sicuro (HTTPS) verso un sito non sicuro (HTTP), le informazioni di riferimento potrebbero non essere trasmesse al sito web non sicuro. Questo può far sì che il traffico venga classificato come traffico diretto anziché come traffico di referral in Google Analytics.
La soluzione è semplice: attivare il protocollo HTTPS sul proprio sito.
Evitare le "vanity URL"
Le vanity URL sono ottime per tracciare in modo approssimativo l’impatto di particolari campagne. Di fatto si tratta di un meccanismo di redirezione di una URL verso un’altra URL. La gestione dei reindirizzamenti, però, è fondamentale per una buona struttura del sito e per l’esperienza dell’utente, oltre che per il monitoraggio.
Perciò, quando si utilizzano vanity URL semplici senza tag UTM, è bene ricordare che si otterranno dati di riferimento piuttosto limitati, perché la redirezione da una URL all’altra genera la perdita delle informazioni relative alla sorgente di partenza.
Utilizzando una vanity URL alla quale vengono aggiunti tutti i tag appropriati (UTM), è possibile garantire che Google Analytics tracci accuratamente le sessioni.
Controllare il codice di Google Analytics
Se sulle dashboard presenti nella proprietà di Google Analytics 4 è già possibile vedere alcuni dati, è quasi certo che il codice di tracciamento è già stato configurato in qualche modo sul sito, o almeno su alcune pagine.
Tuttavia è necessario verificare dove è presente il tag di tracciamento sul sito e se è presente in tutte le pagine.
Se non è stato installato nel posto giusto, potrebbe significare che nuove pagine non vengono tracciate da Google Analytics.
Consiglio sempre di utilizzare Google Tag Manager per gestire il codice di tracciamento di GA4. In questo modo, tra l’altro, abbiamo maggiore controllo sull’attivazione o meno del tracciamento stesso in base alle scelte che l’utente avrà fatto sul banner dei cookie.
A proposito: utilizzi già la Consent Mode V2 per la gestione del consenso da parte degli utenti? Se non sai di cosa si tratta, ho scritto una guida su come la Consent Mode V2 impatta sull’attribuzione in GA4.
Bloccare il traffico interno
È probabile che il tuo team e quello degli sviluppatori visiti il sito web in più occasioni nel corso della giornata, quasi sempre utilizzando un segnalibro o affidandosi al riempimento automatico nella barra degli indirizzi del browser. Sappiamo già cosa significa: traffico direct.
È buona pratica bloccare il tracciamento del traffico interno per evitare di conteggiare una crescita di traffico direct che potrebbe includere traffico irrilevante.
Bloccare il traffico interno è semplice, ma richiede che le visite dello staff e degli sviluppatori avvengano da connessioni con indirizzo IP statico, che dovrai conoscere in anticipo. Per procedere:
- Su GA4, vai in Amministrazione, poi in Flussi di dati sotto Proprietà, e seleziona Configura impostazioni tag.
- Scegli di mostrare tutte le impostazioni e seleziona Definisci traffico interno.
- Aggiungi l’indirizzo IP di tutti gli uffici, in modo che non siano più inclusi nei report.
Creare in GA4 il proprio "Gruppo di canali personalizzato"
Come dicevamo in precedenza, Google Analytics non è infallibile e può catalogare il traffico come Direct perché non riesce a comprenderne l’origine, pur in presenza di informazioni corrette.
Per questo è possibile creare un proprio Gruppo di canali personalizzato all’interno della proprietà di GA4 in modo da indicare in modo preciso a Google come deve categorizzare le varie sorgenti / mezzi di provenienza del traffico. Ho spiegato passo passo come impostarlo in questo articolo dedicato ai gruppi di canali personalizzati in GA4.
Una volta creato il proprio gruppo di canali sarà possibile renderlo predefinito in modo che in tutti i report di GA4 vengano mostrate le sorgenti in base a come le abbiamo classificate in modo custom in base al nostro business.
Maggiori informazioni sulla creazione di un Gruppo di canali personalizzato sono reperibili nella documentazione ufficiale di Google.
Se il tuo sito usa anche il tracciamento server-side, la logica è la stessa: un errore nel container lato server produce esattamente lo stesso effetto sul traffico direct, con la differenza che è ancora più difficile da individuare senza gli strumenti giusti.
"Organic" e "(not set)" nelle campagne google/cpc
Oltre a tutti i problemi che abbiamo analizzato fin qui, nel corso del 2024 e proseguendo nel 2025 e 2026, ci si trova spesso davanti a situazioni incongruenti.
Situazioni in cui, per esempio, abbiamo una corretta assegnazione della source “google”, del medium “cpc” ma la campagna è impostata su “Organic” o “(not set)”, e in alcuni casi “Direct”.
Si tratta di situazioni che si verificano per diversi motivi, che risiedono principalmente nelle normative per la protezione della privacy, oltre che in situazioni tecniche legate alla gestione delle sessioni da parte del browser e di GA4.
Google Consent Mode e l'impatto sull'attribuzione in GA4
Ipotizziamo il seguente scenario:
un utente arriva sulla pagina dopo aver cliccato su un annuncio di Google e sceglie di non accettare la personalizzazione degli annunci o rifiuta i cookie pubblicitari o di marketing.
Nel caso in cui nella URL di destinazione sia presente il parametro GCLID, GA4 può etichettare correttamente la fonte di traffico come google / cpc ma non può accedere ai dati dettagliati della campagna di Google Ads a causa della mancata accettazione del tracciamento tramite i cookie di marketing.
In assenza di informazioni specifiche sulla campagna, il valore della dimensione Campagna della sessione viene impostato sul valore predefinito: Organico.
Sebbene possa sembrare controintuitivo che GA4 non dia come valore predefinito (not set) a questa dimensione, c’è un motivo logico dietro a questa scelta.
La priorità di GA4 è fornire quante più informazioni possibili, anche se limitate.
Impostando la dimensione Campagna della sessione come Organico, GA4 ci segnala che il traffico proviene effettivamente da una ricerca su Google (anche se il click di provenienza era generato da un annuncio), ma i dettagli della campagna specifica non sono disponibili.
Inoltre GA4 potrebbe impostare come predefinito il nome della campagna di sessione su Organico per il traffico di Google Ads anche quando l’utente ha disattivato gli annunci personalizzati in My Ad Center nella gestione del proprio profilo Google.
Problema:
Il parametro GCLID consente a GA4 di riconoscere google/cpc come source/medium, ma le restrizioni imposte dal mancato consenso da parte dell’utente, limitano l’attribuzione a livello di campagna, dando luogo a questo comportamento di ripiego.
Soluzione:
L’utilizzo sia dell’auto-tagging che del tagging manuale (quindi l’uso dei parametri UTM insieme al gclid) può contribuire a mitigare questo problema.
Aggiungendo manualmente utm_campaign=nome_campagna, utm_source=google e
utm_medium=cpc, aiutiamo GA4 ad identificare i dati di una campagna specifica anche se i dati gclid sono limitati a causa delle impostazioni di consenso.
A questo proposito vale la pena ricordare quanto già riportato in precedenza relativamente al fatto che Apple ha introdotto nel suo sistema operativo iOS un sistema di protezione dei propri utenti che, nel momento in cui l’utente clicca su un annuncio sponsorizzato, va ad eliminare automaticamente ogni parametro di auto-tagging (quindi gclid per Google Ads, fbclid per Meta Ads, ecc…), rendendo di fatto obbligatorio l’uso dei parametri UTM che restano l’unico metodo certo di attribuzione.
Mancanza o ritardo dell'evento "page_view"
Quando un utente arriva su una pagina dopo aver fatto clic su un annuncio di Google, si verificano diversi eventi che vengono rilevati ed inviati alle piattaforme di analytics. Tra questi c’è l’evento page_view, che registra, come è facile intuire, la visualizzazione della pagina da parte dell’utente.
Se questo evento si verifica in ritardo, oppure non si verifica nel corretto ordine di esecuzione, oppure non si verifica proprio, GA4 è in grado di riconoscere correttamente la fonte di traffico come google / cpc grazie alla presenza del parametro gclid, ma non è in grado di recuperare in tempo il nome della campagna di sessione, con il risultato che il nome della campagna sarà impostato come (not set).
Nota: è molto probabile che per le SPA (Single Page Application) il nome della campagna a livello di sessione sia impostato su (not set) per il traffico google/cpc proprio a causa del fatto che non si verifica l’evento page_view.
Sessione interrotta da parte dell'utente
Quando, in presenza di source/medium impostati come google/cpc, il nome della campagna viene impostato da parte di GA4 come (referral), significa che ci troviamo davanti alla situazione in cui non c’è stata continuità della sessione dell’utente: questo genera una divisione della sessione GA4 in due o più sessioni.
Configurazione GA4 che non prevede il tracking cross-domain
Questo succede, ad esempio, quando un utente naviga tra domini o sottodomini in presenza di una configurazione di GA che non prevede il cross domain tracking.
In questo caso GA4 potrebbe interpretare una parte della sessione di GA4 come un nuovo invio della pagina, senza parametri di tracciamento.
Facciamo un esempio: un utente clicca su un annuncio che porta a www.dominio.it e poi naviga verso shop.dominio.it e lo stream di GA4 non prevede il tracciamento cross-domain.
In questo caso GA4 mantiene google / cpc come origine, ma può assegnare (referral) come nome della campagna alla visita che viene fatta su shop.dominio.it
Traffico che passa da sistemi intermedi
Il traffico proveniente da un annuncio Google Ads che passa attraverso URL di tracciamento intermedi o piattaforme di terze parti può interrompere la continuità della sessione, soprattutto se gclid viene rimosso lungo questo percorso.
Anche in questo caso ci aiutiamo con un esempio per comprendere la situazione nel migliore dei modi:
un utente fa clic su un annuncio di Google ma viene prima indirizzato attraverso un servizio di tracciamento (per esempio tracking.ilmioannuncio.com) prima di raggiungere la pagina di destinazione finale.
In questo caso GA4 potrebbe etichettare tracking.ilmioannuncio.com come campagna di riferimento e impostare il nome della campagna della sessione su (referral).
Utente che ritorna dopo la fine della sessione
Quando su GA4, in presenza di traffico “google / cpc” ed il nome della campagna impostato su “Direct”, possiamo quasi certamente trovarci in una di queste condizioni:
- l’utente è ritornato sulla pagina dopo la scadenza della sessione e la visita avviene senza il parametro gclid (ad es. un URL diretto o un bookmark o semplicemente dopo 30 minuti dalla fine della sessione precedente, magari perché è semplicemente andato a prendere un caffé ed ha fatto una telefonata o una call)
- Impossibilità da parte di GA4 di riportare l’attribuzione della campagna senza gclid per le nuove sessioni
Soluzione:
per evitare questo tipo di problema e tutti quelli che derivano da visite fatte in sessioni che vengono in qualche modo interrotte, è possibile modificare la configurazione di GA4 andando ad allungare la durata della sessione portandola, per esempio, dal valore di default di 30 minuti al termine massimo: 7 ore e 55 minuti.
In questo modo, anche se l’utente dopo aver visitato il sito va a prendere un caffé e poi torna a visitare il nostro sito, rimarrà all’interno della prima (ed unica) sessione, e non si genereranno sessioni non correttamente valorizzate in quelle informazioni che sono fondamentali per una corretta attribuzione.
Attenzione però: prima di applicare questa modifica vale la pena essere consapevoli di cosa cambia davvero. Il vantaggio è specifico: eviti che GA4 apra una nuova sessione priva di attribuzione ogni volta che un utente si allontana per più di 30 minuti e poi torna, quindi riduci la parte di traffico direct generata da sessioni interrotte per inattività.
Lo svantaggio riguarda tutto il resto della property. Sessioni, tasso di coinvolgimento, pagine per sessione e conversioni per sessione cambiano definizione, perché visite che prima contavano come due o più sessioni distinte ora vengono unite in una sola. Il confronto storico, prima e dopo questa modifica, smette di essere affidabile sul numero di sessioni, e chi legge i report senza sapere che l’impostazione è cambiata rischia di interpretare come calo di traffico quello che in realtà è solo un cambio di come vengono contate le visite. In più, questa modifica non risolve in nessun modo il caso in cui l’utente cambia dispositivo tra il click sull’annuncio e il ritorno sul sito, perché la sessione resta comunque legata al client ID di quel dispositivo.
Per questo non è una modifica da applicare come impostazione predefinita per qualsiasi sito. Ha senso soprattutto per contenuti editoriali lunghi, percorsi decisionali B2B, o e-commerce con carrelli ripresi dopo una pausa, dove le interruzioni di sessione sono frequenti e non riflettono davvero due visite distinte. In tutti gli altri casi, un’estensione più contenuta (per esempio 60-90 minuti invece del massimo di 7 ore e 55 minuti) offre un compromesso più equilibrato tra riduzione del direct e affidabilità delle metriche di sessione.
Conclusioni
La corretta definizione del traffico diretto in Google Analytics 4 non è mai un dettaglio da poco: distinguere il direct vero da quello di ripiego cambia le decisioni che prendi su budget, campagne e contenuti. I passaggi che abbiamo visto in questo articolo ti permettono di ridurre al minimo i riferimenti errati al traffico direct e attribuire le visite ai canali corretti.
Se non ti senti pronto ad affrontare autonomamente queste ottimizzazioni, la mia consulenza di digital analytics parte proprio da qui: puoi usare il modulo di contatto per richiedere un’analisi o supporto nella corretta implementazione dei tuoi asset di analytics.
Scopri di più
Scopri cosa dice Google in merito all’errata attribuzione del traffico diretto.
FAQ rapide
Tra le cause principali troviamo:
-
URL di accesso diretto o tramite bookmark o digitazione manuale.
-
Scarsa o assente implementazione dei parametri di UTM nei link (campagne, newsletter, social, ecc.).
-
Re-indirizzamenti o redirect che eliminano i parametri della sorgente.
-
Link che arrivano da applicazioni che non trasmettono correttamente il riferimento (es. alcune app mobile, email con URL modificati).
-
Configurazioni errate del tracciamento server-side o del consent mode che non consentono di attribuire correttamente la sorgente.
Ecco alcune azioni pratiche:
-
Usare sempre parametri UTM (utm_source, utm_medium, utm_campaign) nei link che partono da campagne, newsletter, social, affiliazioni.
-
Verificare i redirect: assicurarsi che i redirect conservino i parametri UTM e non “sopprimano” la sorgente.
-
Configurare correttamente il tracciamento server-side (se lo stai implementando) per garantire che la fonte venga registrata.
-
Verificare se ci sono accessi da mail, da app, da link non tracciati: magari considerare di mappare le sorgenti via referer o implementare link dedicati.
-
Nel caso di traffico mobile/app, assicurarsi che i link esterni abbiano parametri o che la app gestisca il referer correttamente.
Quando interpreti i dati, tieni presente che il traffico diretto contiene sia utenti genuinamente “diretti” sia utenti che sono stati mal attribuiti. Alcuni suggerimenti:
-
Confronta la percentuale di diretto nel tempo: un aumento improvviso può dare indizio di un problema tecnico (es. modifiche al sito, tracciamento).
-
Usa segmenti: ad esempio analizza il “direct” solo per utenti nuovi vs. utenti di ritorno, per vedere se proviene da ritorni diretti o nuovi accessi.
-
Incrocia con altri parametri quali landing page: se molte visite dirette arrivano su pagine di campagna o URL con UTM mancanti, potrebbe essere un segnale di link non taggati.
-
Considera che il “direct” può impattare l’attribuzione: se troppo elevato, potresti sottostimare le sorgenti che dovrebbero avere meritato un credito.