O que você precisa saber sobre testes A/B para não pisar na jaca

Erick Farias
iFood Tech
Published in
20 min readAug 20, 2020

O que gigantes digitais como Amazon, Facebook, Google, Microsoft e Netflix têm em comum? Entre outras coisas, todos concordam que experimentação é um game changer como motor de inovação e crescimento sustentável.

A revista Harvard Business Review dedicou recentemente (mar/2020) uma edição focada na criação de uma cultura de experimentação, analisando diversos estudos de caso e dando sugestões poderosas, como a democratização da experimentação. Cursos de gerenciamento de produto e inovação possuem módulos inteiros sobre isso. Equipes são criadas para desenhar e monitorar testes. Está mais do que claro que realizar experimentos a rodo é a melhor forma de cultivar ideias disruptivas.

Mas não há como fugir do inevitável: a execução impecável de testes A/B exige um monte de fórmulas matemáticas, noções estatísticas e decisões não tão sexy que precisam ser tomadas no dia a dia. E democratizar uma cultura de experimentação passa pelo conhecimento razoável desses pormenores.

A ideia desse artigo não é ser um guia exaustivo, como os Ultimate Guides publicados no Medium. Mas, sim, um bom resumo de algumas centenas de páginas de conteúdo, com o suficiente para ninguém pisar na jaca quando precisar rodar um teste A/B.

Quanto menos fatos, mais fortes são as opiniões — Arnold Glasow

O que é um teste A/B?

Começamos com um problema de negócio.

Um KPI que precisa subir ou descer, certo? Considere a taxa de conversão média por usuário, por exemplo. Então fazemos uma análise e percebemos que usuários que utilizam iOS possuem uma taxa de conversão mais alta. Existe uma correlação aqui, uma associação. Mas faz sentido pensar que se iPhones forem distribuídos para todos os usuários, a conversão deles irá aumentar? Você sabe que não.

Isso acontece porque duas métricas podem estar associadas, sem que
necessariamente uma cause a outra. Nesse caso, podemos supor que existe uma outra variável oculta que tem efeito sobre o tipo de celular que um usuário possui e sua taxa de conversão. Renda, por exemplo. Talvez essa variável possa ser medida, talvez não.

O que eu posso fazer para saber se minha ideia de Papai Noel vai funcionar para aumentar a conversão? É aqui onde os experimentos entram. Um experimento te dá permissão de dizer que uma coisa causa outra com algum grau de incerteza. Isso é possível ao distribuir os usuários de forma aleatória entre dois ou mais grupos (ex. ganhar iphone, não ganhar iPhone). Formalmente eles são conhecidos como Randomized Controlled TrialsRCTs.

Randomized se refere ao fato de que a atribuição de um usuário à mudança que será testada é feita de forma aleatória. Isso faz com que todas as características que influenciam o resultado sejam distribuídas de forma aproximadamente igual entre os grupos. Assim, podemos ignorar características não observadas que possam ter um efeito sobre o resultado do teste.

Controlled se refere ao fato de que alguns usuários (ou sessões) são deixadas de lado como um grupo controle que não receberá nenhuma mudança.
Ao realizar essa distribuição aleatória, eu posso razoavelmente interpretar as
diferenças entre os resultados como um efeito da minha intervenção.
Dessa forma, podemos estabelecer um raciocínio contrafactual, onde o tomador de decisão possui evidências para responder “o que aconteceria se…”.

Realizar testes permite a inovação e melhoria contínua de produtos e serviços, enquanto o risco da mudança é controlado. Sem experimentos, as decisões de negócios são baseadas em esperança ao invés de evidências. É claro, essas “esperanças” podem ser mais ou menos realistas com base em análises e opiniões de especialistas, mas se os dados mostram de forma confiável que A é melhor que B, de que importa se um especialista acha B uma boa ideia?

Como planejar um teste A / B

Podemos resumir um bom planejamento de um teste A/B em pelo menos 4
perguntas que precisam ser bem respondidas para evitar aquela pisada na jaca.

Elas são as seguintes:

  1. Considerando nossos recursos infinitos, o que podemos fazer para melhorar X da forma mais sustentável e efetiva em termos de custo? (substitua X pelo KPI da vez)
  2. Quais são suas hipóteses estatísticas?
  3. Quão rígido meu experimento precisa ser para suportar decisões relevantes?
  4. Vou precisar espiar os resultados ou posso esperar o teste terminar?

Vamos abordar cada uma delas em detalhes.

1. Considerando nossos recursos infinitos, o que podemos fazer para melhorar X da forma mais sustentável e efetiva em termos de custo? (substitua X pelo KPI da vez)

Todo teste A/B deveria começar com um (ou mais) KPIs que precisam ser
otimizados. Ah, e uma ação padrão.

O que é uma ação padrão? Você possui uma ideia, baseada em algumas análises, opiniões, papers e meetups, e você irá implementá-la a não ser que haja evidências para acreditar que é uma má ideia. Isso é uma ação padrão. É o que você está decidido a fazer com o melhor do seu instinto profissional. (“Fazer nada, a menos que…” também pode ser uma ação padrão).

Suponhamos que precisamos melhorar o KPI de ARPU (Average Revenue per User) e a ação padrão da Product Manager responsável pelo carrinho de compras de um comércio on-line é implementar uma recomendação de itens no momento do checkout. Ela mudará de ideia somente se houver uma queda desse KPI ao implementar a nova feature.

Testes A/B custam caro. Exigem um trabalho meticuloso de analistas. Em contextos de negócio, experimentos desse tipo devem ser executados para informar ações e não para mudar opiniões. Se você não sabe qual KPI quer melhorar e não possui uma ação padrão para isso, você provavelmente não precisa de um teste A/B.

2. Quais são suas hipóteses estatísticas?

Agora que sabemos o problema, precisamos traduzir isso em hipóteses
estatísticas.

Hipóteses estatísticas compactam nossas premissas sobre o mundo que irá gerar os dados do nosso experimento. Elas carregam implicações a respeito do que fazer, considerando nossa ação padrão. Note que, após responder a primeira pergunta, você provavelmente terá uma afirmação sobre a direção do efeito esperado de alguma mudança. No caso, esperamos que a implementação do carrinho não tenha um impacto negativo no ARPU.

Agora, precisamos traduzir essa afirmação em uma Hipótese Nula que traduza esse efeito esperado. Uma hipótese nula descreve as circunstâncias que tornariam a sua ação padrão em uma ação feliz: “A diferença de ARPU entre a versão do carrinho padrão e a versão com recomendação de itens é maior ou igual a zero.”

Pense na sua hipótese nula como aquilo que você vai aceitar como verdade, a menos que você fique surpreso o suficiente com evidências do contrário.

Também precisamos de uma Hipótese Alternativa, que é o contrário da Hipótese Nula. Tudo que é verdade quando a hipótese nula for falsa: “A diferença de ARPU entre a versão do carrinho padrão e a versão com recomendação de itens é menor que zero.”

Isso deixa as coisas organizadas para que realizemos um teste de hipótese que nos permitirá responder à pergunta: A evidência que nós coletamos faz nossa hipótese nula parecer ridícula? — mais sobre isso na seção “Analisando os Resultados do Teste”.

Daqui em diante, consideramos que você entende o que são o Z-Score, variância e desvio-padrão. Se esses termos não fazem sentido pra você, dê uma olhada no apêndice A.

3. Quão rígido meu experimento precisa ser para suportar decisões relevantes?

Esse é seu teste A/B.

Imagine seu experimento como um radar. O que você espera que ele te mostre? Eu imagino que seja o seguinte:

  • Se um ponto aparecer, quero ter certeza de que é uma ameaça (um míssil, outro avião) e não uma andorinha, por exemplo;
  • Se não houver nada ali, quero ter certeza de que realmente não há nenhuma ameaça.

Se o seu radar te mostra um ponto de ameaça, quando na verdade aquilo é uma andorinha, ele cometeu um erro do tipo I: identificou uma diferença quando na verdade não há nenhuma.

Se o seu radar não mostra nada quando na verdade um míssil está vindo na sua direção, ele cometeu um erro do tipo II: não identificou uma diferença quando na verdade existia uma.

Bem, como não queremos que nosso teste A/B cometa os mesmos erros,
precisamos construí-lo para que as probabilidades desses erros sejam
controladas. A boa notícia é que conseguimos fazer isso (e não é difícil ).
Para tanto, precisamos estabelecer duas medidas:

  • Nível de confiança do teste. A probabilidade de cometermos um erro do tipo I é denotada pela letra grega alpha. O inverso disso (1-alpha) é chamado de nível de confiança: a probabilidade de você se surpreender com uma diferença e ela, de fato, ser verdadeira. Então, se você definir um nível de confiança de 95%, isso quer dizer que a cada 100 testes que você realizar, 5 parecerão surpreendentes o suficiente para que você rejeite a hipótese nula, quando na verdade ela não deveria ser rejeitada.
  • Tamanho da amostra. A probabilidade de cometermos um erro do tipo II é denotada pela letra grega beta. O inverso disso (1-beta) é chamado de poder: a probabilidade de você se surpreender com uma diferença, se ela existir. Controlar o poder de um teste te dá a “segurança” de que, se seu teste não for significante, a probabilidade de que não haja nada escondido nos dados é baixa. Para fazermos isso precisamos decidir qual é o efeito mínimo de interesse (MEI) que queremos detectar. 5% de variação? 10%? Qual é o mínimo aceitável? 1% de variação é relevante? O poder de um teste e o respectivo efeito mínimo de interesse indicam a sensibilidade dele em relação a esse valor. Quanto menor esse número for, maior será a quantidade de amostras necessárias.

Com base nessas decisões, podemos calcular o tamanho mínimo da amostra que precisamos ter em cada grupo:

Essa fórmula mostra que o tamanho mínimo da amostra é igual ao Z-score do
nível de confiança
somado ao Z-score do poder do teste, multiplicado pela
variância da métrica testada. Isso tudo dividido pelo efeito mínimo de interesse, elevado ao quadrado.

Se você souber o tamanho total da sua população, é possível utilizar uma fórmula que realiza uma correção por conta da população finita e resulta em tamanhos mínimos menores, principalmente quando a população é pequena:

Em relação à formula anterior, todos os parâmetros continuam os mesmos, exceto por N, que denota o total conhecido da população.

Um ponto importante: como saber a variância da métrica se o teste ainda não foi realizado? Ela precisa ser conhecida ou estimada. Recomenda-se utilizar dados históricos para fazer isso.

E depois de calcular o tamanho da minha amostra, eu posso atribuir 80% delas para receber a mudança e 20% para o controle?

É completamente possível calcular o total de amostras necessárias para o teste e dividi-las de forma desigual (80% para a variante, 20% para o controle, ou vice-versa). Mas você deveria fazer isso?

A recomendação geral é: não faça, a não ser que haja uma justificativa muito boa. Todas as referências consultadas que comentavam sobre esse ponto indicaram que a alocação desigual entre os grupos aumenta significantemente o tempo necessário para se executar um teste, comparado a designs com alocação igual.

O efeito direto é a diminuição do poder do teste, dado que a maioria das
estimativas estatísticas dependem da comparação da variância entre-grupos coma variância intra-grupos. Como uma delas será estimada com menos precisão, por conta da quantidade reduzida de amostras em relação ao ideal, o poder do procedimento como um todo é reduzido.

Isso causa p-valores maiores, intervalos de confiança mais amplos e uma menor severidade do teste. Além de algumas correções importantes para testes de múltiplas variantes não serem aplicáveis a designs de alocação desigual.

E se eu tiver mais de uma variante? Bem, a coisa complica um pouco, mas nem tanto. Dê uma olhada no apêndice D.

Uma nota importante: Em tempos de big data, praticantes de teste A/B tendem a ser relapsos em relação ao tamanho da amostra. Entretanto é válido lembrar que para efeitos de interesse pequenos (1% de aumento relativo, por exemplo), a quantidade de amostras por grupo pode facilmente escalar para mais de dois milhões, para níveis aceitáveis de confiança e poder. Portanto, é importante que o analista que planeja os testes consiga entender os trade-offs entre nível de confiança, poder, efeito mínimo de interesse, tamanho de amostra e a escolha de métrica de avaliação, para definir o design ideal dado o tempo e o budget disponível para o teste.

4. Vou precisar espiar os resultados ou posso esperar o teste terminar?

Existe a possibilidade de seu teste precisar rodar durante dias, semanas e até
meses. A maioria das estatísticas calculadas consideram o caso onde os dados são analisados somente quando o teste está concluído.

Entretanto, dependendo da duração do teste, pode ser lucrativo ter um critério de término antecipado (early stopping), caso as mudanças sejam muito positivas ou muito negativas, por exemplo.

Os dois principais casos nos quais temos testes rodando durante um longo
período geralmente tem a ver com (1) tamanho da amostra ou (2) mensuração de um comportamento ao longo do tempo. Em ambos os casos, espiar os resultados do teste antes da conclusão causa a inflação da probabilidade de erro (sim, isso parece magia negra).

Um estudo publicado por Armitage, em 1969, por exemplo, mostra que uma única espiada aumenta a probabilidade de cometer um erro do tipo I em 170% e 4 espiadas aumenta em quase 300%. Considerando esse problema, vários métodos de teste sequencial foram desenvolvidos, para permitir que um teste seja “monitorado” durante sua execução e finalize caso atrapasse um certo limiar. Conforme recomendado por Georgiev, a melhor forma de lidar com esses casos é utilizar limites de eficácia, discutidos de forma resumida no apêndice E.

Analisando os resultados do teste

O teste de hipótese

Lembra das nossas hipóteses estatísticas? Agora precisamos testá-las, antes de
tomar nossas decisões. Isso consiste basicamente em:

  • Calcular a média das observações no grupo testado;
  • Calcular a média das observações no grupo controle;
  • Calcular o desvio-padrão combinado de ambos os grupos;
  • Calcular qual a distância da média do grupo testado em relação à média do grupo controle, utilizando o desvio-padrão combinado (Z-score);
  • Verificar se há motivos para ficarmos surpresos.

Importante: todos os testes aqui pressupõem uma distribuição normal, homogênea e independente. Essas premissas estatísticas fazem sentido para a grande maioria dos testes A/B. Se tiver fé em mim, siga o jogo, caso contrário, veja nota sobre isso no apêndice B.

Para diferença de proporções, o cálculo do desvio padrão combinado é:

O cálculo da proporção combinação é:

E o Z-score é:

Onde p1 e p2 são as proporções observadas nos dois grupos do teste e n1 e n2
são a quantidade de observações em cada grupo.

Para diferenças de médias, o desvio padrão combinado é:

E o Z-score do teste é:

Assim que tivermos a estatística Z do teste calculada, precisaremos calcular
nosso fator de surpresa. Formalmente conhecido como p-valor.

O que é um p-valor? Ele é simplesmente a probabilidade (variável entre 0 e 1) de se observar um valor maior ou igual ao z-score resultante do seu teste A/B, considerando que a hipótese nula seja verdadeira. Não fez sentido? Em outras palavras, ele indica o quanto você deve ficar surpreso com seu resultado, considerando que as circunstâncias descritas na hipótese nula sejam verdadeiras (espero ter melhorado).

Para calcular o p-valor de um z-score você pode usar fórmulas prontas no excel, em python, em R etc. Por exemplo, imagine um teste que resultou em um z-score de 1.3. O p-valor desse z-score é 0.097. Isso quer dizer que, considerando que a a hipótese nula seja verdadeira, há cerca de 9.7% de probabilidade de se observar um valor tão alto quanto esse.

E daí?

Para saber se você deveria ficar surpreso(!!) e rejeitar sua hipótese nula, você
precisa comparar seu p-valor ao nível de confiança do seu teste, que foi definido no planejamento do teste para controlar o erro do tipo I. Se você considerou um nível de confiança de 95%, seu alpha será 1–0.95 = 0.05.

Se seu p-valor for menor que seu alpha, então você tem motivos para parecer
ridículo agindo como se sua hipótese nula fosse verdadeira. Interprete-o como um fator de surpresa!

“Certo, então se meu teste resultou em p-valor de 0.20, e estou considerando um nível de confiança de 95%, quer dizer que hipótese nula é verdadeira?” Bem, não necessariamente.

Não costumamos dizer que a hipótese nula é verdadeira, mas simplesmente que não ficamos surpresos o suficiente para rejeitá-la. Pode ser que haja outras hipóteses que explicam os dados melhor do que ela, mas isso é papo para outra hora.

O que importa agora é que para ter maior confiança de que realmente sua
hipótese nula não deve ser rejeitada você precisa ter controlado o erro do tipo II no design do seu teste ao definir um tamanho de amostra suficiente. Caso
contrário… Bem, sinto muito.

Intervalos de confiança

Os resultados de um teste também podem ser apresentados através de um
intervalo de confiança. Ele indica uma faixa de valores dentro da qual os
resultados do seu teste estarão X% das vezes, caso você faça o mesmo teste
outras vezes, sendo X o seu nível de confiança. Ele é calculado da seguinte forma, para um intervalo de duas caudas:

onde Z é o Z-score do nível de confiança do seu teste.

Se um intervalo de confiança de 95% resulta em valores entre (2, 18), por
exemplo, podemos dizer que se repetirmos esse teste 100 vezes, a diferença das médias estará entre 2 e 18 unidades em 95 desses testes. Todas as interpretações do p-valor e do intervalo de confiança precisam estar associadas às hipóteses e o procedimento de teste. Sem esse contexto, eles perdem seu sentido.

Cuidados ao analisar segmentos: o problema de realizar vários testes de hipótese

É natural que, após termos os resultados de um teste, seja interessante analisar se as diferenças estatísticas são iguais ou diferentes para segmentos específicos de usuários. Por exemplo, eu posso querer analisar se a diferença observada no resultado do teste continua igual quando comparo usuários de diferentes sistemas operacionais.Ou então, pode ser necessário realizar testes de hipóteses para mais de uma métrica.

Um exemplo disso pode ser uma feature que, para ser lançada, depende de uma diferença positiva na métrica de ARPU, contanto que não haja uma queda na frequência média por usuário.

Embora sejam situações não muitos comuns, nesse cenário, precisamos controlar o que é chamado de Family-Wise Error Rate (FWER), caso pelo menos um resultado significante possa decidir o resultado do seu experimento.

FWER é a probabilidade de que pelo menos 1 dos (vários) testes seja significante.

Agora, pense comigo. Se ao realizar um teste com 95% de confiança, eu tenho
95% de probabilidade de enxergar uma diferença e ela ser, de fato, verdadeira, o que acontece quando eu realizo esses 6 testes? É só fazer a conta: 0.95 * 0.95 * 0.95 * 0.95 * 0.95 * 0.95… Essa probabilidade passa a ser 73.5%. Ou seja:

Quanto mais eu fatiar e revirar os meus dados, maior a probabilidade de eu encontrar alguma coisa que parece interessante, mas na verdade é puro ruído.

Para corrigir isso, é necessário realizar correções nos p-valores dos testes, para que eles digam com precisão o quanto devo ficar surpreso ao analisá-los.

Podemos fazer isso utilizando a correção de Holm-Bonferroni, correção de
Dunnett, a correção de Šidák ou outras. Nesse artigo vamos explicar a correção de Šidák, por ter um bom equilíbrio entre complexidade de implementação e rigidez.

  1. Primeiro, os p-valores dos testes são computados da forma usual;
  2. Então, os p-valores devem ser ordenados de forma crescente, do menor pro maior;
  3. Finalmente, para cada p-valor, do menor para o maior, calcule:

Os p-valores resultantes podem ser analisados como de costume. E sempre lembre da lei de Twyman: números que parecem interessantes ou diferentes geralmente estão errados.

Melhorando o poder de generalização dos seus testes

Quando finalizamos um teste, queremos utilizar os resultados para tomada de
decisões, obviamente. Os resultados observados precisam ser generalizáveis a usuários semelhantes aos que participaram do teste.

Para isso, precisamos que a amostra utilizada no teste seja representativa da
população (base de usuários, no caso). Fracassar nesse quesito significa que todo o trabalho até aqui foi simplesmente em vão. Podemos separar as ameaças à capacidade de generalização de um teste em 3 grupos:

  • Fatores relacionados ao tempo. Alguns comportamentos variam de acordo com o horário, dia da semana ou época do ano. Essas sazonalidades precisam ser consideradas ao se decidir o período de execução de um teste e como seus resultados serão generalizados. Outro ponto a ser considerado é que experimentos curtos podem falhar em
    capturar efeitos em usuários que demoram mais para reagir a um certo
    estímulo. O tempo de execução de um teste também precisa levar isso em
    consideração.
  • Fatores relacionados à mudança da população. Um exemplo trivial seria a execução de uma grande campanha promocional pela própria companhia. Isso pode interagir com o teste e causar resultados que não são generalizáveis. Fatores externos que podem causar mudanças na população precisam ser avaliados.
  • Fatores relação à novidade/aprendizado. Usuários tendem a ter reações fortemente positivas ou negativas a alguma grande mudança, que tendem a suavizar ao longo do tempo. Testes curtos após mudanças significativas podem não generalizar bem para o restante da população por capturar somente essa reação brusca e temporária dos usuários.

Existe uma solução que endereça, de certa forma, quase todas essas ameaças: testes sendo executados por um período mais longo.

Referências
Georgiev, G. (2019) ”Statistical Methods in Online A/B Testing: Statistics for data-driven business decisions”

Kohavi, R. et al. Controlled experiments on the web: survey and practical guide

Dmitriev, P. et al. A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in
Online Controlled Experiments

Dunnet, C. A Multiple Comparison Procedure for Comparing Several Treatments
with a Control

van Belle, G. (2002) Statistical rules of thumb. Wiley, ISBN- 0471402273

Feit, E. Test & Roll: Profit-Maximizing A/B Tests

Apêndice A: Z-scores e desvio-padrões

Precisamos de uma forma para calcular qual a discrepância (ou distância) entre nossas observações e um certo valor esperado.

Uma dessas medidas é a variância, que é a média aritmética das diferenças entre cada observação e a média dessas observações:

Elevar as diferenças ao quadrado é uma forma de “punir” desvios grandes e
garantir que desvios negativos não vão “cancelar” os positivos. Mas não é muito bacana trabalhar com a variância, já que ela está em unidades ao quadrado.

Uma estatística mais conveniente é o desvio padrão, que quantifica a dispersão dos dados na unidade de medida original desses dados. Para obtê-lo, você só precisa calcular a raiz quadrada da variância.

Agora, imagine que um certo teste tenha resultado em uma diferença de 12%, ao comparar o grupo intervenção com o grupo controle, e o desvio padrão da
distribuição seja de 6%. Ao dividir a diferença observada pelo desvio padrão, nós obtemos um standard score, que quantifica a distância do resultado em relação a média, em desvios padrões.

Nesse caso, 12% / 6% = 2; o resultado do teste está 2 a desvios padrões da média. Quando a distribuição das observações é normal, o standard score é chamado de Z-score. Se as observações possuírem uma distribuição diferente, como X2 ou T, o score será chamado de T-score, ou X2-score, por exemplo.

Apêndice B: Premissas probabilísticas do teste

Para que as probabilidades que calculamos façam sentido na avaliação de um
teste A/B, precisamos assumir algumas premissas a respeito do modelo estatístico sendo considerado. Podemos dividir essas premissas em 3 grandes grupos:

  1. Distribuição: adistribuição das observações pode ser Normal, Poisson, Binomial, Exponencial, etc. Diferentes distribuições carregam diferentes testes estatísticos.
  2. Dependência: em resumo, dois eventos são independentes quando a ocorrência de um não afeta a probabilidade de outro acontecer. Existem diferentes tipos de dependência, mas o importante é que para nossos testes, assumimos que os eventos são independentes.
  3. Homogeneidade: dizemos que um processo estocástico é homogêneo quando toda a distribuição subjacente possui a mesma média e desvio-padrão.

Para os testes A/B explicados nesse artigo, assumimos que os dados são
normalmente distribuídos, independentes e homogêneos. Se houver razões para acreditar que essas premissas são inválidas, é necessário ajustar o modelo estatístico utilizado para que as conclusões sejam válidas.

Talvez a premissa que cause mais discussão seja a primeira. Muitos praticantes, preocupados sobre os dados não possuem uma distribuição normal e acabam aplicando outros tipos de testes estatísticos. Quando analisamos o dado de frequência por usuário, por exemplo, é muito provável que observemos dados distribuídos exponencialmente. Algo mais ou
menos assim:

Entretanto, não estamos testando frequência por usuário, mas sim a diferença de frequência média por usuário. E assim como qualquer média aritmética, a
frequência média (ou receita média, etc) possui uma distribuição assintoticamente normal.

Portanto, quando trabalhamos com amostras grandes, a distribuição pode ser assumida como aproximadamente normal pelo Teorema do Limite Central, a despeito da distribuição dos dados originais.

Uma preocupação mais válida é a respeito da premissa de independência. Quando se opta por utilizar métricas baseadas em sessão e não em usuários, por exemplo, podemos ter um problema, já que um usuário pode ter múltiplas sessões e o comportamento em uma sessão pode depender de uma sessão anterior, invalidando a premissa de independência e afetando a precisão dos nossos resultados.

Apêndice C: E seu eu tiver mais de uma variante?

Experimentos com mais de uma variantes são frequentemente chamados de MVT (multi variant tests) ou testes A/B/n, com alguma variação na literatura.

Eu preciso de um MVT?

MVTs são necessários quando é preciso realizar comparações entre o resultado de diferentes intervenções. Imagine que, fazendo parte de um time de CRM, temos 2 tipos de cupons de desconto e queremos testar os efeitos de:

  • Cupom A vs cupom B;
  • Cupom A vs controle;
  • Cupom B vs controle;
  • Cupom A+B vs cupom A;
  • Cupom A+B vs cupom B;
  • Cupom A+B vs controle.

Ignorando as métricas escolhidas e outras questões de design do teste,
possuímos um MVT com 4 variantes [cupom A, cupom B, cupom A+B, controle] e 6 testes de hipótese que precisarão ser realizados para se analisar os resultado sdo teste.

Uma forma ingênua de fazer isso seria realizar todos os testes da forma convencional e reportar os resultados com base nos p-valores ou intervalos de confiança de cada teste. Entretanto, nesse cenário, precisamos controlar o que é chamado de Family-Wise Error Rate (FWER). Discutimos como fazer isso de uma forma simples na seção Cuidados ao analisar segmentos.

Apêndice D: Monitoramento Sequencial

Um dos métodos recomendados por Georgiev para se realizar o monitoramento sequencial de um teste é chamado Alpha Spending Function.

A maior vantagem desse método em relação a outros é que ele permite que a
quantidade e o momento das análises parciais do teste variem de acordo com a vontade do analista, sempre controlando a probabilidade de erro do tipo I.

Esse método consiste, basicamente, em recalcular o alpha do teste cada vez que uma análise é realizada, de acordo com a proporção da amostra total já coletada. A fórmula é simples:

onde t é a proporção da amostra já coletada, e rho é um fator de correção.

Georgiev recomenda utilizar um rho = 3, de forma que o teste se torna
conservador desde o começo, exigindo diferenças maiores para que seja
terminado mais cedo quando a proporção das amostras observadas for baixa.

Imagine, por exemplo, que no dia seguinte após iniciar um teste, precisemos fazer uma análise parcial. Aha! Aparentemente há uma diferença significante, dado que o p-valor do teste é de 0.03. Devemos parar o teste? Bem, recalculando o alpha, considerando que temos só 10% da amostra total coletada, e um rho de 3, como recomendado temos:

Ou seja, com apenas 10% dos dados coletados, precisaríamos ter um p-valor
menor que 0.00005 para realmente ficarmos surpresos com esse resultado
parcial!

Quer receber conteúdos exclusivos criados pelos nossos times de tecnologia? Inscreva-se.

--

--

Erick Farias
iFood Tech

Data Science leader, researcher, miniature painter, rock climber. Linkedin: https://www.linkedin.com/in/erickcfarias/