Il tracciamento delle conversioni da form è uno degli aspetti più critici di qualsiasi strategia di web analytics. Un form non tracciato correttamente significa dati persi, attribuzioni sbagliate e campagne ottimizzate su informazioni incomplete.

Ma c’è un aspetto ancora più importante: tracciare la conversione non basta. Se vuoi sfruttare le Enhanced Conversions di Google Ads (conversioni avanzate), devi catturare i dati dell’utente nel momento esatto in cui compila il form — in particolare email, oppure altri dati utili al matching come telefono o indirizzo. Tracciare solo la thank-you page significa perdere queste informazioni per sempre.

Questo articolo è diviso in due parti:

• Parte 1 — Teoria e Debug: come analizzare qualsiasi form, identificare il tipo di invio e usare la console per capire esattamente cosa succede
• Parte 2 — Implementazione: script completi, configurazione GTM, trigger, variabili e tag pronti per la produzione

Se vuoi ottenere questo risultato senza sporcarti le mani con debug, dataLayer, trigger e mapping delle variabili, contattami: posso occuparmi io dell’implementazione tecnica e della verifica del tracciamento.

Parte 1: Teoria e Debug

I tre scenari di invio form

Non tutti i form si comportano allo stesso modo. Esistono tre scenari principali:

1. Form con redirect (POST tradizionale)

Il form invia i dati con un POST standard e reindirizza a una thank-you page. È lo scenario classico, ma presenta un problema critico: quando l’utente arriva sulla thank-you page, il form non esiste più. Non puoi quindi recuperare email, nome, telefono o altri dati utili per le Enhanced Conversions.

Come riconoscerlo: la pagina si ricarica completamente dopo il submit e l’URL cambia.

Soluzione: devi intercettare il submit prima del redirect, catturare i dati e solo dopo lasciare proseguire l’invio.

2. Form AJAX con evento submit

Il form invia i dati via JavaScript senza ricaricare la pagina. L’evento submit viene comunque triggerato, quindi puoi intercettarlo con un event listener.

Come riconoscerlo: la pagina non si ricarica, ma l’evento submit è presente e verificabile in console.

Soluzione: event listener su submit, con preventDefault() se necessario.

3. Form AJAX senza evento submit (terze parti)

Il form bypassa completamente il submit nativo. Cliccando il pulsante, viene eseguita una funzione JavaScript che invia i dati tramite XMLHttpRequest o Fetch API. Nessun evento submit viene triggerato.

Come riconoscerlo: il pulsante non è un <button type="submit">, oppure il form ha onsubmit="return false", oppure semplicemente l’evento submit non scatta mai.

Soluzione: intercettazione di XMLHttpRequest o Fetch API.

I form embedded di terze parti come Brevo, HubSpot, Mailchimp, Typeform rientrano quasi sempre in questo terzo scenario.

Come analizzare un form: la fase di debug

Prima di scrivere qualsiasi codice, devi capire esattamente come funziona il form. Apri gli strumenti di sviluppo del browser (F12) e segui questa procedura.

Step 1: Ispeziona la struttura del form

Nella tab Elements, trova l’elemento <form> e annota:

• ID: es. id="sib-form"
• Action: URL di destinazione (vuoto = stesso dominio, URL esterno = terze parti)
• Method: GET o POST
• Attributi speciali: onsubmit, data-*

Step 2: Mappa i campi del form

Per ogni campo, documenta l’attributo name: è quello che userai per recuperare i valori.

// Esegui in console per elencare tutti i campi del form
var form = document.getElementById('ID_DEL_FORM');
var fields = form.querySelectorAll('input, select, textarea');
fields.forEach(function(f) {
  console.log('name:', f.name, '| type:', f.type, '| value:', f.value);
});

Step 3: Verifica se l’evento submit viene triggerato

Questo è il test cruciale. Esegui in console:

// Test: l'evento submit viene triggerato?
var form = document.getElementById('ID_DEL_FORM');
form.addEventListener('submit', function(e) {
  console.log('✅ Evento SUBMIT triggerato!');
  console.log('Form data:', new FormData(form));
});
// Ora compila il form e clicca submit. Se vedi il messaggio, puoi usare un listener su submit.
// Se NON vedi nulla, il form bypassa il submit nativo.

Step 4: Monitora le chiamate di rete

Apri la tab Network, filtra per Fetch/XHR, poi compila e invia il form. Osserva:

• URL della richiesta: dominio interno o esterno? (es. sibforms.com)
• Metodo: POST, GET
• Payload: clicca sulla richiesta → tab “Payload” per vedere i dati inviati
• Response: status 200? JSON di risposta?

Step 5: Identifica il tipo di chiamata (XHR o Fetch)

Se il form non triggera submit ma vedi una chiamata in Network, devi capire se usa XMLHttpRequest o Fetch API. Esegui in console prima di inviare il form:

// Intercetta XMLHttpRequest
(function() {
  var origOpen = XMLHttpRequest.prototype.open;
  XMLHttpRequest.prototype.open = function(method, url) {
    console.log('🔵 XHR:', method, url);
    return origOpen.apply(this, arguments);
  };
})();
// Intercetta Fetch API
(function() {
  var origFetch = window.fetch;
  window.fetch = function(url, options) {
    console.log('🟢 FETCH:', url, options);
    return origFetch.apply(this, arguments);
  };
})();

Ora invia il form. In console vedrai:

• 🔵 XHR: POST https://... → il form usa XMLHttpRequest
• 🟢 FETCH: https://... → il form usa Fetch API

Questa informazione è fondamentale per scegliere la tecnica di intercettazione corretta.

Riepilogo: quale strategia usare

Parte 2: Implementazione

Ora che sai come analizzare un form, vediamo l’implementazione completa. Useremo come caso pratico un form Brevo (ex Sendinblue), che rappresenta lo scenario più complesso: nessun evento submit, invio tramite XHR a dominio esterno.

Caso pratico: Form Brevo embedded

Dall’analisi del form (seguendo gli step della Parte 1) emergono queste caratteristiche:

• ID: sib-form
• Evento submit: NON triggerato
• Tipo chiamata: XHR a sibforms.com con parametro isAjax=1
• Campi: NOME, COGNOME, AZIENDA, EMAIL, SMS, MESSAGGIO, CONFERMA
• Widget custom: selettore prefisso telefonico (classe .sib-sms-select, valore in data-value)

2.1 Script di tracciamento (Tag Custom HTML)

Crea un nuovo tag in GTM di tipo Custom HTML e incolla questo codice:

<script>
(function() {
  // ==================================================
  // CONFIGURAZIONE - Modifica questi valori
  // ==================================================
  var FORM_ID = 'sib-form';                    // ID del form
  var XHR_FILTER = 'sibforms.com';             // Dominio da intercettare
  var XHR_PARAM = 'isAjax=1';                  // Parametro che identifica la chiamata
  var EVENT_NAME = 'brevo_form_submit';        // Nome evento per GTM
  var FORM_NAME = 'contact_request_form';      // Nome descrittivo del form
  
  // ==================================================
  // VERIFICA ESISTENZA FORM
  // ==================================================
  var form = document.getElementById(FORM_ID);
  if (!form) return;
  
  // ==================================================
  // PREVIENI DOPPIA ESECUZIONE
  // ==================================================
  if (window['__formTracker_' + FORM_ID]) return;
  window['__formTracker_' + FORM_ID] = true;
  // ==================================================
  // HELPER FUNCTIONS
  // ==================================================
  
  // Recupera il valore di un campo
  function getFieldValue(name) {
    var el = form.querySelector('[name="' + name + '"]');
    if (!el) return '';
    if (el.type === 'checkbox') return el.checked;
    return el.value || '';
  }
  // Recupera il prefisso internazionale dal widget Brevo
  function getSmsCountryCode() {
    var widget = form.querySelector('.sib-sms-select');
    if (!widget) return '+39';
    return widget.getAttribute('data-value') || '+39';
  }
  // Formatta il numero in formato E.164
  function formatPhoneE164(code, number) {
    if (!number) return '';
    var clean = number.replace(/\s+/g, '').replace(/^0+/, '');
    return code + clean;
  }
  // ==================================================
  // INTERCETTAZIONE XMLHttpRequest
  // ==================================================
  var origOpen = XMLHttpRequest.prototype.open;
  var origSend = XMLHttpRequest.prototype.send;
  XMLHttpRequest.prototype.open = function(method, url) {
    this._url = url;
    this._method = method;
    return origOpen.apply(this, arguments);
  };
  XMLHttpRequest.prototype.send = function(body) {
    var xhr = this;
    
    // Filtra solo le chiamate al servizio del form
    if (xhr._url && 
        xhr._url.indexOf(XHR_FILTER) !== -1 && 
        xhr._url.indexOf(XHR_PARAM) !== -1) {
      
      // Cattura i dati PRIMA dell'invio
      var smsCountryCode = getSmsCountryCode();
      var formData = {
        user_first_name: getFieldValue('NOME'),
        user_last_name: getFieldValue('COGNOME'),
        user_company: getFieldValue('AZIENDA'),
        user_email: getFieldValue('EMAIL'),
        user_phone_country_code: smsCountryCode,
        user_phone: formatPhoneE164(smsCountryCode, getFieldValue('SMS')),
        user_message: getFieldValue('MESSAGGIO'),
        user_consent: getFieldValue('CONFERMA')
      };
      // Ascolta la risposta
      xhr.addEventListener('load', function() {
        // Traccia solo se la richiesta ha avuto successo (status 2xx)
        if (xhr.status >= 200 && xhr.status < 300) {
          window.dataLayer = window.dataLayer || [];
          window.dataLayer.push({
            event: EVENT_NAME,
            form_id: FORM_ID,
            form_name: FORM_NAME,
            user_first_name: formData.user_first_name,
            user_last_name: formData.user_last_name,
            user_company: formData.user_company,
            user_email: formData.user_email,
            user_phone_country_code: formData.user_phone_country_code,
            user_phone: formData.user_phone,
            user_message: formData.user_message,
            user_consent: formData.user_consent
          });
          
          console.log('[GTM] Form tracciato:', EVENT_NAME, formData);
        }
      });
    }
    
    return origSend.apply(this, arguments);
  };
})();
</script>

Trigger per il tag

Imposta il trigger su DOM Ready (o Page View se il form è presente subito). Se il form è solo su alcune pagine, aggiungi una condizione sull’URL.

2.2 Trigger Custom Event

Crea un nuovo Trigger in GTM:

• Tipo: Custom Event
• Event name: brevo_form_submit
• This trigger fires on: All Custom Events

Questo trigger scatterà ogni volta che lo script fa il push al dataLayer con l’evento brevo_form_submit.

2.3 Variabili Data Layer

Per utilizzare i dati del form nei tag, crea queste variabili di tipo Data Layer Variable:

Nota: il fatto che questi dati siano disponibili nel dataLayer non significa che debbano essere sempre inviati tutti a Google Ads. Nelle Enhanced Conversions il mapping va fatto rispettando i gruppi di dati accettati dalla piattaforma.

2.4 Tag Google Ads Conversion

Crea un tag Google Ads Conversion Tracking:

• Conversion ID: il tuo ID conversione
• Conversion Label: la tua etichetta
• Trigger: il trigger brevo_form_submit creato sopra

Per le Enhanced Conversions, nella sezione “Include user-provided data”, non trattare i campi come combinabili liberamente. Google Ads accetta almeno uno di questi set di dati: email (preferita), oppure indirizzo con first name, last name, postal code e country; il telefono può essere inviato come match key, ma per massimizzare qualità e copertura è consigliato insieme all’email. :contentReference[oaicite:0]{index=0}

• Email: {{DLV - user_email}} (opzione preferita e sufficiente da sola)
• Phone: {{DLV - user_phone}} (può essere inviato come chiave di matching; in pratica conviene quasi sempre accompagnarlo all’email)
• First Name e Last Name: usali solo se stai passando anche i dati di indirizzo richiesti da Google Ads, cioè almeno postal code e country; facoltativamente puoi aggiungere via, città e regione. :contentReference[oaicite:1]{index=1}

In pratica: se il tuo form raccoglie solo email e telefono, configura l’Enhanced Conversion con questi due campi. Se invece vuoi usare anche nome e cognome, devi strutturare il mapping come address data, non come semplici campi anagrafici isolati. :contentReference[oaicite:2]{index=2}

2.5 Mapping corretto per Enhanced Conversions

Lo schema delle variabili utilizzato in questo articolo è compatibile con Google Ads solo se rispetti i gruppi di dati richiesti dalla piattaforma. Per le Enhanced Conversions for web, Google indica come set validi almeno uno tra: email, oppure full name + address con campi minimi obbligatori, oppure phone number come match key. :contentReference[oaicite:3]{index=3}

Quindi, per un form lead generation standard, la configurazione più semplice e solida è quasi sempre: email + telefono in formato E.164. Se il form raccoglie anche dati di indirizzo, allora puoi estendere il mapping includendo nome, cognome, CAP e paese come blocco address. Google richiede anche la normalizzazione dei dati e il formato E.164 per il numero di telefono. :contentReference[oaicite:4]{index=4}

Debug e Verifica

Test in GTM Preview Mode

1. Attiva la Preview Mode di GTM
2. Vai sulla pagina con il form
3. Compila tutti i campi e invia
4. Nel debugger GTM, verifica che l’evento brevo_form_submit compaia nella timeline
5. Clicca sull’evento e controlla che tutte le variabili siano popolate correttamente

Verifica in Console

Dopo aver inviato il form, esegui in console:

// Visualizza gli ultimi eventi nel dataLayer
dataLayer.filter(function(e) { return e.event; }).slice(-3);

Dovresti vedere l’evento brevo_form_submit con tutti i campi popolati.

Verifica Enhanced Conversions

1. Google Tag Assistant: verifica che il tag di conversione riceva i parametri user_data
2. Google Ads → Conversioni → Diagnostica: controlla che i dati vengano ricevuti e matchati

Tieni presente che Google segnala che la diagnostica e il matching delle Enhanced Conversions possono richiedere tempo per popolarsi dopo l’implementazione. :contentReference[oaicite:5]{index=5}

Troubleshooting

L’evento non compare nel dataLayer

• Verifica che il form abbia l’ID corretto (sib-form o quello che hai configurato)
• Verifica che XHR_FILTER e XHR_PARAM corrispondano alla chiamata reale (controlla in Network)
• Verifica che lo script venga caricato prima del submit (usa DOM Ready come trigger)
• Controlla nella tab Network che la chiamata restituisca status 2xx

Alcuni campi sono vuoti

• I nomi dei campi (NOME, EMAIL, ecc.) sono case-sensitive: verifica che corrispondano esattamente agli attributi name nel form
• Per il telefono Brevo, verifica che il widget prefisso abbia la classe .sib-sms-select
• Esegui lo script di mappatura campi (Step 2 della Parte 1) per verificare i nomi corretti

Lo script viene eseguito due volte

• Il flag window['__formTracker_' + FORM_ID] dovrebbe prevenirlo
• Verifica che il tag GTM non abbia trigger multipli che lo fanno scattare più volte

Il form usa Fetch invece di XHR

Se il test della Parte 1 mostra 🟢 FETCH invece di 🔵 XHR, devi usare questo override alternativo:

<script>
(function() {
  var FORM_ID = 'il-tuo-form-id';
  var FETCH_FILTER = 'dominio-da-intercettare.com';
  var EVENT_NAME = 'form_submit';
  
  var form = document.getElementById(FORM_ID);
  if (!form) return;
  if (window['__formTracker_' + FORM_ID]) return;
  window['__formTracker_' + FORM_ID] = true;
  var origFetch = window.fetch;
  
  window.fetch = function(url, options) {
    var urlString = (typeof url === 'string') ? url : url.url;
    
    if (urlString && urlString.indexOf(FETCH_FILTER) !== -1) {
      // Cattura i dati prima dell'invio
      var formData = {
        user_email: form.querySelector('[name="email"]')?.value || ''
        // ... altri campi
      };
      
      // Esegui la fetch originale e traccia se ha successo
      return origFetch.apply(this, arguments).then(function(response) {
        if (response.ok) {
          window.dataLayer = window.dataLayer || [];
          window.dataLayer.push({
            event: EVENT_NAME,
            form_id: FORM_ID,
            user_email: formData.user_email
            // ... altri campi
          });
        }
        return response;
      });
    }
    
    return origFetch.apply(this, arguments);
  };
})();
</script>

Conclusioni

Il tracciamento dei form di terze parti richiede un approccio metodico:

1. Analizza sempre il form con gli strumenti di debug prima di scrivere codice
2. Identifica il tipo di invio (redirect, submit event, XHR, Fetch)
3. Cattura i dati nel momento giusto — prima dell’invio, non dopo
4. Verifica lo status code prima di tracciare (solo 2xx = successo)
5. Previeni la doppia esecuzione con un flag univoco
6. Standardizza le variabili per riutilizzare i tag su più form
7. Formatta il telefono in E.164 per le Enhanced Conversions
8. Mappa correttamente i dati utente in Google Ads: email da sola va bene, mentre nome e cognome hanno senso solo se accompagnati dall’indirizzo richiesto dalla piattaforma. :contentReference[oaicite:6]{index=6}

Seguendo questa metodologia potrai tracciare qualsiasi form — anche quelli più ostici — e raccogliere i dati necessari per migliorare la qualità della misurazione e delle ottimizzazioni in Google Ads. Le Enhanced Conversions for web usano infatti dati first-party forniti dall’utente, normalizzati e associati alla conversione per migliorare il matching e la misurazione. :contentReference[oaicite:7]{index=7}

Se tutto questo ti sembra troppo complicato — ed è normale che lo sia, perché tra form embedded, dataLayer, trigger GTM, Enhanced Conversions e debug tecnico gli errori sono dietro l’angolo — ci pensiamo noi. Se vuoi implementare un tracciamento affidabile senza perdere lead e senza sporcarti le mani con la parte tecnica, contattaci dal form.

Come verificare se la Consent Mode v2 è implementata correttamente

Implementare la Consent Mode v2 non basta: bisogna verificare che funzioni correttamente. Nella pratica, molti siti hanno una configurazione parziale o errata — il banner cookie c’è, i tag Google ci sono, ma i segnali di consenso non vengono trasmessi nel modo giusto. Il risultato è una perdita silenziosa di dati e campagne che ottimizzano su conversioni incomplete.

In questa guida vediamo come eseguire una verifica completa della Consent Mode v2 usando gli strumenti ufficiali Google, senza dover mettere mano al codice.

Cosa stiamo verificando — i 4 segnali obbligatori

Una Consent Mode v2 correttamente implementata deve trasmettere a Google almeno questi quattro segnali di consenso:

• ad_storage — consenso per la memorizzazione di cookie pubblicitari
• analytics_storage — consenso per i cookie di analytics
• ad_user_data — consenso all’invio di dati utente a Google per scopi pubblicitari
• ad_personalization — consenso per la personalizzazione degli annunci

Ogni segnale può avere valore granted (consenso dato) o denied (consenso negato). Il punto critico non è solo che i segnali esistano, ma che si aggiornino dinamicamente nel momento in cui l’utente interagisce con il banner cookie — questa è la differenza tra una Basic Mode e una Advanced Mode funzionante.

Strumento 1 — Google Tag Assistant (Chrome Extension)

Google Tag Assistant è il punto di partenza per qualsiasi verifica della Consent Mode v2. È un’estensione Chrome gratuita che mostra in tempo reale lo stato dei tag Google e dei segnali di consenso.

Come usarlo per verificare la Consent Mode v2

1. Installa Google Tag Assistant dal Chrome Web Store
2. Apri il sito da verificare in una finestra normale (non in incognito)
3. Clicca sull’icona Tag Assistant nella barra del browser e avvia il debug
4. Nella scheda “Consent” troverai lo stato dei segnali di consenso

Cosa controllare nella scheda Consent

Tag Assistant mostra due momenti fondamentali:

• Default state — i valori dei segnali al caricamento della pagina, prima che l’utente interagisca con il banner. In Advanced Mode tutti e quattro i segnali devono essere presenti (tipicamente a denied). Se non appaiono affatto, la Consent Mode non è attiva.
• Update state — i valori aggiornati dopo che l’utente accetta o rifiuta i cookie. Dopo un’accettazione completa, i segnali ad_storage, analytics_storage, ad_user_data e ad_personalization devono passare a granted.

Se vedi solo il Default state ma nessun Update state dopo aver cliccato “Accetta” sul banner, la CMP non sta comunicando correttamente con GTM.

Segnali di errore comuni in Tag Assistant

• Nessuna scheda “Consent” visibile — la Consent Mode non è configurata nel container GTM
• Default state presente ma Update state assente — la CMP non è integrata correttamente con GTM
• Segnali presenti ma solo analytics_storage e ad_storage — mancano ad_user_data e ad_personalization, obbligatori da marzo 2024
• Update state con valori invariati dopo il consenso — il trigger di aggiornamento non si attiva

Strumento 2 — GTM Preview Mode

La modalità Preview di Google Tag Manager permette di vedere nel dettaglio quali tag si attivano, quando e con quali valori — inclusi i segnali di consenso.

Come usarla per verificare la Consent Mode v2

1. Apri GTM e clicca su “Anteprima” (Preview) in alto a destra
2. Inserisci l’URL del sito e avvia la sessione
3. Nel pannello Tag Assistant che si apre, seleziona l’evento “Consent Initialization” nel menu di sinistra
4. Nella scheda “Consent” verifica i valori di default impostati
5. Interagisci con il banner cookie e controlla se appare un evento di tipo consent update nella timeline

Cosa cercare nella timeline degli eventi

Una implementazione Advanced Mode corretta genera questa sequenza di eventi:

1. Consent Initialization — i segnali di default vengono impostati (tutti a denied per gli utenti SEE)
2. Initialization — GTM si inizializza
3. Page View — caricamento pagina
4. L’utente interagisce con il banner
5. Evento custom della CMP (es. CookieConsentDeclaration o consent_update) — aggiorna i segnali

Se manca il punto 5, la CMP non sta inviando l’aggiornamento a GTM.

Strumento 3 — GA4 DebugView

GA4 DebugView è utile per verificare che gli eventi GA4 vengano effettivamente ricevuti dopo il consenso — e che non vengano inviati prima del consenso in Basic Mode.

Come attivare il DebugView

1. Installa l’estensione Chrome “Google Analytics Debugger”
2. Apri il sito con l’estensione attiva
3. Vai in GA4 → Configura → DebugView
4. Interagisci con il sito e il banner cookie

Cosa verificare

• In Basic Mode: nessun evento deve apparire in DebugView prima che l’utente abbia dato il consenso
• In Advanced Mode: il page_view può apparire prima del consenso (in forma anonima), ma gli eventi di conversione devono attivarsi correttamente dopo il consenso
• Dopo il consenso completo: page_view, session_start e gli eventi ecommerce devono essere visibili regolarmente

Strumento 4 — Consent Mode Debugger (Google Tag Assistant Companion)

Per una verifica ancora più granulare, Google Tag Assistant Companion nel browser mostra i payload completi delle richieste inviate ai server Google, inclusi i parametri di consenso allegati a ogni hit.

Nella Network tab del browser (F12 → Network), filtra per google-analytics.com o gtag e controlla i parametri gcs e gcd allegati alle richieste: questi codici indicano lo stato dei segnali di consenso al momento dell’invio dell’hit.

I 5 errori più comuni che trovo nelle verifiche

1. Consent Mode v1 invece di v2

Alcune implementazioni datate usano ancora la Consent Mode v1, che gestisce solo ad_storage e analytics_storage. La v2 richiede obbligatoriamente anche ad_user_data e ad_personalization. Verificabile direttamente in Tag Assistant — se mancano questi due segnali, l’implementazione è da aggiornare.

2. CMP non certificata IAB TCF 2.2

Non tutte le CMP supportano nativamente la Consent Mode v2. Alcune trasmettono il consenso in formati non compatibili con GTM. Usare una CMP certificata Google (Cookiebot, Iubenda, Axeptio, Usercentrics) è la soluzione più affidabile per garantire la compatibilità.

3. Ordine di caricamento errato

Il comando gtag('consent', 'default', {...}) deve essere eseguito prima di qualsiasi tag Google. Se viene caricato dopo GA4 o Google Ads, quei tag si attivano prima del consenso, vanificando l’intera implementazione. In GTM questo si gestisce tramite il trigger “Consent Initialization” con priorità massima.

4. Segnali di default non impostati per gli utenti SEE

Per gli utenti nello Spazio Economico Europeo, Google richiede che i segnali di default siano impostati esplicitamente a denied. Un’implementazione che non specifica i valori di default lascia i segnali in stato “non definito”, che Google interpreta diversamente da denied — con conseguenze sull’eligibilità al behavioral modeling.

5. Banner cookie che non aggiorna i segnali su navigazione interna

Un errore sottile ma frequente: l’aggiornamento del consenso funziona correttamente sulla prima pagina, ma non viene ripropagato sulle pagine successive della navigazione. Da verificare cliccando su un link interno dopo aver dato il consenso e controllando che l’Update state sia ancora presente in Tag Assistant.

Checklist finale — Consent Mode v2 verificata

• ☐ I 4 segnali obbligatori sono presenti nel Default state (anche se a denied)
• ☐ Il Default state viene impostato prima di qualsiasi tag Google
• ☐ Dopo il consenso, tutti i segnali passano a granted nell’Update state
• ☐ L’Update state è presente anche sulle pagine interne (non solo sulla prima pagina)
• ☐ Gli eventi GA4 appaiono in DebugView dopo il consenso
• ☐ In Basic Mode, nessun evento viene inviato prima del consenso
• ☐ I segnali ad_user_data e ad_personalization sono presenti (v2, non v1)

Hai dubbi sulla tua implementazione?

Se dopo questa verifica trovi anomalie o non sai come interpretare quello che vedi in Tag Assistant, posso analizzare la tua configurazione e individuare esattamente dove si trova il problema.

Ho verificato e corretto implementazioni di Consent Mode v2 su oltre 200 ecommerce — su Prestashop, WooCommerce e altre piattaforme. Nella maggior parte dei casi i problemi rientrano nelle 5 categorie descritte sopra e si risolvono in tempi rapidi.

→ Richiedi un’analisi gratuita della tua Consent Mode v2

Oppure scopri come lavoriamo nella pagina dedicata al servizio di implementazione Consent Mode v2.

Implementazione Consent Mode v2 con Google Tag Manager per Ecommerce

Dal marzo 2024, Google ha reso obbligatoria la Consent Mode v2 per tutti i siti che utilizzano Google Ads o Google Analytics. Se non hai ancora implementato correttamente la Consent Mode v2, stai perdendo dati preziosi, le tue campagne di remarketing sono compromesse e rischi di non essere conforme al GDPR.

Implementiamo la Consent Mode v2 su misura per il tuo ecommerce, tramite Google Tag Manager (GTM), con o senza CMP (Consent Management Platform), in modalità Basic o Advanced. Ogni implementazione è personalizzata in base alla piattaforma, al traffico e agli obiettivi del cliente.

Hai bisogno di un’analisi della tua situazione attuale? Contattaci per un preventivo gratuito.

Cos’è la Consent Mode v2 e perché è obbligatoria

La Consent Mode v2 è una funzionalità di Google che permette ai tag di Google (Analytics, Ads, Floodlight) di adattare il proprio comportamento in base al consenso espresso dall’utente tramite il banner cookie. Non si tratta semplicemente di bloccare o sbloccare i tag: la Consent Mode v2 introduce un meccanismo di modellazione dei dati (behavioral modeling) che consente a Google di stimare le conversioni anche degli utenti che non hanno dato il consenso, preservando la privacy e mantenendo l’efficacia delle campagne.

Esistono due modalità di implementazione:

• Basic Mode: i tag Google vengono caricati solo dopo il consenso esplicito dell’utente. Semplice da implementare, ma comporta una perdita di dati significativa.
• Advanced Mode: i tag vengono caricati subito in modalità “anonima”, senza raccogliere dati personali, e si aggiornano automaticamente quando l’utente acconsente. Questa modalità abilita il modeling delle conversioni e il remarketing anche in assenza di consenso esplicito, nel rispetto del GDPR.

Google richiede l’implementazione di almeno quattro segnali di consenso obbligatori:

• ad_storage
• analytics_storage
• ad_user_data
• ad_personalization

Senza questi segnali correttamente configurati, Google non può applicare il behavioral modeling e le tue campagne Google Ads perdono efficacia in modo drastico.

Cosa rischi senza la Consent Mode v2

• 📉 Perdita di dati in Google Analytics 4: le sessioni e gli eventi degli utenti che non accettano i cookie non vengono tracciati né modellati.
• 🚫 Remarketing bloccato: senza il segnale ad_storage e ad_personalization, Google non può costruire audience per il remarketing.
• ⚠️ Conversioni sottostimate in Google Ads: il sistema di Smart Bidding perde segnali fondamentali e le campagne ottimizzano su dati incompleti.
• 🔴 Non conformità GDPR: rischio di sanzioni da parte del Garante della Privacy.
• 📊 Enhanced Conversions non operative: senza Consent Mode v2 correttamente implementata, anche le Enhanced Conversions di Google Ads non funzionano al massimo.

Come implementiamo la Consent Mode v2

Ogni progetto parte da un’analisi della situazione attuale: piattaforma, CMP esistente (o assente), configurazione GTM, volumi di traffico e obiettivi di business. Solo dopo definiamo la soluzione più adatta.

Implementazione tramite Google Tag Manager (GTM)

GTM è lo strumento centrale di ogni nostra implementazione. Utilizziamo i tag nativi di Consent Mode v2 (o template certificati) per configurare i segnali di default e gestirne l’aggiornamento dinamico in base alle scelte dell’utente. L’implementazione avviene lato client-side e, dove necessario, integrata con il server-side tagging per massimizzare la qualità dei dati.

Implementazione con CMP (Consent Management Platform)

Selezioniamo la CMP più adatta al tuo caso tra le soluzioni certificate da Google (IAB TCF 2.2): Cookiebot, Iubenda, Axeptio, Usercentrics e altre. L’integrazione tra CMP e GTM viene verificata e testata tramite Google Tag Assistant e il Consent Mode Debugger per garantire che i segnali siano trasmessi correttamente.

Implementazione senza CMP (soluzioni custom)

In alcuni casi, specialmente per siti con traffico basso o budget limitato, è possibile implementare la Consent Mode v2 tramite soluzioni custom senza CMP a pagamento. Valutiamo questa opzione caso per caso.

Consent Mode v2 per Ecommerce: Prestashop e WooCommerce

Consent Mode v2 su Prestashop

Prestashop non gestisce nativamente la Consent Mode v2. Abbiamo testato e validato diverse soluzioni per integrare correttamente GTM e la CMP su questa piattaforma, sia tramite moduli dedicati che tramite implementazioni custom. Conosciamo le specificità tecniche di Prestashop (layer di checkout, eventi personalizzati, datalayer ecommerce) e garantiamo un’implementazione precisa anche negli ambienti più complessi.

Consent Mode v2 su WooCommerce e WordPress

Per gli ecommerce WooCommerce, implementiamo la Consent Mode v2 tramite GTM con DataLayer personalizzato per il tracciamento degli eventi ecommerce (add_to_cart, purchase, begin_checkout, ecc.), garantendo la piena compatibilità con le principali CMP disponibili per WordPress.

Consent Mode v2 e Server Side Tagging

Per gli ecommerce con volumi di traffico elevati o che necessitano della massima qualità del dato, affianchiamo alla Consent Mode v2 il Server Side Tagging tramite Google Tag Manager Server-Side. Questo approccio consente di:

• Ridurre il peso degli script lato browser, migliorando i Core Web Vitals
• Aumentare la precisione del tracciamento, riducendo il blocco da parte degli ad-blocker
• Gestire in modo più granulare la trasmissione dei dati verso Google Ads, GA4 e Meta
• Implementare le Enhanced Conversions di Google Ads in modo completo e conforme

Perché scegliere Giordano Tabacco per la Consent Mode v2

• ✅ Certificazioni Google: siamo certificati Google Ads e Google Analytics — vedi le certificazioni
• ✅ Specialisti GTM e Server Side: il tracciamento dati è il nostro core business, non un servizio accessorio
• ✅ Esperienza su ecommerce reali: Prestashop, WooCommerce, contesti ad alto traffico
• ✅ Implementazione testata e verificata: ogni progetto viene validato con strumenti di debug prima della consegna
• ✅ Supporto continuo: non spariscono dopo l’implementazione — siamo disponibili per qualsiasi aggiornamento o problema

Domande Frequenti sulla Consent Mode v2

La Consent Mode v2 è davvero obbligatoria?

Sì. Dal marzo 2024, Google richiede la Consent Mode v2 per tutti i siti nello Spazio Economico Europeo che utilizzano Google Ads o Google Analytics. Senza di essa, non è possibile abilitare il behavioral modeling né il remarketing tramite le piattaforme Google.

Qual è la differenza tra Basic Mode e Advanced Mode?

In Basic Mode i tag Google vengono completamente bloccati fino al consenso dell’utente. In Advanced Mode i tag si caricano subito in forma anonima e si aggiornano al momento del consenso, permettendo la modellazione dei dati anche per gli utenti che rifiutano i cookie. L’Advanced Mode è quasi sempre la scelta raccomandata per gli ecommerce.

Ho già un banner cookie. È sufficiente?

Non necessariamente. Un banner cookie standard non implementa automaticamente la Consent Mode v2. È necessario che la CMP sia integrata correttamente con GTM e che i quattro segnali obbligatori vengano trasmessi a Google al momento giusto. Verifichiamo gratuitamente la tua situazione attuale.

Quanto tempo richiede l’implementazione?

Dipende dalla complessità del sito e dalla configurazione esistente. Nella maggior parte dei casi, un’implementazione completa e testata richiede da 1 a 5 giorni lavorativi.

La Consent Mode v2 risolve i problemi di tracciamento dopo iOS 14?

La Consent Mode v2 agisce sui tag Google e non è una soluzione diretta al blocco dei cookie da parte di Safari/iOS. Tuttavia, combinata con il Server Side Tagging e le Enhanced Conversions, consente di recuperare una parte significativa dei dati persi, migliorando la qualità complessiva del tracciamento.

Offrite assistenza post-implementazione?

Sì. Siamo disponibili per verifiche periodiche, aggiornamenti in caso di modifiche alle policy di Google o alla piattaforma ecommerce, e supporto in caso di anomalie nel tracciamento.

Richiedi un’analisi gratuita della tua Consent Mode

Hai dubbi sulla tua implementazione attuale o parti da zero? Contattaci: analizziamo gratuitamente la tua situazione e ti proponiamo la soluzione più adatta al tuo ecommerce, alla tua piattaforma e al tuo budget.

→ Contattaci ora per un preventivo su misura