Como adicionar um banner de cookies a um site Webflow

Todos os artigos

Para adicionar um banner de cookies a um site Webflow, cole o script da sua plataforma de consentimento em Site settings, Custom code, Head code, acima de todos os outros scripts de rastreamento, e publique. Antes, limpe os campos nativos do Google Analytics e do Meta Pixel em Apps and Integrations: o que estiver ali carrega fora do seu tag manager, onde nenhuma trava de consentimento chega.

O Webflow carrega rastreamento de dois lugares, e o seu banner governa um

Quase todos os guias sobre essa pergunta param no mesmo ponto: crie uma conta em uma ferramenta de consentimento, cole o trecho de código no head, publique. Isso está correto, e não é o que decide se a configuração se sustenta. Um site Webflow tem dois lugares independentes por onde o rastreamento entra na página, e um banner governa só um deles.

Site settings, Custom code é a área que você controla. Padrões, banner e contêiner ficam todos na caixa Head code, na ordem em que você os colocar, e cada tag que o contêiner dispara pode ficar atrás de uma condição de consentimento.

Site settings, Apps and Integrations é a área que as pessoas esquecem que usaram. Cole ali um ID de medição do GA4 e o Webflow injeta o Google Analytics em todas as páginas por você; cole um ID do Meta Pixel e ele faz o mesmo com o pixel. Nenhum dos dois passa pelo seu contêiner, então nada do que você configura nele os afeta. Travar a sua tag do GA4 não muda nada enquanto houver um ID de medição naquele campo.

Os dois campos nem se comportam do mesmo jeito. O campo do Meta Pixel tem uma opção Delay for cookie consent que segura o pixel até o consentimento ser registrado, e a documentação do Webflow deixa claro que ativá-la ainda exige um banner seu. O campo do Google Analytics não tem nada equivalente: um pode ser configurado para esperar, o outro não.

Limpar esses campos muda o que o GA4 conta, então tire uma linha de base antes. Anote uma semana de sessões do GA4 ao lado de outra contagem em que você confia para os mesmos dias, como requisições da CDN ou pedidos. Com o banner no ar, a taxa de aceitação na sua ferramenta de consentimento mostra quanto da diferença vem do consentimento. Essa proporção varia com a região, o público e o design do banner, então meça a sua em vez de pegar um número emprestado.

Como configurar um banner de cookies no Webflow?

1. Limpe primeiro os campos nativos de rastreamento

   Abra Site settings, Apps and Integrations. Se houver ali um ID de medição do GA4 ou um ID do Meta Pixel, o próprio Webflow injeta essa tag em todas as páginas, fora do seu contêiner, onde nenhuma condição de consentimento das suas tags chega. Limpe os campos e carregue as duas tags pelo contêiner. Deixar um deles no lugar enquanto a mesma tag também roda no contêiner gera contagem dupla, além do vazamento.

2. Coloque os padrões negados acima de tudo

   Bem no topo de Site settings, Custom code, Head code, defina um padrão do Consent Mode que negue ad_storage, analytics_storage, ad_user_data e ad_personalization. Ele precisa ficar acima do banner e do contêiner: um padrão que chega depois de uma tag já ter disparado é uma correção tardia, não um padrão. Como trecho independente, ele também sobrevive a uma requisição do banner lenta ou com falha.

3. Adicione o banner, depois o contêiner

   Os dois vão na mesma caixa Head code, o banner primeiro, para que ele registre o seu estado antes de o contêiner ser interpretado. A caixa comporta até 50.000 caracteres, espaço de sobra para os três juntos, então não há motivo para levar uma configuração longa para outro lugar só para economizar espaço.

4. Coloque o noscript do contêiner em Footer code

   O Webflow oferece um espaço no head e outro antes da tag de fechamento do body, mas nenhum logo depois da tag de abertura do body, que é onde a documentação normalmente manda colocar o fragmento noscript de um contêiner. Footer code é o lugar que funciona aqui, e ele importa bem menos que o trecho do head.

5. Resolva os scripts que já estão no head

   Qualquer script de fornecedor colado direto no Head code carrega por conta própria e não pode ser travado por um tag manager que nunca o controlou. Faça o inventário dessa caixa antes de dar o site por concluído. Cada script vai para o contêiner como uma tag travada, é envolvido para que a camada de consentimento possa segurá-lo, ou é justificado como estritamente necessário: uma questão de elegibilidade que vale resolver script a script.

6. Publique e verifique no domínio no ar

   O código personalizado aparece no preview mas só entra no ar quando você publica, então uma verificação no Designer não prova nada. Publique, carregue o domínio no ar em um perfil limpo e não clique em nada: nenhum cookie de análise ou de publicidade gravado, nenhuma requisição chegando aos seus fornecedores. Depois aceite e confirme que tudo aparece. Teste o domínio no ar, não só o subdomínio de staging webflow.io, já que os dois podem estar com estados publicados diferentes.

A sequência completa antes do lançamento, que vale a pena rodar direito uma vez, está em como testar um banner de cookies antes de publicar.

O que pega as pessoas de surpresa no Webflow?

Preview não é publicação. A documentação do Webflow diz isso com todas as letras: os efeitos do código personalizado aparecem no preview, mas só entram no ar quando o site é publicado. Toda verificação de consentimento tem que acontecer no site publicado.

Components duplicam tudo o que você coloca neles. Um trecho de código dentro de um Component usado em um cabeçalho global vai para todas as páginas que usam esse cabeçalho. Dois contêineres em uma página são um tipo de problema à parte, e ele parece uma falha de consentimento muito antes de alguém suspeitar do cabeçalho. Trechos para o site inteiro ficam em Site settings.

O código de página roda depois do código do site inteiro. O código personalizado de uma página específica aparece depois do código do site inteiro no markup. Essa é a ordem certa para os padrões, e significa que um trecho de padrões adicionado a uma única página não consegue salvá-la: o contêiner do site inteiro já foi interpretado acima dele.

O banner documentado para o Pixel é uma trava do pixel, não uma camada de consentimento. O Webflow documenta como montar um banner à mão para o seu Meta Pixel nativo: Interactions para mostrá-lo e escondê-lo, mais um script em Footer code que concede o consentimento do pixel no clique. Ele se limita a esse pixel e diz isso. Lido como uma camada geral de consentimento, fica aquém: concede o consentimento mas não oferece nenhum caminho para retirá-lo, o botão de recusar só esconde o banner, e ele não governa mais nada na página. O artigo 7 do GDPR exige que retirar o consentimento seja tão fácil quanto concedê-lo, então isso é um ponto de partida, não a linha de chegada.

Quando o banner está no ar e os cookies continuam aparecendo

Percorra as fontes na ordem em que elas costumam se revelar a resposta. Primeiro, os campos de Apps and Integrations, que nada no seu contêiner revela. Segundo, scripts colados direto no Head code. Terceiro, um trecho de código duplicado por um Component. Só então abra o contêiner.

Uma quarta fonte não é culpa do Webflow: uma tag corretamente travada ainda pode carregar o pixel de outro fornecedor mais adiante, o que está explicado aqui. A sequência completa antes do lançamento está em como testar um banner de cookies antes de publicar.

Uma dúvida de posicionamento aparece em quase todo projeto Webflow: head ou tag manager. A resposta é os dois, divididos por função. Mantenha um trecho mínimo com os padrões negados no Head code, para o estado negado existir antes de qualquer coisa carregar, e mantenha a ferramenta em si onde as pessoas que gerenciam as tags conseguem alcançá-la. Uma ferramenta que vive só no head e cuja requisição falha deixa o contêiner disparar sem nenhum padrão registrado, o que falha na direção errada.

O Velo se instala no Webflow como um único trecho de código nessa caixa Head code: padrões, banner e o estado de consentimento que o contêiner lê, na ordem certa por construção.