Google Tag Manager para Teste A/B: Guia de Configuração

Configurar o Google Tag Manager (GTM) para um teste A/B é o passo que liga a divisão de tráfego da sua ferramenta de teste ao GA4 e teste A/B: sem essa ponte, o GA4 não sabe qual variação cada visitante viu. Este guia mostra a configuração completa e real, peça por peça: o gatilho de evento personalizado que escuta o dataLayer, as variáveis de camada de dados que leem o nome do experimento e da variação, a tag do tipo Evento do GA4 que junta as duas pontas, a nomenclatura que evita confusão entre testes, como testar tudo no modo de Preview antes de publicar o container e o erro mais comum que distorce a contagem: disparar o evento antes de a variação terminar de carregar.

Por que o Google Tag Manager entra entre o teste A/B e o GA4

O caminho mais comum na prática não é escrever gtag() direto no código da página: é usar o GTM como camada intermediária, porque isso separa “o que disparar” de “onde a lógica de negócio mora”. A peça central continua sendo a mesma coberta no guia de rastreamento de eventos de teste A/B no GA4: um evento customizado carregando o nome do experimento e da variação. A diferença é que, com o GTM, essa configuração vive num container gerenciado visualmente, com Preview antes de publicar e histórico de versões, em vez de ficar espalhada dentro do código-fonte do site.

O dataLayer, o array global que tanto o GTM quanto o gtag.js leem para receber eventos e variáveis, é o ponto de encontro entre as duas partes. O seu snippet de teste A/B (ou a ferramenta de teste que você usa) empurra algo como o exemplo abaixo assim que a variação é decidida para aquele visitante:

A partir desse push, três peças dentro do GTM precisam se encaixar: um gatilho que escuta esse evento, variáveis que leem os dois parâmetros e uma tag que envia tudo para o GA4. As próximas seções cobrem cada peça.

Gatilho de evento personalizado: como o GTM escuta o dataLayer.push

Segundo a documentação oficial do Google Tag Manager sobre eventos personalizados, um gatilho do tipo Evento personalizado monitora a camada de dados à procura de um nome de evento específico: quando algo empurra esse nome via dataLayer.push, o GTM reconhece e dispara as tags associadas a esse gatilho. A configuração pede um campo de Nome do evento, onde você digita exatamente o valor que o seu dataLayer.push usa (no exemplo acima, experiment_impression).

Existe também uma opção de correspondência regex: ligada, ela permite casar o campo com um padrão em vez de exigir igualdade exata, o que é útil quando você quer que um único gatilho cubra vários nomes de evento relacionados (por exemplo, experiment_impression e experiment_click do mesmo teste) sem duplicar a configuração.

Para o caso deste guia, o mais comum é manter a correspondência exata (regex desligado) e usar um único nome de evento, como experiment_impression, reaproveitado por todos os testes A/B do site. Isso simplifica a auditoria: um gatilho, um nome, todas as tags de teste A/B dependuradas dele.

Variáveis de camada de dados: lendo experiment_name e variation_name

O gatilho decide quando disparar; as variáveis decidem o que ler. Segundo a documentação oficial do Google Tag Manager sobre tipos de variável, a Variável de Camada de Dados (Data Layer Variable) busca um valor que foi empurrado para o dataLayer via dataLayer.push e o transforma numa variável utilizável em tags, gatilhos e outras variáveis. A configuração pede o Nome da variável de camada de dados, que é a chave exata do objeto empurrado (experiment_name ou variation_name, no exemplo deste guia), e uma Versão da camada de dados, que controla como o GTM interpreta um ponto (“.”) dentro do nome da chave: a versão 1 trata o ponto como parte literal do nome, enquanto a versão 2 o interpreta como acesso a um nível aninhado dentro de um objeto. Nenhum parâmetro deste guia usa ponto no nome, então a escolha entre as duas versões não muda o resultado aqui.

Para o teste A/B, a prática recomendada é criar exatamente duas variáveis desse tipo:

Variável (nome no GTM)	Nome da chave no dataLayer	Lê o quê
DLV - experiment_name	experiment_name	Identificador do teste, ex.: cta_hero_teste
DLV - variation_name	variation_name	Braço visto pelo usuário, ex.: controle, variacao_b

Essas duas variáveis são reutilizadas por todos os testes A/B que passarem a empurrar o mesmo formato de evento: você não precisa criar um par novo de variáveis a cada experimento, só um novo valor para os parâmetros dentro do dataLayer.push de cada teste.

Tag do tipo Evento do GA4: juntando gatilho e variáveis

Com o gatilho e as variáveis prontos, a última peça é a tag que efetivamente envia o evento para o GA4. Segundo a documentação oficial do Google Tag Manager sobre como configurar eventos do Google Analytics, o tipo de tag correto é Google Analytics: Evento do GA4, e a configuração pede três coisas: o ID de mensuração (ou uma tag de configuração do Google já existente na mesma conta, reaproveitada via referência), um Nome do evento (o nome que vai aparecer nos relatórios do GA4, aqui experiment_impression) e, opcionalmente, Parâmetros do evento, uma tabela de nome/valor onde você aponta cada parâmetro para a variável correspondente.

Se você já reaproveita parâmetros entre várias tags do GA4 (moeda, valor, ou os próprios experiment_name/variation_name em múltiplos eventos do mesmo teste), o Google recomenda centralizar isso numa variável de Configurações de evento (Event Settings), em vez de repetir a tabela de parâmetros em cada tag individual.

Boas práticas de nomenclatura

Um teste A/B rastreado errado no GTM quase sempre é um problema de nomenclatura inconsistente, não de configuração tecnicamente errada. Vale fixar uma convenção única antes de criar o segundo teste:

Elemento	Convenção recomendada	Exemplo
Nome do evento	snake_case, minúsculo, fixo para todos os testes	experiment_impression
Nome do experimento	snake_case, descreve a página e a mudança	cta_hero_teste, checkout_frete_gratis
Nome da variação	sempre a mesma lista de valores possíveis	controle, variacao_b, variacao_c
Gatilhos no GTM	prefixo por tipo	Trigger - experimento
Variáveis no GTM	prefixo pelo tipo de variável	DLV - experiment_name
Tags no GTM	prefixo pelo destino	GA4 Event - experimento

Sem espaço, sem acento e sem maiúscula misturada no valor que vai para o GA4: nomes de evento e de parâmetro com espaço ou acento podem ser normalizados de formas diferentes dependendo da camada (GTM, gtag.js, GA4), e a mesma variação acaba aparecendo como dois valores distintos no relatório.

Como testar no modo de Preview antes de publicar o container

Nenhuma configuração de GTM deveria ir para produção sem passar pelo modo de Preview e depuração. Segundo a documentação oficial do Google Tag Manager, ao clicar em Preview no workspace, o GTM conecta o Tag Assistant ao seu site (ainda rodando a versão não publicada do container) e mostra, em tempo real, quais tags dispararam, em qual ordem, e o que impediu ou permitiu cada disparo. O checklist prático para este teste específico:

1. Abra o Preview, conecte no endereço do seu site (ou de um ambiente de homologação) e navegue até o ponto em que a variação do teste A/B é decidida.
2. No painel do Tag Assistant, confirme que o gatilho de evento personalizado aparece como disparado no momento certo, não antes.
3. Clique no evento correspondente e confira, na aba de variáveis, se DLV - experiment_name e DLV - variation_name mostram os valores esperados (o nome do teste e a variação que você está vendo naquela sessão).
4. Confirme que a tag Google Analytics: Evento do GA4 aparece como disparada logo depois do gatilho, com o nome do evento e os dois parâmetros preenchidos.
5. Abra o DebugView do GA4 em paralelo (numa aba separada) e confira que o mesmo evento chega do outro lado com os mesmos valores.
6. Repita o teste alternando manualmente para a outra variação (ou usando uma segunda sessão), para confirmar que o valor de variation_name muda corretamente e não fica travado no primeiro valor visto.

Só depois desse checklist passar é que faz sentido enviar o workspace para publicação. Segundo a documentação do Google, o Preview também permite compartilhar um link de depuração com outra pessoa da equipe, útil quando quem está testando não tem acesso de edição ao container.

Etapa do checklist	O que conferir	Onde olhar
Gatilho disparou	Nome do evento bate, momento certo (depois da variação aplicada)	Painel de resumo do Tag Assistant
Variáveis preenchidas	experiment_name e variation_name com os valores esperados	Aba de variáveis do evento, no Tag Assistant
Tag do GA4 disparou	Tag aparece como “disparada”, logo após o gatilho	Painel de resumo do Tag Assistant
Evento chegou no GA4	Mesmos valores aparecem do outro lado	DebugView do GA4
Variação muda corretamente	variation_name muda entre sessões diferentes	Repetir o Preview trocando de variação

O erro comum: disparar o evento antes da variação carregar

O erro mais frequente nessa configuração não é de sintaxe, é de momento: o gatilho dispara cedo demais, antes de a ferramenta de teste terminar de aplicar a variação na página. Isso costuma acontecer quando alguém usa um gatilho genérico de carregamento de página (como “Todas as Páginas” ou um evento de DOM pronto) em vez de deixar o próprio script de teste A/B disparar o dataLayer.push só depois de decidir e aplicar a variação.

O efeito prático: parte dos visitantes que na verdade viram a variação B acaba contada como controle (ou o parâmetro chega vazio e nem entra na dimensão), o que infla artificialmente o volume do controle e esconde volume da variação, uma distorção parecida com um Sample Ratio Mismatch, só que a causa mora no momento do disparo dentro do GTM, não no sorteio de tráfego da ferramenta de teste. Vale conferir com um verificador de SRM sempre que a divisão de visitantes por variação, no próprio GA4, aparecer torta sem explicação óbvia.

A correção é sempre a mesma: o gatilho de evento personalizado deve escutar um evento disparado pelo próprio script de teste, no momento exato em que ele terminou de decidir e aplicar a variação, nunca um gatilho genérico de carregamento de página que roda numa hora fixa independente do teste. Se a ferramenta de teste A/B que você usa já expõe um callback ou evento de “variação aplicada”, é esse o gancho certo para o dataLayer.push, não o window.onload nem um gatilho de “DOM pronto” solto.

Um exemplo trabalhado, com os números que chegaram ao GA4 via GTM

Suponha que o teste cta_hero_teste rodou com o evento configurado exatamente como este guia descreve, e o relatório de Exploração do GA4 (alimentado pela tag configurada no GTM) mostrou os seguintes números, agrupados pela dimensão de variação: o controle (A) teve 10.000 usuários com o evento experiment_impression e 500 conversões; a variação B teve 10.000 usuários e 575 conversões.

• Taxa de A: 500 ÷ 10.000 = 5,00%. Taxa de B: 575 ÷ 10.000 = 5,75%.
• Melhora relativa: (5,75 − 5,00) ÷ 5,00 = +15,0%.
• Taxa combinada p̄: (500 + 575) ÷ 20.000 = 5,375%.
• Erro padrão: √[0,05375 · 0,94625 · (1÷10.000 + 1÷10.000)] ≈ 0,00319.
• Escore z: (0,0575 − 0,0500) ÷ 0,00319 ≈ 2,35.
• Valor-p (bilateral) ≈ 0,0187.
• Intervalo de confiança de 95% da diferença: aproximadamente +0,125 a +1,375 pontos percentuais.

Com valor-p de 0,0187 (abaixo do corte de 0,05) e o intervalo de confiança inteiro acima de zero, o resultado é estatisticamente significativo: a variação B venceu com uma melhora relativa de 15%. Esse veredito só é confiável, porém, se a auditoria das seções anteriores tiver passado, ou seja, se o evento realmente disparou depois da variação ser aplicada, sem o erro de momento descrito acima inflando um dos dois lados. Confira a mesma conta na calculadora abaixo, colando os números exportados do seu relatório do GA4:

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.

Faça isso automático na Donnu

Tudo o que este guia cobriu (desenhar o evento, configurar gatilho e variáveis, montar a tag do GA4, testar no Preview e não cair no erro de momento que distorce a contagem) é trabalho real de engenharia de tracking, e um erro em qualquer uma dessas peças pode virar semanas de dados contaminados sem ninguém perceber. A Donnu resolve a causa raiz: a divisão de tráfego e o registro de qual variação cada visitante viu acontecem dentro da própria ferramenta, no momento certo, sem depender de um gatilho de GTM configurado à mão nem de uma tag do GA4 apontando para as variáveis certas. O cálculo de significância também sai pronto, sem precisar montar relatório de Exploração nem colar números numa calculadora à parte.

Comece um teste grátis na Donnu e deixe de depender de gatilho, variável e tag configurados manualmente para saber, com confiança, qual variação está ganhando. Se o seu processo de decisão ainda depende do GA4 como fonte de comportamento e receita complementar, o guia completo de GA4 e teste A/B mostra como as duas peças se encaixam.

Referências

• Google. Eventos personalizados no Gerenciador de Tags (gatilho de evento personalizado, correspondência regex). support.google.com/tagmanager/answer/7679219.
• Google. Tipos de variável definidos pelo usuário para web (Variável de Camada de Dados, versões 1 e 2). support.google.com/tagmanager/answer/7683362.
• Google. Configurar eventos do Google Analytics no Gerenciador de Tags (tag Evento do GA4, parâmetros de evento). support.google.com/tagmanager/answer/13034206.
• Google. Configurar a tag do Google no Gerenciador de Tags (ID de mensuração, configurações de evento reutilizáveis). support.google.com/tagmanager/answer/9442095.
• Google. Fazer preview e depurar containers (modo de Preview, Tag Assistant, compartilhamento de link de depuração). support.google.com/tagmanager/answer/6107056.

---

Leia também: GA4 e teste A/B: o guia completo de integração · Como rastrear eventos de teste A/B no GA4 · Verificador de SRM para teste A/B