Como Escrever uma Hipótese de Teste A/B (Template Grátis)

Uma hipótese de teste A/B é a frase que liga uma evidência a uma mudança, um efeito esperado e a métrica que vai julgar esse efeito. “Vamos só testar” não é uma hipótese: é um chute que ainda não decidiu o que está tentando provar, nem como vai saber se provou. Este guia entrega o template exato, dois exemplos trabalhados com números reais e a ponte entre a hipótese e o dimensionamento do teste.

Sem uma hipótese escrita, o teste vira um espelho: qualquer variação de número no painel parece “confirmar alguma coisa”, porque ninguém definiu antes o que contaria como confirmação. É esse buraco que gera a maior parte dos resultados que ninguém consegue explicar seis meses depois, quando alguém pergunta “por que essa mudança funcionou mesmo?” e a resposta é apenas um encolher de ombros.

O que é uma hipótese de teste A/B (e o que não é)

Uma hipótese forte tem quatro peças amarradas: a evidência que motivou a ideia, a mudança concreta que você vai implementar, o efeito que essa mudança deve causar e a métrica que vai decidir se o efeito aconteceu. Tire qualquer uma dessas peças e a frase deixa de ser testável.

O que não é hipótese:

• “Vamos testar um botão maior.” Não diz por quê, nem o que conta como sucesso.
• “Acho que o checkout está confuso.” É um diagnóstico, não uma previsão. Falta a mudança e a métrica.
• “Vamos redesenhar a página inteira e ver o que acontece.” Mistura tantas variáveis que, mesmo se a conversão subir, ninguém vai saber qual peça causou o quê.

Se você já leu o guia completo de teste A/B, sabe que a hipótese é o passo que separa “rodar um teste” de “rodar um teste que ensina alguma coisa”. Um teste sem hipótese escrita pode até declarar um vencedor, mas não deixa nenhum aprendizado reaproveitável para a próxima página.

O template de hipótese que funciona de verdade

A estrutura mais usada em times de CRO e produto segue esta ordem: evidência, mudança, efeito, métrica. Ela funciona porque obriga você a escrever a métrica primária antes de ver qualquer dado, o que fecha a porta para escolher a métrica depois, na base do “deu vitória em algum lugar”.

Um exemplo curto para fixar a estrutura: “porque observei que 40% dos usuários abandonam o formulário de cadastro no campo de telefone (dado), acredito que tornar esse campo opcional (mudança) vai aumentar os cadastros concluídos (efeito), medido pela taxa de conclusão do formulário (métrica)”. Note que a frase já entrega, de graça, a métrica primária e a direção esperada. Ninguém precisa adivinhar o que conta como vitória depois que o teste termina.

Este é o mesmo esqueleto usado no pilar de teste A/B e no passo a passo de como rodar um teste do zero, onde escrever a hipótese é a etapa 2, logo depois de mapear o funil e antes de desenhar a variação.

Os 3 ingredientes de uma hipótese forte

Além da estrutura da frase, uma hipótese só é forte se cada peça passar num teste de qualidade. Os três ingredientes que separam uma boa hipótese de uma vaga:

Ingrediente	Pergunta que valida	Sinal de alerta
Evidência real	Esse dado veio de analytics, gravação de sessão, pesquisa ou suporte, e não de opinião?	“Acho que…” sem nenhum número por trás
Mudança causal isolada	Dá para apontar exatamente qual elemento mudou, e só ele?	Redesenho amplo, várias mudanças juntas
Métrica primária única	Existe uma métrica, definida antes de rodar, que decide sozinha o teste?	Duas ou mais métricas “candidatas a vencedora”

Um detalhe que costuma passar batido: evidência não precisa ser um número grande de um relatório de BI. Uma gravação de sessão em que cinco usuários clicam num elemento que não é clicável já é evidência qualitativa suficiente para justificar uma hipótese. O que não vale é pular direto da opinião para a variação, sem nenhum dado no meio.

Exemplos trabalhados: e-commerce e SaaS

Duas hipóteses completas, cada uma ancorada num dado plausível para o contexto, com métrica primária, secundária e guardrail nomeadas.

E-commerce: frete visível na página de produto

Porque a análise do funil mostrou que a maior queda de visitantes acontece entre “carrinho” e “checkout”, e a pesquisa de saída aponta o custo de frete como motivo recorrente de abandono, acredito que exibir o valor do frete já na página de produto (em vez de só no checkout) vai reduzir o abandono nessa etapa, medido pela taxa de conclusão de compra.

• Métrica primária: taxa de conclusão de compra (visitantes que chegam ao checkout e finalizam).
• Secundária: taxa de adição ao carrinho, tempo até o checkout.
• Guardrail: ticket médio (o objetivo é converter mais, não empurrar frete grátis a qualquer custo de margem).

SaaS: prova social no formulário de cadastro de trial

Porque o analytics mostra que a taxa atual de conversão de visitante para cadastro de trial é de 8% e a pesquisa com usuários que abandonaram cita “não sei se essa ferramenta serve para o meu caso” como objeção recorrente, acredito que adicionar um selo com o número de contas ativas e um depoimento curto ao lado do formulário vai aumentar os cadastros de trial, medido pela taxa de conversão de visitante para trial iniciado.

• Métrica primária: taxa de conversão de visitante para trial iniciado.
• Secundária: tempo até o início do preenchimento do formulário, taxa de campos abandonados.
• Guardrail: taxa de trial para pago (a mudança não pode atrair cadastros de baixa intenção que nunca convertem).

Repare que, nos dois casos, a métrica primária é uma coisa só, escrita antes de rodar qualquer teste, e a guardrail existe justamente para pegar um efeito colateral que a métrica primária sozinha não enxergaria.

Dimensionando os dois exemplos

Cada hipótese acima já carrega um efeito implícito, então dá para calcular a amostra de cada uma com o mesmo motor de estatística deste site. Para a hipótese de SaaS, com a taxa base de 8% e considerando que vale a pena detectar uma melhora relativa de 20% (de 8% para cerca de 9,6%), o cálculo devolve:

• Amostra necessária: 4.921 visitantes por variação.
• Duração estimada: 23 dias, para 3.000 visitantes por semana chegando à página de cadastro.

Já a hipótese de e-commerce, com taxa base de 3% e um efeito relativo de 15%, precisa de bem mais gente (o próximo H2 mostra a conta completa). A diferença não é acaso: taxas de conversão mais baixas exigem amostras maiores para o mesmo efeito relativo, porque há menos “eventos” de conversão para o teste enxergar em cada grupo de visitantes.

Priorizando suas hipóteses: ICE x PIE

Depois de escrever várias hipóteses, você não vai testar todas ao mesmo tempo. Dois frameworks ajudam a decidir a ordem, dando uma nota a cada eixo numa escala combinada (geralmente 1 a 10) e tirando a média ou a soma:

Framework	Eixos	Ponto forte	Ponto fraco
ICE	Impacto, Confiança, Esforço	Rápido de aplicar, bom para backlog grande	Mais subjetivo, depende de quem pontua
PIE	Potencial, Importância, Facilidade	Considera o quanto a página já é otimizada e o volume de tráfego	Exige mais dado prévio de cada página

Um exemplo pontuado com ICE, usando as duas hipóteses acima mais uma terceira ideia (redesenhar o checkout inteiro), cada eixo de 1 a 10:

O guia completo de otimização de conversão detalha os dois frameworks com mais profundidade e quando vale a pena trocar de um para o outro. A regra prática: escolha um framework, aplique com a mesma régua em todas as ideias do backlog e não recalcule a nota no meio do teste só porque o resultado parcial “parece bom”.

Times pequenos, com backlog curto, tendem a se dar melhor com ICE: é rápido de preencher numa planilha e força uma conversa honesta sobre esforço de implementação. Times com muitas páginas de alto tráfego, decidindo onde vale mais a pena colocar a próxima hipótese, costumam preferir PIE, porque o eixo de “importância” já embute o volume de visitantes daquela página específica, e não só o quanto a ideia parece boa no papel.

Erros comuns na hora de escrever a hipótese

Erro	Por que atrapalha	Correção
Hipótese vaga	“Melhorar o botão” não diz o que muda nem como medir	Escreva as quatro peças: evidência, mudança, efeito, métrica
Testar várias mudanças de uma vez	Se o teste ganhar, você não sabe qual peça causou o efeito	Isole uma mudança por hipótese, ou use um desenho multivariado de propósito
Sem métrica primária definida antes	Abre a porta para escolher “a que deu vitória” depois de ver os dados	Escreva a métrica primária na própria hipótese, antes de rodar
Escrever a hipótese depois de ver os dados	Vira justificativa, não previsão; qualquer resultado “confirma” a hipótese	A hipótese trava antes do teste começar, não depois

Esse último erro é o mais silencioso. Times sob pressão de entregar resultado às vezes rodam o teste primeiro e escrevem a hipótese “bonita” depois, para o relatório. O problema é que isso elimina a única coisa que a hipótese deveria fazer: te forçar a prever um resultado antes de saber qual foi.

Da hipótese ao teste: dimensione

Toda hipótese carrega, implícita ou explicitamente, um tamanho de efeito. “Vai aumentar os cadastros” é vago; “vai aumentar os cadastros em pelo menos 15%” é um efeito mínimo detectável (MDE), e é esse número que decide quantos visitantes o teste precisa. Uma hipótese sem MDE declarado tende a rodar por tempo indefinido, sem critério claro de quando parar.

Pegue a hipótese de e-commerce do exemplo acima: a taxa de conclusão de compra atual (o dado que embasa a hipótese) é de 3%, e a equipe considera que vale a pena detectar uma melhora relativa de 15% (ou seja, ir de 3% para cerca de 3,45%). Rodando o motor de amostra deste site para esse cenário (95% de confiança, 80% de poder, teste bilateral), o resultado é:

• Amostra necessária: 24.193 visitantes por variação.
• Duração estimada: 43 dias, considerando 8.000 visitantes por semana chegando à página de checkout.

Ajuste a taxa base, o efeito que a sua hipótese promete e o seu tráfego semanal para ver o que isso significa no seu caso:

Taxa de conversão atual%Efeito mínimo detectávelrelativo (%)absoluto (pp)Confiança909599%Poder8090%Visitantes por semana (total)Testebilateralunilateral

-Visitantes por variação

-Total (2 variações)

-Duração estimada

Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.

Se o número de dias parecer alto demais para o seu tráfego, você tem três saídas honestas: aumentar o MDE (só vale a pena testar mudanças com efeito esperado maior), aumentar o tráfego que chega àquela etapa (subindo no funil), ou aceitar que aquela hipótese específica vai levar mais tempo. O que não vale é encerrar o teste antes da amostra calculada só porque “já deu para ver uma tendência”: é assim que nasce um falso positivo. Para entender por que isso acontece, veja o guia de significância estatística em teste A/B.

E se o resultado confirmar a hipótese?

Vale fechar o ciclo com um número hipotético, só para mostrar aonde essa amostra leva. Se, ao fim do teste de frete visível, o controle tivesse convertido 960 em 12.000 visitantes (8,0%) e a variação, 1.104 em 12.000 (9,2%), o mesmo motor estatístico deste site devolveria um valor-p de aproximadamente 0,0009 e uma melhora relativa de +15%, bem alinhada com o efeito que a hipótese previu. É esse fechamento (hipótese escrita antes, resultado lido depois, sem trocar a métrica no meio do caminho) que transforma um teste em aprendizado reaproveitável, e não só em mais um número solto num painel.

Template grátis e copiável de documento de hipótese

Copie esta tabela para o seu backlog de testes. Uma linha por hipótese, preenchida antes de qualquer código ser escrito:

Hipótese	Mudança	Efeito Esperado	Métrica Primária	Secundária	Guardrail	Responsável	Início / Fim
Porque [dado], acredito que [mudança] vai gerar [efeito]	O que exatamente muda na página	Direção e magnitude mínima esperada (MDE)	A única métrica que decide o teste	O que você vai observar, sem decidir por isso	O que não pode piorar enquanto a primária melhora	Quem acompanha o teste até o fim	Datas planejadas, definidas antes de começar

Preencher as oito colunas antes de configurar a ferramenta resolve, de saída, três dos quatro erros comuns da seção anterior: hipótese vaga, mudança não isolada e métrica escolhida depois dos fatos.

Faça isso automático na Donnu

Escrever a hipótese é o trabalho fácil. O difícil é transformar essa frase num teste dimensionado corretamente, que ninguém encerra cedo demais e que devolve um veredito honesto no fim. A Donnu conecta as duas pontas: você registra a hipótese e a métrica primária, a ferramenta calcula a amostra e a duração para o seu tráfego real, coleta com um snippet que nunca trava a página, e declara o vencedor com estatística bayesiana, sem espiadela inflando o falso positivo.

Comece um teste grátis de 14 dias e leve sua primeira hipótese do papel ao resultado. Se ainda está montando o funil de teste, veja o passo a passo completo de como rodar um teste A/B, e se quer revisar os fundamentos antes, comece pelo guia do que é teste A/B.

Leia também

• O que é teste A/B? O guia completo
• Como fazer um teste A/B passo a passo
• Significância estatística em teste A/B
• Otimização de conversão (CRO): guia completo

Prefere ler em inglês? Read in English.

Referências

• Kohavi, R., Tang, D. & Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoio em experimentguide.com.
• Miller, E. How Not To Run an A/B Test (por que a métrica e a amostra precisam travar antes do teste começar), 2010. evanmiller.org.
• CXL. Conversion Rate Optimization: guias e frameworks de priorização. cxl.com.
• VWO. The Complete Guide to A/B Testing. vwo.com/ab-testing.
• Optimizely. Experimentation e boas práticas de teste A/B. optimizely.com.