Nel mio lavoro sui tracciamenti del comportamento degli utenti su un sito o su una landing page, uno degli aspetti su cui cerco di mettere la massima attenzione è la finalità di ogni singolo tag. E devo dire che quelli legati a piattaforme pubblicitarie (Google Ads, Meta Ads, ecc…) sono quelli su cui mi concentro maggiormente perché sono quelli che possono contribuire a determinare la resa delle campagne a pagamento. Buona parte di quelle performance dipendono dallo specialista che si è occupato del setup delle campagne, ma poi l’esito della partita passa in mano a chi si occupa della raccolta dei dati post-clic sull’annuncio sponsorizzato.
Ci sono molti aspetti che impattano sul buon esito della raccolta dei dati nel momento in cui l’utente compie la sua conversione (acquisto per un ecommerce, compilazione di un form per un sito di lead generation): consenso utente (il famoso banner dei cookie), corretta gestione dei parametri di auto-tagging (gclid per Google Ads, fbclid per Meta Ads), tempo trascorso tra il clic sull’annuncio e momento della conversione. Non sempre tutto fila liscio, e le piattaforme potrebbero non essere in grado di collegare quell’evento che ha portato alla conversione con l’effettivo clic sulla sponsorizzata.
Le Enhanced Conversions di Google Ads e l’Advanced Matching di Meta permettono di utilizzare alcuni dati inseriti dall’utente durante la conversione, come l’indirizzo email o il numero di telefono, per ridurre in parte questo problema. Attraverso il confronto di questi dati con quelli presenti negli account delle piattaforme, Google e Meta dispongono di ulteriori informazioni con cui provare ad attribuire l’evento di conversione alla specifica campagna da cui l’utente era partito. Quella stessa conversione recuperata, una volta attribuita, entra anche nei dati che alimentano Smart Bidding su Google Ads e l’algoritmo di delivery su Meta: le piattaforme la usano per imparare quali caratteristiche ha chi converte davvero e regolare su questa base a chi mostrare gli annunci nelle aste successive. È su questo secondo effetto, più che sul recupero dell’attribuzione, che si decide se una campagna comincia davvero a performare meglio, ed è il filo che seguo per il resto dell’articolo.
Perché il matching sul solo clic non basta
Quando l’utente clicca su un annuncio Google Ads e atterra sul sito, l’URL contiene quasi sempre un parametro chiamato gclid, che identifica quel clic e viene salvato dal Google tag o dal Conversion Linker nei cookie proprietari e nel local storage del browser. Su Meta il meccanismo è simile: il parametro fbclid genera il cookie _fbc, mentre _fbp identifica il browser da cui arriva la navigazione.
Il collegamento tra la conversione e il clic che l’ha originata regge solo finché questi valori restano nel browser, e capita spesso che non sia così: un redirect ripulisce l’URL prima che il parametro venga letto, una configurazione cross-domain incompleta non trasferisce l’identificativo tra due domini dello stesso funnel, i cookie scadono prima della conversione, oppure l’utente clicca dal telefono e converte giorni dopo dal computer di lavoro. In questi casi gclid o fbclid non sono più disponibili al momento della conversione, e la piattaforma non ha nulla su cui basare l’attribuzione.
Email e numero di telefono forniti dall’utente diventano allora un’informazione aggiuntiva che si affianca a gclid e fbclid: Google Ads e Meta possono confrontarli con i dati già presenti nei rispettivi account e provare comunque a chiudere il collegamento con la campagna. È il meccanismo su cui si basano le Enhanced Conversions di Google Ads e l’Advanced Matching di Meta.Come Google Ads e Meta usano i dati inseriti dall'utente
Le Enhanced Conversions di Google Ads
L'Advanced Matching di Meta
L’Advanced Matching aggiunge gli stessi tipi di dati agli eventi del Meta Pixel, con la stessa distinzione tra raccolta automatica (gestita da Events Manager) e manuale, tramite i parametri em, ph, fn, ln passati al codice di inizializzazione del Pixel. La normalizzazione richiesta da Meta però non coincide con quella di Google: per ph il numero deve contenere solo cifre e prefisso internazionale, senza il segno +, quindi un numero già preparato per Google non è riutilizzabile così com’è per Meta. È un dettaglio facile da perdere quando si costruisce un’unica funzione di normalizzazione pensata per il telefono in generale invece che per il formato richiesto da ciascuna piattaforma, e il risultato è un parametro ph vuoto o malformato senza che nessun tag segnali errore.
L’Advanced Matching riguarda gli eventi inviati dal browser tramite il Pixel; quelli trasmessi dal server tramite la Conversions API usano invece i customer information parameters, con una qualità dell’identificativo che è un tema a sé, trattato nell’articolo dedicato all’Event Match Quality di Meta Ads.
Cosa impara l'algoritmo da ogni conversione che gli mandi
Rincorrere un match rate del 100% nell’attribuzione ha poco senso in un funnel che oggi si sviluppa su più dispositivi, più sessioni e settimane di distanza tra il primo contatto e la conversione: quel percorso frammentato, che Google stessa descrive come messy middle, rende l’attribuzione completa di ogni singola conversione un obiettivo che nessuna configurazione, per quanto accurata, riuscirà mai a raggiungere del tutto. Il mio approccio è diverso: do priorità alla qualità del segnale che arriva alla piattaforma, non alla percentuale di conversioni che riesco a far quadrare nel report.
La differenza conta perché quella conversione, una volta attribuita, entra nei dati su cui Smart Bidding e l’algoritmo di delivery di Meta si allenano per decidere a chi mostrare gli annunci nelle aste successive. Se rappresenta davvero un lead o un acquisto, l’algoritmo impara a riconoscere caratteristiche utili. Se rappresenta un tentativo mal registrato, la piattaforma impara comunque, ma impara la lezione sbagliata, e la applica su budget reale.
Un errore ricorrente: un tag di conversione attivato sul clic del pulsante di invio di un form, invece che sulla conferma reale dell’acquisizione del contatto. Il clic avviene prima della validazione dei campi e prima della risposta del server, quindi scatta anche quando l’invio fallisce. Arricchire quell’evento con email e telefono tramite Enhanced Conversions o Advanced Matching non lo corregge: lo rende solo più riconoscibile alla piattaforma, che ora lo attribuisce con precisione e lo usa come esempio di utente che converte, per trovarne altri simili. Il risultato è un algoritmo che ottimizza, con budget reale, per intercettare persone che cliccano un pulsante e basta, non persone che diventano clienti.
Per questo il lavoro su queste funzionalità dovrebbe partire sempre dalla qualità dell’evento scelto come conversione, prima ancora di preoccuparsi di quanti di quegli eventi la piattaforma riesce ad attribuire. Un match rate alto su un evento debole è una vittoria che costa più di quanto rende.
Tracciare la conferma reale, non il clic sul pulsante
Il problema descritto sopra si risolve a monte, cambiando il momento in cui l’evento di conversione viene generato. Per un sito di lead generation, l’evento dovrebbe partire solo quando il sistema conferma di aver acquisito il form, non quando l’utente clicca sul pulsante di invio: il clic avviene prima della validazione dei campi e prima della risposta del server, quindi può scattare anche quando l’invio fallisce o l’utente deve correggere un errore.
La visualizzazione di una thank you page può essere una conferma affidabile, ma solo se quella pagina viene caricata esclusivamente dopo l’acquisizione effettiva del contatto. Molti form gestiti via AJAX restano invece sulla stessa pagina e mostrano un semplice messaggio di conferma: in questi casi, dopo l’eventuale cambio di stato della pagina, i valori inseriti nei campi potrebbero non essere più disponibili per le Enhanced Conversions e per l’Advanced Matching, proprio quando servirebbero.
Quando il form espone una callback di successo, quel momento può essere usato per inviare un evento nel data layer:
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'lead_submit_success',
user_data: {
email: formValues.email,
phone: formValues.phone
}
});Il codice è indicativo, perché il modo in cui si recupera formValues.email e formValues.phone dipende dal plugin, dal form builder o dall’applicazione in uso. Il punto fermo è che l’evento lead_submit_success va eseguito dopo la conferma del server e prima che i campi vengano svuotati.
In Google Tag Manager si creano due variabili di livello dati, user_data.email e user_data.phone, e il trigger basato sull’evento personalizzato lead_submit_success attiva il tag di conversione Google Ads: le due variabili vengono collegate ai rispettivi campi della variabile Dati forniti dall’utente usata per le Enhanced Conversions. L’email può essere passata in chiaro, perché il Google tag applica lui stesso normalizzazione e hashing; il telefono va invece già formattato in E.164, con prefisso e segno +, quindi se il form restituisce un numero come 333 123 4567 serve una variabile che tolga gli spazi e aggiunga +39 prima di renderlo disponibile al tag.
Per Meta, lo stesso evento personalizzato può attivare il Pixel Lead: l’Advanced Matching manuale usa em per l’email e ph per il telefono, e questi valori devono già essere disponibili nella configurazione del Pixel prima dell’invio dell’evento. Il numero destinato a Meta richiede però una normalizzazione diversa da quella per Google, solo cifre e prefisso internazionale, senza il +: partendo dallo stesso numero del form, la variabile per Google restituirà +393331234567, quella per Meta 393331234567. Sono due stringhe diverse generate dallo stesso dato di partenza, e trattarle come intercambiabili è un altro punto in cui il matching si rompe silenziosamente.
Se si usa l’Advanced Matching automatico, il Pixel prova a recuperare le informazioni direttamente dai campi della pagina: nei form che svuotano i valori subito dopo l’invio, va verificato se Meta riesce a leggerli prima del reset, perché l’attivazione dell’opzione in Events Manager non basta da sola a garantire che i dati vengano effettivamente raccolti.
Inserire email e telefono nel data layer li rende accessibili a qualunque script eseguito nella pagina, quindi vanno usati esclusivamente dai tag previsti e nel rispetto delle scelte di consenso raccolte dalla CMP. Un’alternativa è normalizzare e sottoporre ad hashing i valori prima di inserirli nel data layer: in questo caso servono due variabili distinte per Google e Meta, proprio perché le regole di normalizzazione dei due sistemi non coincidono.
Con questa configurazione, i dati dell’utente vengono associati alla stessa conferma che genera la conversione: Google Ads e Meta ricevono l’evento Lead nel momento in cui il contatto è stato realmente acquisito, e possono usare gli identificativi disponibili per provare a collegarlo alle rispettive campagne.
Come verificare quali dati arrivano davvero alle piattaforme
La verifica parte sempre da una conversione di test eseguita sul sito, con dati creati appositamente e un invio completato fino alla conferma restituita dal sistema. La modalità Anteprima di Google Tag Manager mostra quale evento è stato generato, quali variabili erano disponibili in quel momento e quali tag si sono attivati: nell’esempio della sezione precedente, l’evento da cercare è lead_submit_success e le variabili user_data.email e user_data.phone devono contenere i valori inseriti nel form. Se risultano vuote, il problema sta nella raccolta dei dati o nel momento scelto per il dataLayer.push(), e i tag possono essere configurati correttamente e ricevere comunque variabili prive di contenuto.
Verificare le Enhanced Conversions di Google Ads
Dopo il controllo in Google Tag Manager, la richiesta inviata a Google si esamina dalla scheda Network degli strumenti per sviluppatori del browser, cercando le chiamate verso domini come googleadservices.com o google.com.
Nel payload va cercato il parametro em: una stringa completa indica che il tag ha recuperato e sottoposto ad hashing almeno uno degli identificativi configurati, mentre un valore come tv.1~em senza la stringa successiva segnala che il parametro è stato inviato vuoto. Capita spesso quando il tag di conversione parte dopo che il form ha già svuotato i campi, oppure quando la variabile in Google Tag Manager punta a un elemento che nel frattempo è stato rimosso dalla pagina. La documentazione sulla diagnostica delle Enhanced Conversions riporta i formati da cercare e le principali segnalazioni di errore.
Google Ads mette a disposizione anche un rapporto diagnostico per ciascuna azione di conversione, utile per individuare problemi ricorrenti su un volume ampio di conversioni (formati errati, percentuale bassa di eventi con dati utente), ma quei dati richiedono tempo di elaborazione e non sostituiscono il test diretto nel browser.
Verificare l'Advanced Matching di Meta
Per Meta lo strumento di riferimento è Meta Ads Data Advisor, che ha sostituito Meta Pixel Helper: permette di controllare il caricamento del Pixel, gli eventi inviati e alcuni problemi di configurazione dell’Advanced Matching. Events Manager consente poi di eseguire eventi di test e verificare cosa arriva dalla fonte dati: durante la prova del form, l’evento Lead deve comparire dopo la conferma dell’invio, e i dettagli dell’Advanced Matching mostrano quali parametri utente lo accompagnano.
Con la raccolta automatica, il controllo serve a capire quali campi il Pixel riesce effettivamente a riconoscere: un campo email può essere perfettamente visibile all’utente e strutturato in modo da non essere individuato dal sistema automatico, e i form caricati in iframe o quelli che svuotano subito i valori richiedono un’attenzione ancora maggiore. Nelle configurazioni manuali va controllato l’inizializzazione del Pixel: em deve ricevere l’email, ph il telefono normalizzato nel formato richiesto da Meta. Un parametro presente ma con valore vuoto non contribuisce al matching.
Il consenso va controllato insieme ai tag, non da solo
Le Enhanced Conversions usano il parametro ad_user_data della Consent Mode per sapere se l’utente ha autorizzato l’invio di dati personali a Google per finalità pubblicitarie: quando è impostato su denied, email e telefono non devono essere usati per le Enhanced Conversions. ad_storage controlla invece la memorizzazione e la lettura dei cookie pubblicitari. La documentazione di Google sui tipi di consenso descrive la funzione di ciascun parametro.
La modalità Anteprima di Google Tag Manager mostra anche lo stato del consenso nel momento in cui parte l’evento, e la CMP deve aver aggiornato ad_user_data prima che il tag con email o telefono si attivi. Il Meta Pixel deve rispettare le stesse logiche: l’hashing cambia la forma in cui il dato viene trasmesso, ma non autorizza da solo la raccolta o l’utilizzo di quel dato.
Al termine del test devono risultare verificabili quattro aspetti:
- L’evento viene generato dopo l’acquisizione effettiva della conversione.
- Email e telefono sono disponibili nel momento in cui i tag vengono eseguiti.
- Le richieste contengono i parametri previsti e valori utilizzabili, non stringhe vuote.
- Lo stato del consenso consente l’invio dei dati alle piattaforme pubblicitarie.
Se dopo questi controlli il problema persiste, spesso la causa non sta nei singoli parametri di Enhanced Conversions o Advanced Matching, ma nell’impianto di tracciamento a monte: eventi mal configurati, tag duplicati, contenitori GTM cresciuti senza logica nel tempo. È il tipo di intervento che affronto in una consulenza tracking e tagging.
Conclusioni: cosa cambia davvero per le campagne
Le Enhanced Conversions e l’Advanced Matching funzionano solo se a monte l’evento che arricchiscono rappresenta davvero una conversione, non un tentativo. È il punto centrale di questo articolo, e vale la pena ribadirlo in chiusura: il valore di questi due meccanismi non sta in quante conversioni riescono a far quadrare nel report, sta nella qualità del segnale che finisce dentro Smart Bidding e nell’algoritmo di delivery di Meta.
Chi si concentra solo sull’attribuzione tende a misurare il successo con il match rate, quanta parte delle conversioni la piattaforma riesce ad attribuire alla campagna giusta. È una metrica che dice poco sulla salute reale del tracciamento: un match rate alto su eventi deboli non è un risultato, è un problema che si sta misurando con precisione crescente. La domanda che vale davvero è un’altra: l’evento che arriva alla piattaforma, arricchito o meno, rappresenta un cliente o un clic?
Prima di attivare o ottimizzare Enhanced Conversions e Advanced Matching, controllare quando viene generata la conversione, quali dati sono disponibili in quel momento e quali tag possono usarli in base al consenso raccolto resta il lavoro che conta di più. Il resto, l’hashing corretto, i formati di normalizzazione, la raccolta automatica o manuale, è tecnica che va fatta bene, ma non sostituisce mai la scelta dell’evento giusto da cui partire.
FAQ: domande frequenti su Enhanced Conversions e Advanced Matching
Una conversione standard comunica a Google Ads che sul sito è avvenuta un’azione, come un acquisto o l’invio di un form. Con le Enhanced Conversions, all’evento vengono associati anche dati forniti dall’utente, come email o numero di telefono: Google li utilizza per cercare una corrispondenza con i propri account e attribuire la conversione quando gli identificativi normalmente usati per il tracciamento non sono sufficienti.
Google Ads accetta email, telefono e dati relativi a nome e indirizzo. Meta accetta parametri come email, telefono, nome, cognome ed eventuali identificativi esterni. Conviene inviare soltanto le informazioni che vengono realmente raccolte durante la conversione e che possono essere trattate per questa finalità.
Il loro effetto principale riguarda la qualità del segnale su cui si allenano Smart Bidding e l’algoritmo di delivery di Meta, più che il numero di conversioni attribuite. Se l’evento scelto come conversione rappresenta davvero un lead o un acquisto, arricchirlo con email e telefono aiuta l’algoritmo a riconoscere chi converte per davvero e a cercare altri utenti simili. Se invece l’evento è debole, per esempio un clic sul pulsante di invio invece della conferma reale, l’arricchimento lo rende solo più riconoscibile alla piattaforma, che continua a ottimizzare sul segnale sbagliato.
Sì. L’invio di dati personali a Google Ads e Meta deve rispettare le scelte espresse dall’utente e la normativa applicabile: per Google, il parametro ad_user_data del Consent Mode comunica il consenso relativo all’uso dei dati personali per finalità pubblicitarie, e anche il Meta Pixel e l’Advanced Matching vanno configurati in base alle autorizzazioni raccolte dalla CMP. L’hashing interviene sulla forma tecnica del dato durante la trasmissione, non sostituisce il consenso e non rende automaticamente anonime le informazioni trattate.
L’Advanced Matching associa gli identificativi dell’utente agli eventi inviati dal Meta Pixel via browser. La Conversions API trasmette invece gli eventi dal server e inserisce queste informazioni nei customer information parameters. Le due configurazioni possono lavorare insieme: quando lo stesso evento arriva sia dal Pixel sia dalla Conversions API, Meta deve ricevere un event_id coerente tra le due copie per eseguire correttamente la deduplica.
Il tuo algoritmo di offerta sta imparando dai segnali giusti?
Posso analizzare il tracciamento delle conversioni del tuo sito, controllare la qualità degli eventi che arrivano a Google Ads e Meta e capire se le tue campagne stanno ottimizzando sui segnali giusti o solo sul volume di conversioni attribuite.