Por que o pixel do Facebook continua carregando quando as suas tags estão bloqueadas

Todos os artigos

O pixel do Facebook normalmente carrega por um de três motivos: o código base dele roda no head da sua página antes do banner, a tag dele dispara antes de os seus padrões de consentimento serem definidos, ou a tag nunca exigiu consentimento de publicidade. Se os três estiverem limpos, o script de outro fornecedor provavelmente está injetando o pixel em tempo de execução, e o seu contêiner não consegue travar uma requisição que nunca fez.

Descarte primeiro as causas comuns

Na maioria das vezes, é uma destas.

• O código base do pixel fica no head da sua página sem nenhum fbq('consent', 'revoke') acima, então inicializa antes de o seu banner aparecer.
• A tag dispara em um gatilho que roda antes de os seus padrões de consentimento serem definidos, então não lê escolha nenhuma.
• A tag nunca foi configurada para exigir consentimento de publicidade, então dispara aconteça o que acontecer ao redor.
• Um embed de rede social, um botão de curtir ou um widget de comentários está gravando cookies próprios.

Confira cada uma em uma página real, não no contêiner: como saber se uma tag está mesmo gravando cookies antes do consentimento traz o método. Se elas estiverem limpas e as requisições continuarem, a causa está fora do seu contêiner.

Uma ferramenta de consentimento trava o que o seu contêiner controla

Um pixel de publicidade chega a uma página por uma de três rotas comuns, e uma ferramenta de consentimento alcança cada uma de um jeito diferente. A maioria das respostas publicadas considera só as duas primeiras.

A primeira é uma tag no seu contêiner, que dispara quando o estado de consentimento permite. A segunda é um script no código-fonte da sua página, que uma ferramenta de consentimento normalmente também consegue segurar, reconhecendo-o antes de o navegador executá-lo.

A terceira é a que a maioria dos guias pula. Um script que já está rodando, e que você permitiu legitimamente, carrega o próprio módulo de publicidade em tempo de execução e injeta o pixel. O seu contêiner nunca fez essa requisição, então nada que você mude dentro dele vai impedi-la.

Veja como era a terceira rota em um conjunto de sites em produção que auditamos em agosto. Cookies da Meta e do LinkedIn estavam sendo gravados antes do consentimento, e o diagnóstico interno culpava as tags do contêiner. Em uma sessão nova, com o banner na tela e nada clicado, as duas tags tinham uma condição de armazenamento de publicidade e nenhuma disparou. Os cookies apareceram mesmo assim, com os mesmos IDs de pixel, porque uma tag de plataforma de marketing permitida carregava o próprio arquivo de pixel de publicidade, que carregava as bibliotecas da Meta e do LinkedIn. Nada estava mal configurado; a fronteira só não estava onde todos imaginavam.

Como saber qual deles você tem

Alguns minutos, sem abrir o contêiner.

1. Abra o site em um perfil novo e recuse tudo

   Nenhum consentimento guardado, o painel de rede aberto antes da primeira renderização e uma recusa deliberada.

2. Filtre pelos hosts do próprio pixel

   Para a Meta, isso é connect.facebook.net para a biblioteca e facebook.com/tr para o evento. Olhe também o painel Application: um cookie _fbp aparecendo no seu próprio domínio nessa sessão nova geralmente significa que a biblioteca carregou. Nenhuma requisição e nenhum cookie significa que você não tem esse problema.

3. Expanda a cadeia de iniciadores e não leia só a primeira linha

   Este é o passo em que é mais fácil errar. O seu gerenciador de tags costuma aparecer na cadeia porque carregou o script do fornecedor muito antes, o que não é prova de que uma tag do gerenciador fez essa requisição. O que você procura é a entrada imediatamente acima da chamada do pixel: ela nomeia o script que é dono dela.

4. Compare o contêiner com o que você acabou de ver

   Abra o preview e confira se as tags de publicidade dispararam. Uma tag na lista de não disparadas enquanto a requisição continua aparecendo não é uma contradição: as duas ferramentas descrevem camadas diferentes.

5. Siga o script dono de volta até a plataforma dele

   Encontre o fornecedor por trás disso e, depois, a configuração de integração de publicidade dele. É essa configuração, e não a sua configuração de consentimento, que está colocando o pixel na página.

Por que travar mais no contêiner não funciona

Parece progresso, e é por isso que sai caro. A equipe acrescenta uma condição de consentimento às tags de publicidade, depois um gatilho de bloqueio, depois uma exceção, e conclui que a ferramenta de consentimento está quebrada, quando cada mudança foi feita em uma tag que já não estava disparando.

Separe isso da falha com que costuma ser confundido. As suas próprias tags dispararem antes de o banner registrar os padrões é um problema de tempo, que dá mesmo para corrigir no contêiner, e explicamos em por que as tags disparam antes de o banner de cookies carregar. Isto aqui é escopo, não tempo: as suas tags se comportaram corretamente e algo fora do escopo delas fez justamente o que você estava tentando impedir.

Onde a correção realmente fica

Quatro alavancas. A certa depende do que o script do fornecedor faz antes do consentimento e de em qual categoria o script deveria estar desde o início: em qual categoria de consentimento entra cada script de terceiros trata dessa decisão.

• O portal do próprio fornecedor. A maioria das plataformas que injetam pixels de publicidade oferece uma configuração para isso. Desligar essa integração é o mais limpo: o script continua fazendo o trabalho legítimo dele e para de carregar o pixel de outra empresa.
• Uma chamada antecipada de revogação de consentimento. fbq('consent', 'revoke'), rodando antes que qualquer coisa possa inicializar o pixel, diz à biblioteca da Meta para segurar os eventos, não importa quem a carregou. A documentação de consentimento da própria Meta descreve as chamadas de revogação e de concessão. É uma rede de segurança, não uma resposta completa: a biblioteca continua carregando, e só ajuda se a sua chamada de fato rodar primeiro.
• A tag do fornecedor no seu contêiner. Se uma tag sua carrega o script do fornecedor, trave essa tag no consentimento de publicidade. É uma solução bruta: você também perde o que mais esse script faz para os visitantes que recusam, como formulários ou chat.
• Bloqueio por categoria na ferramenta de consentimento. Se o script do fornecedor carrega fora do seu contêiner, classifique o próprio script como publicidade, para que a ferramenta o segure antes de ele rodar. A mesma contrapartida.

Depois rode o mesmo teste de novo: perfil novo, recusar, filtrar, confirmar que nada chega aos hosts do pixel. Um limite: isso só lê o navegador, então qualquer coisa que os seus servidores enviem por uma API de conversões precisa ser conferida na origem. Verificar no destino em vez de no banner é o hábito geral, descrito em como conferir se o seu banner está mesmo enviando o sinal de consentimento.

Se você também usa o Signals Gateway da Meta, filtre também pelo subdomínio do seu gateway: o pixel dele é um código separado que precisa da própria verificação de consentimento, explicada em como fazer o Meta Signals Gateway respeitar o consentimento de cookies.

O Velo segura os scripts que você marca com uma categoria de consentimento até essa categoria ser concedida; um pixel que outro fornecedor injeta sem essa marcação ainda precisa ser rastreado até o fornecedor.