Como rodar testes A/B em produto: da hipótese ao rollout

Rodar testes A/B em produto exige um ciclo próprio: formular uma hipótese sobre o comportamento do usuário dentro do produto, implementar a variação server-side atrás de uma feature flag, definir uma métrica primária e guardrail metrics antes de abrir o tráfego, calcular o sample size e a duração mínima, decidir com critérios definidos antes do resultado e fazer o rollout gradual do vencedor. Sem esse ciclo, o time não está experimentando. Está apenas ligando e desligando funcionalidades.

Este guia cobre o processo ponta a ponta, do enunciado da hipótese à abertura para 100% da base. Para o conceito de A/B testing, consulte o que é teste A/B. Para o passo a passo genérico de execução, veja como fazer teste A/B. O foco aqui é o contexto específico de produtos digitais: SaaS, aplicativos, plataformas e marketplaces.

Por que testes em produto rodam server-side

Teste A/B de página muda apresentação: título, cor, ordem de blocos. Teste A/B em produto muda comportamento: regra de negócio, algoritmo de recomendação, fluxo de cobrança, lógica de permissão, ordem de etapas do onboarding. Nenhuma dessas mudanças existe na camada que um snippet de JavaScript no navegador consegue alcançar.

A execução client-side também cobra um preço técnico em produto: flicker na renderização, estado inconsistente entre telas e impossibilidade de testar o que acontece no backend. Quando a variação altera o que o sistema faz, e não só o que ele mostra, a alocação do usuário precisa acontecer no servidor, com persistência por user ID e não por sessão ou cookie.

A comparação detalhada entre as duas arquiteturas está em teste A/B client-side vs server-side. A regra prática: se a hipótese envolve lógica de produto, o teste nasce server-side, dentro do código, controlado por feature flag e integrado à stack de dados do produto. É o modelo descrito pela Statsig ao tratar de experimentação server-side: o ganho é medir com precisão o impacto de mudanças de backend, algo que a camada visual não entrega.

O framework T.R.I.L.H.A

O T.R.I.L.H.A organiza a experimentação em produto em seis etapas encadeadas: Tese, Roteamento, Indicadores, Limite, Hora de decidir e Abertura gradual. Cada etapa tem uma entrega obrigatória. O teste não avança enquanto a entrega anterior não estiver fechada.

T — Tese: a hipótese de produto

Hipótese de produto não é palpite de interface. O formato recomendado tem quatro partes: para segmento, mudar comportamento do produto vai gerar efeito esperado na métrica, porque mecanismo causal. Sem o mecanismo, a hipótese é intestável: mesmo um resultado positivo não ensina nada reutilizável.

Exemplo: para novos usuários do trial, adiantar o primeiro momento de valor para as primeiras 24 horas vai aumentar a ativação, porque usuários que percebem valor cedo têm mais dias úteis para formar o hábito de uso antes do fim do período gratuito. Note que a métrica é comportamental e medida ao longo do tempo, não um clique pontual.

R — Roteamento: exposição controlada por feature flags

A feature flag é a infraestrutura que separa deploy de exposição. O código da variação sobe para produção desligado. A flag define quem vê o quê: controle e tratamento, com alocação aleatória e persistente por user ID. O mesmo usuário precisa cair sempre no mesmo grupo, em qualquer dispositivo, durante todo o teste.

Roteamento mal feito contamina o experimento. Se a alocação muda no meio do caminho ou mistura sessões do mesmo usuário em grupos diferentes, o efeito medido deixa de ser atribuível à variação. A decisão entre construir essa camada internamente ou adotar uma plataforma pronta está em criar ou comprar feature flags.

I — Indicadores: métrica primária e guardrails

Cada teste tem exatamente uma métrica primária, definida antes do início e ligada diretamente à hipótese. Em produto, ela costuma ser de comportamento: ativação, adoção de uma funcionalidade, retenção em uma janela, conclusão de um fluxo central. Métricas secundárias ajudam a explicar o resultado, mas não decidem o teste.

As guardrail metrics protegem o resto do sistema. Um teste pode melhorar a métrica primária e, ao mesmo tempo, degradar latência, elevar taxa de erro, derrubar receita ou aumentar volume de suporte. A Optimizely ilustra o modelo com um caso de SaaS: métrica primária de adoção de funcionalidade acompanhada de guardrails como tempo de uso da plataforma, engajamento com funcionalidades existentes e satisfação do cliente, cada uma com um limite de alerta. Guardrail violada encerra o teste, mesmo com a primária subindo.

A instrumentação desses indicadores depende de uma base de product analytics confiável. Se o evento não é rastreado corretamente hoje, ele não pode ser métrica de teste amanhã.

L — Limite: sample size e duração mínima

O sample size é calculado antes do teste, a partir de quatro parâmetros: taxa atual da métrica primária, efeito mínimo detectável, significância (em geral 5%) e poder estatístico (em geral 80%). Efeito pequeno exige amostra grande. Se o produto não tem volume para detectar o efeito esperado em semanas, a hipótese precisa ser mais agressiva ou a métrica, mais frequente.

A duração mínima deve cobrir ciclos completos de uso do produto, em geral uma a duas semanas inteiras, para absorver diferenças entre dias úteis e fim de semana. E há um erro estatístico clássico a evitar: olhar o resultado todo dia e parar quando der significância. Evan Miller demonstrou no artigo How Not to Run an A/B Test que quem confere o resultado 10 vezes durante o teste precisa de uma significância reportada de 1% para obter os 5% reais. Na prática, espiar e parar cedo transforma falso positivo em decisão de produto.

H — Hora de decidir: critérios definidos antes do resultado

A regra de decisão é escrita antes de o teste abrir. O formato básico tem três saídas. Se a métrica primária melhora com significância e nenhuma guardrail é violada, o vencedor avança para rollout. Se a primária piora ou alguma guardrail rompe o limite, a variação é revertida. Se o teste fecha sem significância após atingir o sample size planejado, o resultado é inconclusivo: registra-se o aprendizado e itera-se a hipótese.

Resultado neutro não é fracasso de processo. É a distribuição esperada. No artigo The Surprising Power of Online Experiments, publicado na Harvard Business Review em 2017, Ron Kohavi e Stefan Thomke relatam que, na Microsoft, cerca de um terço dos experimentos melhora as métricas pretendidas, um terço é neutro e um terço piora os resultados; no Google e no Bing, apenas 10% a 20% dos testes geram resultado positivo. Um programa de experimentação em produto existe justamente porque a intuição acerta menos do que parece.

A — Abertura gradual: o rollout do vencedor

Vencer o teste não significa abrir para 100% da base no mesmo dia. O padrão recomendado é o progressive rollout: a GrowthBook descreve a rampa típica de 5% para 25%, depois 50% e só então 100%, monitorando sinais de produção em cada estágio. A feature flag continua ativa durante toda a subida e funciona como kill switch: se erro, latência ou suporte disparam, a exposição volta a zero em minutos, sem novo deploy.

Só depois de estável em 100% o código do controle é removido e a flag, aposentada. Flag esquecida vira dívida técnica e risco operacional.

Exemplo brasileiro: o trial da AURUM

A AURUM, legaltech brasileira dona da plataforma Astrea, aplicou exatamente esse desenho no trial de 10 dias do produto. O problema era estrutural: os clipes jurídicos, insumo central do sistema, podiam levar até 48 horas para aparecer após o cadastro, e o usuário levava até três dias para chegar ao momento de valor.

O time de growth tratou o trial como programa de experimentação dentro do produto, com feature flags, rollout controlado e métricas de guarda. No primeiro experimento, redesenhou a primeira experiência inteira, com a desistência no onboarding como guardrail metric. O resultado foi um aumento de 105% na taxa de ativação. Três experimentos encadeados ao longo de um ano levaram a ativação do trial de 1% para 4%, um crescimento de 300%. O detalhamento do case, com as imagens dos testes, está em case AURUM: experimentação no trial.

O padrão do case é o ponto central deste guia: a hipótese era sobre comportamento dentro do produto, a exposição era controlada por flags, cada experimento tinha métrica primária e guarda próprias, e o ganho foi acumulado em ciclos sucessivos, não em um teste isolado.

Erros que derrubam testes em produto

Abrir o teste sem sample size calculado e encerrar por calendário ou pressão de roadmap.
Alterar a alocação da flag ou o conteúdo da variação no meio do experimento.
Declarar vencedor no primeiro pico de significância, o problema de peeking descrito por Evan Miller.
Medir só a métrica primária e ignorar guardrails de erro, latência, retenção e receita.
Testar várias mudanças de uma vez e não conseguir atribuir o efeito a nenhuma delas.
Pular o rollout gradual e abrir o vencedor para toda a base sem kill switch.

Experimentação em produto é disciplina de engenharia e de decisão, não recurso visual. O time que domina o ciclo completo — hipótese, roteamento, indicadores, limite, decisão e abertura — transforma cada release em aprendizado medido. O que não é medido dessa forma é aposta.

Revisão: Taciana Serafim, fundadora e CEO da CRO Brasil.

Última atualização: novembro de 2026.

Fontes

Kohavi, R. e Thomke, S. — The Surprising Power of Online Experiments, Harvard Business Review (2017): https://hbr.org/2017/09/the-surprising-power-of-online-experiments
Miller, E. — How Not to Run an A/B Test: https://www.evanmiller.org/how-not-to-run-an-ab-test.html
GrowthBook — Feature Flags 101: The Ultimate Guide for Product and Engineering Teams: https://www.growthbook.io/blog/what-are-feature-flags
Optimizely — Understanding and Implementing Guardrail Metrics: https://www.optimizely.com/field-notes/articles/understanding-and-implementing-guardrail-metrics
Statsig — Enhance Web Application Performance with Server-Side Testing: https://www.statsig.com/perspectives/enhance-web-application-performance-with-server-side-testing

Perguntas frequentes

Teste A/B em produto precisa de feature flag?

Sim. A feature flag é o que separa deploy de exposição, garante que cada usuário fique sempre no mesmo grupo e funciona como kill switch durante o rollout. Sem flag, não há como controlar quem vê a variação de forma persistente por user ID.

Qual a diferença entre métrica primária e guardrail metric?

A métrica primária decide o teste: é uma só, definida antes do início e ligada à hipótese. As guardrail metrics protegem o resto do sistema — latência, taxa de erro, retenção, receita, volume de suporte — e, se violadas, encerram o teste mesmo com a primária melhorando.

Por que testes de produto rodam server-side?

Porque a hipótese envolve lógica de produto: regra de negócio, algoritmo, fluxo de cobrança, onboarding. Essas mudanças vivem no backend e um snippet client-side não as alcança. A execução no servidor também evita flicker e estado inconsistente entre telas.

Quanto tempo deve durar um teste A/B em produto?

O suficiente para atingir o sample size calculado antes do início e cobrir ciclos completos de uso, em geral uma a duas semanas inteiras. Encerrar antes, no primeiro pico de significância, infla falsos positivos, como demonstra o artigo de Evan Miller.

O que fazer quando o teste fica inconclusivo?

Registrar o aprendizado e iterar a hipótese. Dados relatados na Harvard Business Review mostram que, na Microsoft, cerca de um terço dos experimentos tem resultado neutro. Inconclusivo faz parte da distribuição normal de um programa de experimentação.

A comunidade CRO Brasil reúne profissionais de CRO, produto e growth que praticam experimentação em produto no dia a dia. Para trocar experiências sobre testes server-side, feature flags e rollout, conheça a CRO Brasil.