A maioria dos testes A/B em e-commerce não gera resultado. Não porque a metodologia não funcione — funciona. Porque as lojas testam as coisas erradas, com volume insuficiente, por tempo curto demais, ou sem saber interpretar os resultados.
Testes A/B bem conduzidos são uma das ferramentas de CRO com maior ROI: permitem tomar decisões baseadas em dados reais do seu público, não em benchmarks de outro setor ou em opiniões de stakeholders.
O que é um teste A/B?
Um teste A/B (também chamado de split test) é um experimento controlado onde uma variante de uma página ou elemento (versão B) é mostrada a uma porcentagem do tráfego, enquanto o restante continua vendo a versão original (versão A). O objetivo é medir qual versão produz mais conversões — pedidos, add_to_carts, cliques num CTA ou qualquer métrica de negócio relevante.
A lógica estatística é simples: com volume suficiente de usuários em cada variante e tempo suficiente para eliminar sazonalidade, a diferença nas taxas de conversão pode ser atribuída à mudança testada, não ao acaso.
O erro mais comum: testar sem hipótese baseada em dados
Testar a cor do botão de compra porque "li num artigo que botão laranja converte mais" é o exemplo clássico de teste sem hipótese. Isso pode até gerar uma vitória estatística, mas raramente tem impacto real na receita.
Testes A/B com resultado real começam com uma pergunta específica, baseada em dados:
Processo correto:
- Analisar o GA4 e identificar a etapa do funil com maior abandono
- Usar heatmaps (Clarity, Hotjar) para entender o comportamento nessa página
- Formular uma hipótese: "Se removermos o campo 'complemento' obrigatório do checkout, a taxa de conclusão do endereço aumentará porque está causando atrito desnecessário"
- Implementar o teste e medir
Hipótese genérica (evitar): "Vamos testar um botão verde"
Hipótese com dados: "Heatmaps mostram que 40% dos usuários mobile não chegam ao botão de compra na PDP — vamos testar fixar o botão na parte inferior da tela"
O que testar primeiro: priorização por impacto
Nem todas as páginas ou elementos têm o mesmo potencial de ganho. A regra geral é testar onde há mais volume de usuários E maior abandono.
Alta prioridade (maior impacto potencial)
- Checkout — etapa de identificação: mostrar checkout como visitante em destaque vs. login primeiro
- Checkout — etapa de pagamento: ordem dos métodos de pagamento, destaque para Pix ou parcelamento
- PDP — botão de compra: texto do CTA, posicionamento acima da dobra, tamanho em mobile
- PDP — informações de frete: mostrar estimativa antes vs. não mostrar
- Carrinho — call to action: texto "Finalizar compra" vs. "Comprar agora" com selos de segurança
Média prioridade
- Ordem dos produtos na página de categoria (relevância vs. margem vs. novidade)
- Layout de prateleiras de cross-sell no carrinho
- Formulário de cadastro: campos opcionais vs. obrigatórios
- Posicionamento de avaliações na PDP
Baixa prioridade (teste raramente gera impacto real)
- Cores de botões sem fundamento em dados comportamentais
- Imagens da homepage sem relação com abandono mapeado
- Mudanças no rodapé ou header
Como calcular o tamanho de amostra necessário
Um erro crítico é encerrar testes antes de atingir significância estatística. Para calcular o tamanho de amostra:
- Taxa de conversão atual: 1,5%
- Melhoria mínima detectável (MDE): 10% (você quer detectar uma melhoria de pelo menos 0,15 pp)
- Significância estatística: 95% (padrão de mercado)
- Poder estatístico: 80%
Com esses parâmetros, você precisará de aproximadamente 25.000 usuários por variante. Se sua loja tem 10.000 sessões por mês e você vai testar 50% do tráfego, serão ~5.000 usuários/variante/mês — o que significa que o teste precisa rodar 5 meses para ser válido.
Regra prática: lojas com menos de 200 pedidos por mês raramente têm volume suficiente para testes A/B com significância estatística. Para essas lojas, implementações diretas baseadas em heurísticas de CRO têm melhor ROI que testes formais.
Ferramentas de teste A/B para e-commerce
| Ferramenta | Modelo | Ideal para |
|---|---|---|
| Google Optimize (descontinuado) | Gratuito | — |
| VWO | Pago (~$200/mês) | Equipes com volume médio-alto |
| AB Tasty | Pago | Enterprise |
| Optimizely | Pago (alto) | Enterprise com times dedicados |
| Convert | Pago (~$700/mês) | E-commerces médio-grandes |
| Feature flags (LaunchDarkly, etc.) | Pago | Testes controlados por feature flag |
Para a maioria dos e-commerces de médio porte, o modelo mais prático é usar feature flags de framework (Next.js, VTEX IO workspaces) para implementar variantes e medir no GA4 usando eventos customizados e segmentos de usuário.
Como medir os resultados no GA4
No GA4, crie um segmento de usuário para cada variante (usando um parâmetro customizado enviado via GTM quando o usuário é atribuído a uma variante) e compare as métricas de conversão entre os segmentos.
O relatório de Exploração de Funil segmentado por variante mostra exatamente onde cada grupo diverge no comportamento — muito mais rico do que simplesmente comparar taxas de conversão finais.
Por que a maioria dos testes "não funciona"
Os motivos mais comuns que invalidam resultados:
- Tempo insuficiente — encerrar após 1 semana com baixo volume
- Peeking — checar os resultados diariamente e encerrar ao ver uma variante "ganhando"
- Sazonalidade ignorada — comparar semana normal com semana de promoção
- Mudanças simultâneas — alterar dois elementos ao mesmo tempo (o que causou a diferença?)
- Métrica errada — medir cliques no botão em vez de pedidos finalizados
Trabalho com CRO baseado em dados em lojas VTEX há 10 anos. Se quiser implementar testes A/B com metodologia correta na sua loja, conheça o serviço de CRO para VTEX ou fala comigo.