O experimento que prova qualquer coisa (inclusive o que você quer ouvir)
Se você trabalha com produto há mais de seis meses, já viu isso acontecer:
O time lança um A/B test.
O dashboard mostra +12% de conversão.
Todo mundo comemora.
Duas semanas depois… o resultado desaparece.
O problema não é o A/B testing. O problema é como interpretamos dados sob pressão.
Em ambientes com metas agressivas, política interna e necessidade constante de justificar roadmap, é extremamente fácil usar dados para confirmar hipóteses e, não para testá-las.
Como product manager ou head de produto, seu papel não é “provar que estava certo”. É reduzir incerteza com rigor estatístico e clareza estratégica.
Neste artigo, vamos aprofundar:
Os principais erros que distorcem A/B tests
Como evitar armadilhas estatísticas clássicas
Como estruturar experimentos robustos
Um checklist prático para seu time nunca mais se autoenganar
O que é A/B Testing (de verdade)
A/B testing é um experimento controlado onde você compara duas versões de uma variável (A vs B) para medir impacto em uma métrica definida.
Mas aqui vai a definição que realmente importa:
A/B testing é um mecanismo de tomada de decisão sob incerteza estatística.
Ele não serve para validar opiniões. Ele serve para estimar probabilidades.
Onde product managers se enganam
1. Parar o teste quando “já está ganhando”
Esse é o erro mais comum.
Você olha o dashboard no terceiro dia e vê:
Variante B: +18%
p-value < 0.05
E decide encerrar.
O problema?
Você fez peeking, analisou o experimento antes do tempo adequado.
Quanto mais você olha antes do tamanho de amostra correto, maior a chance de falso positivo.
Resultado: você implementa algo que não tem efeito real.
2. Testar múltiplas coisas ao mesmo tempo
Alterar:
Título
Cor do botão
Copy
Layout
E depois concluir:
“A nova versão performa melhor.”
Mas… qual variável causou o impacto?
Sem isolamento de variável, você não está fazendo ciência. Está fazendo tentativa e erro com estatística.
3. Ignorar tamanho de amostra
Rodar experimento com:
300 usuários (número tirado da cabeça)
Alta variabilidade
Decisão baseada em 7 conversões de diferença
Isso não é estatisticamente confiável.
Antes de rodar qualquer experimento, você precisa calcular:
a. Baseline da métrica
O que é?
É o desempenho atual da sua métrica antes do experimento.
Exemplo:
Taxa de conversão atual do onboarding: 30%
Retenção D7 atual: 22%
Taxa de upgrade: 8%
Esse número é seu ponto de partida.
Por que isso importa?
Porque todo cálculo de amostra depende do baseline.
Se sua conversão é 5%, detectar um aumento para 6% é muito mais difícil do que sair de 40% para 41%.
Quanto menor a métrica, maior a variabilidade relativa.
Exemplo prático
Você quer testar uma nova copy no checkout.
Baseline atual: 30% de conversão
Se você não sabe esse número com precisão (média histórica consistente), seu cálculo de amostra já nasce errado.
Sem baseline confiável, você está testando no escuro.
b. Minimum detectable effect (MDE)
O que é?
É o menor impacto que você quer (ou consegue) detectar com o experimento.
Em outras palavras:
Qual é o menor ganho que realmente vale a pena para o negócio?
Exemplo
Se sua conversão é 30%, você pode definir:
MDE = +1% absoluto (30% → 31%)
Ou +5% relativo (30% → 31,5%)
Agora vem o ponto estratégico:
Se você define um MDE muito pequeno (ex: 0,5%), o tamanho de amostra necessário explode.
Se define um MDE muito grande (ex: +20%), pode ignorar ganhos relevantes.
A pergunta que um Head de Produto deve fazer:
Qual é o impacto mínimo que move a agulha do negócio?
Isso conecta estatística com estratégia.
c. Poder estatístico (Statistical Power)
O que é?
É a probabilidade de detectar um efeito real quando ele realmente existe.
Normalmente usamos 80% ou 90%.
Se você escolhe 80% de poder, significa:
Se a mudança realmente gera o impacto definido no MDE, temos 80% de chance de detectá-lo.
O risco aqui
Se o poder for baixo:
Você pode descartar uma melhoria real.
O experimento termina como “inconclusivo”.
O time perde confiança em experimentação.
Analogia simples
Imagine um detector de metais.
Baixo poder = detector fraco → deixa passar ouro real.
Alto poder = detector sensível → maior chance de identificar algo valioso.
Mas atenção: quanto maior o poder, maior a amostra necessária.
d. Nível de significância (α)
O que é?
É a probabilidade de você aceitar um falso positivo.
Normalmente usamos 5% (0,05).
Isso significa:
Você aceita que 5% dos experimentos “vencedores” podem ser pura sorte.
Traduzindo para a realidade
Se sua empresa roda 100 experimentos por ano:
Estatisticamente, cerca de 5 podem ser falsos positivos.
E isso é normal. Faz parte do modelo.
O problema real
O problema começa quando você:
Faz múltiplos testes simultâneos
Analisa antes da hora
Escolhe a métrica que “ganhou”
Aí o erro de 5% vira 15%, 20%, 30%.
E você começa a implementar ilusões.
Como esses 4 elementos trabalham juntos
Quando você define:
Baseline
MDE
Poder
Significância
Você consegue calcular:
Tamanho mínimo de amostra
Duração estimada do experimento
Critério claro de parada
Sem isso, você não está fazendo A/B testing.
Está fazendo torcida estatística.
Exemplo prático: O falso crescimento
Imagine que seu onboarding converte 30%.
Você testa nova copy e após 5 dias vê:
A: 30%
B: 34%
p-value = 0.04
Você implementa.
Após 1 mês, a taxa volta para 30%.
O que aconteceu?
Provavelmente:
Amostra insuficiente
Efeito sazonal
Segmentação não balanceada
Variabilidade natural
Você confundiu ruído com sinal.
Boas práticas de A/B testing para PMs estratégicos
1. Defina hipótese clara
Não é:
“Vamos ver se melhora.”
É:
“Se alterarmos X, esperamos que Y aumente porque Z.”
Estrutura:
Mudança específica
Métrica primária
Racional comportamental
2. Tenha UMA métrica primária
Evite:
Métrica principal
6 métricas secundárias
Escolher a que deu melhor
Isso é cherry-picking estatístico.
3. Calcule amostra antes
Use calculadoras estatísticas ou ferramentas dedicadas.
Nunca defina tamanho de amostra depois de ver resultado parcial.
De uma olhada nessas duas calculadoras que eu encontrei:
4. Rode o teste pelo ciclo completo do comportamento
Se seu produto tem padrão semanal, não rode por 3 dias.
Se há sazonalidade mensal, considere isso.
5. Documente experimentos
Times maduros constroem histórico de:
Hipótese
Métrica
Resultado
Conclusão
Aprendizado
Isso evita repetir erros.
Erros comuns
Usar A/B test para justificar roadmap já decidido
Isso não é experimentação.
É validação política.
Não considerar impacto sistêmico
Um experimento pode melhorar conversão e piorar retenção.
A métrica local pode prejudicar a métrica global.
Quando NÃO usar A/B Testing
Mudanças muito pequenas com impacto irrelevante
Funcionalidades estruturais grandes
Problemas com pouca amostra
Quando o custo do experimento é maior que o aprendizado
Nem toda decisão precisa de experimento.
Checklist prático para não se enganar
Antes de rodar:
Hipótese clara
Métrica primária definida
MDE definido
Tamanho de amostra calculado
Critério de parada definido
Período mínimo respeita ciclo comportamental
Durante:
Não olhar resultado antes da hora
Não mudar escopo no meio
Garantir randomização correta
Depois:
Validar consistência por segmento
Avaliar impacto sistêmico
Documentar aprendizado
Conclusão: Dados não eliminam viés, eles amplificam se você não tiver método
A/B testing é uma ferramenta poderosa.
Mas sem rigor, ele vira apenas uma forma sofisticada de confirmar crenças.
Product Managers maduros entendem que:
Estatística não é opinião.
Resultado positivo não significa causalidade.
Velocidade sem método gera ilusão de aprendizado.
O verdadeiro diferencial competitivo não é testar mais.
É testar melhor.
Se você quer construir autoridade como PM ou Head de Produto, comece aqui:
Transforme experimentação em disciplina, não em torcida organizada.
Porque dados não mentem.
Mas pessoas interpretam errado.
E produto é, acima de tudo, decisão sob incerteza.