Teste A/B no WooCommerce: o guia completo
Como fazer teste A/B no WooCommerce: cache de página, blocos x shortcode, qual métrica usar por etapa e a conta de amostra que decide o que dá para testar.
📚 Este artigo faz parte do guia Otimização de Checkout: o Playbook de Teste A/B.
Fazer teste A/B no WooCommerce não é diferente de fazer em qualquer loja, exceto por quatro detalhes que só aparecem numa instalação WordPress e que derrubam a maioria dos primeiros testes: o cache de página, a convivência entre o checkout em blocos e o checkout clássico, os conflitos entre plugins, e a escolha da etapa a medir. Este guia, parte do playbook de otimização de checkout em e-commerce, cobre os quatro, mostra qual métrica usar em cada etapa da loja, e traz a conta que decide o que dá e o que não dá para testar no seu volume, com calculadora ao vivo e exemplo trabalhado ponta a ponta.
O que muda numa loja WooCommerce
O WooCommerce é um plugin de e-commerce para WordPress, com mais de 7 milhões de instalações ativas segundo o repositório oficial de plugins do WordPress (wordpress.org). Ele não traz motor de experimentação embutido, então o teste sempre vem de fora, por um dos dois caminhos:
| Caminho | Como funciona | Vantagem | Armadilha principal no WordPress |
|---|---|---|---|
| Client-side por snippet | Uma tag no cabeçalho troca o conteúdo no navegador do visitante | Instala em minutos, não depende de deploy | Cintilação se a tag carregar tarde; depende de JavaScript |
| Server-side em PHP | Um hook sorteia a variação antes de montar a página | Sem cintilação, funciona com JavaScript desligado | Cache de página pode congelar uma variação e servi-la a todos |
A diferença entre os dois modelos está detalhada no guia de teste A/B client-side x server-side. Para a maioria das lojas WooCommerce, o caminho client-side é o único que sai do papel em prazo curto, e a razão é a próxima seção.
Obstáculo 1: o cache de página
Este é o problema número um, e ele é silencioso. Quase toda loja WordPress séria roda com cache de página, seja por plugin, seja por CDN. O cache existe justamente para não executar o PHP a cada visita: ele guarda o HTML gerado uma vez e devolve o mesmo arquivo para as próximas pessoas.
Isso é excelente para desempenho e é fatal para um teste server-side ingênuo. Se o seu código sorteia a variação em PHP e o cache guarda a primeira resposta gerada, todo mundo passa a receber aquela variação. O teste continua “rodando” no painel, e a divisão real de tráfego já não é a que você configurou.
Existe teste server-side correto convivendo com cache: basta que a chave do cache inclua a variação, ou que a decisão aconteça na borda, antes de o cache responder. Isso é trabalho de infraestrutura, descrito no guia de como implementar teste A/B server-side. O erro é rodar o teste sem tratar o cache e confiar no relatório.
Independentemente do caminho escolhido, existe uma verificação obrigatória no primeiro dia: olhar a divisão real de visitantes entre as variações. Uma divisão que deveria ser 50/50 e aparece como 68/32 não é azar, é um defeito de instrumentação, e o teste inteiro fica inválido enquanto ele não for corrigido.
Obstáculo 2: checkout em blocos x checkout clássico
Segundo a documentação do WooCommerce, lojas iniciadas a partir do lançamento da versão 8.3, em novembro de 2023, já vêm com os blocos de Carrinho e Finalização como experiência padrão, sem necessidade de configuração (WooCommerce, Cart and Checkout Blocks as Default). Lojas mais antigas normalmente continuam com o checkout clássico, montado por shortcode.
Para o teste, a consequência é direta: as duas versões geram HTML diferente. Um seletor de CSS escrito olhando o checkout clássico simplesmente não encontra nada no checkout em blocos, e o teste roda sem nunca aplicar a variação, produzindo um empate perfeito que parece resultado e é defeito.
Antes de escrever qualquer variação, confira qual das duas a sua loja usa e escreva o seletor contra a estrutura real da página. Se você administra mais de uma loja, não reaproveite o seletor entre elas sem conferir.
Obstáculo 3: conflito de plugins e visitante logado
Duas particularidades de WordPress fecham a lista de armadilhas técnicas.
A primeira é o conjunto de plugins. Uma loja WooCommerce típica roda dezenas deles, e vários mexem no mesmo lugar em que o seu teste mexe: otimizadores de checkout, plugins de campos personalizados, de frete, de popup. Quando dois códigos alteram o mesmo elemento, quem aplica por último ganha, e o resultado varia por ordem de carregamento. O sintoma é a variação “às vezes aparecer”.
A segunda é o visitante logado. Administradores, editores e clientes recorrentes logados costumam ver o site com barra de administração, cache desativado e às vezes preços diferentes. Incluir esse público no teste contamina os dois lados de forma desigual. A regra prática é excluir usuários logados com papel administrativo do experimento, e decidir conscientemente se clientes logados entram ou não, documentando a escolha.
A conta que decide o que dá para testar
Aqui está a parte que resolve a objeção mais comum de lojista: “a minha loja é pequena demais para testar”. Quase sempre a frase está errada, e o que está errado é a etapa escolhida para medir.
Considere uma loja com 6.000 visitas por semana e uma taxa de conversão geral de 1,8% (visita até pedido). Querendo detectar um ganho relativo de 20%, a 95% de confiança e 80% de poder, a amostra necessária é de 23.507 visitas por variação, o que leva 55 dias.
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Ajuste a calculadora acima para taxa base 1,8, efeito mínimo detectável 20 (relativo) e 6.000 visitantes por semana para reproduzir esse número. Quase dois meses é um prazo que a maioria das lojas não aceita, e é aí que o time desiste ou, pior, para o teste na metade.
Agora mude a etapa medida. A mesma loja tem 1.200 inícios de finalização por semana, e 45% deles viram pedido. Testar uma mudança dentro do checkout, medindo a taxa de conclusão a partir do início da finalização, com um ganho relativo de 10%, exige apenas 1.931 visitantes por variação, o que leva 23 dias.
Aproximação normal de duas proporções, divisão igual entre as variações. A data usa o seu fuso e recalcula ao vivo.
| Desenho | Taxa base | Volume que alimenta | Amostra por variação | Duração |
|---|---|---|---|---|
| Loja inteira, visita até pedido, ganho de 20% | 1,8% | 6.000 visitas/semana | 23.507 | 55 dias |
| Etapa de checkout, início até pedido, ganho de 10% | 45% | 1.200 inícios/semana | 1.931 | 23 dias |
A diferença não vem de mágica estatística, vem de duas coisas ao mesmo tempo: taxas base altas exigem amostras muito menores para o mesmo ganho relativo, e o funil filtra justamente quem já demonstrou intenção. Testar dentro do checkout é o caminho de menor custo de amostra em quase toda loja pequena e média.
O contrapeso honesto: medir a etapa não é o mesmo que medir o negócio. Uma mudança que melhora a conclusão do checkout pode, por exemplo, aumentar a taxa e reduzir o ticket médio se ela empurra o cliente a finalizar mais rápido. Por isso a receita por visitante entra sempre como métrica de guarda, mesmo quando a métrica primária é a etapa.
Qual métrica usar em cada etapa da loja
| Onde está a mudança | Métrica primária | Métricas de guarda |
|---|---|---|
| Página inicial e categorias | Taxa de visita a página de produto | Receita por visitante, taxa de saída |
| Página de produto | Taxa de adição ao carrinho | Receita por visitante, taxa de devolução quando disponível |
| Carrinho | Taxa de início de finalização | Ticket médio, receita por visitante |
| Finalização (checkout) | Taxa de conclusão a partir do início | Receita por visitante, taxa de erro de pagamento |
| Preço, frete e promoção | Receita por visitante | Margem, ticket médio, taxa de conversão |
A regra por trás da tabela: quanto mais perto a métrica primária estiver da mudança, mais rápido o teste fecha, e quanto mais longe ela estiver do dinheiro, mais indispensável fica a métrica de guarda. A página de produto e o carrinho ganham tratamento detalhado no guia de teste A/B de página de produto e no de carrinho abandonado.
Passo a passo para o primeiro teste
- Escolha a etapa com maior perda absoluta. Some quantas pessoas saem em cada passo do funil e ataque o degrau que perde mais gente, não o que parece mais feio.
- Escreva a hipótese antes de abrir a ferramenta. O que muda, por quê, qual métrica primária, qual efeito mínimo que justifica implementar.
- Dimensione antes de rodar. Calcule a amostra e a duração com o tráfego real daquela etapa. Se o resultado for maior do que o prazo aceitável, mude a ambição ou a etapa, nunca o rigor.
- Instale a tag e confira a divisão real. No primeiro dia, olhe se a distribuição bate com o configurado. Confira também em mobile e com um usuário deslogado, em aba anônima.
- Deixe rodar semanas inteiras. Loja tem sazonalidade forte de dia de semana. Encerrar no meio de uma semana compara segunda-feira com sábado.
- Leia com o intervalo de confiança na frente. Estimativa pontual isolada vira promessa que o dado não sustenta, como explicado no guia de significância estatística.
- Implemente a vencedora de verdade no tema ou no plugin. Variação servida por snippet é temporária; o ganho definitivo só existe quando ela vira código da loja.
Erros comuns em teste A/B no WooCommerce
| Erro | Sinal de alerta | Correção |
|---|---|---|
| Ignorar o cache num teste server-side | Divisão de tráfego longe do configurado | Varie a chave do cache por variação, ou use client-side |
| Escrever o seletor para a versão errada do checkout | Empate perfeito e variação que nunca aparece | Confira se a loja usa os blocos ou o shortcode clássico antes de escrever |
| Incluir administradores logados no teste | Poucas sessões com comportamento muito atípico | Exclua papéis administrativos e documente a decisão sobre clientes logados |
| Medir só a conversão geral numa loja pequena | Teste com duração de meses e abandonado no meio | Meça a etapa, com receita por visitante como guarda |
| Encerrar no meio da semana | Resultado que muda de sinal conforme o dia da leitura | Rode em blocos de semanas completas |
| Testar durante promoção grande | Comportamento de compra completamente diferente | Evite períodos atípicos ou trate-os como um teste à parte |
| Rodar três testes no mesmo funil ao mesmo tempo | Resultados que não somam quando implementados | Um teste por etapa, ou desenho fatorial declarado antes |
| Deixar a variação vencedora no snippet para sempre | Ganho depende da ferramenta continuar carregando | Implemente no tema ou plugin e remova o teste |
Faça isso automático na Donnu
A parte difícil de testar numa loja WooCommerce quase nunca é a ideia, é a operação em volta dela: conferir se a divisão de tráfego saiu certa e ler o resultado sem transformar uma estimativa imprecisa em promessa de receita. A Donnu cobre exatamente esse trecho: você cola um snippet que não trava o carregamento da loja, define a métrica, e a Donnu acompanha a divisão real de tráfego, avisa quando ela destoa do configurado e devolve o veredito com o intervalo de confiança de 95% na frente, sem declarar vencedora antes de a variação acumular pelo menos 200 visitantes e 7 dias no ar.
Comece um teste grátis de 14 dias e rode o primeiro teste no degrau que mais perde gente. Para o quadro completo, veja o playbook de otimização de checkout e a lista de ferramentas de teste A/B para WordPress.
Referências
- WooCommerce. Cart and Checkout Blocks as Default. Documentação oficial. woocommerce.com/document/cart-checkout-blocks-status.
- WordPress.org. WooCommerce, página do plugin no repositório oficial. wordpress.org/plugins/woocommerce.
- Google Search Central. A/B testing best practices for Search. developers.google.com/search/docs/crawling-indexing/website-testing.
- Kohavi, R., Tang, D. e Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material complementar em experimentguide.com.
Leia também:
Perguntas frequentes
- O WooCommerce tem teste A/B nativo?
- Não. O WooCommerce é um plugin de e-commerce para WordPress e não traz um motor de experimentação embutido, então o teste vem de uma ferramenta externa: um snippet client-side que troca o conteúdo no navegador, ou uma implementação server-side em PHP com sorteio no servidor. Cada caminho tem uma armadilha própria numa instalação WordPress, e a maior delas é o cache de página.
- Por que o cache de página atrapalha o teste A/B no WooCommerce?
- Porque a maior parte das lojas WordPress serve HTML pré-gerado por um plugin de cache ou por um CDN, e um teste server-side que decide a variação no PHP pode ter a resposta congelada e entregue a todo mundo. O sintoma clássico é uma divisão de tráfego muito diferente de 50/50 no relatório. Testes client-side não sofrem disso, porque o HTML é o mesmo para todos e a troca acontece no navegador depois.
- Dá para testar a página de finalização do WooCommerce?
- Dá, mas o alvo do seletor depende de qual versão de checkout a loja usa. Segundo a documentação do WooCommerce, lojas criadas a partir da versão 8.3, de novembro de 2023, já vêm com os blocos de Carrinho e Finalização como padrão, enquanto lojas mais antigas costumam usar o checkout clássico por shortcode. A estrutura de HTML das duas é diferente, então um seletor escrito para uma quebra na outra.
- Minha loja tem pouco tráfego. Dá para testar mesmo assim?
- Depende de qual etapa você escolhe medir. A conversão da loja inteira costuma ter uma taxa base baixa e exigir amostra grande: no exemplo trabalhado deste guia, detectar um ganho relativo de 20% sobre uma base de 1,8% leva 55 dias com 6.000 visitas por semana. Já testar dentro do checkout, onde a taxa base é muito maior, resolve em 23 dias com apenas 1.200 inícios de finalização por semana. Mudar a etapa medida muda a viabilidade sem abrir mão do rigor.
- Qual métrica usar num teste de loja WooCommerce?
- A métrica primária tem que ser a mais próxima possível do que a mudança altera, e a receita por visitante deve estar sempre entre as métricas de guarda. Uma alteração na página de produto pede taxa de adição ao carrinho como primária; uma alteração no checkout pede a taxa de conclusão do pedido a partir do início da finalização. Em nenhum dos casos a receita por visitante pode ficar de fora, porque é ela que revela um ganho de volume conquistado com queda de ticket.
- Preciso de um plugin para rodar teste A/B no WooCommerce?
- Não necessariamente. Ferramentas por snippet funcionam colando uma tag no cabeçalho do site, o que pode ser feito por um plugin de inserção de código, pelo tema ou pelo gerenciador de tags. Um plugin dedicado facilita a instalação, mas adiciona mais um item ao conjunto de plugins da loja, e conflito entre plugins é uma das causas mais comuns de comportamento estranho numa instalação WordPress.