O problema: tags que disparam cedo demais

Um banner de consentimento só funciona se as tags por trás dele respeitarem a escolha do visitante. A falha mais comum é simples: o banner aparece, mas os scripts de análise e de anúncios já carregaram e definiram identificadores antes de alguém clicar em qualquer coisa. Corrigir isso significa bloquear scripts até que o consentimento seja dado. Há três maneiras práticas de fazer isso.

Método 1: reescrever o tipo do script

Os navegadores só executam um elemento script quando seu tipo é um tipo JavaScript. Se você mudar o tipo para text/plain, o navegador ignora o script. Em seguida, você adiciona um atributo data que registra a qual categoria de consentimento o script pertence:

• Mude type="text/javascript" para type="text/plain".
• Adicione um atributo como data-category="analytics".
• Quando o visitante consente com essa categoria, um pequeno carregador restaura o tipo e insere o script para que ele seja executado.

Bom para: um punhado de scripts conhecidos, inline ou externos, nos seus templates. Cuidado com: scripts injetados por outros scripts, que nunca passam pelos seus templates e, portanto, nunca são reescritos.

Método 2: controlar as tags em um gerenciador de tags

Se suas tags ficam no Google Tag Manager ou em uma ferramenta semelhante, você pode deixar o contêiner na página e controlar o disparo com gatilhos que levam o consentimento em conta. Cada tag recebe um requisito de consentimento, e o gerenciador de tags só a dispara quando o estado de consentimento correspondente é concedido. A grande vantagem é o controle centralizado: o marketing pode adicionar tags sem mexer nos templates, e a regra acompanha a tag.

Bom para: sites com muitas tags de marketing. Cuidado com: scripts fixos no código fora do contêiner e tags HTML personalizadas que carregam outros scripts por conta própria.

Método 3: carregar scripts dinamicamente com o consentimento

Aqui você remove totalmente as tags script da página e escreve uma função que as injeta somente após um evento de consentimento. É a opção mais limpa para aplicações de página única e para desenvolvedores que querem controle total:

1. Ouça o callback de consentimento da sua CMP.
2. Verifique quais categorias foram concedidas.
3. Crie um elemento script, defina sua origem e anexe-o ao documento.
4. Execute qualquer código de inicialização no manipulador de carregamento do script.

Bom para: aplicações modernas com etapa de build. Cuidado com: esquecer de tratar o visitante recorrente, cuja escolha armazenada deve acionar o carregamento ao abrir a página, sem um novo clique.

Tratando a retirada do consentimento

Bloquear antes do consentimento é só metade do trabalho. Se um visitante retirar o consentimento depois, pare de chamar as ferramentas e garanta que elas não continuem lendo ou gravando identificadores. Remover um script da página não remove o código que já está na memória, então recarregar a página após a retirada costuma ser a abordagem confiável mais simples.

Qual você deve escolher?

• Poucos scripts, templates renderizados no servidor: método 1.
• Muitas tags de marketing, editadas por quem não é desenvolvedor: método 2.
• Aplicação de página única ou front-end sob medida: método 3.
• Ambientes mistos costumam combinar dois deles. Só garanta que nenhuma tag fique sem cobertura de todos.

Como testar

1. Abra uma janela privada com o cache limpo.
2. Abra as ferramentas de desenvolvedor do navegador nas abas Network e Application antes de carregar a página.
3. Carregue a página sem tocar no banner. Confirme que nenhuma requisição de análise ou publicidade é enviada e que nenhum cookie ou item de armazenamento relacionado aparece.
4. Aceite apenas uma categoria e confirme que somente os scripts correspondentes carregam.
5. Rejeite tudo, recarregue e repita a primeira verificação.
6. Retire o consentimento e verifique o comportamento descrito acima.

Onde a FlexyConsent se encaixa

A FlexyConsent oferece suporte ao IAB TCF 2.4 e ao Google Consent Mode v2 e é uma CMP certificada pelo Google (CMP ID 317). Qualquer que seja o método de bloqueio escolhido, o papel do banner é dar ao seu código um sinal claro do que o visitante escolheu. O seu papel é garantir que todo script o obedeça.

Principais conclusões

• Scripts que carregam antes de o visitante escolher anulam o propósito do banner.
• Reescrita de tipo, gatilhos do gerenciador de tags e carregamento dinâmico servem cada um a um tipo diferente de site.
• Scripts injetados por outros scripts são o vazamento mais comum.
• Trate visitantes recorrentes e a retirada do consentimento, não apenas a primeira visita.
• Teste em uma janela privada limpa, com as ferramentas de desenvolvedor abertas, antes de tocar no banner.