Como escrever um plano de experimentos que evita erros caros

O problema: planos de experimento como cerimônia

Ben Williams, líder de produto e crescimento que trabalhou na Snyk e em empresas que assessora, publicou a versão 2026 de seu tutorial e template de plano de experimentos, com foco nos erros que viu equipes cometerem nos últimos 12 a 18 meses. Para ele, é fácil avaliar a maturidade do processo de testes - e do processo de growth em geral - de uma equipe apenas lendo seus planos de experimento: muitos os tratam como documentos que apenas marcam caixa e dão sensação de rigor.

Antes de preencher qualquer template, ele propõe uma pergunta inicial: será que este caso precisa mesmo de um experimento? Situações em que não faz sentido incluem alta confiança que torna a implementação de baixo risco, tráfego insuficiente na superfície de produto para aprender em prazo aceitável, perguntas mais de 'por quê?' do que de 'o quê?', e ausência de uma hipótese bem formulada.

Estrutura do plano, seção por seção

O template começa com resumo e objetivo de aprendizado (mudar X para o grupo U, melhorar a métrica Y sem prejudicar Z) e a hipótese, que deve ser baseada em dados, não opiniões. Williams usa o formato de hipótese nula (H₀) e alternativa (H₁), lembrando que o teste reúne evidência contra a hipótese nula, não prova a alternativa. A seção de evidência deve documentar analytics, replays de sessão, entrevistas e pesquisa competitiva - planos com evidência bem documentada, segundo ele, ganham mais adesão de stakeholders. Experiência exige descrição clara dos grupos controle e teste, com capturas de tela.

A seção de targeting (onde, quem, quando de assignment e exposure, como dividir o tráfego) recebe atenção especial. Williams destaca a distinção entre assignment (o sistema decide a variante, geralmente cedo, para evitar flicker) e exposure (o momento em que o usuário realmente alcança a divergência). Apenas usuários expostos devem entrar na análise: se só 10% dos atribuídos chegam à mudança, o tamanho de amostra necessário sobe na ordem de cem vezes. Ele alerta que a maioria dos SDKs registra exposure no momento em que a variante é pedida, não vista, e recomenda verificar se o evento dispara nos dois ramos e se o banner de consentimento não está filtrando a população do experimento - o que não invalida a randomização, mas torna o resultado válido apenas para quem aceita rastreamento.

Métricas, estatística e regras de parada

Na hierarquia de métricas, a primária é a única que decide o desfecho estatístico; guardrails são testadas separadamente e podem bloquear a implementação; métricas de monitoramento dão contexto e nunca sustentam decisões. Ele adverte que, com nível de significância de 5%, testar muitas métricas gera falsos positivos - cerca de 1 em 20 por puro acaso - e recomenda manter a lista de guardrails curta.

O desenho estatístico inclui baseline, desvio padrão, potência (ex.: 80%), significância (ex.: 5%), MDE e amostra/runtime necessários. O MDE deve ser igual à menor mudança que valeria a pena implementar. Nas regras de parada, ele alerta que olhar resultados de um teste de horizonte fixo múltiplas vezes infla a taxa de falsos positivos; quem precisa de leitura antecipada deve usar métodos sequenciais ou always-valid, e os thresholds de guardrail devem ser acordados com stakeholders antes do lançamento.

Pré-lançamento, limitações e decisão

Um checklist de pré-lançamento cobre verificação de ambas as variantes em produção, eventos chegando ao analytics, split de tráfego conferido (inclusive 24 horas depois) e ausência de outros lançamentos na mesma superfície. Williams cita o sample ratio mismatch como assassino silencioso da validade: quando o split real difere do especificado, tudo à jusante é não confiável mesmo com dashboards aparentemente normais.

Limitações conhecidas devem ser escritas antes do lançamento - declaradas antes, são restrições aceitas por todos; depois, parecem desculpas. O framework de decisão prevê ações para cada desfecho (rejeitar H₀ com guardrails ilesos, rejeitar com guardrail prejudicado, não rejeitar com amostra adequada ou insuficiente, resultado negativo), mais um plano de comunicação com stakeholders. Por fim, a seção de resultados documenta desfecho estatístico, validade e interpretação, com cuidado terminológico: significância estatística não 'prova' a hipótese, e falhar em rejeitar H₀ não prova ausência de efeito.

Ele conclui que rigor e clareza em cada seção sustentam decisões melhores e uma cultura de experimentação - como ocorreu em seu período na Snyk - e disponibiliza o template completo em Notion.