Guia: teste A/B via GTM

Rodar teste A/B pelo GTM pode reduzir a dependência do ciclo de desenvolvimento. Para mudanças pequenas, a ideia sai da cabeça e pode ir para o ar no mesmo dia.

Tem também um conjunto de armadilhas que, se você ignorar, produz resultado inválido sem avisar. Este é o roteiro que eu uso, na ordem em que as decisões aparecem.

#Antes de tudo: esse teste deveria ser no GTM?

O GTM roda no navegador, depois que a página já começou a carregar. Isso define o que é razoável fazer.

Funciona bem para mudança de texto, cor, ordem de elementos, exibir ou esconder um bloco, mudar rótulo de botão. Coisas pequenas e visuais.

Funciona mal para mudança acima da dobra em página lenta, alteração que muda a estrutura da página, qualquer coisa que dependa de estado que só o backend conhece, e single page application que redesenha o componente depois que você já mexeu nele.

Se a sua variação está no segundo grupo, o GTM vai te dar dor de cabeça de piscada e de reversão, e a conta sai mais cara que ter feito direto no código.

#O sorteio precisa ser estável

Esse é o ponto onde a maioria das implementações caseiras quebra.

A pessoa precisa cair sempre no mesmo grupo, em toda visita, em toda página. Se o sorteio roda a cada carregamento, a mesma pessoa vê A na home e B no produto, os grupos se misturam e o teste não mede nada.

A forma mais simples é sortear uma vez e guardar:

var KEY = 'exp_pdp_galeria';
var variant = null;

try { variant = localStorage.getItem(KEY); } catch (e) {}

if (variant !== 'a' && variant !== 'b') {
  variant = Math.random() < 0.5 ? 'a' : 'b';
  try { localStorage.setItem(KEY, variant); } catch (e) {}
}

Duas observações. Use uma chave por experimento, com nome do experimento dentro, para não colidir com o próximo. E lembre que localStorage é por navegador: quem troca de dispositivo é sorteado de novo. Isso é contaminação, é inevitável nessa abordagem, e você precisa saber que existe ao ler o resultado.

#A piscada

Como o GTM entra depois do HTML, existe um intervalo em que a versão original aparece antes de a variação ser aplicada. O usuário vê o conteúdo mudar na frente dele.

Isso é feio e, pior, contamina o experimento: quem viu a piscada teve uma experiência diferente de quem não viu, e a piscada acontece mais em conexão ruim, que correlaciona com dispositivo mais fraco, que correlaciona com conversão menor.

Três caminhos, em ordem de preferência:

1. Escolha uma mudança que não pisca. Alterar algo abaixo da dobra resolve o problema sem gambiarra.
2. Dispare no gatilho de Inicialização, não em "Todas as páginas". Inicialização roda antes, e a diferença é perceptível.
3. Esconda o alvo enquanto decide, com um estilo aplicado no começo e removido depois de aplicar a variação. Se você fizer isso, coloque um tempo limite para revelar de qualquer jeito. Um script que falha e deixa a seção escondida para sempre custa mais que a piscada.

#Mande a variante para o dataLayer

Aplicar a variação é metade do trabalho. Sem registrar quem viu o quê, não existe análise.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'experiment_impression',
  experiment_id: 'pdp_galeria',
  experiment_variant: variant
});

Dispare esse evento no momento em que a variação foi aplicada, não no carregamento da página. A diferença importa: se a pessoa saiu antes de o script rodar, ela não participou do experimento e não deveria entrar na conta.

No GA4, um caminho prático é enviar isso como propriedade de usuário além de parâmetro de evento. Como propriedade, o valor mais recente passa a descrever aquele usuário e permite comparar métricas que acontecem várias páginas depois. Use uma propriedade diferente por experimento: uma propriedade genérica de variante seria sobrescrita pelo teste seguinte. E lembre de registrar a dimensão personalizada, senão o valor chega e não aparece em relatório nenhum.

#Antes de olhar quem ganhou, olhe o SRM

Repita comigo: a primeira leitura de um experimento não é o resultado, é o SRM.

Se a divisão deveria ser 50/50 e chegou 53/47 com volume alto, alguma coisa quebrou. Sorteio enviesado, script falhando em um navegador específico, evento de impressão disparando mais em um grupo. Qualquer uma dessas invalida a comparação, porque os grupos deixaram de ser equivalentes.

É um qui-quadrado de trinta segundos. Se der desvio significativo, pare, ache a causa e rode de novo. Ler o vencedor de um teste com SRM é pior que não ter testado, porque você vai implementar uma decisão errada achando que tem evidência.

#Duração combinada antes

Calcule o efeito mínimo detectável com o seu tráfego e a sua taxa base antes de subir qualquer coisa. Se a conta disser que você só detecta ganho de 20% para cima, e a sua mudança é um ajuste de rótulo, o teste não vai responder nada e é melhor gastar as três semanas em outra coisa.

Definida a duração, respeite. Fechar semanas inteiras, sempre, para não carregar dia da semana no resultado. E não pare no dia em que a significância apareceu: parar quando ficou bom transforma o teste numa máquina de achar ruído favorável.

#Limpeza

Teste que acabou sai do container. Não desative apenas: remova. Para apagar a chave do localStorage que já ficou no navegador das pessoas, publique antes uma limpeza temporária com localStorage.removeItem('exp_pdp_galeria'); tirar o código do container, sozinho, não apaga o que já foi salvo.

Container com seis experimentos encerrados ainda pendurados fica difícil de auditar e imprevisível, e é assim que alguém, meses depois, descobre que parte dos usuários ainda está numa variação que ninguém lembra de ter criado.

#Quando parar de usar o GTM para isso

Essa abordagem tem um teto claro. Quando você chega em qualquer um destes pontos, vale mudar de ferramenta ou levar o experimento para o código:

• Precisa de mais de duas variações com divisão desigual
• Precisa segmentar quem entra no teste por critério de servidor
• A piscada não some por mais que você tente
• Vai rodar vários experimentos ao mesmo tempo na mesma página
• Precisa de análise de significância confiável sem montar tudo na mão

Até esse ponto, GTM resolve, e resolve rápido. Depois dele, você está usando um martelo para apertar parafuso.