Uma tag que não dispara é um dos problemas mais comuns de quem configura rastreamento. Você publica o container do Google Tag Manager, abre a página, e o Tag Assistant ou o GA4 não registram o evento esperado.

O caminho para resolver começa em separar quatro sintomas que costumam ser tratados como um só: o Tag Assistant não conecta à página, a tag não é encontrada na página, a tag funciona no Preview mas não no site ao vivo, e a tag é encontrada e publicada mas não dispara na sessão. Cada um tem causas diferentes, e misturá-los é o que faz a pessoa mexer no código quando o defeito está em outro lugar. Este guia mostra como identificar qual é o seu caso e o passo a passo para achar a falha dentro do Tag Assistant.

O Tag Assistant e o modo de visualização do GTM são a mesma interface

Antes de diagnosticar, vale desfazer uma confusão básica. Quando você clica em Visualizar no GTM, o que abre é o Tag Assistant, e ele conecta o rascunho do seu container a essa sessão de diagnóstico. O modo de visualização do GTM e o Tag Assistant não são duas ferramentas separadas, são a mesma interface, iniciada de dentro do Tag Manager.

A ferramenta na web, em tagassistant.google.com, é essa mesma interface de diagnóstico. Para ler o que acontece no navegador, ela pode contar com a extensão unificada do Tag Assistant, mas a extensão é opcional no caso comum. Ela é necessária em situações específicas: tags que rodam dentro de um iframe, pop-ups, abas ou janelas novas e depuração de várias abas ao mesmo tempo. Na página comum, a sessão conecta sem ela.

Isso importa para o diagnóstico. Se você está numa versão antiga da extensão, ou no Tag Assistant Companion, que está sendo aposentado, parte do comportamento pode não corresponder à documentação atual. O Tag Assistant unificado mais a ferramenta na web são o caminho atual; a extensão legada já foi descontinuada.

Por onde começar: quatro sintomas diferentes

A maior parte do tempo perdido acontece porque a pessoa trata os quatro sintomas como se fossem um só. Antes de culpar a tag, identifique qual é o seu.

O Tag Assistant não conecta à página

A sessão de visualização não abre, ou abre sem dados. As causas costumam ficar fora da sua tag: a permissão da extensão não dá acesso ao site, o parâmetro de debug quebra o carregamento da página, um CSP bloqueia o script de diagnóstico, ou um firewall ou proxy corta a conexão. O defeito aqui é de conexão, e mexer na tag não ajuda.

A tag não é encontrada na página

O Tag Assistant conecta, mas não lista a tag esperada. As causas: o snippet não está na página, ou está alterado; você está testando a URL ou o domínio errado; a tag carrega tarde demais para o momento da leitura; ela roda dentro de um iframe ou numa página AMP que a leitura comum não cobre; ou um redirecionamento troca a página antes da leitura terminar. A tag pode existir, mas não estar onde a ferramenta procura.

A tag funciona no Preview, mas não no site ao vivo

A tag aparece e dispara no modo de visualização, mas no site ao vivo não faz nada. Esse é o sintoma mais fácil de confundir com defeito de tag. A causa, quase sempre, é o container não ter sido publicado. O Preview executa o rascunho que você está editando, então a tag nova funciona ali; no site ao vivo o navegador carrega a última versão publicada, que ainda não tem a tag. Para confirmar, compare a versão do container em preview com a versão publicada, e publique se a edição ficou só no rascunho.

A tag é encontrada e publicada, mas não dispara na sessão

A tag está na página, faz parte do container publicado, mas não executa naquela sessão. Aqui moram as causas avaliadas em tempo real: o gatilho não foi satisfeito, o consentimento está segurando a tag, uma exceção de gatilho a cancelou, ou uma variável não tem valor naquele evento. A próxima seção mostra como isolar qual.

Como achar a falha dentro do Tag Assistant

Para o quarto sintoma, o defeito aparece dentro do Tag Assistant, e existe uma sequência de cliques que leva direto a ele.

No painel esquerdo, depois de reproduzir a ação que deveria disparar a tag, selecione o evento certo. Uma tag de compra é avaliada no evento de compra, não no carregamento da página inicial; selecionar o evento errado é o que faz a tag parecer ausente.

Ilustração da lista de tags no modo de visualização do GTM, mostrando uma tag que disparou e uma que não disparou com o gatilho não atendido.
Ilustração da lista de tags no Preview, não é uma captura. A linha que não disparou mostra o gatilho não atendido, não um erro de código.

No resumo do evento, a interface separa Tags que dispararam e Tags que não dispararam. Clique na tag que não disparou. O detalhe mostra os gatilhos de disparo avaliados e qual condição não foi atendida, por exemplo, o gatilho esperava um valor de dataLayer que não chegou, ou uma página que não casou com o padrão configurado.

Se a condição depende de uma variável, abra a aba Variables no mesmo evento. Ela mostra o valor resolvido de cada variável naquele instante. Uma variável marcada como indefinida ali existe no container, mas não encontrou valor no dataLayer, no DOM ou no contexto daquele evento; o problema não é a variável faltar, é a fonte que deveria alimentá-la. É diferente de referenciar uma variável que não existe no container, o que o GTM costuma sinalizar como referência quebrada ao validar.

Se a tag envolve consentimento, abra a aba Consent no evento e confira o estado de cada parâmetro de storage. Uma tag segurada por consentimento aparece aí, e não nas condições do gatilho.

O consentimento é a causa que mais confunde, porque o comportamento esperado parece defeito se você não sabe qual modo está rodando.

No consent mode básico, as tags do Google não disparam enquanto o consentimento está negado. É o bloqueio limpo. No avançado, elas podem carregar mesmo com o storage negado e enviar pings sem cookie. Esses pings podem alimentar a modelagem do Google, mas a modelagem depende da propriedade cumprir requisitos de volume e configuração, então nem todo tráfego negado aparece recuperado nos relatórios. O que cada tag faz depende do tipo de consentimento de cada parâmetro de storage e dos consent checks adicionais. A aba Consent do Tag Assistant mostra o estado de cada parâmetro na sessão, e é ali que se vê se a tag está segurada por consentimento ou por outra coisa. Para confirmar os quatro sinais da V2 nessa aba, o guia sobre como validar o Consent Mode V2 mostra o passo a passo.

Dois defeitos distintos cabem aqui, e a causalidade é o contrário do que parece à primeira vista. Se o consentimento padrão negado é declarado depois das tags carregarem, as tags disparam antes do estado negado ser aplicado, o que leva a coleta antes do consentimento, o oposto do desejado. Se o visitante aceitou mas o consentimento segue negado, o problema não é o default, é o update: ele não ocorreu, foi enviado com valores errados, ou foi processado na ordem errada. São dois consertos diferentes. Escrevi um guia sobre como integrar o banner de cookies ao GA4 e à Meta, onde essa fronteira entre os dois lados costuma quebrar.

Como confirmar o disparo em três etapas

O Tag Assistant mostrar a tag como disparada prova que ela executou, não que o dado chegou ao destino. Para confirmar, siga três etapas, cada uma medindo uma coisa.

O GTM, via Tag Assistant, confirma a execução: a tag rodou sua lógica e tentou fazer o que foi configurada para fazer.

A aba de rede do navegador mostra a requisição do hit, e é preciso conferir o status. Uma requisição concluída, com resposta do endpoint, confirma o transporte. Uma entrada marcada como blocked, com indicadores como bloqueio por CSP ou por extensão, ou failed, indica que a requisição foi impedida antes de sair ou no meio do caminho. Então uma linha na aba de rede é uma tentativa, não uma confirmação de chegada.

O destino confirma o recebimento. Para o GA4, o DebugView mostra cada evento chegando em tempo real. Para o Google Ads, o caminho é o diagnóstico de tags do Ads dentro do Tag Assistant, e não o DebugView, que é uma ferramenta do GA4. Quando as três etapas concordam, o disparo aconteceu de fato. Quando param de concordar, o ponto em que divergem é o problema: execução sem requisição concluída aponta para bloqueio no transporte, e requisição concluída sem recebimento aponta para o destino.

Checklist rápido

Cada item aponta para uma verificação concreta dentro do Tag Assistant ou do navegador.

  • Container publicado? Compare a versão em preview com a publicada antes de qualquer outra coisa.
  • Evento certo selecionado? Escolha no painel esquerdo o evento em que a tag deveria disparar.
  • Tags que não dispararam: clique na tag e leia qual condição do gatilho falhou.
  • Variável indefinida na aba Variables? A variável existe, mas a fonte não alimentou valor naquele evento.
  • Consentimento: na aba Consent, confira se algum parâmetro está negado e segurando a tag.
  • Rede: confira o status da requisição, não só a presença dela.
  • Recebimento: no DebugView do GA4, ou no diagnóstico de tags do Ads.

Quando o server-side ajuda (e o que ele não resolve)

O rastreamento server-side ajuda num caso específico e é honesto sobre o que não resolve.

Ele ajuda quando o hit é cortado no transporte para tráfego que consentiu. Bloqueadores de anúncio e extensões de privacidade impedem requisições que iam direto do navegador às plataformas. Mandar o evento a um endpoint no seu próprio domínio reduz parte desses cortes.

O Safari é um caso à parte e não deve ser lido como um bloqueador de requisições. O Intelligent Tracking Prevention restringe cookies, armazenamento e rastreamento entre sites, e impõe limites até a disfarces de primeira parte via CNAME. O que o server-side pode oferecer nesse terreno é durabilidade maior do cookie quando ele é definido pelo servidor em certas configurações, e não uma neutralização do ITP.

O server-side não resolve o que está antes do transporte. Um gatilho não atendido, uma CMP mal configurada e um evento que nunca chegou ao dataLayer continuam quebrando do mesmo jeito, porque o server-side ainda precisa de um sinal saindo do navegador e ainda tem que respeitar o consentimento. Se o seu problema for gatilho, dataLayer ou consentimento, o conserto é client-side.

Se você já isolou que a perda é no transporte e quer entender a hospedagem de container server-side, o guia sobre o que é o Stape cobre o que ela resolve e quando não vale a pena. Se prefere que alguém monte e valide o seu setup, dá uma olhada nos serviços de rastreamento.