Saltar para o conteúdo

Teste A/B: como fazer sem se enganar com o resultado

A nova versão da página foi ao ar, o painel da ferramenta mostrou “+38%, 96% de chance de ser melhor” no quinto dia, o time comemorou e publicou. Dois meses depois, os leads estão iguais ao que eram antes. Ninguém mentiu. O teste é que foi montado para achar um vencedor, e não para descobrir se havia um. Este guia cobre hipótese, amostra, duração e os três erros que mais fazem um teste A/B mentir, e o que fazer quando o tráfego não dá para testar.

Também chamado:
A/B test, split test, experimento controlado online
Unidade:
diferença na métrica primária (absoluta ou relativa) + intervalo de confiança
Cadência:
por experimento, com duração fixada antes de começar
Por Lucas Adiers Stefanello
Resposta rápida
Teste A/B é mostrar, ao mesmo tempo e por sorteio, duas versões de uma página para grupos diferentes de visitantes e medir qual entrega mais na métrica escolhida antes de começar. Ele só é confiável se quatro coisas forem fixadas antes: hipótese, métrica primária, tamanho de amostra e duração. Os erros que mais enganam são espiar e parar quando ficou “significativo” (peeking), ler vitória no efeito novidade e não conferir se o sorteio dividiu o tráfego como deveria (SRM). Com pouco tráfego, A/B só enxerga mudança grande; aí é melhor testar mudanças grandes, medir um passo mais alto do funil ou usar pesquisa qualitativa.
n por variante ≈ 16 × σ² / δ²

O que é teste A/B

Teste A/B é o jeito mais confiável que existe de saber se uma mudança causou um efeito. A lógica é simples: você sorteia quem vê a versão A (controle) e quem vê a B (variante). Como o sorteio é aleatório, tudo o que muda o comportamento das pessoas (dia da semana, campanha no ar, humor do mercado) cai igual nos dois grupos. A única diferença sistemática é a mudança que você fez. Se a métrica se move, foi ela.

Essa confiança toda depende de o teste ser bem montado, e a maioria das ideias não funciona. No artigo em que a equipe de experimentação da Microsoft descreve sua operação, só um terço das ideias testadas melhorou a métrica que pretendia melhorar.[1] Traduzindo: num time que não testa, boa parte do que vai ao ar é neutra ou piora, e ninguém fica sabendo.

Os termos que aparecem o tempo todo:

  1. Hipótese: “porque observamos X, se mudarmos Y, esperamos que Z aumente”. Sem a observação, é palpite.
  2. Métrica primária: a uma métrica que decide o teste. As outras são de apoio ou de proteção (guardrail).
  3. Efeito mínimo detectável (MDE): a menor diferença que o teste precisa conseguir enxergar. Quanto menor, mais amostra.
  4. Significância (α): a chance que você aceita de declarar diferença quando não existe nenhuma. O padrão é 5%.
  5. Poder estatístico (1 − β): a chance de detectar o efeito se ele existir de verdade. O padrão é 80%.
  6. Intervalo de confiança: a faixa em que o efeito real provavelmente está. “+12%, entre −3% e +27%” é um resultado muito diferente de “+12%, entre +8% e +16%”.

Teste A/B também não é comparação de antes e depois. Pôr a página nova no ar em outubro e comparar com setembro mistura a mudança com tudo o que mudou entre os dois meses. Pode servir de pista; não é teste.

Como calcular a amostra (e a duração)

A regra prática para α = 5% bicaudal e poder de 80% é de Kohavi, Tang e Xu, no livro de referência sobre experimentos online[2], e é a mesma fórmula que o PostHog documenta para a calculadora dele, onde o 16 corresponde a 80% de poder com 95% de confiança.[3] Nela, σ² é a variância da métrica (para uma taxa de conversão p, σ² = p × (1 − p)) e δ é o efeito mínimo detectável em termos absolutos.

δ é absoluto: taxa atual × efeito relativo
n por variante ≈ 16 × σ2 / δ2  ·  σ2 = p × (1 − p)
Números ilustrativos de um site B2B. Página de serviço que converte 2% das sessões em formulário: σ² = 0,02 × 0,98 = 0,0196. Para detectar uma melhora relativa de 20% (de 2% para 2,4%), δ = 0,004 e n = 16 × 0,0196 / 0,000016 = 19.600 sessões por variante, 39.200 no total. Com 6.000 sessões por mês, o teste leva mais de 6 meses. Para detectar 10% (δ = 0,002), são 78.400 por variante: dois anos. Aceitando ver só efeitos de 50% (δ = 0,01), caem para 3.136 por variante, cerca de um mês.

A leitura: com tráfego de site B2B, A/B só enxerga mudança grande. Trocar a cor do botão raramente mexe 50%. Reescrever a proposta de valor, cortar o formulário pela metade ou mudar a oferta, talvez. Para comparação, o exemplo do próprio livro: conversão de 5% e melhora relativa de 5% pedem 121.600 usuários por variante.[2]

A pegadinha do cálculo é usar o MDE relativo no lugar do absoluto. “20%” vira δ = 0,2 e a conta devolve 8 sessões por variante. Parece ótimo e está errado por três ordens de grandeza. Sempre converta: δ = taxa atual × efeito relativo.

Antes de ler qualquer resultado, confira se o sorteio funcionou. É o teste de SRM (sample ratio mismatch): a divisão real entre A e B tem que bater com a planejada, dentro do que o acaso explica.

Checagem de SRM: qui-quadrado sobre a divisão de visitantes
χ2 = Σ (observado − esperado)2 / esperado
Exemplo ilustrativo. Divisão planejada 50/50, 10.000 visitantes: o esperado era 5.000 em cada lado. Chegaram 5.200 e 4.800. χ² = (5.200 − 5.000)² / 5.000 + (4.800 − 5.000)² / 5.000 = 8 + 8 = 16, p ≈ 0,00006. Abaixo do limite de p < 0,0005: a divisão está quebrada e o resultado não deve ser lido até achar a causa.

O limite de p < 0,0005 é o que a Microsoft usa para acusar SRM.[4] Parece rigoroso demais, e é de propósito: com milhares de visitantes, uma divisão que parece “quase 50/50” pode esconder um defeito de sorteio, de redirecionamento ou de coleta.

Benchmarks: o que calibra a expectativa

Teste A/B não tem “taxa boa” de referência. Os números abaixo são parâmetros e achados de quem roda experimento em escala, para calibrar expectativa e montar o teste. Não encontramos dado primário sobre testes em sites B2B brasileiros.

Parâmetro / achadoValorFonte
Ideias testadas na Microsoft que melhoraram a métrica-alvocerca de 1 em 3Kohavi et al., 2013[1]
Experimentos no Google que levaram a mudança no negócio (citação de Jim Manzi)cerca de 10%Kohavi et al., 2013[1]
Duração do placar final na plataforma da Microsoftmúltiplo de semanas, em geral 2 semanasKohavi et al., 2013[1]
Significância e poder padrãoα = 5% · poder = 80%Kohavi, Tang, Xu, 2020[2] · PostHog[3]
MDE padrão sugerido pela calculadora do PostHog30% relativoPostHog[3]
Falso positivo real ao checar a cada observação e parar no primeiro “significativo” (α nominal de 5%)26,1%Evan Miller, 2010[5]
Testes A/B com SRMcerca de 6% na Microsoft · cerca de 10% em parte dos testes do LinkedInMicrosoft Research[4]
Limite de p-valor para acusar SRMp < 0,0005Microsoft Research[4]
Parâmetros de operações de experimentação em escala. Servem para calibrar, não como meta.

Se até a Microsoft acerta uma ideia em três[1], um teste seu que “ganhou” no quinto dia com 30 conversões merece desconfiança antes de comemoração. Espiar e parar cedo transforma 5% de falso positivo em 26%.[5]

Como implementar na prática

Um teste A/B confiável depende menos da ferramenta e mais do que se decide antes de ligar e do que se confere antes de ler. E a métrica que ele lê precisa ser a mesma que já bate com o CRM, senão a variante vence no painel e o comercial não vê diferença.

Onde os dados moram

Sorteio e exposição Ferramenta de experimento (PostHog, Optimizely, VWO, Statsig) ou feature flag no código. Registra quem viu qual versão.
Métrica primária Evento de conversão no analytics (formulário enviado, agendamento), de preferência o mesmo evento que já é auditado contra o CRM.
Qualidade do lead CRM. É onde você confirma que a variante não trouxe mais lead ruim.
Registro do experimento Um documento por teste: hipótese, métrica, amostra, duração, resultado e decisão.

Quem precisa entrar

Marketing / Produto Dono da hipótese e da decisão.
Dev Implementa a variante e o sorteio sem piscar a página. O “flicker”, que mostra A antes de B, também contamina o teste.
Dados / RevOps Calcula a amostra, confere o SRM, lê o resultado e o impacto no CRM.
Comercial Avisa se a qualidade do lead mudou durante o teste.
  1. 1 Escreva a hipótese com a observação que a sustenta: gravação de sessão, dado de funil, fala de cliente.
  2. 2 Escolha uma métrica primária e até duas de proteção, como taxa de lead qualificado e tempo de carregamento.
  3. 3 Calcule amostra e duração antes de ligar. Arredonde a duração para semanas cheias, para cobrir o ciclo da semana. Se passar de 8 a 12 semanas, repense o teste.
  4. 4 Rode um teste A/A quando a ferramenta for nova ou mudar de configuração: as duas versões iguais. Ele deve dar “sem diferença” e dividir o tráfego certo. Se der vencedor ou SRM, o problema está na instalação.[2]
  5. 5 Ligue e não decida no meio. Olhar para achar bug pode; parar porque ficou verde, não. Se precisar olhar e decidir cedo, use uma ferramenta com teste sequencial, feito para isso.[6]
  6. 6 Confira o SRM antes de olhar a métrica. Divisão fora do esperado é resultado inválido.[4]
  7. 7 Leia o intervalo de confiança, não só o p-valor. E segmente com cautela: fatiar por dispositivo, canal e região depois do fato gera “vencedores” por acaso.
  8. 8 Registre a decisão, inclusive quando não deu nada. Teste neutro também é aprendizado: evita que alguém refaça a mesma ideia daqui a seis meses.

Quando o tráfego é pequeno demais para A/B

É a situação da maioria dos sites B2B. A conta de amostra diz “meses”, e o time precisa decidir antes disso. Os caminhos, do mais forte para o mais fraco:

  1. Teste mudanças grandes. Oferta, proposta de valor, estrutura da página. MDE de 30% a 50% cabe no volume de muito site B2B.
  2. Meça um passo mais alto do funil. “Começou o formulário” ou “clicou em agendar” acontece mais que “enviou”. Confirme depois no CRM.
  3. Corrija o que é bug sem testar. Formulário que quebra no celular não precisa de A/B.
  4. Use pesquisa qualitativa. Gravação de sessão, teste de usabilidade com poucos usuários, entrevista com cliente. Não prova causa, mas acha o problema óbvio. É o terreno do CRO, do qual o teste A/B é só uma ferramenta.
  5. Antes e depois com controle. Se não dá para sortear, compare a página alterada com uma página parecida que não mudou, no mesmo período. É evidência mais fraca, e deve ser tratada como tal.

Armadilhas comuns

Estes são os erros que mais aparecem quando revisamos testes que “ganharam” e não mudaram nada no comercial. Quase todos se resolvem antes de ligar o teste.

Espiar e parar quando ficou verde

É o erro mais comum e o mais caro. A ferramenta atualiza o resultado todo dia; em algum dia, por acaso, a variante fica “significativa”; alguém para o teste e publica. O cálculo de significância pressupõe que você olha uma vez, no fim. Olhando todo dia e parando no primeiro verde, o falso positivo sobe muito acima dos 5% prometidos.[5] A gente só aceita parar antes quando a ferramenta usa teste sequencial, desenhado para isso.

Ler o efeito novidade como vitória

Botão novo, layout novo, formato novo: quem já conhece o site clica por curiosidade. Na primeira semana a variante dispara, na terceira volta ao normal. O contrário também existe (efeito de primazia): quem está acostumado estranha a mudança e converte menos no começo. Por isso rodamos pelo menos duas semanas cheias e olhamos a curva do efeito ao longo do tempo, não só o número final. Se o ganho encolhe semana a semana, desconfie.

Não conferir o SRM

Já vi teste “ganhar” porque a variante B tinha um redirecionamento a mais, e o robô de busca e parte dos visitantes com bloqueador caíam só no A. O grupo B ficou menor e mais qualificado por acidente. Nenhum ajuste de estatística salva isso. A divisão se confere antes da conversão; fora do esperado, o teste vai para o lixo.[4]

Trocar a métrica primária depois de ver o resultado

O formulário não mudou, mas “o tempo na página subiu”, então declaram vitória por ele. Com vinte métricas no painel, alguma vai dar diferença por acaso. A métrica que decide é a que foi escrita antes de ligar.

Testar o que o tráfego não consegue medir

O caso típico: página com 3 mil sessões por mês, conversão de 1,5%, e o time quer testar o texto do botão. A conta mostra que levaria mais de um ano para ver 10% de diferença. O teste roda três semanas, dá “inconclusivo” e todo mundo conclui que “teste A/B não funciona aqui”. Funciona, para a pergunta certa. A conta de amostra vem antes de qualquer teste entrar na fila.

Otimizar o formulário e piorar o lead

A variante sem o campo “empresa” converte mais, e o comercial passa a receber mais lead de pessoa física. Se a métrica primária é só “formulário enviado”, o teste declara vitória. Por isso sempre entra uma métrica de proteção ligada ao CRM, como a taxa de lead qualificado ou a stage conversion.

Não rodar A/A na ferramenta nova

Instalação de ferramenta de teste costuma ter algum defeito: script que carrega tarde, evento contado duas vezes numa versão, cookie que muda o grupo da pessoa quando ela volta. O A/A mostra isso antes que um teste de verdade seja decidido em cima de dado torto.[2] Conversão duplicada é uma das causas mais comuns de vencedor falso; os erros comuns no GA4 e o event tracking são o lugar de conferir. Evento perdido no navegador distorce do mesmo jeito (veja rastreamento server-side).

Em tráfego pago, a métrica primária de muitos testes é a própria conversão da campanha, então vale ter as conversões no Google Ads bem definidas antes. E é na landing page que a maioria desses testes acontece.

Checklist de implementação

FAQ

Perguntas frequentes sobre teste A/B

As dúvidas que mais aparecem de quem quer testar sem se enganar.

O que a conta de amostra mandar, arredondado para semanas cheias e nunca menos de duas. A Microsoft fecha o placar em múltiplos de semana, em geral duas.[1] Parar porque “já deu significativo” antes disso é o erro de peeking.

Depende da conversão atual e do tamanho do efeito que você quer ver. Com 2% de conversão, detectar 20% de melhora pede perto de 20 mil sessões por variante (n ≈ 16 × σ² / δ²).[2][3]

É o limite de risco que você aceita de ver diferença onde não existe. Com 5%, em média 1 de cada 20 testes sem efeito real vai parecer ter efeito. Por isso significância sozinha não basta: olhe o intervalo de confiança e o tamanho do efeito.

Sample ratio mismatch: quando a divisão real de visitantes entre A e B difere da planejada além do que o acaso explica. É sinal de defeito no sorteio, no redirecionamento ou na coleta. Com SRM, o resultado não vale.[4]

Para testar a ferramenta, não a página. As duas versões são iguais; o esperado é “sem diferença” e divisão correta. Se aparecer vencedor com frequência, a instalação tem defeito.[2]

Não automaticamente. A “chance de ser melhor” também oscila com o tempo, e parar no primeiro número alto tem o mesmo vício. O que permite olhar e decidir cedo com segurança é um método sequencial, como o do Stats Engine da Optimizely.[6]

Teste mudanças grandes, meça um passo mais alto do funil, corrija o que é bug sem testar e use pesquisa qualitativa. Antes e depois com página de controle é uma alternativa mais fraca, mas melhor que nada.

Pode, num teste multivariante, mas cada combinação divide o tráfego de novo. Em site B2B isso quase sempre deixa o teste lento demais. Uma mudança por vez é o caminho mais seguro com pouco volume.

Um teste só é tão bom quanto a métrica que ele lê

Quando a conversão do site e a venda do CRM estão no mesmo painel, fica claro qual variante ganhou de verdade. O primeiro passo é o Diagnóstico grátis do site, para saber se o site mede a conversão bem o bastante para testar. A plataforma Intelligence da Incuca liga o evento do teste ao CRM e mostra se a variante trouxe lead que vira venda. Se o time não tem braço para montar e rodar os testes, a Incuca faz com vocês.

Conhecer o Intelligence

Referências

  1. [1] Kohavi, R.; Deng, A.; Frasca, B.; Walker, T.; Xu, Y.; Pohlmann, N. Online Controlled Experiments at Large Scale (um terço das ideias melhora a métrica-alvo; ~10% no Google; placar em múltiplos de semana). KDD 2013. https://www.exp-platform.com/Documents/2013%20controlledExperimentsAtScale.pdf
  2. [2] Kohavi, R.; Tang, D.; Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing (regra n ≈ 16σ²/δ², teste A/A). Cambridge University Press, 2020. https://www.cambridge.org/core/books/trustworthy-online-controlled-experiments/D97B26382EB0EB2DC2019A7A7B518F59
  3. [3] PostHog. Running time and sample size (documentação de Experiments: fórmula, 80% de poder, 95% de confiança, MDE padrão de 30%). https://posthog.com/docs/experiments/sample-size-running-time
  4. [4] Microsoft Research. Diagnosing Sample Ratio Mismatch in A/B Testing (6% dos testes na Microsoft, ~10% em parte dos testes do LinkedIn, limite p < 0,0005). Artigo original: Fabijan, A. et al., KDD 2019, https://dl.acm.org/doi/10.1145/3292500.3330722 https://www.microsoft.com/en-us/research/articles/diagnosing-sample-ratio-mismatch-in-a-b-testing/
  5. [5] Miller, E. How Not To Run an A/B Test (falso positivo de 26,1% ao checar a cada observação). 2010. https://www.evanmiller.org/how-not-to-run-an-ab-test.html
  6. [6] Optimizely. Statistical analysis methods overview (Support Help Center; teste sequencial do Stats Engine). https://support.optimizely.com/hc/en-us/articles/39714777161229-Statistical-analysis-methods-overview
Lucas Adiers Stefanello

Sobre o autor

Lucas Adiers Stefanello

Fundador e CEO da Incuca, onde junta dados de marketing, vendas e receita para mostrar onde a empresa perde venda. Trabalha com tecnologia para negócios desde 2013 e coordena a Comunidade Incuca.