Blog
Un banner dei cookie davanti al tagging lato server: cosa cambia e cosa no
Pubblicato · 5 min di lettura
La domanda arriva in due forme. «Mi serve ancora un banner se i tag ora sono first-party?»: sì. «Il mio banner funziona ancora se i tag ora sono first-party?»: di solito, ma il modo in cui può fallire è silenzioso, e vale venti minuti per esserne certi. Questa non è consulenza legale; è una descrizione della meccanica, perché ciò che il tuo consulente ti dice di fare, la configurazione lo faccia davvero.
Cosa cambia il tagging lato server riguardo al consenso: nulla
Un nome host first-party è una proprietà tecnica di una richiesta. Non è un permesso. Se ieri ti serviva il consenso per impostare un cookie di analisi, ti serve anche oggi, e il fatto che il cookie ora sia impostato da metrics.tuosito.com invece che da google-analytics.com non c’entra nulla. La domanda dell’autorità è cosa raccogli e perché, non quale server ha visitato il pacchetto lungo il percorso.
Ciò che cambia è dove va una richiesta bloccata. Gli ad blocker e le funzioni di privacy dei browser bloccano per nome host e per pattern di URL, e bloccano googletagmanager.com. Non bloccano il tuo dominio. Un visitatore che ha acconsentito e che una lista di filtri avrebbe scartato in silenzio ora viene contato. Questo è tutto il beneficio, ed è un beneficio solo per i visitatori che hanno acconsentito.
Consent Mode, in un paragrafo
I tag di Google leggono uno stato di consenso con una manciata di permessi denominati — analytics_storage, ad_storage, ad_user_data, ad_personalization — e adattano ciò che inviano. Prima che il visitatore decida, un gestore del consenso invia un valore predefinito denied; quando sceglie, invia un aggiornamento. Nello stato denied il tag Google si attiva comunque, ma manda un ping senza cookie: nessun ID cliente, nessun cookie, un segnale che una pagina è stata vista e nulla più. Una volta che analytics_storage passa a granted, invia l’hit completo. Il container server riceve ciò che è stato inviato, e i segnali di consenso viaggiano con l’hit, quindi il tag GA4 lato server si comporta allo stesso modo.
L’ordine conta, e i tag di SignalHost non aggiungono condizioni proprie
Il gestore del consenso deve caricarsi prima del tag Google, così che il suo valore predefinito sia già in posizione quando il tag valuta per la prima volta. La maggior parte dei gestori offre un valore wait_for_update proprio per questo: qualche centinaio di millisecondi in cui il tag attende uno stato di consenso prima di assumere denied.
Le entità che SignalHost crea nel tuo container non portano condizioni di consenso. È voluto. I tag di Google rispettano Consent Mode da soli; un controllo di consenso aggiunto a mano sul tag Google, senza nulla sui tag evento GA4 sotto di esso, è il primo dei due errori qui sotto.
Errore uno: condizionare il tag Google e non i tag evento
Il tag Google è ciò che instrada la misurazione attraverso il container server. Un tag evento GA4 — un tag di acquisto, per esempio — può inviare da solo. Se il tag Google attende il consenso e i tag evento no, i tag evento si attivano prima del consenso e inviano direttamente a Google, e lo fanno da una pagina il cui banner è ancora aperto. La pagina del container non mostra nulla di strano, perché gli hit non sono mai passati dal container.
O non condizioni nulla a mano e lasci fare a Consent Mode, oppure condizioni ogni tag che può inviare. Non esiste una via di mezzo coerente.
Errore due: un gestore del consenso bloccante che non riconosce il tuo loader
Alcuni gestori del consenso funzionano bloccando gli script finché il consenso non viene dato: intercettano i tag script per URL e li trattengono. Le loro liste conoscono googletagmanager.com. Non conoscono exxz2gdaz1jz.tuosito.com, perché nessuna lista potrebbe: nome host e nome file del loader sono unici per il tuo container. In modalità di blocco, quindi, il loader può essere lasciato passare senza condizioni, e se ti affidi al blocco anziché a Consent Mode, quello è un tag che si attiva prima del consenso.
Due vie d’uscita. Aggiungi a mano l’URL del loader alle regole di blocco del gestore, nella categoria a cui appartiene la tua analisi. Oppure — meglio, perché gestisce correttamente anche il ping senza cookie — affidati a Consent Mode per i tag di Google e usa il blocco solo per gli script che non lo supportano. Il nostro stesso sito usa un gestore del consenso in modalità di blocco automatico con Consent Mode accanto; il tag Google è posizionato dopo lo script del gestore, e un test nel repository fallisce se qualcuno ne inverte l’ordine.
Il lato server, e le altre destinazioni
Lo stato di consenso arriva al container server dentro ogni hit, e il tag GA4 lato server lo legge come farebbe quello del browser. Nulla dalla nostra parte concede o amplia un consenso; un ping senza cookie resta un ping senza cookie.
Se colleghi una destinazione Meta o TikTok, gli stessi hit le alimentano. Se il consenso marketing negato di un visitatore debba fermare quegli inoltri è una decisione che esprime il tuo gestore del consenso: attraverso la categoria in cui si trova il loader, e a seconda che la tua configurazione rispetti l’ad_storage di Consent Mode. Verificalo come verificheresti qualsiasi cosa qui: apri il sito con il banner senza risposta, guarda la scheda di rete e osserva cosa parte.
Una lista di controllo
- Lo script del gestore del consenso sta sopra il tag Google nella pagina.
- Uno stato di consenso predefinito denied viene inviato prima che il tag si carichi, con un wait_for_update.
- Nessun tag nel container ha una condizione di consenso aggiunta a mano — oppure ce l’ha ogni tag che può inviare.
- Con il banner senza risposta, la scheda di rete mostra un ping senza cookie (gcs=G100 nella richiesta) e nessun hit completo.
- Dopo l’accettazione, la stessa pagina mostra un hit completo e la pagina del container lo conta.
- Se il gestore blocca per URL, l’URL del loader è nelle sue regole.
