Mi capita spesso di prendere in gestione sistemi di tracciamento realizzati da altri professionisti o agenzie.
E quasi sempre mi trovo davanti a situazioni che mi fanno storcere il naso perché le impostazioni evidenziano una scarsa conoscenza dello strumento e delle regole base per l’impostazione dei tracciamenti e delle normative a cui il tracking deve sottostare.
Nel passato l’attività di configurazione dei tracciamenti non richiedeva particolari abilità o conoscenze.
L’introduzione della nuova versione di Google Analytics (GA4) e le normative per la protezione della privacy degli utenti hanno cambiato drasticamente lo scenario.
L’utilizzo del tagging server-side, poi, richiede spesso una comprensione tecnica che va al di la delle competenze di molti analisti.
Gli errori principali nella configurazione dei tracciamenti
Ci sono alcuni errori che ritrovo spesso, e sono quasi sempre legati ad una mancata comprensione di quello che richiede la GDPR e come le norme devono essere applicate e tradotte a livello tecnico in fase di implementazione dei tracciamenti.
Vediamo ora i problemi che riscontro più spesso.
Gestione del consenso dell'utente (GDPR e Consent Mode V2)
Questo è l’ambito in cui riscontro le mancanze più gravi in quanto impattano su un aspetto normativo che può portare il proprietario del sito ad incorrere in sanzioni.
- Impostazione default consenso utente: la normativa prevede che quando l’utente arriva sul sito tutti i tracciamenti siano bloccati di default, fino a quando l’utente non esprime o nega il proprio consenso. Molto spesso questo elemento è assente nel sistema di tracking (e non viene implementato diversamente, risultando totalmente assente)
- Piattaforma di raccolta del consenso (banner dei cookie): in Tag Manager esiste un trigger apposito per attivare il banner dei cookie, ma molto spesso al suo posto viene usato “All Pages”; l’uso del trigger sbagliato può causare parecchi problemi nella raccolta dei dati
- Attivazione dei tag di piattaforme Google non gestito con la Consent Mode V2: questo fa si che da un lato la raccolta dei dati non sia conforme alla GDPR, ma riduce notevolmente anche il volume di dati raccolti da queste piattaforme. Inoltre, con l’introduzione della CM V2, Google Ads non consente più il corretto funzionamento delle campagne per chi non implementa correttamente questa funzionalità
- Attivazione dei tag per piattaforme non Google non aderenti al consenso dell’utente: capita spesso di vedere questi tag senza la configurazione del blocco nel caso in cui l’utente non abbia dato il proprio consenso
Ottimizzare in modo globale la raccolta del consenso
In particolare c’è un aspetto legato alla GDPR e alla CMP che, secondo me, spesso non viene preso in considerazione: secondo la norma, tutti i cookie profilanti e traccianti devono essere preventivamente bloccati fino a quando l’utente non ha accettato il tracciamento tramite il banner.
Ebbene, se la CMP viene attivata tramite un tag di Google Tag Manager, sarà in grado di bloccare solo i cookie generati tramite i tag attivati da GTM stesso. Ma cosa succede per quei cookie che vengono generati da elementi presenti sul sito? Per esempio quelli di Youtube, oppure quelli dei vari form di raccolta dati che se generati da un CRM portano con se anche informazioni di profilazione tramite cookie?
Se la CMP funziona solo grazie a Tag Manager non sarà in grado di bloccare preventivamente questi cookie generati da elementi presenti sul sito, rendendo il sito non a norma, perché questi cookie non saranno bloccati preventivamente da nessuno.
- Script che imposta tutte le categorie di cookie con default su “denied”
- Script di attivazione di Google Tag Manager
- Script di attivazione della CMP (Cookiebot, Iubenda, ecc…)
Ovviamente per poter funzionare correttamente la CMP deve inviare nel dataLayer tutti i cambi di stato delle accettazioni: CookieBot lo fa automaticamente, mentre per Iubenda si deve modificare lo script di installazione aggiungendo la gestione di questi eventi.
(puoi vedere un esempio in questo documento di Cookiebot, e in questo trovi informazioni per il default multiplo in base alla nazione dell’utente).
L’attivazione della CMP direttamente in pagina con lo script presente nel codice HTML (punto 3 della lista sopra) consente di risolvere il problema, perché si occuperà di bloccare tutti i cookie generati direttamente dagli elementi presenti nella pagina stessa.
Tag Manager (eseguito prima della CMP e quindi non bloccato da essa) si occuperà poi di bloccare preventivamente quelli generati dai vari tag e script presenti nel suo contenitore.
Utilizzo errato dei trigger e configurazione dei tag
Anche in questo ambito riscontro spesso errori che sembrano banali o ininfluenti, e che invece hanno un impatto notevole sulla raccolta dei dati.
- Google Tag: è quel tag che serve ad attivare la configurazione di GA4 ed ora anche Google Ads.
Quando Google ha introdotto questo nuovo tipo di tag in GTM, ha previsto anche un trigger di sistema specifico per gestire questo tag. Ma anche in questo caso quello che riscontro è che viene usato troppo spesso il trigger “All Pages” al posto di quello dedicato. L’uso di “All Pages” fa si che l’attivazione di questo tag specifico possa avvenire in tempi errati, per esempio dopo l’attivazione di altri tag, inficiando in questo modo la raccolta di quei dati perché non sarà stata attivata preventivamente la configurazione.
Un altro problema generato da un uso scorretto di questo tag è l’errata interpretazione che questo tag serva per inviare a Google Analytics 4 l’informazione sulla visualizzazione della pagina, l’evento che GA4 riconosce come “page_view”. Mentre invece il “Google Tag” è un tag di configurazione della comunicazione tra GTM e GA4, non un tag deputato ad inviare eventi e parametri a GA4.
Mi capita quasi sempre di trovare all’interno del “Google Tag” l’impostazione del parametro “send_page_view” = true
Questo fa si che appena questo tag viene eseguito, venga inviato a GA4 l’evento di “page_view” che va a sommarsi a tutte le visualizzazioni raccolte da quella pagina.
Personalmente lo considero un errore, in quanto in quel momento è possibile che non siano ancora valorizzate tutte le informazioni (presenti nelle variabili) che possiamo inviare a GA4 insieme all’evento per arricchire le informazioni di tracciamento. E soprattutto in quella fase quasi certamente il consenso dell’utente non è ancora stato impostato in base alle sue scelte dall’evento “Consent Update”, e se il consenso è rimasto sul default, quindi negato, sarà stato inutile raccogliere quel dato.
Per questo preferisco sempre creare un tag evento GA4 “page_view” separato che attivo in occasione dell’ultimo evento che viene attivato in Tag Manager.
La stessa cosa la faccio per i tag di remarketing delle piattaforme di advertising.
È vero che all’interno del “Google Tag” è possibile inserire dei parametri con delle informazioni, e tra questi l’invio della page_view, ma è necessario comprendere a fondo il funzionamento di GA4 per comprendere anche come gestire correttamente i tag relativi: per inviare gli eventi a GA4 è necessario usare i tag appositi, quelli che si chiamano “Google Analytics: GA4 Event” (anche “page_view” è un evento, quindi perché usare un tipo di tag diverso?).
Raccolta dei lead ed invio dei form
Su tutti i siti, che siano ecommerce oppure siti di lead generation, troviamo almeno un form di contatto.
Il tracking di questo evento è fondamentale per tutte le piattaforme (in particolar modo per i siti di lead generation, ma non solo):
- per le piattaforme ADV si tratta di uno degli eventi principali, sulla base del quale vengono ottimizzate le campagne grazie al machine learning che si basa su dati che devono essere il più possibile precisi
- per GA4 si tratta dell’evento “form_submit” o anche dell’evento “generate_lead”. E quando GA4 è collegato a Google Ads questo può diventare un obiettivo secondario che può aiutare anch’esso nell’ottimizzazione delle campagne
Si tratta quindi di un evento che è bene trattare con i guanti, in particolare per ottimizzare le performance (e quindi i budget) delle piattaforme di advertising (Google Ads, Meta Ads, LinkedIn Ads, TikTok Ads, ecc..).
Uno degli errori che rilevo spesso relativamente a questo aspetto è l’utilizzo della visualizzazione della “thank-you page” o del messaggio di conferma come attivatore per questo evento.
Lo ritengo un errore per diversi motivi:
- l’utente potrebbe ricaricare la thank-you page ed in questo caso avremo l’attivazione multipla del tag e quindi un invio doppio, triplo, ecc… di questo evento
- qualcuno potrebbe arrivare alla thank-you page per altre vie (per esempio perché è indicizzata su Google e presente nei risultati di ricerca). Anche in questo caso avremmo un invio di una informazione non corretta
- si potrebbe limitare questo problema impostando l’attivatore in modo che la visualizzazione della thank-you page debba essere preceduta dalla visualizzazione della pagina con il form di contatto per far attivare l’evento in modo che l’evento venga registrato solo se alla thank you page l’utente arriva dopo l’effettiva compilazione del form. Ma non ho mai visto impiegare questo piccolo stratagemma
- l’uso della thank-you page o del messaggio di conferma non consente di raccogliere i dati necessari per le Enhanced Conversion
Personalmente preferisco sempre utilizzare un tag di tipo “Custom HTML” per generare un “listener Javascript” che rimane in ascolto della sottomissione effettiva del form e che al momento dell’invio effettivo invia un evento al dataLayer nel quale raccoglie anche i dati necessari per le Conversioni Avanzate (ovviamente valutando se l’utente ha dato il suo consenso alla raccolta di questi dati). Purtroppo non è possibile crealo per tutti i vari tool di generazione dei form, anche se devo dire che questa limitazione l’ho incontrata per adesso con un solo strumento di form management (ed in questo caso ho dovuto adattarmi anche io all’uso della thank-you page, mitigando però il problema di eventuali sottomissioni multiple come descritto in precedenza).
A proposito dei dati utilizzati dalle Enhanced Conversion un “difetto” che trovo quando si cerca di raccoglierli è l’uso della modalità automatica di individuazione di queste informazioni. In questo modo si sta delegando a GTM di individuare quali sono i dati presenti nel form, e non sempre questo meccanismo funziona, anche per motivi diversi.
Personalmente preferisco perdere il tempo necessario per costruire la mia raccolta di queste informazioni, potendo governare in modo totale e consapevole quello che sta succedendo. Certo, questo richiede più tempo, ma il risultato paga sempre.
La mia precedente vita da sviluppatore mi ha insegnato che è sempre meglio avere il più possibile il controllo di tutto quello che succede piuttosto che affidarsi agli automatismi che non si possono controllare.
Tracciamento eventi ecommerce non completo
I motivi per cui raccogliamo i dati sono essenzialmente due:
- raccolta di dati statistici per poter fare analisi ed individuare spazi di miglioramento del business
- raccolta dati di marketing da dare in pasto agli algoritmi di machine learning delle piattaforme pubblicitarie per ottimizzarne le performance e ridurne i costi
Uno degli errori che riscontro in ambito di tracciamento degli eventi ecommerce è la mancanza di tracciamento per qualcuno degli eventi standard. Questo, a livello statistico, impedisce la corretta costruzione del “funnel di acquisto” rendendo meno evidenti le eventuali perdite di utenti nelle varie fasi del percorso. Cosa che è invece molto importante in fase di analisi per individuare eventuali colli di bottiglia o funzionalità non performanti che impediscono agli utenti di proseguire nel loro percorso verso l’acquisto finale.
Utilizzo di elementi preconfezionati
Ho visto molti professionisti che si occupano di tracking acquistare corsi con “recipe” allegate (si tratta di configurazioni già pronte all’uso).
Purtroppo questa modalità è tipica di chi non ha competenze specifiche in ambito tracking e si affida a prefabbricati per svolgere compiti che diversamente non sarebbe in grado di svolgere.
Si tratta, a mio avviso, di un errore in quanto si dovrebbe sempre avere la competenza totale per gestire quello che si va ad implementare.
L’uso di elementi prefabbricati, soprattutto quando non si ha la competenza per comprendere esattamente non solo cosa fanno, ma anche il perché lo fanno in un certo modo, espone al rischio di ritrovarsi come nelle sabbie mobili nel momento in cui cambia qualcosa dell’elemento che si sta gestendo con quel “pezzo precostituito”. E a quel punto ci si trova con qualcosa che non si governa e non si è in grado di adattare alla nuova situazione. E non è raro pensare che qualcosa possa cambiare, basti pensare alle normative, alla Consent Mode, a nuovi elementi che Google introduce in Tag Manager, ecc…
Disordine nella gestione degli elementi
Ci sono poi una serie di cose che non sono a tutti gli effetti degli errori, ma rendono la gestione degli elementi molto complicata.
- Nomenclatura “a caso”: l’uso di una nomenclatura chiara e precisa per nominare i tag, i trigger, le variabili, è fondamentale per non incorrere in errori; trovo invece molto spesso nomi casuali, molto diversi per elementi simili, ecc…
- Mancato uso delle “Cartelle”: poter raggruppare i vari elementi in cartelle aiuta molto nell’organizzazione di un contenitore GTM
Conclusioni
La configurazione dei tracciamenti per le piattaforme di analytics e di advertising ha assunto negli anni una complessità tale che richiede figure professionali specializzate non solo su aspetti prettamente tecnici, ma anche nella comprensione delle normative che impattano sulle configurazioni e che abbiano una comprensione tecnica del funzionamento delle piattaforme.
I tracciamenti non possono più prescindere da competenze approfondite, sia sull’aspetto tecnico che normativo.
Per questo ti consiglio di non affidare il tracciamento dei dati del tuo sito a chi lo ha sviluppato o a chi segue le tue campagne di advertising: non è detto che abbiano tutte le competenze che sono necessarie oggi.
Se vuoi puoi usare il pulsante qui sotto per richiedere una mia consulenza.
FAQ
Significa un tracciamento tecnicamente corretto e governabile, ma anche coerente con GDPR e consenso, in modo che i dati siano utilizzabili sia per analisi (GA4) sia per ottimizzazione campagne (Ads, Meta, ecc.).
Tra i più frequenti: gestione consenso non corretta, trigger usati in modo improprio, tagging di eventi critici (form, ecommerce) incompleto, uso di elementi preconfezionati senza pieno controllo, disordine nella nomenclatura e organizzazione del container.
Sì, l’impostazione corretta è che i tracciamenti restino bloccati di default finché l’utente non esprime una scelta, e che i tag si comportino in modo coerente con quella scelta.
Perché l’assenza (o l’implementazione scorretta) della Consent Mode V2 impatta sia la conformità sia la raccolta del segnale, e può compromettere l’efficacia delle campagne e della misurazione.
Spesso no. L’attivatore corretto è quello specifico per l’inizializzazione del consenso. Se Google l’ha creato, un motivo ci sarà, no?!?
Perché una CMP attivata via Tag Manager può governare bene i cookie e gli script caricati tramite GTM, ma non necessariamente quelli generati direttamente dalla pagina (es. embed, tool esterni, alcuni form). Da qui il tema dell’implementazione “in pagina” in head, prima possibile.
Sì, perché può partire troppo presto, quando variabili utili non sono ancora valorizzate e quando il consenso potrebbe essere ancora sul default. Per questo io propongo di usare un evento page_view separato, attivato più tardi e in modo controllato.
Perché può generare duplicazioni (refresh), false attivazioni (accesso diretto, indicizzazione) e in generale non è un segnale affidabile. Inoltre, non è adatta quando vuoi raccogliere dati utili per le Enhanced Conversions in modo robusto.
L’impostazione più solida è usare un listener JavaScript che intercetta la sottomissione reale e invia un evento al dataLayer, includendo (quando lecito e coerente col consenso) i dati necessari per le conversioni avanzate.
Se mancano eventi standard, diventa difficile ricostruire correttamente il funnel e individuare colli di bottiglia. Inoltre riduci la qualità del segnale che alimenta le piattaforme advertising per l’ottimizzazione.
Perché se non controlli davvero cosa fanno e perché lo fanno, quando cambia qualcosa (normative, Consent Mode, piattaforme, container) ti ritrovi con un sistema che non governi e non sai adattare.
Con una governance minima: nomenclatura coerente di tag/trigger/variabili, uso delle cartelle, e in generale una struttura che renda il container leggibile e manutenibile nel tempo.