Consent Mode V2 su Shopify. Il banner nativo non basta.
Un e-commerce migra su Shopify, il tracking sembra funzionare, ma GA4 perde i ping e Google Ads non riceve conversioni. Il problema è nel banner cookie nativo e nel modo in cui gestisce il consent mode. Ecco cosa succede davvero sotto il cofano.
Qualche settimana fa mi sono trovato a guardare i dati di un e-commerce che aveva appena migrato su Shopify. Tutto sembrava a posto. Le transazioni arrivavano, Meta riceveva gli eventi, il banner dei cookie compariva al primo accesso. Il cliente era tranquillo.
Poi ho aperto BigQuery e ho notato che mancavano i ping di GA4. Non tutti gli eventi. Proprio i ping. Quelli che il consent mode avanzato dovrebbe mandare anche quando l'utente non ha ancora dato il consenso.
Da lì è partita una di quelle analisi che sembrano semplici ma ti portano a smontare mezzo setup.
Il contesto tecnico
Il progetto era chiaro. L'e-commerce aveva migrato da una piattaforma precedente a Shopify. Il tracking era gestito interamente tramite le app native di Shopify. Niente GTM. Il banner dei cookie era quello nativo della piattaforma. Meta Pixel e Conversions API funzionavano tramite l'integrazione diretta.
Il consent mode v1, quello base, funzionava. Se l'utente accettava i cookie, i tag si attivavano. Se rifiutava, non partiva niente. Corretto. Ma il consent mode v2 richiede qualcosa di più.
Cosa fa il consent mode v2 e perché è diverso
Il consent mode v2, o advanced consent mode, prevede che prima ancora che l'utente interagisca con il banner, il browser mandi a Google un segnale di default con tutti i consensi impostati su "denied". Questo permette a GA4 di inviare dei ping anonimi, senza cookie, che Google usa per modellare i dati mancanti.
In pratica, anche se l'utente non accetta i cookie, Google riceve comunque un segnale. Non un dato personale. Un ping statistico che serve per la modellazione delle conversioni e per ridurre il gap tra dati reali e dati tracciati.
Per Google Ads questo è ancora più importante. Senza quei segnali, le campagne perdono dati di conversione e l'algoritmo di ottimizzazione lavora con informazioni incomplete.
Il consent mode v2 non serve per tracciare chi rifiuta i cookie. Serve per dire a Google "questo utente esiste, ha visitato il sito, ma non ha dato il consenso". Senza quel default denied iniziale, Google non sa nemmeno che l'utente c'è.
Il problema del banner nativo Shopify
Quello che ho trovato analizzando il setup è che il banner nativo di Shopify non imposta un default state denied. I segnali di consenso diventano disponibili solo dopo che l'utente interagisce con il banner e accetta.
Tradotto in pratica. Un utente arriva sul sito. Il banner compare. L'utente naviga tre pagine senza cliccare niente. In un setup corretto con consent mode v2, GA4 avrebbe ricevuto tre ping anonimi. Con il banner nativo di Shopify, GA4 non riceve nulla. Zero. Come se quell'utente non fosse mai esistito.
Meta invece funzionava. L'integrazione diretta di Shopify con Meta non dipende dal consent mode di Google. Ha il suo sistema. Per questo il cliente non aveva notato il problema. I numeri di Meta erano coerenti, quelli di GA4 no.
Come l'ho scoperto
Il primo segnale è arrivato dai daily report automatici che mandiamo su Slack. I numeri di sessioni GA4 erano calati dopo la migrazione, ma non in modo drammatico. Sembrava un calo fisiologico post migrazione. Ma quando ho confrontato le sessioni GA4 con i dati Shopify nativi, il gap era troppo grande.
Sono andato in BigQuery a guardare gli eventi raw. Nessun ping. Nessun evento con consent state "denied". Solo eventi con consent "granted". Il che significa che GA4 vedeva solo gli utenti che accettavano il banner, e di quelli che ignoravano il banner o rifiutavano non c'era traccia.
Ho poi verificato in developer console. Nessun comando gtag('consent', 'default', ...) nel codice sorgente prima del caricamento dei tag. Il banner di Shopify gestisce il consenso a modo suo, tramite le sue API interne, ma non scrive il segnale nel formato che Google si aspetta.
Le opzioni sul tavolo
A quel punto avevo due strade.
La prima era tornare a GTM. Installare Google Tag Manager, configurare Cookiebot o un altro CMP certificato, e gestire tutto il tracking da lì. Soluzione pulita, controllo totale, ma significa buttare via l'integrazione nativa di Shopify e riconfigurare tutto. Più ore, più complessità, e il cliente deve pagare un CMP (nel caso di Cookiebot, circa 90 euro al mese).
La seconda era intervenire direttamente nel tema Shopify. Aggiungere uno script che imposta il consent default denied prima che qualsiasi tag si carichi, e poi aggiornare il consent state quando l'utente interagisce con il banner nativo. In pratica, fare da ponte tra il sistema di consent di Shopify e il formato che Google richiede.
Ho scelto la seconda strada. Meno invasiva, mantiene l'architettura esistente, e il fix è relativamente contenuto.
La soluzione nel dettaglio
Il fix consiste nell'aggiungere nel tema Shopify, prima di qualsiasi altro script di tracking, un blocco che imposta il consent default.
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'wait_for_update': 500
});Questo dice a Google "per ora tutto negato, aspetta 500 millisecondi per un eventuale aggiornamento". Poi, quando il banner nativo di Shopify registra il consenso dell'utente, uno script di callback legge lo stato del cookie di Shopify e manda il consent update.
Il punto delicato è che il banner nativo di Shopify salva il consenso in un cookie con un formato suo. Ho dovuto leggere quel cookie, interpretare i valori, e tradurli nei parametri che Google si aspetta. Non è difficile, ma bisogna sapere dove guardare.
Ho preparato un documento tecnico con tutte le istruzioni per lo sviluppatore Shopify del cliente e un video Loom che spiega il problema e la soluzione passo passo. Lo sviluppatore era in un altro fuso orario, quindi la comunicazione asincrona era l'unica opzione pratica.
Un pattern che si ripete
Questo non è un caso isolato. Ho visto lo stesso problema su almeno tre e-commerce diversi nell'ultimo anno. Ogni volta con varianti leggermente diverse.
Un brand di orologi svizzero aveva un banner custom con un cookie che restituiva "ok" o "ko". Dovevo leggere quel valore e tradurlo in consent signals. Un altro e-commerce con il sito custom aveva lo sviluppatore che voleva creare un banner proprietario invece di usare Cookiebot, e abbiamo dovuto documentare esattamente quale formato il cookie doveva avere.
Il denominatore comune è sempre lo stesso. Il banner c'è, sembra funzionare, l'utente vede la scelta, ma il segnale tecnico che Google si aspetta non viene generato nel modo corretto. E senza quel segnale, il consent mode v2 non si attiva.
Se state usando Shopify con le app native di tracking e il banner cookie nativo, controllate in developer console se vedete il comando gtag('consent', 'default', ...) nel codice sorgente. Se non c'è, il consent mode v2 non sta funzionando. I vostri dati GA4 sono incompleti.
L'impatto sui numeri
Quanto impatta in pratica? Dipende dal tasso di consenso del sito. In Italia, con i banner GDPR, tipicamente il 60 e 70 percento degli utenti accetta i cookie. Il restante 30 e 40 percento viene perso completamente senza consent mode v2.
Con il consent mode v2 attivo, Google riesce a modellare una parte significativa di quel traffico mancante. Non è un dato esatto, è una stima statistica, ma è enormemente meglio di zero.
Per Google Ads l'impatto è ancora più concreto. Le conversioni modelizzate entrano direttamente nell'ottimizzazione delle campagne. Senza quei dati, l'algoritmo di Smart Bidding lavora alla cieca su un terzo del traffico.
Cosa ho imparato
La migrazione a Shopify semplifica molte cose, ma il tracking non è una di quelle. Le app native funzionano bene per i casi base, ma appena entri nel territorio del consent mode avanzato, delle configurazioni Google Ads specifiche, o dei requisiti GDPR europei, le cose si complicano.
Ho imparato che dopo ogni migrazione di piattaforma, anche se tutto sembra funzionare, devo sempre verificare tre cose. Primo, che il consent default denied sia presente nel codice sorgente prima di qualsiasi tag. Secondo, che in BigQuery ci siano eventi con consent state "denied", non solo "granted". Terzo, che il gap tra sessioni GA4 e sessioni della piattaforma nativa sia ragionevole.
Se manca anche solo uno di questi tre check, c'è qualcosa che non va. E il fatto che Meta funzioni non è una garanzia che Google funzioni. Sono due sistemi completamente separati.
Il consent mode sembra una cosa burocratica. In realtà è un pezzo fondamentale dell'infrastruttura dati di qualsiasi e-commerce europeo. E quando non funziona, non te ne accorgi dai report standard. Te ne accorgi solo guardando i dati raw.