Feature Flags x Teste A/B: qual a diferença

Feature flag e teste A/B resolvem perguntas diferentes, mesmo parecendo a mesma coisa de longe. A feature flag é um mecanismo de entrega: um interruptor no código que decide, sem novo deploy, quem vê qual versão de uma funcionalidade. O teste A/B é um método de medição: divide o público em grupos comparáveis e usa estatística para dizer se uma mudança realmente melhora uma métrica, ou se a diferença observada é só acaso. Confundir os dois é um erro caro e comum: times usam uma flag para liberar 50% do tráfego, olham o painel de analytics por cima, “sentem” que o número subiu, e shipam para todo mundo sem nunca ter rodado um teste de verdade.

Este guia separa os dois conceitos com clareza: o que cada um faz sozinho, quando usar só flag, quando usar só teste A/B, e como combinar as duas coisas (que é o padrão que LaunchDarkly, PostHog, Split (agora Harness) e Optimizely descrevem em sua própria documentação) sem perder o rigor estatístico pelo caminho.

Feature flag e teste A/B, em uma frase cada

Uma feature flag (ou feature toggle) é uma condicional no código que liga ou desliga um comportamento em tempo de execução, sem precisar de um novo deploy. Segundo Martin Fowler, no artigo de referência sobre o tema, “feature toggles são uma técnica poderosa, que permite times modificarem o comportamento do sistema sem alterar código”. Ela responde: quem vê o quê, agora.

Um teste A/B é um experimento controlado: divide o tráfego aleatoriamente entre uma versão de controle e uma ou mais variações, mede uma métrica primária em cada lado, e usa um teste estatístico (valor-p, intervalo de confiança, ou uma probabilidade bayesiana) para decidir se a diferença é real. Ele responde: essa mudança funciona, ou foi coincidência?

	Feature flag	Teste A/B
Pergunta que responde	Quem vê o quê, agora?	Essa mudança funciona de verdade?
Natureza	Mecanismo de entrega (deploy/release)	Método de medição (estatística)
Decide com base em	Regra de negócio, risco, permissão	Significância estatística ou probabilidade bayesiana
Precisa de amostra calculada?	Não	Sim
Pode existir sem o outro?	Sim (rollout, kill switch, permissionamento)	Sim (mas normalmente entregue via alguma forma de divisão de tráfego)

A diferença central: controlar exposição x medir efeito

A forma mais direta de guardar a diferença: flag controla exposição, teste A/B mede efeito. Uma flag pode expor uma funcionalidade a 5%, 50% ou 100% dos usuários sem que isso, sozinho, diga qualquer coisa sobre se aquela funcionalidade é boa. Um teste A/B pode medir o efeito de uma mudança mesmo sem nenhuma flag envolvida (o desenho clássico de teste A/B de marketing troca elementos direto na página, sem infraestrutura de flag por trás). São eixos diferentes, e um projeto pode precisar de um, do outro, ou dos dois ao mesmo tempo.

Quando usar só feature flag

Use feature flag sem teste A/B por trás quando a pergunta é sobre risco de entrega, não sobre efeito em uma métrica. Os três casos mais comuns, segundo o próprio glossário da Optimizely sobre feature flags:

• Rollout progressivo (canary release). Libere a funcionalidade para 1%, depois 10%, depois 50% dos usuários, monitorando erros e performance a cada patamar antes de avançar. A pergunta aqui é “isso quebra alguma coisa?”, não “isso converte mais?”.
• Kill switch. Um interruptor que desliga uma funcionalidade instantaneamente se algo der errado em produção, sem precisar de rollback de deploy. A Optimizely descreve essa lógica como uma camada final de proteção: se uma funcionalidade se comportar de forma inesperada, você vira a chave e volta para a versão estável na hora, sem esperar por um novo deploy.
• Permissionamento. Controlar quem tem acesso a um recurso por plano, por região ou por segmento (uma funcionalidade enterprise, uma feature em beta fechado para um grupo de clientes). Esse tipo de flag costuma viver muito tempo, ao contrário das flags de rollout, que devem ser removidas assim que a funcionalidade estabiliza.

Nenhum desses três casos precisa de amostra calculada, de significância ou de grupo de controle. A decisão é binária e operacional: “isso está seguro?” ou “essa pessoa pode ver isso?”, não “essa mudança move a métrica?”.

Quando usar só teste A/B

Na direção oposta, use teste A/B sem depender de infraestrutura de feature flag quando a pergunta é sobre efeito em uma métrica que importa, e o risco técnico da mudança é baixo. O caso clássico é o teste A/B de marketing e CRO: título da página, texto do botão, layout do formulário, preço exibido. Nenhuma dessas mudanças ameaça a estabilidade do sistema; o risco é só de conversão, e é exatamente isso que o teste mede.

Sinal de que você precisa de rigor estatístico, não só de uma flag: a decisão vai custar caro se você errar (mexer em preço, em checkout, em onboarding), a diferença esperada é pequena o suficiente para se confundir com ruído, ou você vai defender essa decisão com números depois. Nesses casos, pular direto para “botei em 50% e o gráfico parece melhor” é o erro descrito pelo próprio PostHog em sua documentação: você não controla significância estatística, e a diferença que parecia real pode ser só acaso.

Se você está montando esse tipo de teste do zero, vale calcular a amostra antes de rodar: veja o guia completo de teste A/B para o passo a passo e a calculadora de tamanho de amostra.

Quando usar os dois juntos

O padrão mais maduro, e o que LaunchDarkly, PostHog e Split/Harness descrevem em suas próprias documentações de produto, é usar a flag como mecanismo de entrega e colocar o teste A/B como camada de experimentação por cima dela. A flag controla quem recebe qual variação; o teste A/B, amarrado a essa mesma divisão, mede se a variação vence. Na prática de produto, isso costuma seguir os mesmos patamares de um rollout progressivo, só que com uma etapa de medição formal no meio do caminho, antes de avançar para 100%:

Esse é exatamente o modelo que o PostHog descreve para as suas próprias experiments: você cria uma flag com variantes, adiciona rastreio de experimento por cima, e a plataforma cuida da divisão aleatória, da coleta de eventos e do cálculo de significância. A LaunchDarkly descreve o mesmo padrão em sua documentação de experimentação: a flag entrega as variações, e as métricas conectadas à flag dizem qual delas venceu, permitindo então ampliar o rollout daquela variação para toda a base.

Exemplo prático: e-commerce e SaaS

E-commerce. Uma loja quer trocar o fluxo de checkout para uma versão em uma página só (em vez de três etapas). O risco técnico é real (checkout quebrado é receita perdida na hora), então a mudança nasce atrás de uma feature flag, liberada primeiro para 5% do tráfego só para garantir que nada quebra. Depois de confirmado que está estável, a flag passa a alimentar um teste A/B de verdade: 50% dos visitantes veem o checkout novo, 50% veem o antigo, com atribuição estável por visitante e a taxa de conclusão de compra como métrica primária. Só depois de o teste declarar significância é que a flag avança para 100%.

SaaS. Um time de produto quer testar um novo fluxo de onboarding que pede menos informação no cadastro. O risco técnico é baixo (não mexe em cobrança nem em dados sensíveis), mas o efeito na métrica (ativação em 7 dias) é incerto e pode ir para qualquer lado. Aqui, a flag existe mais por conveniência de deploy contínuo (a equipe de engenharia consegue mergear o código incompleto na branch principal sem afetar produção) do que por medo de quebrar algo; o teste A/B, com uma amostra calculada antecipadamente pelo volume de novos cadastros por semana, é quem decide se o onboarding novo fica.

Lendo o resultado com rigor, mesmo vindo de uma flag

Depois que uma flag entrega as duas versões e o teste roda no patamar estável (por exemplo, os 50% do exemplo do checkout), a leitura estatística é a mesma de qualquer teste A/B: compare visitantes e conversões de cada lado. Reaproveitando um exemplo já verificado no motor estatístico deste blog, com o controle registrando 210 conversões em 4.200 visitantes e a variação 273 em 4.200:

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.

Rodando esses números na calculadora acima, a taxa do controle é 5,0%, a da variação é 6,5%, o valor-p bilateral fica perto de 0,003 e o intervalo de confiança da diferença não cruza zero. Ou seja: mesmo tendo vindo de uma flag em 50% de rollout, a diferença é significativa, não é ruído, e só nesse ponto faz sentido avançar a flag para 100%. Para o passo a passo completo dessa conta, veja como declarar significância estatística sem se enganar.

Um detalhe que vale reforçar: dados coletados enquanto a porcentagem do rollout ainda estava mudando (de 1% para 10%, de 10% para 50%) não deveriam entrar nessa conta. Cada mudança de patamar pode alterar quem está sendo exposto (times de rollout progressivo costumam variar o critério de seleção a cada fase), e misturar cohorts diferentes na mesma análise estatística é um jeito silencioso de contaminar o resultado. Trate cada patamar estável como a janela de coleta do teste.

Feature flag x teste A/B, lado a lado

Critério	Feature flag	Teste A/B
Objetivo	Controlar risco de entrega	Medir efeito em uma métrica
Unidade de decisão	Regra de negócio (plano, região, % de rollout)	Estatística (valor-p, IC, ou probabilidade bayesiana)
Tempo de vida típico	Curto para rollout (dias a semanas); longo para permissionamento	Duração fixa, calculada por amostra e tráfego
Quem decide	Engenharia / produto, por critério de risco	O resultado estatístico, definido antes do teste
Ferramentas de referência	LaunchDarkly, Split/Harness, Flagsmith, Unleash	Donnu A/B, VWO, Optimizely, GrowthBook
Erro comum se usada sozinha	Achar que “está em produção” significa “está aprovada”	Rodar sem infraestrutura de segurança em mudanças de alto risco técnico

Erros comuns ao misturar os dois

• Declarar vencedor olhando o rollout, sem teste. A flag chegou a 50%, o número no dashboard “parece” melhor, e a equipe já avança para 100% sem nunca ter calculado significância. É exatamente o padrão que o PostHog cita como o erro mais caro: a diferença observada pode ser inteiramente ruído.
• Misturar dados de patamares diferentes do rollout na mesma análise. Juntar a semana em que o rollout estava em 10% com a semana em que já estava em 50% distorce a comparação, porque o público exposto muda a cada mudança de patamar.
• Deixar a flag viva depois que o teste terminou. Flags de rollout e de teste A/B são transitórias por natureza. Martin Fowler chama atenção para isso: flags esquecidas acumulam dívida técnica e tornam o código cada vez mais difícil de entender. Assim que o teste decide (ganhou, perdeu ou foi descartado), a flag deveria ser removida, não deixada “por via das dúvidas”.
• Usar teste A/B em uma mudança de alto risco técnico sem flag por trás. Testar uma reescrita grande de checkout direto, sem um kill switch disponível, tira de você a capacidade de reverter na hora se algo quebrar em produção.

Faça isso automático na Donnu

Combinar rollout controlado com leitura estatística honesta é trabalho manual quando cada peça vive numa ferramenta diferente. A Donnu A/B cuida da parte de medição dessa combinação: você define a hipótese e a divisão de tráfego, o snippet leve nunca trava a página do seu produto, e o motor estatístico bayesiano declara o vencedor com o mesmo rigor descrito neste guia, sem “olhar o dashboard e sentir” que uma variação está ganhando.

Comece um teste grátis de 14 dias e meça a próxima mudança com a estatística certa, não só com a flag em 50%. Para entender a base estatística por trás de qualquer teste, veja o guia completo de teste A/B; para decidir onde a divisão de tráfego deveria acontecer, tecnicamente, veja teste A/B client-side x server-side.

---

Leia também: Feature flags: o guia completo · O que é teste A/B? O guia completo · Teste A/B client-side x server-side

Referências

• Fowler, M. Feature Toggles (aka Feature Flags). martinfowler.com/articles/feature-toggles.html.
• LaunchDarkly. Experimentation. launchdarkly.com/docs/home/experimentation.
• PostHog. What is a feature flag? Feature Flags vs Remote Config vs A/B Testing. posthog.com/blog/what-is-a-feature-flag.
• Optimizely. Feature flags. Optimization Glossary. optimizely.com/optimization-glossary/feature-flags.