A/B Testing & Experimentação

O Problema

A maioria dos "testes" não são testes

As equipas correm testes A/B todos os dias e chegam a conclusões erradas. Não porque os dados mentem, mas porque a experiência foi desenhada de uma forma que torna impossíveis conclusões válidas. Testar mal é pior do que não testar: cria decisões erradas com confiança.

Experiência inválida

Mudou duas coisas ao mesmo tempo (cor do botão + texto)
Parou o teste quando os resultados "pareciam bons"
Correu durante 3 dias num fim de semana de feriado
Não pré-calculou o tamanho de amostra necessário
Declarou vencedor a p = 0,09 ("perto o suficiente")

O resultado pode estar direcionalmente certo. Mas não há como saber, e agir sobre ele como facto é perigoso.

Experiência válida

Uma variável alterada, tudo o resto idêntico
Duração decidida à partida com base no tamanho de amostra
Correu sobre tráfego representativo (mínimo de uma semana)
Tamanho de amostra calculado antes do lançamento (MDE definido)
Decisão tomada num limiar de significância pré-acordado

O resultado pode ser usado com confiança conhecida. Percebes a probabilidade de estares errado.

Fundamentos

Começa com uma hipótese, não com a cor de um botão

Toda a experiência começa com uma observação sobre o comportamento dos utilizadores, uma mudança proposta e um resultado previsto. Sem esta estrutura, não estás a experimentar. Estás a decorar.

O formato da hipótese: "Acreditamos que [mudança] vai causar [resultado] para [segmento de utilizadores], porque [raciocínio]. Vamos medir isto com [métrica]."

01

Observação: Que comportamento motivou isto?

Começa com dados, não com ideias. Heatmaps mostram utilizadores a ignorar o CTA. Gravações de sessão mostram abandono num campo específico do formulário. A análise de funil revela que 60% dos utilizadores abandonam o checkout no passo da morada. A observação é a tua evidência de que algo está partido; justifica o teste.

02

Hipótese: Que mudança vais fazer e porquê?

Sê específico quanto ao mecanismo. "Acreditamos que adicionar um selo de confiança junto ao botão de checkout vai aumentar a conversão porque os utilizadores hesitam em partilhar dados de pagamento com uma marca desconhecida." A cláusula do "porque" obriga-te a pensar de forma causal, não apenas correlacional.

03

Métrica primária: Qual é a tua única medida de sucesso?

Escolhe uma métrica primária antes de o teste correr. Se medires 20 métricas e declarares vitória naquela que se mexeu, vais encontrar um "vencedor" por puro acaso de todas as vezes. As métricas secundárias podem informar a interpretação; não podem retroativamente tornar-se a medida primária.

04

Minimum Detectable Effect: Que tamanho de mudança importa?

O MDE é a menor melhoria que justificaria implementar a mudança. Se a tua taxa de conversão é 4% e precisas de um aumento relativo de 20% (para 4,8%), precisas de ~9.500 utilizadores por variante para o detetar com 95% de confiança. Calcula isto antes do teste; determina quanto tempo precisas de o correr.

Estatística

Significância estatística: o que significa mesmo

A significância estatística é o conceito mais mal compreendido na experimentação. "95% de confiança" não significa que tens 95% de certeza de que a variante é melhor. Significa: se de facto não houvesse diferença, verias resultados tão extremos por puro acaso apenas 5% das vezes.

p-value

A probabilidade de ver este resultado por acaso. Um p-value de 0,05 significa que há 5% de probabilidade de ver esta diferença mesmo que a variante não tenha efeito real. O limiar padrão é p < 0,05 para a maioria das decisões de produto. Para decisões de alto risco (pricing, fluxos centrais de checkout), usa p < 0,01. O p-value não é a probabilidade de a tua hipótese ser verdadeira.

Poder estatístico

A probabilidade de detetar um efeito real. O poder é o reverso da significância. O poder padrão é 80%, ou seja, se houver mesmo um efeito do tamanho do teu MDE, vais detetá-lo 80% das vezes. Testes de baixo poder produzem demasiados falsos negativos: declaras "sem vencedor" quando havia mesmo um. Testes sub-dimensionados são tão enganadores como espreitar cedo.

Tamanho de amostra

Inegociável: calcula antes de começar. O tamanho de amostra depende de três inputs: a tua taxa de conversão base, o teu MDE e a significância/poder-alvo. Efeitos menores exigem amostras maiores. Uma melhoria relativa de 2% sobre uma taxa de conversão de 50% precisa de muito mais utilizadores do que uma melhoria relativa de 20% sobre uma taxa de 2%. Usa uma calculadora online. Não adivinhes.

Intervalo de confiança

O intervalo onde o efeito verdadeiro provavelmente vive. Um intervalo de confiança de 95% de [+1,2%, +4,8%] significa que o efeito verdadeiro está provavelmente algures nesse intervalo. ICs largos sinalizam testes sub-dimensionados. ICs estreitos (mais dados) dão estimativas precisas. Um IC que inclui zero significa nenhum efeito significativo, mesmo que a estimativa pontual pareça positiva.

Armadilhas

Os erros que invalidam experiências

Estes são os erros que produzem conclusões erradas com confiança, o resultado mais perigoso na tomada de decisão baseada em dados.

Atenção a estes

Espreitar, parar cedo quando os resultados parecem bons: O erro mais comum. De cada vez que olhas para os resultados ao vivo e ponderas parar, estás a correr múltiplos testes implícitos, inflacionando a tua taxa de falsos positivos. Se espreitas a p = 0,05 ao dia 3 e é significativo, há uma probabilidade real muito maior de estares errado do que 5%. Compromete-te à partida com uma duração e não olhes cedo.

Testar várias variantes sem correção: Testar A vs B vs C vs D em simultâneo multiplica a tua taxa de falsos positivos. Com 4 variantes e p < 0,05, o acaso sozinho produz um "vencedor" ~19% das vezes entre comparações. Usa correção de Bonferroni ou um framework Bayesiano quando testas várias variantes.

Efeito de novidade: Os utilizadores envolvem-se mais com qualquer coisa nova, sobretudo utilizadores recorrentes que encontram uma interface alterada. Um teste que corre 3 dias pode captar ganhos impulsionados pela novidade que desaparecem ao fim de uma semana. Inclui sempre pelo menos uma semana completa de tráfego e verifica tendências ao longo do tempo dentro do período do teste.

Sample Ratio Mismatch (SRM): Se atribuis 50/50 mas vês 48/52 no tráfego real, a tua aleatorização está partida. O SRM invalida qualquer resultado, independentemente da significância. Verifica isto antes de declarar um vencedor: teste qui-quadrado entre a divisão de tráfego esperada e a real. Corrige sempre o SRM antes de interpretar resultados.

Viés de sobrevivência na segmentação: Encontrar "vencedores" em subgrupos post-hoc (o teste ganhou para utilizadores mobile na Alemanha que se registaram nos últimos 30 dias!) é quase de certeza um falso positivo. Pré-especifica quaisquer análises de subgrupo na tua hipótese. Vitórias de segmento post-hoc são hipóteses para o próximo teste, não conclusões acionáveis.

Métodos Avançados

Para além do A/B testing clássico

O A/B testing clássico tem limites claros. Quando o tráfego é baixo, as mudanças são complexas ou precisas de iterar mais depressa, vale a pena conhecer estas alternativas.

Testes Multivariados

Testar vários elementos em simultâneo (título + imagem + CTA) para encontrar a melhor combinação. Exige amostras muito maiores; o tráfego necessário escala com o número de combinações. Melhor para páginas de muito tráfego com vários elementos independentes a otimizar.

A/B Testing Bayesiano

Em vez de um binário "significativo/não significativo", os métodos Bayesianos dão-te uma probabilidade de a variante B ser melhor do que a A, atualizada continuamente à medida que os dados chegam. Melhor para equipas que precisam de decidir com dados imperfeitos e não podem esperar pelos tamanhos de amostra clássicos.

Algoritmos Bandit

Os algoritmos multi-armed bandit deslocam dinamicamente o tráfego para a variante vencedora durante o teste, minimizando a receita perdida por expor utilizadores a uma experiência inferior. Úteis para campanhas de curta duração onde esperar pela significância clássica é demasiado lento.

Âmbito

Quando o A/B testing é a ferramenta errada

O A/B testing é poderoso mas não é universal. Saber quando não testar é tão importante como saber como testar.

Bons casos de uso para A/B testing

Texto do CTA, posição do botão, comprimento do formulário
Variações do fluxo de onboarding
Assuntos de email e horas de envio
Apresentação de pricing e packaging
Título e imagem de destaque da homepage

Volume alto, resultado mensurável, mudança isolada: território clássico de A/B.

Maus casos de uso para A/B testing

Redesenhos completos de produto (variáveis a mais)
Mudanças com efeitos de rede (contaminação entre grupos)
Páginas de baixo tráfego (anos até atingir significância)
Decisões éticas ou de marca (nem tudo é uma métrica)
Mudanças de comportamento de longo prazo (teste demasiado longo)

Usa antes pesquisa qualitativa, rollouts faseados ou juízo de especialista.

Conclusão

A experimentação como disciplina

O objetivo não é correr mais testes. É aprender mais depressa. As equipas que integram a experimentação na sua cultura entregam melhores produtos, cometem menos erros caros e acumulam aprendizagem ao longo do tempo.

Desenha antes de construir

Escreve a hipótese, define a métrica primária e calcula o tamanho de amostra necessário antes de escrever uma única linha de código. A maioria das más experiências é mal desenhada, não mal executada.

Aprende com as derrotas

Um teste bem desenhado que não mostra efeito continua a ser valioso; exclui uma hipótese e redireciona o esforço. Equipas com alta velocidade de testes mas baixa taxa de vitórias continuam a aprender mais depressa do que equipas que mal experimentam.

O rigor estatístico é respeito pelas decisões

Cada atalho no desenho do teste (espreitar, sub-dimensionar, ignorar o SRM) é um atalho para conclusões erradas. O custo a jusante de uma má decisão baseada em dados inválidos excede em muito o custo de correr o teste como deve ser.

A/B Testing&Experimentação