L’errore più diffuso è sempre lo stesso: spostare i tag nel container server e considerare chiusa la questione del consenso, perché "ormai gira tutto sul mio dominio". Il costo è doppio. Da una parte un tag Meta CAPI che continua a spedire email hashate anche dopo il rifiuto del banner, cioè un trattamento senza base giuridica che nessuna configurazione tecnica può giustificare. Dall’altra, l’effetto opposto: blocchi troppo aggressivi che impediscono persino il ping cookieless verso Google, con la modellazione delle conversioni che non si attiva mai e campagne ottimizzate su una frazione dei dati reali.
Questa guida parte dove finiscono quasi tutte le altre: non da come si installa una CMP, ma da cosa succede al segnale di consenso quando la richiesta lascia il browser ed entra nel container server.
Il malinteso da chiarire subito: il server-side non aggira il consenso
Il Consent Mode v2 è un meccanismo di browser. La scelta dell’utente viene raccolta dalla CMP, scritta nel dataLayer tramite il comando gtag('consent', ...) e applicata ai tag che girano sulla pagina. Il container server non decide nulla: riceve un segnale già formato e si limita a rispettarlo, ignorarlo o distruggerlo.
Passando al server-side non cambia chi decide, cambia dove viene eseguita la richiesta e chi scrive i cookie. È proprio per questo che il rischio aumenta invece di diminuire: il tuo endpoint può impostare cookie HTTP-only con durata lunga, costruire ID persistenti e inoltrare dati a piattaforme terze senza che il browser abbia alcuna voce in capitolo. Tutte azioni che nel client-side erano vincolate ai controlli nativi dei tag, e che sul server devi vincolare a mano.
I segnali da governare sono quattro: ad_storage (cookie pubblicitari), ad_user_data (invio di dati utente a Google per finalità pubblicitarie), ad_personalization (remarketing e personalizzazione), analytics_storage (cookie di misurazione). I primi tre riguardano Ads, il quarto GA4.
Un’opinione netta: in uno scenario server-side l’implementazione base non ha senso. Con la modalità base i tag non partono affatto in assenza di consenso, quindi al container server non arriva nulla e non hai nemmeno il ping cookieless da inoltrare a Google. L’implementazione avanzata è l’unica coerente con un’architettura in cui hai investito tempo e denaro proprio per non perdere segnale.
Prerequisiti: cosa deve già funzionare lato browser
Prima di aprire il container server, verifica cinque cose.
La CMP deve avere un template Consent Mode nativo e deve impostare i default prima di qualunque tag. Le piattaforme di consenso diffuse sul mercato italiano lo fanno, ma solo se le installi come previsto. L’errore classico è caricare la CMP come tag dentro GTM con trigger "Inizializzazione consenso" mal configurato, o peggio come tag normale: in quel caso i default arrivano dopo, e il primo hit parte con uno stato sbagliato.
L’ordine corretto è: default di consenso, poi caricamento di gtag/GTM, poi aggiornamento del consenso quando l’utente clicca. Niente scorciatoie.
Nelle impostazioni del container web attiva wait_for_update con un valore sufficiente a coprire la risposta della CMP (qualche centinaio di millisecondi), imposta i default per area geografica se tratti anche mercati extra-UE, e valuta url_passthrough e ads_data_redaction. Il primo propaga gclid tra le pagine quando i cookie non sono disponibili, il secondo riduce i dati inviati a Google quando ad_storage è negato.
Infine, il server_container_url deve essere impostato sul tag Google e sui tag Ads che intendi far passare dal server. Da quel momento l’hit esce verso il tuo dominio e tutto quello che segue è responsabilità tua. Se non hai ancora chiaro cosa cambia nel percorso della richiesta, parti dalla differenza tra tracciamento client side e server side.
Regola a monte: se il consenso è sbagliato nel browser, nessuna configurazione server potrà ripararlo. Non perdere tempo sul container server finché il test lato pagina non è pulito.
Come il segnale di consenso arriva al container server
Apri gli strumenti di sviluppo, scheda Rete, filtra le richieste verso il tuo dominio di tracciamento e guarda i parametri della query string.
gcs è il più leggibile. Formato G seguito da tre cifre: la prima è un flag interno, la seconda è ad_storage, la terza analytics_storage. G100 significa entrambi negati, G101 solo analytics concesso, G110 solo pubblicitario concesso, G111 consenso pieno. Se gcs manca del tutto, il Consent Mode non è attivo su quella pagina.
gcd è la stringa estesa: contiene tutti e quattro i segnali con i rispettivi stati di default e di aggiornamento. È meno leggibile a occhio, ma è quella che Google usa per capire se può modellare. dma e dma_cps riguardano la conformità al Digital Markets Act, npa=1 indica annunci non personalizzati, _rdp il restricted data processing per gli Stati Uniti.
Dentro il container server questi valori riappaiono nell’anteprima, nella scheda Event Data dell’evento in ingresso, come proprietà di sistema popolate dal client GA4 (cerca le chiavi che iniziano con x-ga-gcs, x-ga-gcd, x-ga-dma). Crea subito due variabili di tipo Event Data che leggano x-ga-gcs e, se ti serve granularità sui quattro segnali, una variabile di ricerca che traduca la stringa in valori leggibili tipo ads_granted / ads_denied. Ti serviranno in ogni trigger della sezione successiva.
Ultimo punto, spesso frainteso: gli hit senza consenso devono comunque arrivare al container server e proseguire verso Google. Sono ping cookieless, privi di identificatori, e sono esattamente la materia prima della modellazione. Se li blocchi, elimini la possibilità di recuperare qualcosa.
Configurare i tag Google nel container server
Il tag GA4 lato server funziona bene se lo lasci lavorare. Il payload in ingresso contiene già i parametri di consenso e il tag li inoltra. Il problema nasce quando qualcuno ricostruisce la richiesta a mano o applica trasformazioni aggressive sull’evento: in quel caso gcs e gcd spariscono e Google riceve un hit senza contesto, trattandolo come privo di Consent Mode. Se usi le trasformazioni, verifica sempre che le proprietà di sistema sopravvivano.
Per Google Ads valgono ad_user_data e ad_personalization. Senza il primo non puoi inviare dati utente; senza il secondo non puoi alimentare il remarketing. Il tag Google Ads nel container server rispetta il segnale se gli arriva correttamente, quindi la cosa più sensata è non aggiungere blocchi manuali sopra: rischi di sopprimere anche i ping utili. Su come questo si riflette sulle campagne abbiamo già scritto perché il server-side è l’alleato migliore di Google Ads.
Le conversioni avanzate sono il punto più delicato. Stai inviando email o telefono hashati: senza ad_user_data concesso non devono partire, punto. Se raccogli quei dati nel Data Layer, assicurati che la pipeline sia condizionata e non "sempre attiva" per comodità.
Poi c’è il nodo dei cookie. Il container server può scrivere cookie first-party via risposta HTTP, tipicamente l’FPID usato da GA4. Sono cookie a tutti gli effetti, scritti da te, con durata lunga e non cancellabili dalle restrizioni ITP come i cookie JavaScript. Scriverli a prescindere dal consenso significa impostare un identificatore persistente su un utente che ha rifiutato: è la contestazione più facile da sollevare in un controllo. Condiziona la scrittura dell’FPID allo stato di analytics_storage, usando l’apposita impostazione del client GA4 o un controllo esplicito.
Quando il consenso manca ma vuoi comunque misurare il traffico in forma aggregata, valuta una trasformazione che degradi il dato (rimozione di IP, user_id, parametri URL identificativi) invece di bloccare l’evento intero.
Il punto cieco: i tag non-Google nel container server
Qui sta il rischio vero, e quasi nessuno lo nomina. Meta CAPI, TikTok Events API, Pinterest, Klaviyo, Bing: nel container server questi tag non hanno alcun controllo automatico del consenso. Se il trigger scatta, l’evento parte. Non esiste una casella "rispetta il Consent Mode" che ti salvi.
La configurazione minima è un’eccezione sul trigger: se la variabile di consenso pubblicitario non è concessa, il tag non deve attivarsi. Costruiscila sul valore di gcs o sulla variabile tradotta che hai creato prima, e applicala a tutti i tag di piattaforme terze, non solo a quelli di conversione.
Per Meta, il blocco sul trigger non basta a essere ordinati: la Conversions API prevede campi dedicati allo stato di consenso e ai limiti di trattamento. Passali come parametri dell’evento, così la piattaforma registra il contesto e non solo l’assenza del dato.
Il caso più insidioso è l’evento server-to-server. L’ordine confermato dal gestionale o dalla piattaforma e-commerce arriva al container server via HTTP, senza browser, senza cookie, senza alcun contesto di consenso. Soluzione: registra lo stato del consenso al momento dell’ordine (puoi salvarlo come proprietà dell’ordine o come campo custom al checkout) e allegalo al payload che invii al container. Se non lo fai, hai due opzioni, entrambe cattive: inviare sempre, oppure non inviare mai. Lavorare bene sul Data Layer è ciò che rende possibile la prima.
Verifica: cinque test in un quarto d’ora
Test 1, browser. Scheda Rete, filtro sul dominio di tracciamento. Carica la pagina senza toccare il banner e annota gcs. Accetta e ricarica. Il valore deve cambiare. Se resta identico, la CMP non sta aggiornando il consenso.
Test 2, anteprima del container server. Verifica che l’evento in ingresso contenga i segnali e, nello scenario "rifiuto", che i tag non-Google risultino effettivamente non attivati. Controlla la scheda del tag, non solo il riepilogo.
Test 3, GA4. DebugView per vedere gli eventi in tempo reale e i report standard per distinguere traffico consentito, modellato e perso. L’indicazione sulla soglia dei dati e la presenza di dati modellati compaiono solo quando Google ritiene sufficiente il volume.
Test 4, Google Ads. Nella diagnostica delle conversioni controlla lo stato del consent mode e la copertura di ad_user_data e ad_personalization. Se risulta non configurato mentre il banner funziona, quasi sempre il problema è che i segnali si perdono nel passaggio al container server.
Test 5, cookie. Ispeziona lo storage prima di qualsiasi interazione col banner. Per ogni cookie presente devi sapere chi lo ha scritto: JavaScript del browser o risposta HTTP del tuo server. I secondi si riconoscono dal flag HttpOnly.
La matrice di test da ripetere a ogni modifica: quattro stati di consenso (rifiuto totale, solo analytics, solo pubblicità, accettazione piena) per tre eventi chiave (page_view, add_to_cart, purchase). Dodici verifiche, mezz’ora di lavoro, zero sorprese.
Gli otto errori che vediamo più spesso
- Default di consenso impostati dopo il caricamento dei tag: il primo hit parte già compromesso e arriva al server con uno stato falso.
- Payload ricostruito a mano nel container server, con perdita di
gcsegcd: Google riceve l’hit ma non lo considera idoneo alla modellazione. - Convinzione che il dominio personalizzato first-party sostituisca la base giuridica. Non la sostituisce: cambia il mittente tecnico, non la natura del trattamento.
- Trigger server duplicati che fanno partire due volte la stessa conversione quando il consenso cambia a metà sessione.
- CMP configurata solo sul container web principale, dimenticando il secondo container, il checkout su sottodominio o l’app.
- FPID scritto a prescindere dal consenso.
- Blocco totale dei tag Google con consenso negato, quando basterebbe lasciar passare il ping cookieless: conversioni modellate perse per sempre.
- Nessun monitoraggio della distribuzione degli stati di consenso nel tempo. Se il tasso di accettazione crolla da un giorno all’altro, devi accorgertene dal tuo monitoraggio, non dalle campagne che smettono di performare.
Quanto si recupera davvero, e quando farsi accompagnare
Tieni separate due cose che vengono spesso confuse. Il server-side recupera il segnale perso per ad-blocker, accorcia meno i cookie nei browser con restrizioni tipo ITP e rende l’invio più affidabile: agisce sugli utenti che hanno accettato. Il Consent Mode avanzato agisce sugli altri, permettendo a Google di stimare le conversioni di chi ha rifiutato. Sono leve diverse e si sommano. Le trovi approfondite nella sezione dedicata a qualità del dato, consenso e ad-blocker.
Due avvertenze. La modellazione richiede volumi minimi che Google non pubblica nel dettaglio: su siti con poco traffico può non attivarsi mai, e va messo in conto. E se dopo la configurazione vedi le conversioni salire di colpo, verifica il doppio conteggio client più server prima di esultare: è la causa numero uno degli aumenti "miracolosi".
Una cosa non si recupera in nessun caso: l’utente che rifiuta non torna identificabile, qualunque sia l’architettura.
Puoi procedere in autonomia se hai un container server già attivo, un solo dominio, una CMP con template nativo e solo tag Google. Conviene farsi affiancare se gestisci più domini o sottodomini, se hai CAPI e piattaforme terze nel container server, se ricevi eventi dal gestionale o se devi documentare la configurazione al DPO. In quel caso prepara prima l’elenco dei tag attivi, la CMP in uso, lo schema degli eventi e l’export di una richiesta di rete di esempio: dimezzi i tempi. Se preferisci imparare facendo, esiste anche un percorso di tutoring su Tag Manager server-side.
Promemoria finale: la configurazione tecnica non sostituisce il parere legale su base giuridica e informativa. Il Consent Mode esegue una decisione, non la prende al posto tuo.
Domande frequenti
Se ho il tracciamento server-side devo comunque mostrare il banner cookie?
Sì. Il banner e la base giuridica dipendono dal trattamento dei dati, non dal punto in cui viene eseguita la richiesta. Anzi, con il server-side puoi scrivere cookie first-party dalla risposta HTTP con durata lunga: il consenso diventa ancora più rilevante, non meno.
Cosa significa esattamente gcs=G100 e come lo verifico?
Nel parametro gcs la seconda cifra indica ad_storage e la terza analytics_storage: G100 significa entrambi negati, G101 solo analytics concesso, G110 solo pubblicitario, G111 consenso pieno. Lo verifichi aprendo gli strumenti di sviluppo del browser, scheda Rete, filtrando le richieste verso il tuo dominio di tracciamento e leggendo la query string. Se gcs non compare, il Consent Mode non è attivo su quella pagina.
Come blocco Meta CAPI quando l'utente rifiuta il consenso pubblicitario?
Nel container server non esiste un controllo automatico: devi creare una variabile che legga lo stato del consenso dall’evento in ingresso e usarla come eccezione sul trigger del tag CAPI. In aggiunta, passa lo stato del consenso anche tra i parametri dell’evento inviati a Meta, così la piattaforma registra il contesto del trattamento.
Come gestisco il consenso per gli eventi inviati al container server dal mio backend?
Gli eventi server-to-server non hanno contesto di consenso perché non passano dal browser. La soluzione è registrare lo stato del consenso al momento dell’ordine, salvarlo come campo dell’ordine nel gestionale o nella piattaforma e-commerce, e allegarlo al payload inviato al container server. Senza questo passaggio restano solo due opzioni, inviare sempre o non inviare mai, entrambe sbagliate.