Checklist de Google Tag Manager: 100 pontos para 2026

Há uma pergunta que faço sempre que entro numa conta nova e que quase ninguém responde de imediato: “quem publicou a última versão do contentor e o que é que mudou?” O silêncio diz-me tudo. O Google Tag Manager decide o que é medido no teu site, e por isso é também onde os erros custam mais caro, porque não partem nada visível. O site continua bonito, as páginas carregam, e só três meses depois é que reparas que metade das conversões nunca chegou a lado nenhum. Esta checklist de Google Tag Manager tem 100 pontos de verificação.

Escrevi a primeira versão deste guia em 2020. Desde então mudaram três coisas que obrigam a reescrever tudo: o consentimento passou a condicionar o disparo das etiquetas, as etiquetas do lado do servidor deixaram de ser luxo de empresa grande, e o Universal Analytics desapareceu. Se andas a seguir uma checklist de Google Tag Manager escrita antes de 2024, estás a validar um contentor que já não existe.

Como usar esta checklist de Google Tag Manager

Percorre por ordem. Não é uma lista de compras onde escolhes o que te apetece, é uma sequência: o planeamento condiciona a instalação, a instalação condiciona a camada de dados, e a camada de dados condiciona tudo o resto. Se saltares o primeiro bloco e fores direto às etiquetas, vais construir bem em cima de alicerces errados.

Os pontos marcados com (crítico) são os que, sozinhos, deitam o trabalho ao lixo. Um contentor sem código em todas as páginas mede metade do site. Uma etiqueta que dispara antes do consentimento é um problema legal, não um problema de analítica. Um evento de compra sem identificador de transação enche o relatório de receita duplicada.

Uma nota antes de começares: isto assume que tens acesso de publicação ao contentor e alguém do lado do desenvolvimento que consegue mexer no código do site. Sem as duas coisas, cumpres talvez metade dos pontos. Trata disso primeiro, porque um contentor onde só o marketing mexe e ninguém pode alterar o site está condenado a soluções remendadas.

1. Planeamento antes de tocares no contentor

É a parte que toda a gente salta e que separa um contentor limpo de um contentor que ninguém percebe ao fim de dois anos. O bloco mais aborrecido desta checklist de Google Tag Manager é também o que te poupa mais horas.

  • Existe uma conta por organização e um contentor por site, sem contentores partilhados entre domínios que nada têm a ver uns com os outros.
  • A conta está associada a um email da empresa e não à conta pessoal de um freelancer que passou por lá em 2021.
  • Há pelo menos duas pessoas com permissão de publicação, para o caso de uma sair ou perder o acesso.
  • As permissões estão atribuídas por função: quem só consulta tem leitura, quem constrói tem edição, e a publicação fica reservada a duas ou três pessoas.
  • Existe um plano de medição, nem que seja uma folha de cálculo, com a lista de eventos, o nome de cada um e os parâmetros que transporta.
  • Cada evento do plano está ligado a um objetivo de negócio concreto e não a “seria interessante saber”.
  • Está definido quem é o dono da medição e quem é o contacto técnico do lado do site.
  • Sabes que ferramentas vão viver dentro do contentor e quais ficam de fora por decisão consciente.
  • Existe um registo de alterações onde fica escrito quem pediu o quê e porquê.

2. Instalação do código no site

Parece o ponto mais trivial e é onde encontro mais problemas em auditorias. O código tem duas partes e cada uma tem o seu sítio: a primeira, em JavaScript, no cabeçalho, o mais acima possível; a segunda logo a seguir à abertura do corpo da página. Trocar a ordem funciona quase sempre, e “quase sempre” é precisamente o problema.

  • A primeira parte do código está no cabeçalho, antes de outros scripts de terceiros (crítico).
  • A segunda parte está imediatamente a seguir à abertura do corpo (crítico).
  • O código está em todas as páginas, incluindo as que ninguém se lembra: obrigado, erro 404, checkout, área de cliente, páginas de campanha criadas à pressa (crítico).
  • Confirmaste com o Tag Assistant que o contentor carrega em cada um desses tipos de página, e não só na página inicial.
  • O identificador do contentor é o mesmo em todo o lado e não há um segundo contentor esquecido a disparar em paralelo (crítico).
  • Se existem subdomínios, está decidido se usam o mesmo contentor e se a medição entre eles é contínua.
  • O código não está a ser injetado por um plugin e por código manual ao mesmo tempo, o que duplica tudo (crítico).
  • Em pré-produção o contentor não é o mesmo de produção, ou então o tráfego interno está excluído.

3. Preparar o site para ser medido

Um contentor só é tão bom quanto o site que tem por baixo. Metade dos pontos que falham em auditoria falham aqui, no código do site, e não na plataforma. É também a parte da checklist de Google Tag Manager que precisas de levar a quem trata do site, porque sozinho não a resolves.

  • Os elementos importantes (botões de conversão, formulários, passos do checkout) têm identificadores únicos e estáveis (crítico).
  • Esses identificadores não mudam quando o site é atualizado, porque não dependem de classes geradas pelo construtor de páginas.
  • Os formulários estão preparados para serem seguidos: submissão detetável, mensagem de sucesso identificável e um evento próprio quando o envio é assíncrono.
  • A informação adicional que interessa medir está exposta em atributos próprios, como o tipo de formulário, o plano escolhido ou a posição do botão na página.
  • Se o site é de página única, existem eventos próprios a marcar cada mudança de vista, porque o carregamento de página não volta a acontecer (crítico).
  • Nesse caso, o endereço virtual usado para cada vista é consistente e legível.

4. A camada de dados

A camada de dados é o contrato entre o site e a medição. Sem ela, o Tag Manager adivinha a partir de texto de botões e classes de CSS, e no dia em que alguém mudar “Comprar” para “Finalizar compra” a tua conversão desaparece sem aviso. Nenhuma checklist de Google Tag Manager séria trata isto como opcional.

  • O objeto da camada de dados é declarado antes do código do contentor, para não haver eventos perdidos no arranque (crítico).
  • Toda a informação é enviada por acrescento e nunca por reatribuição da variável, que apaga o que lá estava (crítico).
  • Cada envio tem um nome de evento claro, em minúsculas e com sublinhados.
  • Os dados do utilizador que fazem sentido medir (sessão iniciada, tipo de cliente, escalão de plano) estão disponíveis na camada de dados.
  • Nenhum dado pessoal identificável circula na camada de dados: nada de email em texto simples, nome, telefone ou morada (crítico).
  • Se precisas de identificar o utilizador para medição avançada, o valor segue transformado, nunca em bruto.
  • No comércio eletrónico, o objeto enviado inclui identificador de transação único (crítico).
  • Inclui o valor da encomenda, a moeda e a distinção clara entre valor com e sem portes e impostos.
  • A lista de produtos traz identificador, nome, categoria, preço unitário e quantidade de cada item.
  • O identificador de produto é o mesmo que existe no catálogo e no feed, para as listas cruzarem.
  • O evento de compra dispara uma única vez por encomenda, mesmo que o cliente recarregue a página de obrigado (crítico).
  • Existe limpeza do objeto entre envios, para não ficarem produtos colados ao evento seguinte.
  • Os passos intermédios (ver produto, adicionar ao carrinho, iniciar checkout, dados de pagamento) estão todos a enviar.
  • Os valores numéricos vão como números e não como texto com símbolo de euro.

5. Consentimento antes de disparar etiquetas

Este bloco não existia na versão de 2020 e hoje é o primeiro que verifico. Uma etiqueta que dispara antes de o utilizador dizer que sim não é um defeito de analítica, é uma exposição legal. Os reguladores europeus têm sido consistentes: recusar tem de ser tão fácil como aceitar.

  • Existe uma plataforma de gestão de consentimento a funcionar em todas as páginas.
  • O aviso permite recusar com o mesmo número de cliques com que permite aceitar (crítico).
  • Nenhuma etiqueta de analítica ou de publicidade dispara antes de haver decisão do utilizador (crítico).
  • O modo de consentimento está ativo e os estados por omissão estão definidos como negados antes da escolha (crítico).
  • Os sinais de armazenamento de analítica, de publicidade, de dados do utilizador e de personalização são todos atualizados quando a escolha é feita.
  • A atualização acontece na mesma página em que o utilizador clica, sem esperar por novo carregamento.
  • Cada etiqueta tem as definições de consentimento configuradas e não ficaram todas no valor por omissão.
  • Testaste os três cenários (aceitar tudo, recusar tudo, aceitar em parte) e sabes o que dispara em cada um (crítico).
  • Depois de recusar, confirmaste que não ficam cookies de terceiros no navegador.
  • A decisão persiste entre páginas e entre sessões, e o aviso não reaparece a cada clique.
  • Existe uma forma visível de o utilizador mudar de ideias e retirar o consentimento.
  • A política de privacidade reflete as ferramentas que estão mesmo dentro do contentor, e não uma lista copiada de outro site.

6. Nomenclatura de etiquetas, acionadores e variáveis

Contentores sem convenção tornam-se ingeriíveis. Já abri contentores com 180 etiquetas chamadas “GA4 evento”, “GA4 evento (novo)”, “GA4 evento final v2”. Quem criou aquilo percebia; mais ninguém. Esta parte da checklist de Google Tag Manager não melhora a medição num único dia, mas decide se daqui a um ano ainda consegues trabalhar naquilo.

  • Existe uma convenção de nomes escrita e acessível a quem mexe no contentor.
  • As etiquetas seguem sempre a mesma ordem: plataforma, tipo, ação, como em “GA4 – Evento – Formulário de contacto”.
  • Os acionadores dizem o que fazem e em que condição, e não “acionador 3”.
  • As variáveis têm prefixo que identifica a origem: camada de dados, código personalizado ou constante.
  • As pastas agrupam por plataforma ou por projeto.
  • Não existem etiquetas em pausa há mais de seis meses à espera de “um dia talvez”.
  • Não existem acionadores órfãos sem etiqueta associada.
  • Os valores repetidos em várias etiquetas vivem numa constante e não copiados à mão.

7. Versões, espaços de trabalho e testes

Publicar direto para produção porque “é só uma alteraçãozinha” origina metade dos incidentes de medição que vejo. Usar espaços de trabalho, pré-visualização e versões custa cinco minutos; não usar custa uma semana de dados.

  • Cada conjunto de alterações vive no seu espaço de trabalho e não misturado com o de outra pessoa.
  • Nenhuma alteração é publicada sem passar antes pela pré-visualização (crítico).
  • A pré-visualização foi feita nas páginas reais onde a etiqueta deve disparar, e não só na inicial.
  • Testaste também onde a etiqueta não deve disparar, que é o teste que quase ninguém faz.
  • Testaste em telemóvel e não apenas em computador.
  • Cada versão publicada tem nome e descrição a dizer o que mudou.
  • Já reverteste para uma versão anterior pelo menos uma vez, para não ser a estreia em pleno incidente.
  • As publicações não acontecem à sexta ao fim do dia nem em véspera de campanha.
  • Existe uma exportação recente do contentor guardada fora da plataforma.

8. Ligação ao Google Analytics 4

O Tag Manager é o carteiro, o GA4 é a caixa de correio. Se o carteiro entregar cartas sem remetente nem assunto, a caixa enche e continua inútil. Esta parte da checklist de Google Tag Manager é a que transforma cliques em relatórios que alguém consegue ler numa reunião sem pedir desculpa.

  • A etiqueta base do Google dispara em todas as páginas com o identificador de medição correto (crítico).
  • Existe apenas uma etiqueta base por propriedade, sem duplicações que inflacionam sessões (crítico).
  • Os nomes dos eventos usam minúsculas e sublinhados, sempre com a mesma grafia, porque o GA4 distingue maiúsculas de minúsculas (crítico).
  • Quando existe um evento recomendado pelo Google para aquela ação, é esse o nome usado em vez de um inventado.
  • Os eventos de comércio eletrónico seguem a estrutura esperada pelo GA4 e não um formato à medida.
  • Os parâmetros que precisas de ver em relatórios estão registados como dimensões ou métricas personalizadas.
  • O número de dimensões personalizadas é gerido com critério, porque o limite existe e chega mais depressa do que imaginas.
  • As conversões principais estão marcadas como eventos-chave e correspondem a ações de negócio.
  • Validaste o disparo no DebugView do GA4 e não só na pré-visualização do Tag Manager (crítico).
  • A lista de referências indesejadas está configurada, para o gateway de pagamento não aparecer como fonte de tráfego.
  • O tráfego interno da empresa está filtrado.
  • A medição entre domínios está configurada, se o percurso do cliente atravessa mais do que um domínio (crítico).
  • Os parâmetros de campanha usados em anúncios e newsletters seguem uma convenção escrita e em minúsculas.
  • Comparaste uma semana de encomendas no GA4 com a plataforma de vendas e sabes explicar a diferença (crítico).

9. Etiquetas do lado do servidor

Em 2020 isto era conversa de conferência; hoje é uma decisão de negócio. Com bloqueadores a crescer, navegadores a encurtar a vida dos cookies e etiquetas de terceiros a estragar a velocidade das páginas, mover parte da medição para o servidor deixou de ser exótico. Esta secção serve tanto para implementar como para decidir que ainda não é a tua altura.

  • Já calculaste quanto perdes hoje em eventos que não chegam ao destino, antes de investir em servidor.
  • Há orçamento para o alojamento do contentor de servidor, que é um custo mensal recorrente.
  • Existe alguém com competência técnica para manter aquilo, dentro da empresa ou no fornecedor.
  • Se avançaste, o contentor de servidor corre num subdomínio do teu domínio principal, com certificado válido (crítico).
  • O cliente do GA4 no servidor recebe os pedidos e reencaminha-os para a propriedade certa.
  • O consentimento é respeitado também no servidor, porque mudar a etiqueta de sítio não muda a obrigação legal (crítico).
  • Sabes o que é enviado para cada destino a partir do servidor, e nada segue para terceiros sem base para isso (crítico).
  • Comparaste os números antes e depois da migração, com pelo menos duas semanas em paralelo.
  • A monitorização está ligada, com alerta se o servidor deixar de responder.
  • O site continua a funcionar se o contentor de servidor falhar.

10. Velocidade e manutenção

Um contentor não é um projeto, é um sistema vivo, e cada etiqueta de terceiros é código que não controlas a correr no teu site. Este último bloco garante que daqui a seis meses ainda podes confiar nos números.

  • Sabes quantas etiquetas disparam no carregamento inicial de uma página típica.
  • Nenhuma etiqueta pesada dispara em todas as páginas quando só interessa numa.
  • As que não são necessárias no arranque disparam depois da interação ou com atraso.
  • Mediste o tempo de carregamento com e sem contentor, para saberes o custo real.
  • De três em três meses alguém percorre a lista de etiquetas e apaga o que não serve.
  • As permissões são revistas e os acessos de quem saiu são removidos (crítico).
  • As conversões principais são testadas à mão, ponta a ponta, com um formulário ou encomenda real (crítico).
  • Existe um alerta que avisa quando um evento importante deixa de aparecer nos relatórios.
  • O plano de medição está atualizado com o que existe hoje e não com o que se planeou no ano passado.
  • Sempre que o site é redesenhado, a medição entra no plano desde o início e não na véspera do lançamento (crítico).

Há uma decisão que não se resolve com um visto na caixa: medir no navegador ou no servidor. A tabela abaixo é a que uso para decidir com clientes, sem romantismo técnico.

Etiquetas no navegador ou no servidor: o que muda na prática
Critério No navegador No servidor O que decide
Custo mensal Zero, para além do tempo de quem gere Alojamento recorrente, que sobe com o tráfego Volume de visitas e margem do negócio
Perda por bloqueadores Relevante em públicos técnicos Muito menor, o pedido sai do teu domínio Perfil do público que te visita
Duração dos cookies próprios Encurtada por vários navegadores Definidos pelo servidor, com vida mais longa Ciclo de decisão longo ou compra por impulso
Peso na página Cada etiqueta corre no navegador do utilizador Um pedido, com o processamento fora do navegador Quantas ferramentas de terceiros tens
Controlo sobre os dados O terceiro recebe o que conseguir apanhar Decides campo a campo o que sai Sensibilidade dos dados e exigência jurídica
Manutenção Qualquer pessoa treinada consegue gerir Precisa de competência técnica permanente Existir ou não quem trate disto na equipa
Tempo até funcionar Dias Semanas, com período em paralelo Urgência da campanha que está para arrancar

Desliza a tabela para o lado para veres todas as colunas

Os cinco erros que encontro em quase todos os contentores

Depois de dezenas de auditorias com esta checklist de Google Tag Manager na mão, são sempre os mesmos cinco problemas. Nenhum é difícil de resolver e todos distorcem números que estão a decidir onde vai o orçamento.

  1. Etiquetas a disparar antes do consentimento O aviso aparece, o utilizador ainda não clicou, e a etiqueta de publicidade já foi. Acontece porque ficou com o acionador de visualização de página e ninguém tocou nas definições de consentimento. É o ponto mais grave de todos, porque não é só medição errada: expõe a empresa.
  2. Contentores duplicados a somar tudo a dobrar Alguém instalou o contentor no tema, mais tarde outra pessoa instalou por plugin, e ninguém removeu o primeiro. Resultado: sessões duplicadas, taxa de conversão a metade do valor real e uma equipa a discutir se a campanha resultou com base em números inventados.
  3. Medição colada ao texto dos botões O acionador dispara quando o texto do clique é “Pedir orçamento”. Em novembro alguém muda para “Quero um orçamento” para testar a conversão. A conversão sobe no site e desaparece do relatório.
  4. Compras contadas duas vezes A página de obrigado envia o evento sempre que carrega. O cliente recarrega para ver o comprovativo, ou o email de confirmação leva-o de volta ao mesmo endereço. A receita fica acima da real e o retorno da campanha parece melhor do que é.
  5. Ninguém sabe o que foi publicado Versões sem nome, sem descrição, publicadas por quatro pessoas ao longo de dois anos. Quando algo parte, não há como saber o que mudou nem quando. Cinco segundos a escrever uma descrição poupam meio dia de investigação daqui a três meses.

Por onde começar se o tempo for pouco

Se não tens uma tarde inteira para isto, faz estes cinco passos por esta ordem e ficas com oitenta por cento do valor numa hora. O resto da checklist de Google Tag Manager fica para a semana seguinte.

  1. Confirma que o contentor está em todas as páginas e só uma vez Abre o Tag Assistant e percorre cinco tipos de página: inicial, produto ou serviço, contacto, obrigado e uma de erro. Confirma que carrega em todas e que não há dois contentores em simultâneo.
  2. Testa o consentimento nos três cenários Aceita tudo, recusa tudo, aceita só uma parte. Em cada caso, vê o que dispara. Se alguma coisa dispara depois de recusares, para tudo e trata disso antes de mais nada.
  3. Valida a conversão mais importante do negócio Uma só, a que paga as contas. Preenche o formulário ou faz uma encomenda de teste e segue o evento desde o clique até ao DebugView do GA4.
  4. Compara os números com a realidade Pega numa semana e compara as encomendas ou contactos do GA4 com o que existe na plataforma de vendas ou no CRM. Se a diferença for maior do que consegues explicar, tens um problema de medição e não de marketing.
  5. Limpa e documenta Apaga as etiquetas em pausa há meses, remove acessos de quem já não trabalha contigo e escreve uma descrição na próxima versão que publicares.
Quero uma auditoria à minha mediçãoPreenche o formulário. A minha equipa responde por email ou telefone em 24 horas úteis.

Perguntas frequentes sobre Google Tag Manager

Quanto tempo demora a percorrer esta checklist de Google Tag Manager?

Num site pequeno, com poucas etiquetas e sem loja, fazes tudo numa tarde. Num site com comércio eletrónico, vários domínios e campanhas de tráfego pago a correr, conta com dois a três dias, sobretudo por causa dos testes de consentimento e da validação das conversões. Percorrer é rápido; o que demora é corrigir o que ela revela.

Preciso mesmo do Tag Manager ou basta instalar o GA4 diretamente?

Podes instalar diretamente e, se só queres saber quantas pessoas visitam o site, até chega. O problema aparece na segunda ferramenta, no primeiro evento personalizado e no dia em que precisas de mudar algo sem esperar duas semanas pelo programador. A partir daí, esta checklist de Google Tag Manager deixa de ser burocracia e passa a ser a única forma de saberes o que está lá dentro.

O consentimento vai fazer-me perder dados?

Vais perder visibilidade sobre quem recusa, e isso é o sistema a funcionar como deve. O que não podes é usar essa perda como desculpa para disparar tudo à mesma. O caminho é ter um aviso claro, pedir só o que precisas, explicar em linguagem simples para que serve e ligar o modo de consentimento. Uma medição honesta com noventa por cento dos dados é mais útil do que uma medição completa que te põe em risco.

Vale a pena passar as etiquetas para o servidor?

Depende do volume de tráfego, do peso das etiquetas de terceiros e de existir alguém que consiga manter aquilo. Se vendes online com volume relevante e a diferença entre o que a plataforma regista e o que o GA4 mostra já te tira o sono, provavelmente compensa. Se tens um site institucional com dois formulários por semana, o dinheiro está mais bem aplicado noutro sítio.

Com que frequência devo repetir esta verificação?

A lista completa, uma vez por ano ou sempre que o site sofra alterações grandes. Os pontos críticos, de três em três meses. E há um momento em que é obrigatória, sem discussão: antes e depois de qualquer redesenho ou migração de plataforma. É aí que a medição parte, e é sempre semanas depois que alguém repara.

Consigo cumprir isto sem programador?

Uma parte sim. A validação, a nomenclatura, as permissões, os testes de consentimento e a limpeza do contentor fazes sozinho. A camada de dados e os identificadores estáveis nos elementos do site não, e é aí que está o valor real de uma boa implementação. Percorre a checklist de Google Tag Manager primeiro, vê exatamente o que falha, e só depois leva ao desenvolvimento uma lista concreta em vez de um pedido vago para “arranjar o Analytics”.

Categoria :
Analytics e medição

Partilhar :