O problema: etiquetas que se disparan demasiado cedo

Un banner de consentimento só funciona se as etiquetas que hai detrás respectan a elección do visitante. O fallo máis común é sinxelo: aparece o banner, pero os scripts de analítica e de publicidade xa cargaron e estableceron identificadores antes de que ninguén fixese clic en nada. Solucionalo significa bloquear os scripts ata que se dea o consentimento. Hai tres maneiras prácticas de facelo.

Método 1: reescribir o tipo do script

Os navegadores só executan un elemento script cando o seu tipo é un tipo de JavaScript. Se cambia o tipo a text/plain, o navegador ignora o script. Despois engade un atributo data que rexistra a que categoría de consentimento pertence o script:

• Cambie type="text/javascript" por type="text/plain".
• Engada un atributo como data-category="analytics".
• Cando o visitante consinte nesa categoría, un pequeno cargador restablece o tipo e insire o script para que se execute.

Bo para: un puñado de scripts coñecidos, inline ou externos, nos seus modelos. Cuidado con: os scripts inseridos por outros scripts, que nunca pasan polos seus modelos e polo tanto nunca se reescriben.

Método 2: controlar as etiquetas nun xestor de etiquetas

Se as súas etiquetas viven en Google Tag Manager ou unha ferramenta semellante, pode deixar o contedor na páxina e controlar o disparo con activadores que teñen en conta o consentimento. A cada etiqueta dáselle un requisito de consentimento, e o xestor só a dispara cando se concedeu o estado de consentimento correspondente. A gran vantaxe é o control centralizado: mercadotecnia pode engadir etiquetas sen tocar os modelos, e a regra viaxa coa etiqueta.

Bo para: sitios con moitas etiquetas de mercadotecnia. Cuidado con: os scripts escritos directamente que quedan fóra do contedor e as etiquetas custom HTML que cargan outros scripts propios.

Método 3: cargar os scripts dinamicamente co consentimento

Aquí elimina por completo as etiquetas script da páxina e escribe unha función que as inxecta só despois dun evento de consentimento. É a opción máis limpa para aplicacións dunha soa páxina e para desenvolvedores que queren control total:

1. Escoite o callback de consentimento do seu CMP.
2. Comprobe que categorías se concederon.
3. Cree un elemento script, estableza a súa orixe e engádao ao documento.
4. Execute calquera código de inicialización no load handler do script.

Bo para: aplicacións modernas cun paso de build. Cuidado con: esquecerse do visitante que volve, cuxa elección almacenada debe desencadear a carga ao cargar a páxina sen un novo clic.

Xestionar a retirada

Bloquear antes do consentimento é só a metade do traballo. Se un visitante retira o consentimento máis tarde, deixe de chamar ás ferramentas e asegúrese de que non sigan lendo nin escribindo identificadores. Retirar un script da páxina non elimina o código que xa está na memoria, así que recargar a páxina tras a retirada adoita ser o enfoque fiable máis sinxelo.

Cal debería elixir?

• Poucos scripts, modelos renderizados no servidor: método 1.
• Moitas etiquetas de mercadotecnia, editadas por non desenvolvedores: método 2.
• Aplicación dunha soa páxina ou front end a medida: método 3.
• Os entornos mixtos adoitan combinar dous deles. Só asegúrese de que ningunha etiqueta quede sen cubrir por ningún.

Como probalo

1. Abra unha xanela privada coa caché borrada.
2. Abra as ferramentas de desenvolvedor do navegador nas pestanas Network e Application antes de cargar a páxina.
3. Cargue a páxina e non toque o banner. Confirme que non se envían solicitudes de analítica nin de publicidade e que non aparecen cookies nin entradas de almacenamento relacionadas.
4. Acepte só unha categoría e confirme que só se cargan os scripts correspondentes.
5. Rexeite todo, recargue e repita a primeira comprobación.
6. Retire o consentimento e verifique o comportamento descrito arriba.

Onde encaixa FlexyConsent

FlexyConsent admite IAB TCF 2.4 e Google Consent Mode v2, e é un CMP certificado por Google (CMP ID 317). Sexa cal sexa o método de bloqueo que escolla, o traballo do banner é darlle ao seu código un sinal claro do que elixiu o visitante. O seu traballo é asegurarse de que cada script o obedeza.

Conclusións clave

• Os scripts que cargan antes de que o visitante elixa anulan o propósito do banner.
• A reescritura do tipo, os activadores do xestor de etiquetas e a carga dinámica serven cada un para un tipo de sitio distinto.
• Os scripts inseridos por outros scripts son a fuga máis común.
• Xestione os visitantes que volven e a retirada, non só a primeira visita.
• Probe nunha xanela privada limpa coas ferramentas de desenvolvedor abertas antes de tocar o banner.