Teste A/B: frequentista, bayesiano e sequencial na prática

Publicado em · 25 min de leitura

Um panorama de como funciona cada abordagem, onde cada uma trava, e o que separa um teste em que dá pra confiar de um teste que parece ótimo até deixar de parecer.

Bora entender tudo que da de A/B no menor tempo possível

Bora entender tudo que da de A/B no menor tempo possível

Em 2012, um engenheiro do Bing teve uma ideia, mover o texto secundário do anúncio pra linha do título e deixar o título mais longo. A ideia ficou na fila do produto por seis meses, despriorizada, até alguém implementar em três dias e rodar um teste A/B só pra tirar a curiosidade. Em poucas horas o sistema disparou um alerta de “bom demais pra ser verdade” porque a receita estava 12% acima do controle. Não era bug. A mudança virou a melhor ideia geradora de receita da história do Bing, mais de US$ 100 milhões por ano só nos EUA, conforme reportado por Kohavi e Thomke na Harvard Business Review.

Esse é o lado bom. O lado feio é que na própria Microsoft, ao longo de mais de uma década rodando testes em escala, cerca de um terço das ideias melhoram a métrica-chave, um terço fica neutro, e um terço piora. No Bing especificamente, a taxa de sucesso é ainda menor. Booking roda 25.000 testes A/B por ano. Se as estatísticas fossem mal calibradas, eles estariam tomando milhares de decisões erradas com confiança alta.

A escolha entre Frequentista, Bayesiano e Sequential não é discussão acadêmica. É a diferença entre confiar nesse 1/3 que de fato funciona ou se iludir com falsos positivos no resto do ano.

Quando você repara que gastou todo seu tempo em algo que não funciona

Quando você repara que gastou todo seu tempo em algo que não funciona

Frequentista, o padrão e suas pegadinhas

O Frequentista é o que praticamente toda calculadora online de A/B usa por baixo. A lógica vem do Neyman-Pearson framework dos anos 30, você define uma hipótese nula H₀ (as variantes são iguais), uma alternativa H₁ (são diferentes), calcula a estatística do teste, e a partir daí o p-value, a probabilidade de observar o resultado que você observou (ou mais extremo) se H₀ fosse verdadeira.

Se p < 0,05, rejeita H₀. Se p ≥ 0,05, falha em rejeitar. Não é “aceita H₀”, é “não consegui derrubar”. Sutil, mas importante.

O sample size você calcula antes, em função de quatro coisas, a variância da métrica, o lift mínimo que você quer detectar (MDE), o nível de significância (α, tipicamente 0,05) e o power (1-β, tipicamente 0,8). Roda até o N planejado, olha o resultado, decide.

Funciona. Tem décadas de uso, fundamentação teórica sólida, e qualquer revisor de paper e produto aceita. O problema é que quase ninguém respeita o protocolo na prática.

Pegadinha 1, peeking

A regra é não olhar antes do N planejado. Olhar antes corrompe o p-value de uma forma específica, quanto mais frequentemente você olha, mais alto fica o falso positivo acumulado. A Optimizely simulou isso explicitamente. Em teste A/A (mesma variante contra ela mesma, então o resultado correto é zero efeito) com 5.000 visitantes:

Lendo de novo, mais da metade dos testes A/A com peeking aleatório declararia um vencedor que não existe. Em um teste de 1 milhão de visitantes com peeking, esse número passa de 70%.

Por que isso acontece? Porque o p-value não é um valor estável que converge pra “o” valor verdadeiro. Ele oscila. Em um A/A, se você plota o p-value ao longo do tempo, ele cruza 0,05 várias vezes mesmo quando o efeito real é zero. Você só precisa esperar pra cruzar de novo, e parar nesse ponto, pra “encontrar” significância.

Armadilha 2, multiple testing

Você roda um teste com 1 variante e 1 métrica, taxa de erro 5%. Roda com 4 variantes e 5 métricas, são 20 comparações independentes. A probabilidade de pelo menos um falso positivo sobe pra cerca de 64% (1–0,9⁵²⁰).

A correção mais simples é Bonferroni, dividir α pelo número de testes. Conservadora demais quando há correlação entre métricas. Alternativas modernas usam Benjamini-Hochberg pra controlar FDR (False Discovery Rate) em vez de FWER (Family-Wise Error Rate). A Optimizely controla FDR diretamente no Stats Engine.

Armadilha 3, low power

Power é a probabilidade do seu teste detectar um efeito real. Roda um teste com 1.000 visitantes pra detectar lift de 0,5%, seu power é tipo 15%. Mesmo que a variante seja melhor, em 85% dos casos seu teste não consegue ver. Não é “deu empate”, é que o teste é cego para o efeito que você quer medir.

E aqui mora o problema composto, testes com baixo poder não só falham em detectar efeitos verdadeiros, eles também magnificam efeitos quando são significativos. O fenômeno é conhecido como winner’s curse. Se um teste underpowered dá p < 0,05, o effect size estimado tende a ser muito maior que o real, porque só os ruídos grandes conseguem cruzar a barreira de significância. Resultado, você lança, mede em produção depois, e o efeito sumiu.

Armadilha 4, p-hacking

Variação refinada das três anteriores. Você roda o teste, não deu significância no agregado. Corta por mobile, não deu. Corta por novos vs recorrentes, deu! Publica.

Esse “deu” é puramente artefato de quantos cortes você tentou. Se você faz 20 cortes em um A/A, a probabilidade de pelo menos um dar p < 0,05 por puro acaso é alta. Kohavi, Tang e Xu chamam isso, no livro Trustworthy Online Controlled Experiments, de uma manifestação de Twyman’s Law: qualquer número que pareça interessante ou diferente provavelmente está errado. Resultado positivo aparente em segmento específico merece checagem dobrada.

Quando você acredita em todo resultado só por ter números nele

Quando você acredita em todo resultado só por ter números nele

Frequentista funciona, com metodologia

Calculou sample size antes. Travou as métricas antes. Não olhou no meio. Não correu múltiplos cortes em busca de história. Aí é robusto, transparente e barato.

A questão é que ambientes de produto têm pressão pra “ver como tá indo”, múltiplos stakeholders olhando a mesma dashboard, e a tentação humana óbvia de declarar vitória cedo. A metodologia é sólida, o ambiente é hostil pra ela.

Bayesiano, a alternativa que parece intuitiva (e o que esconde)

O Bayesiano inverte a pergunta. Em vez de “qual a probabilidade de eu ver isso se H₀ for verdade?”, ele responde direto, “qual a probabilidade de B ser melhor que A?”.

A mecânica usa o teorema de Bayes. Você começa com um prior (uma crença inicial sobre a distribuição da métrica), observa os dados, e calcula o posterior, a distribuição atualizada. Pra teste de conversão, o prior padrão é uma distribuição Beta, que é o conjugado natural da distribuição Binomial dos dados, e isso significa que o posterior também é Beta e tem fórmula fechada. Sem MCMC, sem amostragem cara, é conta direta.

Os outputs do Bayesiano são qualitativamente diferentes do Frequentista:

Soa muito mais alinhado com decisão de negócio que p-value puro. Foi por isso que a VWO construiu o SmartStats em cima de Bayes-Beta-Binomial e o Google Optimize (descontinuado em 2023) também usava Bayesiano.

Onde o Bayesiano se sai bem

Três pontos em que ele de fato é melhor que Frequentista clássico:

  1. A pergunta que ele responde é a pergunta que você quer fazer. “Qual a probabilidade de B ser melhor que A?” é o que o stakeholder quer ouvir. Não é o que o p-value entrega. Permite incorporar conhecimento prévio formalmente. Se você já rodou 200 testes em landing pages e sabe que lifts típicos ficam entre -5% e +5% com média perto de zero, dá para colocar essa informação no prior em vez de assumir uniformidade. A interface de “expected loss + threshold of caring” força você a pensar em quanto risco de perda você topa. Para ser declarada vencedora no SmartStats da VWO, uma variante precisa ter expected loss abaixo de um threshold E chance de bater todos acima de 95%. Isso é mais robusto que só “p < 0,05”.

Mas nem tudo que brilha no escuro é ouro.

Prior escondido

Vendors comerciais frequentemente fixam priors ou funções de utilidade sem documentar, o que torna impossível para o usuário avaliar ou ajustar as premissas. Georgi Georgiev, do Analytics Toolkit, documentou múltiplos casos de plataformas que apresentam outputs Bayesianos sem expor os priors usados. Se o prior é Beta(1,1) (uniforme), os resultados começam em 50%/50% e demoram a se mover. Se é Beta(50, 950) (informativo, baseado em conversão histórica de 5%), os resultados começam concentrados perto de 5% e exigem muito mais dados para deslocar.

A consequência prática, dois Bayesianos com priors diferentes, vendo os mesmos dados, podem dar números diferentes. E se você nem sabe qual prior está rodando, não tem como avaliar se está conservador ou agressivo demais.

“Probability to be best” não significa o que parece

Lê isso devagar. Em uma plataforma Bayesiana padrão com prior não-informativo, a probabilidade de B ser o melhor começa em 50% (com 2 variantes) e na maioria dos A/A fica em torno de 50% mesmo com centenas de milhares de visitantes. Faz sentido, se A = B, a métrica oscila simétrica em torno de 50%.

Georgiev mostrou em 60 A/A reais rodados no Google Optimize que a “probability to be best” se distribuía em torno de 50% como esperado, mas em vários testes individuais cruzou os 95% por puro acaso e pelo tempo necessário para um operador não-treinado declarar vencedor.

O número “B tem 87% de probabilidade de ser o melhor” é frequentemente lido como “tenho 87% de certeza que vou ganhar receita lançando B”. Não é. É a probabilidade de B ter conversão maior que A, condicional ao prior usado, sem nenhuma garantia de quanto maior nem por quanto tempo. As duas coisas não são a mesma.

Stopping rules ainda importam

Esse é o erro mais comum no mercado. Muita gente migra para Bayesiano achando que pode olhar o teste a qualquer hora e parar quando bem entender porque “Bayesiano não sofre de peeking”. Não exatamente.

Sob suposições estritas e priors específicos, alguns Bayes factors são invariantes ao stopping rule. Mas na prática, A/B testing comercial usa priors padrão e hipóteses compostas, e nesse cenário a robustez teórica se quebra. O posterior pode ficar calibrado de forma ruim e levar a decisões enviesadas.

A explicação intuitiva é que stopping rule é parte do processo gerador dos dados. Se você decide parar quando “probability to be best > 95%”, você está condicionando o experimento a parar nas trajetórias em que esse limiar é cruzado, o que enviesa a estimativa final para cima. Bayesianos sérios reforçam isso. Bayesiano sem stopping rule disciplinado tem o mesmo problema que Frequentista com peeking. A interface só esconde melhor.

Sequential, monitorar continuamente sem queimar α

Sequential é o que as pessoas normalmente querem no começo, olhar o teste continuamente sem corromper a inferência. A ideia é antiga, vem do Sequential Probability Ratio Test (SPRT) de Wald nos anos 1940, originalmente desenvolvido para controle de qualidade na 2ª Guerra. A aplicação moderna em A/B é mais recente.

Existem duas linhagens vivas, always-valid (mSPRT) e Group Sequential com alpha spending. Resolvem o mesmo problema por caminhos diferentes.

Always-Valid e mSPRT

A Optimizely usa o mixture sequential probability ratio test (mSPRT), descrito no paper de Johari, Pekelis, Walsh e Koomen como base do Stats Engine. A construção produz p-values “sempre válidos” no sentido formal de que P(p_T ≤ x) ≤ x para qualquer regra de parada T, ou seja, o usuário pode olhar quando quiser, parar quando quiser, e a inferência continua correta no sentido frequentista.

A intuição por trás é que o mSPRT mistura sobre uma família de hipóteses alternativas (o “m” de mixture) usando um prior τ. Isso resolve o problema do SPRT clássico, que exigia você fixar um effect size antes para calcular as fronteiras, o que ninguém faz na prática em produto.

Em simulações onde o Frequentista clássico ajustado para peeking diário declarava falso vencedor em 57% dos testes, o sequencial cai para 3%, conforme reportado pela Optimizely.

Tem custo. Sequential precisa de mais amostra para atingir poder equivalente quando o efeito é pequeno. Você ganha flexibilidade de parada em troca de eficiência estatística no pior caso. A magnitude depende do prior τ usado e do effect size verdadeiro.

Group Sequential e Alpha Spending

Alternativa mais antiga, vinda de ensaios clínicos. A ideia, em vez de olhar continuamente, você define N olhadinhasprogramadas (ex.: a cada 25% da amostra prevista) e usa uma função de alpha spending para dividir os 5% de erro entre eles.

O paper seminal é Lan e DeMets (1983), que generalizou trabalhos anteriores de Pocock (1977) e O’Brien e Fleming (1979). As duas funções clássicas:

Existem variantes intermediárias (Wang-Tsiatis, alpha-spending linear) e a flexibilidade de usar funções customizadas, em que os timings dos looks não precisam ser fixados antes, basta a função de gasto.

Dá aquela relaxada antes das conclusões aí

Dá aquela relaxada antes das conclusões aí

Quem usa o quê

Booking, Microsoft e Netflix usam variações de sequential testing combinadas com alpha spending ou group sequential nas suas plataformas internas. Optimizely oferece always-valid como modo padrão. ABsmartly (fundada por engenheiros que construíram a plataforma da Booking) oferece Group Sequential como default e Frequentista de horizonte fixo como alternativa pra times que querem alta confiabilidade ou têm sazonalidade semanal forte.

Na prática, sequential virou o padrão de fato em programa de experimentação maduro. Calculadora online de A/B ainda é Frequentista clássico ou Bayesiano simples na maioria dos casos.

Resumo das três abordagens

O Frequentista responde “quão improvável é esse resultado se as variantes fossem iguais”, exige sample size pré-calculado, é sensível a peeking, e funciona se o operador respeitar o protocolo. Curva de aprendizado baixa, pegadinhas potencialmente altas.

O Bayesiano responde “qual a probabilidade de B ser melhor”, aceita conhecimento prévio formalmente, expressa incerteza em distribuições, e tem outputs alinhados com decisão de negócio. Mas depende de priors que muitas vezes são opacos, e na prática ainda é sensível a stopping rules mal pensados.

O Sequential responde “essa diferença é robusta a continuar olhando”, permite parada flexível por design, é o que empresas que rodam dezenas de milhares de testes por ano usam, e cobra uma sobrecarga de amostra em troca da flexibilidade.

Não tem paradigma certo. Tem paradigma adequado pro contexto. Time pequeno com calculadora online provavelmente está rodando Frequentista mal-disciplinado e ganharia migrando pra plataforma Bayesiana com expected loss + threshold. Plataforma com time de ciência de dados no produto e volume relevante quase certamente quer sequential.

Variance reduction, um atalho pra todos

Independente do paradigma, existe uma técnica que reduz o sample size necessário sem mudar a metodologia, variance reduction. A mais popular é CUPED (Controlled-experiment Using Pre-Experiment Data), introduzida por Deng, Xu, Kohavi e Walker em paper de 2013 da Microsoft.

A intuição é simples. A maior parte da variabilidade da métrica de um usuário no experimento vem da variabilidade do próprio usuário antes do experimento. Usuários heavy estavam heavy antes. Usuários churn estavam churn antes. Se você usa o comportamento pré-experimento como covariável e ajusta a métrica do experimento pelo que era esperado dado o histórico, a variância residual cai drasticamente.

No paper original, em um experimento do Bing, usar queries-por-usuário do período pré-experimento como covariável reduziu a variância em mais de 45%. Combinada com outras covariáveis, chegou perto de 50%. Variância 50% menor significa intervalo de confiança mais estreito pelo mesmo N, o que significa metade do tempo pra detectar o mesmo efeito.

A Microsoft conseguiu, com CUPED, transformar testes que levavam 8 semanas em testes de 5 a 6 semanas. Para uma empresa que roda dezenas de milhares de testes por ano, isso é dobrar a velocidade de iteração.

CUPED virou padrão. Statsig, Eppo, Amplitude, LaunchDarkly e Kameleoon implementam variantes. A Netflix publicou um paper em 2016 (Xie e Aurisset) com adaptações pro contexto deles. Meta tem variantes com machine learning (Guo et al., 2021). A versão moderna do CUPED, em paper de 2023 do próprio Deng, generaliza pra métricas razão e percentil, e pra uso de dados no experimento, não só pré-experimento.

Se você está em uma plataforma comercial moderna, provavelmente CUPED já está rodando por baixo. Se está rodando A/B em SQL caseiro, vale ler o paper original e aplicar.

Validação de amostragem

Antes de analisar resultado, valide o setup. Essa etapa é normalmente esquecida em ambientes imaturos e automatizada nos maduros. Sem ela, qualquer das três metodologias acima entrega número errado com confiança alta.

A/A, o teste do teste

A/A é o exato A/B, mas com a mesma variante nos dois lados. O efeito real é zero. Se o resultado dá “vencedor”, o problema não é a variante, é a infraestrutura.

Optimizely usou A/A simulado pra calibrar o Stats Engine, é o experimento de referência pra mostrar o problema do peeking. Microsoft, Booking e Netflix rodam A/A periodicamente em produção, contra tráfego real. O propósito é detectar bugs sutis na plataforma que só aparecem com volume, hash de bucketing enviesado, exposure logging que dispara em momento diferente entre variantes, exclusão de bots aplicada em janelas diferentes, cache invalidation assimétrica.

Se um A/A em produção declara vencedor com p < 0,05 em mais de ~5% das execuções, algo está quebrado. A taxa esperada de falso positivo precisa bater exatamente com α. Não bate, tem viés sistemático.

No final tudo é sobre como abordar as coisas

No final tudo é sobre como abordar as coisas

Sample Ratio Mismatch (SRM)

Você desenhou o teste 50/50, e nos logs o controle ficou com 50,2% e o tratamento com 49,8%, o que parece irrelevante à primeira vista, mas com volume alto o teste de qui-quadrado pode apontar algo como 1 em 500.000 de essa diferença acontecer por puro acaso, ou seja, pequeno no percentual, mas grande na evidência.

SRM com p-value tão baixo é evidência forte de bug ou viés. As causas comuns:

O caso de SRM da Microsoft, documentado por Kohavi, ilustra sutileza. Em um experimento, o engajamento aumentou tanto na variante de tratamento que os heavy users acabaram acima do threshold de classificação de bots e foram removidos da análise, distorcendo a divisão. Quando o threshold de bot foi ajustado, o SRM sumiu, e o tratamento revelou ser ainda melhor que a leitura inicial. SRM não é só erro técnico, é também sintoma de que algo está acontecendo de verdade e precisa ser entendido.

Microsoft monitora SRM automaticamente em todo experimento. Se dispara, o resultado é considerado inválido até a causa raiz ser identificada. Não importa o quão bom esteja parecendo o lift principal. Booking faz checagem automatizada de SRM como parte do platform, com bloqueio de promoção de variantes em caso de mismatch.

Balanceamento pré-experimento

Antes do tratamento ser aplicado, os dois grupos deveriam ser estatisticamente indistinguíveis em qualquer métrica pré-experimento. Se não são, a randomização está enviesada ou a unidade de randomização tem viés temporal.

A checagem é simples, rodar o mesmo teste estatístico que você usaria pós-experimento (Frequentista, Bayesiano, qualquer um) sobre métricas do período anterior à exposição. Se aparece diferença estatisticamente significante em métricas pré-experimento, qualquer diferença pós-experimento fica confundida pela diferença pré-existente.

CUPED, mencionado na seção anterior, mitiga parcialmente esse problema ao ajustar pelo histórico, mas a checagem de balanceamento vale como sanity check independente do método de análise. Se o balanceamento falha sistematicamente, o problema está na randomização, não na análise.

Qualidade do hash e bucketing

A função que decide qual usuário cai em qual variante precisa ser uniforme. Implementações ingênuas como user_id % 2 parecem funcionar mas têm problemas, IDs sequenciais correlacionam com momento de cadastro, então dois grupos podem ter distribuições diferentes de usuários novos vs antigos. Em sistemas com IDs gerados por máquina (Snowflake, por exemplo), o módulo pode pegar o bit de machine_id e dividir por datacenter em vez de aleatoriamente.

Implementações robustas usam hash criptográfico do user_id concatenado com um salt do experimento, tipo SHA-256 de experiment_id:user_id. Isso garante três coisas, assignment determinístico (o mesmo usuário sempre cai na mesma variante daquele experimento), independência entre experimentos (assignment em um experimento não correlaciona com outro, então um usuário pode estar simultaneamente em 15 experimentos sem viés cruzado), e uniformidade (cada bucket recebe a fração esperada).

Validação periódica do hash inclui rodar a função em milhões de IDs e verificar uniformidade não só global mas em cortes, geo, idade do cadastro, plano, hora do dia. Não-uniformidade em algum corte sinaliza que cohorts específicas estão sub ou sobre-representadas em alguma variante.

Trigger analysis e Intent-to-Treat

Quando o tratamento só afeta um subconjunto dos usuários (exemplo feature visível só em uma página específica, ou só em mobile, ou só pra usuários com saldo acima de X), a análise tem dois caminhos:

A regra prática é, se o trigger é simétrico (mesma definição em controle e tratamento, contado da mesma forma), a análise restrita aos triggered é válida. Se é assimétrico (tratamento triggera por critério diferente do controle, ou só registra trigger no tratamento), a análise vira ITT obrigatoriamente.

CUPED tem extensões específicas pra one-sided triggering, em que o trigger só é observado em uma das variantes. É um cenário comum em feature flags onde o evento de exposição só dispara quando a feature é renderizada, ou seja, só na variante de tratamento.

Treta nos três

Validação de amostragem cuida do setup. Mas mesmo com setup perfeito, existem fenômenos que destroem a inferência de qualquer paradigma. Esses são os problemas que sobrevivem a todas as checagens automatizadas e ainda assim quebram a leitura do teste.

Agora que estamos aqui, vamos até o final

Agora que estamos aqui, vamos até o final

Outliers e dados sujos

Em um experimento da Amazon documentado por Kohavi, com 100.000 usuários, conversão de 2% e ticket médio de US$ 30 davam US$ 60.000 de receita total. Lift de 2% seria US$ 1.200. Ocasionalmente um “usuário” comprava ~US$ 2.500 numa única transação. Esse usuário sozinho jogado em controle ou tratamento podia inflar o resultado em mais que o efeito esperado pelo lift real.

A descoberta foi que bibliotecas compram livros em lotes irregulares, gerando essas compras gigantes. A solução, capar o valor de qualquer usuário individual no percentil 99 da distribuição (winsorização). Métricas robustas, percentis em vez de médias, ajudam.

Bots

Mais de 50% do tráfego do Bing é classificado como não-humano, segundo Kohavi. Em e-commerce e mídia o número também é alto. Sem filtragem de bots, você está testando se variante vermelha ou azul agrada mais o crawler do Google e robôs de scraping, o que provavelmente não é seu KPI.

Filtragem de bot tem que ser consistente entre controle e tratamento, senão você gera SRM artificialmente. E precisa ser reavaliada quando o teste muda comportamento de usuário, como no caso Microsoft acima.

Novelty effect e long-term effect

A variante “nova” causa estranhamento ou curiosidade nas primeiras semanas, e o efeito decai. Ou o oposto, dark pattern que dá lift de curto prazo e queima retenção em 3 meses.

Kohavi recomenda duas abordagens. Long-term experiments rodados com objetivo explícito de aprendizado, no Bing fazem isso aumentando e diminuindo o número de ads pra entender impacto em métricas-chave de longo prazo. E modelos preditivos com dados históricos pra estimar impacto futuro a partir de sinais de curto prazo. No caso da Amazon, o time de email descobriu que mandar mais email aumentava receita de curto prazo mas elevava unsubscribes, perdendo receita futura. Construíram um modelo pra prever essa perda e usar como contra-métrica.

Click-bait de anúncio é o exemplo arquetípico. CTR sobe no curto prazo, retenção e satisfação caem no longo. Sem métrica de longo prazo, o teste declara vitória e a empresa perde dinheiro em silêncio.

Heterogeneous Treatment Effects (HTE)

O efeito médio do teste é positivo. Mas talvez seja muito positivo em mobile e ligeiramente negativo em desktop, e o agregado mascara isso. HTE é a análise de como o efeito varia entre subpopulações.

O Netflix Tech Blog descreveu como o platform deles suporta análise automatizada de HTE como parte do reporting padrão. Microsoft, Google e LinkedIn fazem o mesmo. Sem HTE, decisão de lançamento global baseada em média pode prejudicar segmentos importantes.

O risco oposto também existe, p-hacking via segmentação. Se você corta por 30 segmentos procurando “onde funcionou”, a chance de encontrar significância por acaso é alta. Por isso bons platforms fixam segmentos de interesse antes do teste rodar.

OEC, a métrica que decide

Última peça da cadeia, Overall Evaluation Criterion (OEC). É a métrica única (ou função das métricas) que vai decidir o teste antes do teste começar.

Sem OEC declarada, qualquer time encontra alguma métrica pra justificar a decisão que queria. Conversão subiu 1% mas tempo na página caiu 8%? Se OEC era conversão, lança. Se OEC era engagement composto, repensa. Se não havia OEC, vira política.

O scorecard típico de Bing tem mais de 2.000 métricas, segundo Kohavi. A maioria existe pra detectar consequências inesperadas, não pra decidir o teste. Algumas dessas métricas são guardrails, qualquer queda significativa nelas bloqueia o lançamento independentemente do que aconteceu com a OEC. Latência, taxa de erro, refund rate, accessibility, fraud, customer service contact rate.

Booking mantém guardrails explícitos como cancellation rate, payment failures, refund friction, e load times. Lift na conversão de 3% que vem com aumento de 1% no cancellation pode ser zero ganho líquido depois que o cliente cancela e a logística absorve o custo.

Conclusão

Frequentista, Bayesiano e Sequential resolvem o mesmo problema com prioridades diferentes. O Frequentista é robusto se o protocolo for respeitado, e a maior parte da prática viola o protocolo. O Bayesiano dá outputs mais legíveis pra negócio mas esconde decisões de modelagem (priors) que mudam o resultado, e ainda é vulnerável a stopping rules mal pensadas. O Sequential resolve o problema operacional do peeking e por isso virou o padrão em programas maduros, ao custo de overhead estatístico no pior caso.

O denominador comum dos três é Twyman’s Law, qualquer resultado aparente demais provavelmente está errado. Vale checar SRM, vale rodar A/A periodicamente, vale duplicar a análise de qualquer lift inesperadamente alto. Bing achou US$ 100M em uma mudança trivial, mas a maior parte do crescimento de Bing veio de incrementos de 0,1% a 0,2% por iteração, somando ~2% ao ano. Airbnb fez ~6% de uplift em receita acumulando 250 experimentos pequenos em search relevance.

Cultura de experimentação madura não é cultura de testes geniais. É cultura de muitos testes, com rigor, com guardrails automatizados, com platform que bloqueia decisão errada antes de ela acontecer, e com humildade pra aceitar que dois terços das ideias não vão funcionar mesmo que pareçam ótimas no whiteboard.

A escolha do paradigma estatístico é uma camada disso. Sozinha não resolve nada. Combinada com SRM monitorado, OEC declarada antes, guardrails travados, variance reduction aplicada onde dá, e disciplina de stopping rule, vira o sistema operacional de quem cresce por A/B.

Referências

#testes-ab#estatistica#experimentacao