Rastreamento de anúncios parou? Confira plugin, deploy e cache

Quando o rastreamento de anúncios para de funcionar, a primeira suspeita costuma cair no Meta. Só que o diagnóstico deve começar antes: no código que o site realmente entregou ao navegador. Um plugin pode ter sido desativado, um deploy pode ter substituído o trecho de rastreamento ou o cache pode continuar servindo uma versão antiga. Se o script não está na página, nenhuma configuração dentro da plataforma de anúncios consegue fazê-lo disparar.

O caminho curto é seguir a ordem em que o evento deveria acontecer. Abra o código-fonte com Ctrl+U, confirme se o snippet está presente, teste a execução no Preview e só então confira cache, rede e recebimento no destino. Depois do reparo, compare eventos rastreados com ações reais do negócio. Essa sequência mostra onde o sinal sumiu sem desmontar uma configuração que talvez ainda esteja correta.

Por que o rastreamento parece ter parado do nada?

O rastreamento parece parar do nada porque a mudança que o interrompeu costuma acontecer fora da tela onde o problema aparece. A plataforma de anúncios deixa de receber eventos hoje, mas a causa pode ter sido uma atualização do site, a troca do tema, a remoção de um plugin ou um deploy feito horas antes. Também existe atraso entre a alteração e a percepção: ninguém olha o painel a cada visita, então a falha só chama atenção quando os números caem. Trate “do nada” como “ainda não ligamos a falha a uma mudança”. Primeiro, descubra se o código continua instalado na página pública, se executa na ação certa e se a requisição chega ao destino. Essa ordem evita começar pelo último elo e atribuir ao Meta um evento que nem saiu do site.

Em WordPress, vale conferir a lista de plugins ativos e o local onde o snippet foi inserido. Se a equipe trocou o plugin de cabeçalho, restaurou um backup ou publicou um tema novo, o código pode ter sumido mesmo que o container do Google Tag Manager continue intacto.

Como confirmar pelo Ctrl+U se o código ainda está na página?

Abra a URL pública exata que recebe tráfego, pressione Ctrl+U e procure o identificador do container ou o endereço do script instalado. Esse teste lê o HTML entregue pelo servidor naquela página. Ele responde uma pergunta simples: o visitante recebeu o trecho que deveria iniciar o rastreamento? Faça a busca numa janela anônima, sem estar logado no WordPress, porque administradores podem receber uma versão diferente. Repita na landing page e, se o funil usa outro domínio, na página seguinte. Se o código não aparece, não adianta começar pelo Gerenciador de Eventos. Volte ao mecanismo de instalação: plugin ativo, campo salvo, tema atual, template da página e artefato publicado no último deploy. Se aparece duplicado, registre isso também. Duas instalações podem gerar contagem em dobro e pedem outro diagnóstico agora.

Esse passo confirma presença. A execução só aparece no Preview, que vem logo depois.

O que o Preview mostra que o código-fonte não mostra?

O Preview mostra se o container carregou, qual evento ocorreu e se a tag passou pelas condições do gatilho. O código-fonte pode conter o snippet e, ainda assim, uma regra impedir a execução: consentimento negado, seletor alterado, evento ausente no dataLayer ou variável sem valor. Reproduza a ação real, selecione o evento correspondente no painel e abra o detalhe da tag. O artigo sobre tag que não dispara no Tag Assistant mostra como separar container não encontrado, rascunho não publicado e gatilho não atendido. Há uma armadilha importante: o modo de visualização pode executar o rascunho do container. Se funciona no Preview e falha numa visita comum, compare o rascunho com a versão publicada antes de procurar defeito no navegador.

Depois da execução, confira a aba de rede. A tag aparecer como disparada significa que ela tentou rodar. Uma requisição concluída e o evento visível no destino formam as próximas provas.

Como o cache faz uma correção certa parecer errada?

O cache faz uma correção certa parecer errada quando alguma camada continua entregando o HTML ou JavaScript anterior. Você reativa o plugin, salva o snippet ou corrige o deploy, mas o visitante ainda recebe a cópia criada antes do reparo. Isso pode acontecer no plugin de cache do WordPress, no servidor, na CDN ou no navegador. Limpe apenas as camadas que você controla e teste de novo numa janela anônima. Em seguida, repita o Ctrl+U e procure o mesmo identificador. A mensagem “cache limpo” no painel não basta. A prova é a resposta pública já conter o código atual. Evite mudar outras partes da implementação durante esse teste. Se você altera plugin, container e gatilho ao mesmo tempo, perde a capacidade de saber qual ação resolveu e aumenta a chance de criar um segundo defeito.

Cache também pode produzir um resultado desigual. Uma página atualizada funciona, enquanto outra landing page continua presa numa versão anterior. Teste as URLs que recebem mídia e também a home.

Qual checklist usar antes de mexer no Meta?

Use um checklist que acompanhe o evento da origem até o destino e anote o primeiro ponto que falha. Comece pela página pública, não pelo painel administrativo. Depois, faça uma mudança por vez e repita o mesmo teste. Essa disciplina parece lenta quando a equipe está com pressa, mas costuma reduzir o tempo total porque elimina tentativas sem prova. Se o código sumiu do HTML, revise plugin ou deploy. Se está presente e o Preview não conecta, investigue o carregamento do container. Se conecta e a tag não executa, leia gatilho, variáveis e consentimento. Se executa e não há requisição concluída, procure bloqueio no transporte. Se a requisição termina e o destino não registra o evento, confira endpoint, identificador, credencial e diagnóstico de recebimento. Só então vale investigar uma indisponibilidade da plataforma.

1. Abra a URL da campanha numa janela anônima.
2. Use Ctrl+U e confirme que o snippet esperado está no HTML.
3. Entre no Preview e reproduza a ação que deveria gerar o evento.
4. Veja se a tag executou no evento certo.
5. Confira a requisição na rede e a resposta do endpoint.
6. Procure o evento na ferramenta de teste ou diagnóstico do destino.
7. Compare a versão publicada com o último deploy e limpe o cache se a página estiver antiga.
8. Teste novamente fora do Preview.

Se há um banner de consentimento, inclua um teste com aceite e outro com recusa. O guia sobre banner de cookies, GA4 e Meta explica por que mostrar o banner e atualizar o estado das tags são tarefas diferentes.

Como saber se o conserto continua funcionando amanhã?

Um teste manual prova uma sessão. Para saber se o conserto continua funcionando, compare continuamente fatos do negócio com eventos recebidos. Use pedidos aprovados, leads válidos ou outra ação registrada fora da plataforma de anúncios como referência. Escolha o mesmo período, fuso, status e escopo dos dois lados. A diferença não precisa ser zero para o monitor ser útil, pois consentimento, bloqueios e regras de atribuição podem separar as contagens. O alerta deve observar mudança de patamar: queda brusca na razão entre eventos e ações reais, ausência de um tipo de evento enquanto há pedidos, ou crescimento anormal de duplicatas. Cuidado com o falso verde. Se não houve vendas e também não houve eventos, dois zeros não provam que a implementação está saudável. O monitor precisa saber se existiu tráfego ou atividade suficiente para esperar algum sinal.

O guia sobre dashboard e infraestrutura de eventos mostra como reconciliar as duas camadas pelo identificador do pedido, sem escolher uma tela por conveniência.

Quando vale revisar toda a implementação?

Vale revisar a implementação inteira quando o primeiro ponto de falha muda entre páginas, quando o código aparece duplicado, quando ninguém sabe qual plugin ou deploy é a fonte oficial, ou quando a equipe não consegue ligar um pedido real ao evento recebido. Nessa situação, reativar o snippet resolve o sintoma de hoje, mas deixa a operação pronta para repetir a falha no próximo update. A revisão deve definir um único dono da instalação, documentar onde o código entra no site, registrar a versão publicada e criar uma conferência entre ações reais e eventos. Quem publica também precisa saber qual verificação encerra a tarefa. Remova instalações antigas com cuidado, porque dois pixels ou dois containers podem parecer redundância e terminar em duplicação.

A Advanced Tracking Academy faz esse diagnóstico seguindo os recibos do fluxo: página entregue, tag executada, requisição concluída e evento recebido. Veja o escopo dos serviços de implementação e diagnóstico de rastreamento. O objetivo é sair com a causa localizada e um monitor que avise quando a diferença voltar, antes que a queda no painel vire a primeira notícia do problema.