Design de Experimentos Que Sobrevive à Revisão das Partes Interessadas

Uma equipe com a qual trabalhei rodou um teste de cor de banner no trimestre passado. Três dias. Cerca de 200 usuários por grupo. O PM olhou para o dashboard, viu p = 0,07 no click-through e escreveu no Slack: "direcional positivo, vamos publicar." Seis semanas depois, a métrica principal estava estável, o modelo de personalização de ML downstream havia sido retreinado silenciosamente em tráfego randomizado no nível de sessão para um objetivo no nível de usuário e, quando o VP perguntou qual era a hipótese original, ninguém conseguia encontrá-la.

Esse experimento tinha quatro problemas empilhados um sobre o outro: amostra insuficiente, nenhum cálculo de efeito mínimo detectável, unidade de randomização errada e uma espiadinha no dia 2 que influenciou a decisão. Cada um deles, por si só, teria invalidado o resultado. Juntos, produziram uma decisão confiante construída sobre nada.

Este guia é o antídoto. É o playbook de design que torna essa história impossível de se repetir. Aquele em que um PM, um líder de engenharia e um VP cético podem ler o documento de leitura e chegar à mesma conclusão que você chegou.

O Template de Hipótese

A maioria dos experimentos falha antes mesmo de qualquer dado ser coletado, porque a hipótese não é falsificável. "Melhorar a UX." "Tornar o checkout melhor." "Aumentar o engajamento." Nenhuma dessas pode estar errada, o que significa que nenhuma delas pode estar certa tampouco.

Uma hipótese que você consegue defender tem quatro partes:

Problema: o número específico que você não gosta, hoje, com uma linha de base.
Mudança prevista: o que você vai fazer, em uma frase.
Métrica de sucesso: o único número primário pelo qual você vai julgá-la.
MDE: o menor tamanho de efeito que mudaria a sua decisão de negócio.

Preenchida, fica assim:

A taxa de conclusão do checkout é de 38% (linha de base de 90 dias, n aprox. 1,2 milhão de sessões). Adicionar uma barra de progresso de 4 etapas no fluxo de checkout reduzirá o abandono após a etapa de endereço. Métrica primária: taxa de conclusão, medida por usuário, janela de 14 dias. MDE: 1,5 ponto percentual de ganho absoluto (4% relativo). Qualquer valor menor não justifica o custo de engenharia.

Observe o que o template impõe. Você se compromete com um número de linha de base, para não poder argumentar post-hoc que a métrica era diferente. Você se compromete com uma métrica primária, para não poder mudar para uma secundária quando a primária decepcionar. Você se compromete com um MDE, para não poder afirmar que um ganho de 0,3 pp "importa." E o MDE está fundamentado em uma decisão de negócio (o menor ganho que mudaria o que você faria em seguida), não em uma conveniência estatística.

Rejeite hipóteses vagas antes de começar. Se uma parte interessada diz "queremos testar um novo layout para ver o que acontece," o seu trabalho é questionar: qual número muda, em quanto, e por que esse número importa? "Vamos ver o que acontece" é uma questão de pesquisa, não um experimento.

Matemática de MDE e Tamanho da Amostra

Esta é a seção que, mais do que qualquer outra, vai evitar que você publique resultados sem valor. A matemática não é opcional.

Para um teste de duas amostras de proporções com alfa = 0,05 (bicaudal) e poder = 0,80, o tamanho de amostra por grupo é aproximadamente:

n aprox. 16 x sigma² / delta²

Onde sigma² é a variância da métrica e delta é o tamanho do efeito absoluto que você quer detectar (seu MDE). Para uma métrica binária como conversão, sigma² aprox. p(1 - p), onde p é a taxa de linha de base.

Vamos fazer o exemplo do checkout do início ao fim.

Taxa de conclusão da linha de base: p = 0,38
Variância: sigma² = 0,38 x 0,62 aprox. 0,2356
MDE: delta = 0,015 (1,5 ponto percentual absoluto)
delta² = 0,000225

n aprox. 16 x 0,2356 / 0,000225
n aprox. 16.755 por grupo

Portanto, aproximadamente n = 17.000 usuários por grupo, n = 34.000 no total, para detectar de forma confiável um ganho de 1,5 pp em uma linha de base de 38% com 80% de poder. Se o volume diário de usuários elegíveis é de 5.000, isso representa um teste mínimo de 7 dias. Se você quiser um MDE de 1 pp, o denominador cai aproximadamente 2,25 vezes e você precisará de n aprox. 38.000 por grupo, próximo de um teste de 16 dias.

Agora observe o teste de banner do início: 200 usuários por grupo, taxa de click-through de linha de base de cerca de 8%. Variância aprox. 0,074. Para detectar um ganho de 1 pp com 80% de poder, n aprox. 16 x 0,074 / 0,0001 = 11.840 por grupo. Eles tinham 200. O teste era matematicamente incapaz de detectar o efeito que eles esperavam. O p = 0,07 que citaram não era um sinal quase significativo; era ruído aleatório em uma amostra que não poderia ter sinalizado coisa alguma.

Algumas notas práticas:

O 16 na fórmula vem de (z_alfa/2 + z_beta)² x 2 para alfa = 0,05, poder = 0,80. Para 90% de poder, use aprox. 21. Para alfa = 0,01 (correção de Bonferroni para 5 métricas, por exemplo), a constante sobe ainda mais.
Para métricas contínuas (receita por usuário, duração da sessão), use a variância real da amostra e tome cuidado com caudas pesadas. Limitar ou transformar logaritmicamente a métrica costuma ser a decisão certa; faça isso antes de rodar, não depois.
O tamanho da amostra escala com 1/delta². Reduzir o MDE à metade quadruplica a amostra necessária. É por isso que "vamos rodar mais tempo se não aparecer" é uma fantasia.

Se a calculadora de tamanho de amostra diz que você precisa de 38.000 usuários por grupo e a equipe tem apenas 5.000 por semana, suas opções são: rodar por 8 semanas, aceitar um MDE maior (e admitir que você não consegue detectar ganhos menores) ou escolher um experimento diferente. Não há uma quarta opção em que a matemática se dobre.

Unidade de Randomização: Usuário, Sessão ou Cluster

Escolher a unidade de randomização errada é o exterminador silencioso dos A/B tests. Você vai obter um valor-p limpo para a pergunta errada.

Randomização no nível de usuário é o padrão para a maioria dos experimentos de produto. Um usuário é atribuído a uma variante na primeira vez que ele acessa o experimento e permanece nela para sempre (ou pelo menos durante a janela do teste). Isso é correto quando a métrica é computada por usuário: retenção, LTV, frequência de compra, taxa de retorno em 7 dias.

Randomização no nível de sessão atribui cada sessão de forma independente. Isso funciona para métricas sem estado, de sessão única, como tempo de carregamento de página ou taxa de conversão de sessão única em uma landing page onde os usuários não retornam. Quebra badly quando a métrica se acumula entre sessões. Se você randomiza um algoritmo de recomendação no nível de sessão e mede a retenção de 30 dias, você mostrou ao usuário três experiências de recomendação diferentes ao longo de 30 dias; você está medindo a média de A e B, não A contra B.

Randomização em cluster é para efeitos de marketplace, rede e sociais. Se a variante muda como oferta e demanda se encontram (um novo algoritmo de ranking em um marketplace, uma mudança no feed que afeta o que outros usuários veem), você não pode randomizar usuários individuais. Eles se interferem mutuamente. Randomize no nível de geo, de marketplace ou de cluster social. O custo é que o seu n efetivo cai para o número de clusters, não o número de usuários, e o seu cálculo de tamanho de amostra precisa usar a variância no nível de cluster (que costuma ser muito maior do que a variância no nível de usuário).

A pergunta de diagnóstico: "Se eu atribuísse o usuário A ao controle e o usuário B ao tratamento, o resultado do usuário A poderia ser influenciado pela experiência do usuário B?" Se sim, você tem interferência e precisa de randomização em cluster ou de um design de switchback.

O erro de nível de sessão do teste de abertura era exatamente esse. Click-through é tecnicamente uma métrica de sessão, então a randomização no nível de sessão passou na verificação inicial. Mas o modelo downstream que foi retreinado nos dados precisava de sinal no nível de usuário. A unidade de randomização deve corresponder à unidade de análise, e ambas devem corresponder à unidade de decisão.

Métricas de Proteção

A métrica primária diz se a mudança funcionou. As métricas de proteção dizem se ela quebrou algo mais.

Pré-registre de duas a quatro métricas de proteção que não devem regredir além de um limiar, mesmo que a primária ganhe. Métricas de proteção padrão:

Latência (tempo de carregamento p95, tempo de resposta de API): muitas "vitórias" são vitórias porque a nova variante carregou mais rápido, não porque a mudança foi boa.
Taxa de erro (erros 5xx, erros de JS no lado do cliente): um tratamento que dobra a taxa de erro está publicando um bug, independentemente do que a conversão faz.
Receita por usuário: se você otimiza click-through e a receita por usuário cai, você encontrou uma forma de fazer as pessoas clicarem em coisas de menor valor. Não publique.
Taxa de tickets de suporte: mudanças de UX que confundem os usuários aparecem aqui, não na métrica de conversão.

O limiar importa. Um padrão comum: "a métrica de proteção não deve regredir mais de 1% relativo, ou o experimento falha independentemente do resultado primário." Pré-registre o limiar. Do contrário, quando a latência vier 2% mais lenta, a conversa vira "2% é realmente significativo" e você está negociando consigo mesmo.

O objetivo das métricas de proteção é detectar o experimento que ganhou na primária, mas destruiu o negócio. Elas são a ferramenta mais subutilizada no trabalho de DS e o seguro mais barato que você pode contratar.

O Documento de Leitura

Mesmo formato, sempre. O documento de leitura que sobrevive à revisão tem uma página, é escaneável em 90 segundos e não tem surpresas no apêndice. Veja o template:

Hipótese: um parágrafo, o template de quatro partes acima, escrito antes do início do experimento.
Design: unidade de randomização, meta de tamanho de amostra, MDE, métrica primária, métricas de proteção, alocação de tráfego.
Datas e amostra: data de início, data de fim, tamanho real da amostra obtido por grupo.
Resultado primário: estimativa pontual, intervalo de confiança de 95%, valor-p. Uma linha.
Métricas de proteção: tabela com delta, IC e aprovado/reprovado vs. limiar pré-registrado.
Cortes de segmento pré-registrados: mesma métrica, desagregada pelos segmentos comprometidos com antecedência.
Decisão: publicar / não publicar / iterar, com a justificativa diretamente ligada ao resultado.
Plano de reversão: se publicado, como monitorar em produção e o que aciona uma reversão.

O que não consta no documento de leitura: cortes de segmento post-hoc apresentados como descobertas, reformulações narrativas da hipótese ou conclusões "direcionais." Se um corte de segmento é exploratório, rotule-o como exploratório em uma seção claramente demarcada. O revisor deve conseguir identificar de relance quais números foram planejados e quais foram buscados.

A disciplina é o template. Quando todo experimento da organização usa o mesmo one-pager, os revisores param de ter que aprender o estilo pessoal de cada DS e passam a conseguir avaliar o trabalho de fato.

Por Que a Maioria dos Experimentos Falha

Depois de revisões suficientes, os modos de falha se agrupam em uma lista curta:

Amostra insuficiente. O cálculo de MDE não foi feito, ou foi feito e ignorado. O teste não poderia ter detectado o efeito que está sendo afirmado.
Hipótese vaga. Nenhuma previsão falsificável, nenhuma métrica primária comprometida, nenhum MDE. O experimento "é bem-sucedido" independentemente do que os dados dizem.
Unidade de randomização errada. No nível de sessão para uma pergunta de nível de usuário, ou no nível de usuário para uma pergunta de marketplace com interferência.
Sem métricas de proteção. A primária ganhou, a equipe publicou, a latência regrediu 8% e três semanas depois alguém percebe que a receita caiu.
Sem plano de reversão. O código foi publicado, o experimento foi declarado concluído e ninguém monitorou a produção. A mudança deriva e ninguém consegue atribuir a deriva ao lançamento.
Confundido com outro lançamento. O experimento foi executado durante uma ação de marketing ou uma atualização de UI que atingiu os dois grupos. O efeito estimado é o experimento mais o confundidor, e você não consegue separá-los.

Cada um desses é evitável na fase de design. Nenhum deles é corrigível após a coleta de dados.

Evitando o HARKing

HARKing (da sigla em inglês para "formular hipóteses após conhecer os resultados") é a forma mais comum de autoenganação em experimentação. O padrão: você rodou um teste em toda a base de usuários, a primária foi nula, mas a variante parece ótima para "usuários no iOS nos EUA que chegaram via busca paga." Então isso vira o título.

O problema é puramente estatístico. Se você cortar seus dados em 20 segmentos, você esperaria que um deles atingisse p < 0,05 por acaso. Selecionar o vencedor depois de olhar todos os 20 e apresentá-lo como um resultado confirmado é, matematicamente, fraude. Você encontraria o mesmo "efeito" em um lançamento de moeda se dividisse suficientemente.

A correção é o pré-registro. Antes do início do experimento, escreva:

A métrica primária.
Os cortes de segmento exatos que você vai relatar (por exemplo, usuários novos vs. recorrentes, mobile vs. desktop, top 3 mercados), e apenas esses.
Qualquer subgrupo que você compromete como análise confirmatória.

Qualquer coisa que você encontrar depois vai para uma seção claramente rotulada como "Exploratório," com uma observação de que os valores-p não são corrigidos para múltiplos testes e que a descoberta precisa de um experimento de acompanhamento para ser confirmada. Nunca chame um resultado de subgrupo post-hoc de "significativo." Chame-o de hipótese para o próximo teste.

A correção cultural é mais difícil do que a técnica. Quando uma parte interessada está desesperada por uma vitória e o corte post-hoc a entrega, a pressão para legitimá-la como um resultado confirmado é real. A disciplina do pré-registro (escrevê-lo antes) é o que lhe dá respaldo para resistir.

Disciplina Contra Espiadelas

Aqui está um número que surpreende as pessoas: se você verifica a significância do seu A/B test todos os dias por duas semanas, sua taxa efetiva de falsos positivos não é 5%. É próxima de 14%. Talvez maior, dependendo de quão agressivo você for ao parar cedo.

O motivo é o problema de testes sequenciais. Um t-test ou z-test padrão é calibrado para uma única olhada nos dados, após a coleta de uma amostra pré-comprometida. Cada olhada adicional é outra chance para o ruído aleatório cruzar o limiar. Se você espiadela e para, está selecionando o momento mais extremo em um passeio aleatório e o relatando como um resultado fixo.

Você tem duas opções limpas:

Comprometer-se com o tamanho da amostra. Calcule n, rode o teste até atingir n, e olhe para o resultado uma única vez. Sem dashboards diários influenciando decisões de parar/publicar. Monitorar métricas de proteção por segurança é aceitável; usar a métrica primária para encerrar o experimento cedo não é.
Usar um método de teste sequencial. mSPRT (mixture sequential probability ratio test), designs sequenciais em grupo com funções de gasto de alfa, ou métodos Bayesianos implementados corretamente com priors informativos. Esses permitem que você espiadle com a frequência que quiser com inferência válida, ao custo de uma amostra ligeiramente maior para compensar.

O que você não pode fazer é rodar um teste de horizonte fixo, espiadela diariamente e parar no momento em que p cruza 0,05. Esse é o gerador de falsos positivos mais comum na experimentação industrial, e é o motivo pelo qual "vitórias publicadas" rotineiramente não se replicam quando medidas corretamente depois.

A correção é processual. Escreva a regra de parada no documento de design. "Vamos rodar por n = 17.000 por grupo, estimativa de 8 dias, e ler o resultado uma única vez." Se a equipe não consegue resistir ao dashboard, esconda a métrica primária da visualização ao vivo e apenas exponha as métricas de proteção. A disciplina é o design.

Conclusão

O documento de leitura que sobrevive à revisão é aquele em que as decisões de design foram tomadas antes do início da coleta de dados. A hipótese era específica. O tamanho da amostra foi calculado. A unidade de randomização foi justificada. As métricas de proteção foram pré-registradas. Os cortes de segmento foram comprometidos com antecedência. A regra de parada foi escrita.

Todo o resto é narrativa. E narrativa é ótima para a seção descritiva do documento de leitura, mas não pode ser a base de uma decisão de publicação.

A batalha que você vence é a travada antes da coleta de dados. Invista uma hora no documento de design. É a hora mais barata que você vai gastar no trimestre, e é a que decide se o seu experimento sobrevive à revisão ou entra silenciosamente na pilha de testes "direcionalmente positivos" que ninguém consegue reconstruir seis meses depois.

Playbooks para Data Scientists