Histórico de versões do Google Tag Manager: quem alterou o quê e como repor

O que é o histórico de versões do Google Tag Manager?

O histórico de versões do Google Tag Manager é o registo de todas as versões de um contentor: um instantâneo da configuração num dado momento. A Google apresenta as versões como a forma de recuperar de erros, por exemplo ao voltar a uma versão anterior quando algo foi publicado cedo demais.

É criada uma versão sempre que alguém clica em Enviar e escolhe Publicar e criar versão ou Criar versão. Só utilizadores com acesso de aprovação ou superior podem criar versões. Cada contentor novo começa com uma versão inicial chamada "Version 1 - Empty Container".

Para quem gere meios pagos, isto pesa. As conversões do Google Ads e da Meta, os eventos do GA4 e os sinais de consentimento passam muitas vezes pelo GTM. Quando uma versão altera um acionador ou uma variável, os números nas plataformas mudam no mesmo dia, e nada no Google Ads ou no Gestor de Anúncios da Meta explica porquê. A resposta costuma estar na lista de versões.

Como saber quem alterou um contentor do GTM e quando?

Abra Versões na navegação superior. A tabela mostra o número de cada versão, o ambiente, quem a criou, quem a publicou e a data na coluna Publicada. Ao abrir uma versão, vê as etiquetas, os acionadores e as variáveis que alterou.

O GTM distribui o histórico por vários sítios, e cada um responde a uma pergunta diferente:

Há ainda um sítio que muitas equipas esquecem. As definições da própria etiqueta Google (no GA4 ou no Google Ads) têm um separador de histórico próprio, com ID da alteração, tipo, data e quem publicou. Essas edições nunca aparecem nas versões do GTM, por isso convém verificar os dois quando uma etiqueta começa a comportar-se de outra forma.

Como comparar duas versões do GTM?

O GTM compara alterações elemento a elemento, e não versões inteiras lado a lado. Abra uma versão, clique numa etiqueta, acionador ou variável da lista de alterações e o GTM mostra esse elemento comparado com a versão mais recente no momento em que a versão foi criada.

Antes de publicar, a lista Alterações no espaço de trabalho faz o mesmo com o rascunho: o menu Mais ações de cada elemento mostra o que mudou face à versão mais recente do contentor. Use este passo como revisão, tal como um programador lê as diferenças antes de integrar código.

Para comparar duas versões afastadas no tempo, percorra a lista por ordem. Abra cada versão entre as duas datas e anote os elementos alterados. É mais lento, mas é o método que mostra exatamente que versão introduziu a alteração que procura.

Como repor uma versão anterior do GTM?

Para repor, publique a última versão que funcionava. O GTM volta a colocá-la ativa sem eliminar nada mais recente.

1. Clique em Versões e encontre a última versão que registava as conversões corretamente (use as datas da coluna Publicada e as descrições).
2. Abra-a e leia a lista de alterações para saber o que está a repor.
3. Clique em Ações e depois em Publicar. Se trabalha com ambientes, o menu Ações do ecrã Versões também permite publicar num ambiente específico.
4. Inicie a pré-visualização a partir do espaço de trabalho e confirme no Tag Assistant que as etiquetas principais disparam nos acionadores certos.
5. Registe a reposição (data, hora, número da versão, motivo), porque os dados de conversão passam a ter duas quebras para explicar.

Se só precisa de parte da configuração antiga, use Definir como a versão mais recente. Esta opção substitui o rascunho atual pelo conteúdo dessa versão, para que o possa corrigir e publicar uma versão nova. Avise a equipa antes: o trabalho em curso nesse rascunho é substituído.

Porque é que alterações de etiquetas no GTM estragam as conversões?

A maior parte das quebras de conversão com origem no GTM vem de poucas edições que parecem inofensivas no editor. Exemplos do que procurar na lista de alterações de uma versão:

• Acionadores editados: o caminho da página de agradecimento passou de "/obrigado" para "/obrigado-contacto" e a etiqueta de conversão deixa de disparar.
• Etiquetas duplicadas: é adicionada uma nova etiqueta do GA4 ou do Google Ads enquanto a antiga continua ativa, e as conversões duplicam (ver conversões duplicadas no Google Ads).
• Variáveis alteradas: a equipa de desenvolvimento muda o nome de uma variável da camada de dados e o valor ou o ID da transação chega vazio.
• Consentimento: uma alteração ao banner ou ao modo de consentimento reduz as conversões observadas (ver quebra de conversões com o modo de consentimento).
• Etiquetas pausadas ou eliminadas numa limpeza, sem ninguém verificar quais alimentavam as licitações.

As estratégias de licitação automática aprendem com estes sinais. Uma versão que reduz para metade as conversões registadas pode baixar as licitações durante dias, e um erro de medição transforma-se num problema real de resultados.

Como provar que uma alteração no GTM causou a quebra de conversões?

Coloque todas as alterações dos dias anteriores à quebra numa só cronologia e exclua primeiro a hipótese de medição. Uma versão do GTM publicada no dia em que a métrica mudou é a primeira hipótese, não a conclusão.

1. Fixe a data. Identifique o primeiro dia em que a métrica mudou na plataforma de anúncios e no GA4 (ver como distinguir um problema de medição de uma perda real de tráfego).
2. Liste todas as alterações dos 7 dias anteriores. Versões do GTM com datas de publicação, edições no Google Ads e na Meta, lançamentos no site, atualizações do banner de cookies, alterações no CRM e automatismos das plataformas.
3. Exclua a medição. Se os cliques e as sessões se mantiveram e as conversões caíram, desconfie das etiquetas. Abra a versão publicada mais perto da data, leia a lista de alterações e teste o percurso de conversão na pré-visualização.
4. Teste uma hipótese de cada vez. Exemplo: se a versão 41 alterou o acionador do formulário, reponha esse acionador numa versão nova e veja se as conversões recuperam nos dias seguintes. Não mexa em licitações nem orçamentos na mesma janela.
5. Registe o resultado para que a próxima pessoa não repita a investigação.

O guia para explicar uma quebra de conversões ao cliente mostra como apresentar a conclusão. Para manter estas alterações numa só cronologia, o Changeline importa automaticamente as edições do Google Ads através de uma ligação só de leitura, e a equipa regista à mão as versões do GTM, os lançamentos do site e o resto, com data, responsável e motivo. Pode criar gratuitamente a cronologia de um projeto.

Como nomear versões e gerir espaços de trabalho no GTM?

Dê a cada versão um nome que se perceba seis meses depois sem a abrir. O GTM pede Nome da versão e Descrição da versão sempre que cria ou publica uma; preencha ambos.

Exemplo de convenção: 10-10-2026 | GA4 compra: corrige transaction_id | pedido 214, com uma descrição que liste os elementos alterados e o motivo. Evite nomes como "ajuste" ou "correção".

Regras para espaços de trabalho

• Os contentores normais permitem o espaço de trabalho predefinido mais até 2 adicionais, ou seja, 3 em simultâneo; o Tag Manager 360 permite espaços ilimitados.
• Quando outro espaço de trabalho publica, o seu passa a indicar que está desatualizado. Atualize-o e resolva os conflitos antes de publicar, ou arrisca-se a sobrepor a correção de um colega.
• Um espaço de trabalho por tarefa, com o nome da tarefa, publicado ou eliminado em poucos dias.
• Publique versões pequenas. Uma versão com 25 elementos alterados é difícil de diagnosticar quando as conversões mudam.

O histórico do GTM fica dentro do GTM. O seu registo de alterações de marketing é onde o número da versão, o motivo e o contexto de negócio ficam ao lado das edições de campanhas, sem que quem lê o relatório precise de acesso ao GTM. Se também assinala alterações no analytics, veja as anotações no GA4.