Google Analytics è un fantastico strumento di analisi dei siti web per gli addetti al marketing che vogliono capire come gli utenti interagiscono con i loro contenuti.
Le analisi a livello di acquisizione del traffico ci forniscono raggruppamenti in base alla provenienza, fornendo in questo modo una serie di “categorie” che ci consentono di capire da dove provengono i visitatori e con cosa interagiscono.
In questo ambito una crescita anomala del direct traffic (o “traffico diretto“) è una delle problematiche che anche io mi ritrovo spesso ad affrontare.
Ma che cos’è il traffico “direct”? E soprattutto, come si può aggirare il problema della crescita anomala per capire da dove provengono realmente gli utenti e ottenere “attribuzioni” il più corrette possibile?
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
In Google Analytics 4, è possibile accedere al rapporto “Acquisizione traffico” selezionando “Rapporti” e poi scegliendo “Acquisizione traffico” all’interno della sezione “Ciclo di vita”:
In questa area di Google Analytics 4 è possibile vedere alcuni report sul traffico e sui canali. Scorrendo verso il basso in questa pagina, è possibile vedere i dati completi sul traffico diretto rispetto agli altri canali.
È quindi possibile confrontare il traffico diretto con le altre sorgenti, e visualizzarle in base a:
- Pagina di destinazione
- Fonte del primo utente
- Media della sessione e altro ancora
Per ottenere maggiori informazioni sul traffico diretto è anche possibile utilizzare modelli personalizzati in “Esplora”, generando i propri report di analisi.
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)
- 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
Lanci gli annunci Meta. I clic ci sono, il coinvolgimento sembra ottimo, le conversioni arrivano a fiumi. Poi apri GA4… e vedi un problema:
1. Metà dei tuoi acquisti non ha alcuna fonte
2. facebook / cpc? Da nessuna parte. Ma (direct) / (none) è alle stelle
Cosa sta succedendo?
È il famigerato browser in-app di Meta: Facebook e Instagram non aprono i link in Chrome o Safari, ma intrappolano gli utenti nel browser interno della app. Ed è qui che il treno dell’attribuzione deraglia.
Ecco come funziona:
1. L’utente clicca sull’annuncio → il sito si apre all’interno del browser in-app di Meta.
2. Il referrer viene rimosso (perché si tratta di un’app), i parametri fbclid o UTM vanno persi nei reindirizzamenti o nei caricamenti dinamici.
3. L’utente torna più tardi tramite Safari o Chrome, digitando manualmente l’URL o da una scheda salvata. GA4 pensa che si tratti di una sessione (diretta) completamente nuova.
Il risultato? Meta genera vendite. GA4 non vede… nulla.
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 succede 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 GA 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 rilevare la visita a quella pagina e quindi a definirla come “referrer” rispetto alla seconda pagina.
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.
Secondo uno studio recente, quasi l’80% delle condivisioni di link avviene attraverso questi canali, rendendo l’attribuzione ancora più difficile.
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.
Problemi di tracciamento o raccolta dei dati
Nonostante le questioni che abbiamo elencato, possiamo molto probabilmente affermare che buona parte non viene registrato come traffico diretto perché un utente ha visitato direttamente il nostro sito web digitando 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 sulla impossibilità di comprendere correttamente la sorgente della visita.
L’assenza di questi dati può verificarsi per due motivi principali: perdita di dati sul referrer e mancanza di dati sul referrer.
Se la maggior parte del traffico del vostro sito web è diretto, non c’è da esserne fieri. Non si tratta automaticamente del riconoscimento di un brand molto forte.
È molto probabile che indichi una implementazione di GA4 o Tag Manager con problemi di tagging.
Vediamo in dettaglio questi aspetti legati all’attribuzione da parte delle piattaforme di analytics.
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 si trova ad implementare i tracciamenti per le varie piattaforme, che si tratti di GA4, Google Ads, Facebook Ads, ecc…
A volte una implementazione non corretta dei tracciamenti può compromettere anche la corretta raccolta dei dati, che può impattare a sua volta sulla mancata attribuzione del traffico.
Ma a volte può essere anche una errata configurazione della proprietà di Google Analytics 4 a generare questo tipo di problematica.
Spesso scoprire un problema di errata configurazione nei tracciamenti o in GA4 non è così semplice, e solo un occhio esperto e competente riesce ad individuare il punto critico e porvi rimedio.
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 può essere proprio GA4 che “non ce la fa”. Altre volte possono verificarsi bug o cambi di gestione dei dati nella piattaforma.
In queste situazioni è necessario procedere diversamente, per esempio andando ad indicare direttamente a Google qual è la corretta attribuzione.
In questi casi è necessario “bloccare” l’attribuzione automatica e andare a sovrascrivere le informazioni “native” che vengono inviate a GA4 con altre specifiche che decidiamo noi, in modo che GA4 non debba fare altro che “fidarsi di noi” ed utilizzare le informazioni che abbiamo inviato per attribuire correttamente la fonte.
La prima implementazione da fare, come vedremo tra poco, è l’uso corretto dei “parametri UTM“. In questo modo possiamo dire noi a Google Analytics come deve essere catalogata la sorgente della visita.
In aggiunta all’uso corretto dei parametri UTM, è possibile impostare un proprio “Gruppo di canali personalizzato” in modo da istruire GA4 per una corretta attribuzione secondo le 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.
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 predefinito”
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.
PS: non sai cosa sono le “vanity URL”? Prima di proseguire, scoprilo in questo post dello Studio Legale Paolini.
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 puoi dare una occhiata al mio articolo a questo riguardo.
Bloccare il traffico interno
È probabile che il vostro team e quello degli sviluppatori visiti il sito web in più occasioni nel corso della giornata.
E quasi sicuramente questo viene fatto utilizzando un segnalibro (o bookmark), oppure affidandosi al riempimento automatico nella barra degli indirizzi del browser. A questo punto sappiamo bene cosa questo significhi: 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 internet con indirizzo IP statico, ed è necessario conoscere questi indirizzi IP. Per procedere con il blocco del traffico interno è possibile procedere in questo modo:
su GA4 andare in “Amministrazione” e da lì selezionare “Flussi di dati” sotto “Proprietà”. Quindi selezionate “Configura impostazioni tag”.
Scegliere di mostrare tutte le impostazioni e poi selezionare “Definisci traffico interno”.
Qui sarà possibile aggiungere 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.
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.
"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, 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, che potremmo definire, 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, è consigliabile modificare la configurazione di GA4 andando ad allungare la durata della sessione portandola dal valore di default di 30 minuti al termite 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.
Conclusioni
Sebbene la corretta definizione del traffico diretto in Google Analytics 4 possa essere una seccatura, speriamo che questi passaggi possano essere di aiuto a ridurre al minimo i riferimenti errati al traffico “direct” per poter attribuire le visite ai canali corretti.
Se non vi sentite pronti per affrontare autonomamente queste ottimizzazioni, potete utilizzare il modulo di contatto per richiedere una nostra analisi o supporto nella corretta implementazione dei vostri asset di analytics.
Scopri di più
Scopri cosa dice Google in merito all’errata attribuzione del traffico diretto.
FAQ rapide
Il traffico diretto corrisponde alle visite che GA4 non riesce ad attribuire a una fonte/mezzo specifico, e quindi le classifica come “Direct / (none)”. Questo può essere un problema perché in realtà può nascondere fonti di traffico reali (es. link da email, bookmark, URL senza parametri) rendendo l’analisi della performance e dell’attribuzione poco precisa.
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.
Una percentuale moderata di traffico diretto è normale: ad esempio utenti che digitano direttamente l’URL, usano un bookmark o tornano sul sito. Tuttavia, se la quota di “Direct / (none)” supera il 20-30 % (o un valore molto superiore in contesti specifici), è opportuno fare una verifica approfondita. In molti casi, una percentuale molto elevata segnala problemi di tracciamento, link non taggati o perdite di attribuzione.
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.