Pular para o conteúdo

Teste A/B com pouco tráfego

Com o tráfego de uma startup, a maioria dos testes A/B não tem poder estatístico suficiente: você não consegue detectar efeitos pequenos com confiança, então o caminho honesto é testar só grandes mudanças, usar métodos que precisam de menos amostras ou pular o teste. Este guia mostra como saber em qual situação você está — e o que fazer em vez disso.

Atualizado em 8 min de leituraPor fromHello

O essencial

  1. O poder estatístico é a chance de um teste detectar um efeito real. Pouco tráfego traz pouco poder, então só diferenças grandes são detectáveis.

  2. O efeito mínimo detectável (MDE) sobe quando a amostra encolhe — na escala de uma startup, isso costuma significar variações de 20% ou mais, não de 2%.

  3. Os métodos sequenciais e bayesianos reduzem o problema do tamanho da amostra. Não o eliminam.

  4. Muitas vezes a decisão certa é não fazer teste A/B: lance com uma métrica de proteção, faça uma aposta maior ou parta para o qualitativo.

Por que pouco tráfego quebra a maioria dos testes A/B

Um teste A/B compara duas versões e pergunta se a diferença é real ou ruído. Para responder, ele precisa de observações suficientes para separar o sinal do acaso, e as startups raramente as têm. Com algumas centenas de conversões por mês, a matemática diz que você só consegue enxergar diferenças grandes — então o conselho popular de testar tudo leva você a rodar testes que nunca iam chegar a uma conclusão. Escolher os poucos testes que valem a pena é a razão de ser de um roadmap de experimentação.

Poder estatístico e MDE em palavras simples

O poder estatístico é a probabilidade de um teste detectar um efeito real quando ele existe — 80% é a meta habitual. O efeito mínimo detectável (MDE) é a menor melhoria que um teste consegue captar com esse poder, dados a sua taxa de base e o tamanho da amostra. Os dois andam juntos: menos visitantes empurram o MDE para cima. Na escala de uma startup, o MDE costuma ser uma variação relativa de 20% a 50%, não os 2% que a cor de um botão poderia render. Se a sua mudança é menor que o seu MDE, o teste não consegue vê-la em nenhuma janela realista.

Com o tráfego de uma startup, só efeitos grandes são detectáveis — o quadrante em destaque é onde o teste A/B com pouco tráfego funciona de fato. Efeitos pequenos exigem uma escala que você ainda não tem.

Por que só efeitos grandes são detectáveis

O tamanho de amostra necessário cresce mais ou menos com o inverso do quadrado do efeito que você quer detectar, então reduzir o MDE pela metade multiplica por cerca de quatro os visitantes de que você precisa. O próprio exemplo do Optimizely põe números nisso: com uma taxa de base de 10%, detectar um ganho de 3% exige cerca de quinze vezes os visitantes que um ganho de 10% exige. Os efeitos que uma equipe pequena consegue medir com honestidade são, portanto, os de grande porte: uma nova página de preços, um fluxo de onboarding refeito, uma oferta central diferente — não microtextos. Um CRO Specialist passa a maior parte do tempo decidindo quais mudanças são grandes o bastante para valer um teste.

Os testes sequenciais e bayesianos ajudam, um pouco

Os métodos sequenciais deixam você parar cedo quando um resultado é decisivo, com uma matemática feita para resistir a verificações repetidas. O desenho sequencial de Evan Miller pode cortar as observações em 25% a 50% quando o efeito real é grande — e existe justamente para que você não fique espiando um teste de amostra fixa. As abordagens bayesianas informam a probabilidade de uma variante superar a outra em vez de um valor-p, o que é mais fácil de interpretar com o teste em andamento. As duas reduzem o problema do tamanho da amostra. Nenhuma o elimina: se o efeito real é minúsculo, todo método ainda precisa de mais dados do que você tem.

Teste mudanças maiores e não espie o resultado

Duas regras mantêm honestos os testes com pouco tráfego. Primeiro, teste mudanças maiores: escolha variações grandes o bastante para superar o seu MDE e rode um único A/B limpo em vez de uma grade multivariada que divide ainda mais o seu tráfego. Segundo, fixe o tamanho da amostra e a regra de parada antes de começar e não declare um vencedor no primeiro dia em que o resultado parecer significativo — espiar cedo um teste de amostra fixa é o que faz o ruído ser lançado como vitória. Se você roda etapas de divisão automáticas dentro de uma jornada, vale a mesma disciplina: registre de antemão a métrica e o horizonte. Um grupo holdout — uma fatia que você mantém de propósito na experiência antiga — é uma forma simples de conferir se um efeito é real. Equipes pequenas rodam poucos testes, então escolha os que valem a pena e rode-os direito.

FAQ

Perguntas frequentes

  • De quanto tráfego eu preciso para fazer teste A/B?

    Depende da sua taxa de conversão de base e do efeito que você quer detectar, não de um número fixo de visitantes. Como referência aproximada, o guia da VWO cita benchmarks aproximados de menos de ~1.000 visitantes ou de 5 a 10 conversões por semana. Abaixo disso, planeje testar só mudanças grandes ou pule os testes formais.

  • Os testes sequenciais ou bayesianos resolvem o problema de pouco tráfego?

    Ajudam, não resolvem. Os dois podem encerrar um teste mais cedo quando o efeito é grande, mas, se a diferença real for pequena, todo método ainda precisa de dados que você não tem. Eles reduzem o problema do tamanho da amostra em vez de eliminá-lo.

  • Uma startup deve fazer teste A/B?

    Às vezes. Reserve os testes para mudanças grandes o bastante para superar o seu efeito mínimo detectável. Para todo o resto, lance com uma métrica de proteção, junte mudanças pequenas ou use pesquisa qualitativa. Rodar testes sem poder estatístico desperdiça semanas e gera uma falsa confiança.

  • O que é peeking e por que ele é um problema?

    Peeking é verificar repetidamente um teste de amostra fixa e pará-lo no instante em que parece significativo. Isso infla os falsos positivos, porque o ruído cruza o limiar por acaso se você olha vezes suficientes. Fixe de antemão o tamanho da amostra e a regra de parada ou use um método feito para verificações sequenciais.

fromHello é um software de automação de marketing de código aberto: mensagens acionadas pelo que as pessoas fazem.

O fromHello Cloud está disponível em acesso antecipado pela lista de espera.

Acesso antecipado

fromHello Cloud

Ninguém empreende para ficar pequeno.

O acesso antecipado ao fromHello Cloud é liberado em etapas. O onboarding é assistido: ajudamos você a configurar tudo e a trazer seus contatos.

Vamos avisar você por e-mail quando sua vaga for liberada. Sem spam.

Ainda não quer entrar? Ver no GitHub