Experimentação
Antes de aprovar um teste A/B, veja se o seu volume responde alguma coisa
O time quer dividir o tráfego por semanas pra testar duas versões da página. Antes de aprovar, peça a conta que mostra se o seu volume consegue apontar uma vencedora a tempo de servir pra decisão.
O time ou a agência chega com a proposta: testar duas versões da página ou do formulário, dividir o tráfego por algumas semanas e investir horas de produção nisso. Antes de dizer sim, vale perguntar se o volume da sua página consegue apontar a versão melhor enquanto essa resposta ainda serve pra alguma coisa.
A conta fica com quem propôs o teste. O seu papel é pedir essa conta por escrito e ver se o prazo que ela devolve cabe na decisão que você tem pela frente.
O volume só diz algo junto da diferença que importa
Uma página pode ter visita todo dia e mesmo assim demorar demais pra responder ao teste. A conta depende da métrica escolhida, da taxa atual dela e, principalmente, da menor diferença que faria você trocar de versão. Quanto menor essa diferença, mais dados e mais tempo o teste pede, como mostra a documentação de amostra do PostHog.
Na calculadora do PostHog, esse efeito mínimo vem em 30% por padrão. Só que isso é um ajuste de software, e quem sabe o que importa é o seu negócio. Eu pediria pro time justificar: uma melhora desse tamanho mudaria a sua decisão? Se uma diferença menor já bastaria, a amostra precisa ser calculada pra ela, mesmo que a espera cresça.
A ficha que eu pediria antes de aprovar
Peça os oito campos abaixo preenchidos antes de liberar a produção. Você não refaz cálculo nenhum, só confere como um número puxa o outro.
| Campo | O que pedir ao time |
|---|---|
| Resultado escolhido e por quê | Qual métrica decide e como ela se liga ao resultado do negócio. |
| Conversões por mês | Quantas vezes essa métrica acontece entre os usuários elegíveis, com período e fonte. |
| Taxa atual | Conversões divididas pelos usuários elegíveis, no mesmo período. |
| Menor diferença que mudaria a decisão | Em percentual relativo e em pontos percentuais. |
| Amostra por variante | Quantos usuários cada versão exige e com quais parâmetros. |
| Semanas necessárias | Estimativa pelo volume elegível e pela divisão entre versões. |
| Regra de encerramento | Amostra, duração e critério de análise escritos antes do lançamento. |
| O que será feito se der inconclusivo | A decisão que será tomada se nenhuma versão se destacar. |
Se o histórico de acessos e conversões não estiver consolidado, peça isso primeiro. O PostHog recomenda usar dado histórico real em vez de palpite otimista.
Uma conta hipotética mostra o tamanho da espera
Pense numa página inventada só pra fazer a conta: 1.200 usuários elegíveis por mês e 120 formulários concluídos, uma taxa de 10%. O dono quer enxergar uma subida pra 12%, aumento relativo de 20%, ou 2 pontos percentuais.
Pela fórmula que o PostHog publica, com 80% de poder estatístico e 95% de confiança, cada versão precisa de uns 3.600 usuários. Com duas versões, 7.200. Dividindo pelos 1.200 do mês, são seis meses, umas 26 semanas, só pra juntar a amostra.
E isso supondo tráfego constante, todo o público elegível no teste e divisão igual. Se o resultado escolhido for contrato fechado, entra ainda o tempo comercial: numa venda de ciclo longo, o teste termina de coletar e os contatos daquele período podem seguir em negociação.
Mesmo depois disso, não há vencedora garantida. O PostHog avisa que bater a amostra só significa que, se existir um efeito daquele tamanho, a chance de detectá-lo é boa. Não significa que ele vai aparecer.
Quando a conta não fecha, ainda tem saída
A primeira conversa é sobre uma mudança maior, já que as boas práticas do PostHog lembram que testar mudanças pequenas demais atrasa as que importam. Maior na página, e não no número digitado na calculadora pra encurtar o prazo: a proposta precisa explicar por que aquela alteração mexeria no comportamento de quem chega.
Outra saída é medir uma etapa anterior, que acontece mais vezes. Pra avaliar um formulário, eu olharia pedidos qualificados, sem tirar contratos do acompanhamento. Só que o limite fica escrito: o teste responde sobre pedidos qualificados e, sozinho, não prova aumento de vendas.
Dá também pra cortar a proposta pra versão atual contra uma só alternativa. A documentação de distribuição do PostHog diz que cada variante a mais pede mais tráfego, e avisa que, abaixo de 1.000 usuários por variante, a exposição entre os grupos pode diferir até 20%. Leia esse 1.000 como alerta sobre volume baixo, e não como piso que deixa qualquer teste suficiente.
Se nada disso couber, eu consideraria não testar e implantar como decisão reversível, desde que dê pra desfazer com custo aceitável. Ficam registrados o motivo, os sinais acompanhados e a condição pra voltar atrás. Esse acompanhamento ajuda a decidir, mas comparar antes e depois não prova que a mudança causou o resultado.
Combine o fim do teste antes do começo
O PostHog recomenda fixar amostra e duração antes de lançar, porque espiar o painel e encerrar quando o número parece bom leva a decidir cedo demais. Mesmo o teste sequencial, que permite acompanhar o tempo todo, pede amostra planejada antes.
Aprovar um teste sem volume pra decidir custa semanas de tráfego dividido e, no fim, uma conclusão com cara de resposta. E um inconclusivo não diz que as versões são iguais nem que a ideia era ruim. Diz que a pergunta segue aberta.
Na próxima proposta, use a ficha pra combinar com o time qual decisão os dados vão sustentar e até quando ela serve. Se a espera passar desse ponto, devolva pra ajuste antes da produção. Pra discutir o que mudar na própria página, a próxima leitura é página de vendas curta ou longa.
