Métricas de Tempo até o Evento em Teste A/B
Quando a métrica é um tempo, e não uma taxa, a censura distorce a média. Como ler tempo até o evento com Kaplan-Meier, RMST e log-rank em teste A/B.

📚 Este artigo faz parte do guia Significância Estatística em Teste A/B: O Guia.
Quando a métrica do seu teste é um tempo, e não uma taxa, a média simples mente por construção: ela só consegue somar quem já teve o evento, e quem demora mais fica de fora. Na simulação deste guia a média ingênua encolheu um efeito real de 1,4408 semana para 0,2063 semana, quase sete vezes menos, enquanto a curva de Kaplan-Meier e o log-rank leram o mesmo efeito com z de 10,9053. Este guia mostra o que é censura à direita, por que ela quebra a média e as taxas de retenção, como ler a curva inteira em vez de uma fatia, e quando a troca compensa. Faz parte do nosso guia completo de teste A/B e complementa métrica substituta e holdout de longo prazo.
O problema: a métrica que importa é um relógio, não um interruptor
A maioria das métricas de teste A/B é binária. O usuário comprou ou não comprou. Clicou ou não clicou. Isso funciona muito bem quando o evento acontece dentro da sessão, e é por isso que a conta de duas proporções domina o mercado.
Só que boa parte das decisões de produto é sobre permanência, e permanência é um relógio. Quanto tempo até o usuário cancelar. Quanto tempo até ele fazer a segunda compra. Quanto tempo até ele passar uma semana inteira sem abrir o app.
O jeito padrão de transformar relógio em interruptor é escolher uma data e perguntar “estava ativo no dia 7?”. Isso resolve o problema de formato e cria dois problemas novos.
O primeiro é que a data é arbitrária. Retenção em D7 e retenção em D30 medem coisas diferentes, e podem discordar. Escolher qual reportar depois de ver os dois é exatamente o tipo de liberdade que o plano de análise pré-registrado existe para fechar.
O segundo é mais sutil e é o assunto deste guia: transformar em binário joga fora a informação de quanto tempo. Dois usuários que cancelaram, um no dia 8 e outro no dia 180, entram na conta de “não retido em D7” com o mesmo peso. E o usuário que ainda está ativo no último dia do teste entra como “retido” sem que ninguém saiba se ele vai durar mais uma semana ou mais três anos.
Chandar, St. Thomas, Maystre e coautores, num trabalho do Spotify apresentado na WWW 2022, tratam esse desenho como um problema de tempo até o evento e propõem uma métrica de tempo até a inatividade justamente porque, nas palavras deles, o desfecho de retenção não é observável no fim do teste A/B.
Censura à direita, em uma frase
Censura à direita é o usuário que chega ao fim da janela de observação sem ter tido o evento. Você sabe que o tempo dele é maior que a janela. Não sabe quanto.
Repare no detalhe que faz toda a diferença: os censurados não são um caso aleatório. Eles são, por definição, os usuários que duraram mais. Descartá-los é o mesmo erro de raciocínio do atrito diferencial, com outra origem: o dado que some não some por acaso.
Chandar e coautores dão o exemplo mais didático que já vimos disso. Considere duas coortes com tempo médio verdadeiro até a inatividade de 2 e de 36 semanas. Se você tentar estimar esse tempo na semana 10 ignorando os censurados, o resultado é uma subestimação severa. Na coorte de 36 semanas, quase ninguém teve o evento ainda, e a média será calculada sobre a minoria atípica que saiu cedo.
Exemplo trabalhado: o mesmo teste lido de quatro jeitos
Simulamos um teste de retenção com 12.000 usuários por braço e janela de observação de 12 semanas. O evento é ficar uma semana inteira inativo. A verdade do mundo simulado: no controle, a chance semanal de ficar inativo é de 11,0 por cento; na variação, 9,5 por cento. Ou seja, a variação é genuinamente melhor, e é melhor de um jeito constante ao longo do tempo.
Leitura 1: retenção binária, a que quase todo mundo usa
A primeira leitura é a padrão de mercado: escolher uma semana e contar quem ainda estava ativo. Esses números você pode conferir agora na calculadora:
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.
Cole 12000 visitantes e 7497 conversões no controle, 12000 e 8080 na variação, e o resultado é o da linha da semana 4 abaixo.
| semana lida | controle | variação | lift relativo | z | valor-p | IC 95% da diferença |
|---|---|---|---|---|---|---|
| semana 2 | 9.540 / 12.000 (79,5000%) | 9.819 / 12.000 (81,8250%) | +2,9245% | 4,5600 | 5,12e-6 | [1,3261 pp; 3,3239 pp] |
| semana 4 | 7.497 / 12.000 (62,4750%) | 8.080 / 12.000 (67,3333%) | +7,7764% | 7,8849 | 3,11e-15 | [3,6523 pp; 6,0644 pp] |
| semana 8 | 4.718 / 12.000 (39,3167%) | 5.443 / 12.000 (45,3583%) | +15,3667% | 9,4716 | abaixo de 1e-20 | [4,7938 pp; 7,2895 pp] |
Três leituras corretas, três respostas diferentes. O lift relativo sai como mais 2,92 por cento, mais 7,78 por cento ou mais 15,37 por cento dependendo só de qual semana você escolheu antes de olhar. Nenhuma delas está errada; elas simplesmente respondem a perguntas diferentes.
O problema aparece quando a escolha da semana não foi feita antes. Aí você tem três chances de encontrar um número bonito, e o controle de erro Tipo I que você acha que tem não é o que você tem, pelo mesmo mecanismo descrito em muitas métricas em um teste.
Leitura 2: a média ingênua, a que erra feio
A tentação natural de quem quer sair do binário é calcular o tempo médio até o evento. E a implementação natural disso é somar o tempo de quem teve o evento e dividir pela quantidade.
| braço | censurados na semana 12 | média ingênua (só quem teve o evento) | média verdadeira (não observável) |
|---|---|---|---|
| controle | 2.954 de 12.000 (24,62%) | 5,1523 semanas | 9,0984 semanas |
| variação | 3.653 de 12.000 (30,44%) | 5,3586 semanas | 10,5392 semanas |
| diferença | 5,82 pp a mais de censura na variação | 0,2063 semana | 1,4408 semana |
A média ingênua não erra só o nível, ela erra o efeito. A diferença verdadeira entre os braços é de 1,4408 semana, e a média ingênua devolve 0,2063 semana, cerca de um sétimo. E o mecanismo é perverso: quanto melhor a variação, mais usuários dela ficam censurados (30,44 por cento contra 24,62 por cento), e mais a média dela é puxada para baixo pelo descarte. O viés trabalha contra exatamente o braço que você queria premiar.
Vale registrar que a média verdadeira da tabela acima só existe porque isto é uma simulação. Num teste real ela é inacessível: por isso a resposta não é “calcular a média direito”, é medir outra coisa.
Leitura 3: a curva de Kaplan-Meier
Kaplan-Meier resolve a censura sem descartar ninguém. A ideia é calcular, semana a semana, a probabilidade condicional de sobreviver àquela semana entre quem ainda estava sob observação, e multiplicar essas probabilidades. Um usuário censurado na semana 12 contribui para todas as semanas de 1 a 12 e depois simplesmente sai do denominador, sem ser contado como evento.
Repare na coincidência que não é coincidência: a curva do controle vale 0,6247 na semana 4, e a retenção binária da semana 4 deu 62,4750 por cento. É o mesmo número. A leitura binária não é uma alternativa à curva, é um ponto dela. Quando você reporta retenção em D7, está reportando um pixel de um gráfico que já tem e não olhou.
A tabela completa das duas curvas:
| semana | controle | variação | diferença |
|---|---|---|---|
| 1 | 0,8943 | 0,9032 | +0,0089 |
| 2 | 0,7950 | 0,8183 | +0,0233 |
| 4 | 0,6247 | 0,6733 | +0,0486 |
| 6 | 0,4890 | 0,5551 | +0,0661 |
| 8 | 0,3932 | 0,4536 | +0,0604 |
| 10 | 0,3154 | 0,3740 | +0,0586 |
| 12 | 0,2462 | 0,3044 | +0,0582 |
Leitura 4: RMST e log-rank, os dois números para reportar
Ter a curva inteira é ótimo para entender, e ruim para decidir: ninguém aprova um lançamento olhando doze pares de números. Duas reduções resolvem isso.
RMST (tempo restrito médio de sobrevivência) é a área sob a curva de Kaplan-Meier até um horizonte que você escolhe antes de olhar. É o tempo médio de permanência dentro daquela janela, e sai em unidade de tempo:
- controle: 6,8380 semanas dentro de 12
- variação: 7,3803 semanas dentro de 12
- diferença: 0,5423 semana, ou cerca de 3,8 dias a mais de permanência por usuário em doze semanas
Repare que 0,5423 é bem menor que a diferença verdadeira de 1,4408 semana da tabela da leitura 2, e isso está certo: o RMST responde uma pergunta menor e honesta (“quanto tempo a mais dentro de 12 semanas”), não a pergunta impossível (“quanto tempo a mais no total”). Ele não extrapola para além do que você observou. Essa é a virtude, não o defeito.
Log-rank é o teste que compara as duas curvas inteiras. Ele soma, semana a semana, a diferença entre os eventos observados num braço e os eventos esperados sob a hipótese de que as curvas são iguais:
| quantidade | valor |
|---|---|
| eventos observados na variação | 8.347 |
| eventos esperados sob hipótese nula | 9.027,66 |
| variância | 3.895,69 |
| estatística z | 10,9053 |
| valor-p bilateral | abaixo de 1e-26 |
| razão de risco (Peto) | 0,8397 |
A razão de risco de 0,8397 quer dizer que, a cada semana, o risco de o usuário da variação ficar inativo é cerca de 16 por cento menor que o do usuário do controle. É a tradução direta da vantagem de 11,0 contra 9,5 por cento de chance semanal que colocamos no mundo simulado, o que é uma boa checagem de sanidade da conta.
O ganho de sensibilidade em tempo até o evento, medido
Compare as duas leituras sobre exatamente os mesmos 24.000 usuários:
Uma ressalva honesta: comparar o z de um teste binário na semana 4 com o z de um log-rank não é comparar poder para a mesma hipótese, porque as hipóteses não são as mesmas. O que a comparação mostra é mais simples e ainda assim decisivo: a leitura binária descarta informação que a leitura de curva usa, e o preço disso aparece no tamanho do sinal.
A versão empírica desse resultado é o achado central do trabalho do Spotify. Chandar e coautores validaram a métrica de tempo até a inatividade em 51 testes A/B rodados nos produtos de recomendação e busca entre março e dezembro de 2020, cada um envolvendo milhões de usuários, restritos a testes com pelo menos 28 dias após um período de entrada de 7 dias. A conclusão que eles reportam: as métricas previstas de tempo até a inatividade são mais sensíveis que as métricas observadas de retenção, e o teste A/A de validação, com 432 valores-p re-sorteados, deu distribuição uniforme, o que descarta a explicação de que a sensibilidade maior vinha de falso positivo inflado.
Vale notar o que eles também acharam sobre a métrica binária: o poder discriminativo da retenção semanal na semana 4 é cerca do dobro do da semana 2. Ou seja, mesmo dentro do mundo binário, a escolha da data muda a sensibilidade por um fator de dois. É mais um argumento para não deixar essa escolha solta.
Quando usar cada métrica de tempo até o evento
Nada disso significa que retenção binária é errada. Significa que ela tem um domínio de validade.
| situação | leitura recomendada | por quê |
|---|---|---|
| evento acontece dentro da sessão (clique, compra imediata) | proporção simples | não há censura relevante; a conta de duas proporções basta |
| decisão precisa de um número por semana, quase todo mundo já teve o evento | proporção na data pré-registrada | censura baixa, viés pequeno, comunicação trivial |
| censura acima de 20 por cento no fim da janela | Kaplan-Meier + RMST | a média e a proporção começam a depender da janela |
| a variação muda a velocidade, não o total | curva inteira + log-rank | uma fatia única pode não ver nada ou ver tudo |
| a métrica é permanência e a decisão é de lançamento | RMST para comunicar, log-rank para decidir | RMST sai em unidade de tempo, que a diretoria entende |
| os braços têm janelas de observação diferentes | obrigatoriamente curva | proporção compara peras com maçãs; ver maturidade de coorte |
A última linha é a mais importante e a mais ignorada. Se um braço foi liberado em rampa e o outro não, os usuários dos dois braços não tiveram o mesmo tempo de exposição, e nenhuma proporção construída sobre “ativo no fim do teste” significa a mesma coisa nos dois lados.
As três premissas que você precisa checar
Análise de sobrevivência não é mágica, e tem premissas que dá para violar sem perceber.
1. A censura é não informativa. A premissa é que o tempo até o evento do usuário é independente do mecanismo de censura. Chandar e coautores registram que o modelo de Cox assume isso, e que a premissa é satisfeita quando o tempo de censura é fixo. Numa janela administrativa (o teste acabou no dia X para todo mundo), isso é razoável. Se a censura acontece porque o usuário desinstalou o rastreamento, não é: aí a censura carrega informação sobre o desfecho, e você está no território de perda de rastreamento.
2. Riscos proporcionais, se você usar Cox ou razão de risco. A razão de risco só é um número único se a razão entre os riscos dos dois braços for constante no tempo. No nosso mundo simulado ela é por construção. No mundo real, um efeito novidade forte quebra isso: o risco muda de razão ao longo das semanas, e reportar uma razão de risco única vira uma média sem sentido de coisas diferentes. O sintoma visual é curvas que se cruzam. O RMST não tem essa premissa, e é por isso que ele é a escolha mais segura quando você suspeita de efeito que varia no tempo.
3. O horizonte foi escolhido antes. RMST depende do horizonte. Escolher o horizonte que dá o melhor resultado é a mesma armadilha de escolher a semana da retenção binária, com um nome mais sofisticado. Fixe o horizonte no plano de análise, e prefira algo defensável: um múltiplo de semanas inteiras, pela razão de sempre, o ciclo semanal.
Como montar isso na prática
O trabalho não é estatístico, é de instrumentação. Para calcular Kaplan-Meier você precisa de duas colunas por usuário que quase nenhuma montagem de teste A/B guarda:
tempo: o número de períodos entre a entrada no teste e o evento, ou entre a entrada e o fim da observação, o que vier primeiro.evento: 1 se o evento aconteceu dentro da janela, 0 se o usuário foi censurado.
A partir daí a conta é aritmética simples. Para cada período t, com d eventos entre n usuários ainda sob risco, a sobrevivência acumulada é o produto de (1 - d/n) ao longo dos períodos. Nada de biblioteca pesada e nada de modelo.
Três decisões operacionais que definem a qualidade do resultado:
- A origem do relógio é a entrada no teste, nunca a data do calendário. Um usuário que entrou no dia 20 de um teste de 28 dias tem 8 dias de relógio, não 28. Misturar as duas origens é o erro que produz curvas com degraus estranhos no fim.
- A janela de observação tem que ser a mesma para todo mundo, ou você precisa modelar isso. O jeito limpo é fixar um período de entrada (o Spotify usou 7 dias) e observar todo mundo pelo mesmo número de períodos depois disso.
- Guarde a data do evento, não só o sinalizador. Trocar retenção binária por tempo até o evento depois que o teste acabou é impossível se você só gravou “retido: sim”. Guardar a data custa uma coluna.
Erros comuns
- Calcular a média só sobre quem teve o evento. O erro central deste artigo: subestimou o efeito por um fator de quase sete na nossa simulação, e subestima mais no braço que está ganhando.
- Tratar censurado como “não teve o evento”. É o espelho do erro anterior e inflaciona a sobrevivência em vez de deflacionar. Censurado não é nem evento nem não evento: é observação parcial.
- Escolher a data da retenção depois de ver os números. D7, D14 e D30 dão respostas diferentes, e nossa própria tabela mostra lift variando de mais 2,92 a mais 15,37 por cento conforme a semana.
- Reportar razão de risco com curvas que se cruzam. Se as curvas se cruzam, não existe uma razão de risco única para reportar. Use RMST.
- Escolher o horizonte do RMST olhando o resultado. Mesma armadilha, roupa nova.
- Achar que curva resolve amostra pequena. Log-rank tem mais sensibilidade que uma fatia binária, mas continua precisando de eventos. Com poucos eventos, a curva balança feio no fim, onde restam poucos usuários sob risco. A regra prática é olhar o número de usuários sob risco a cada período e desconfiar da cauda.
- Confundir tempo até o evento com métrica substituta. São coisas diferentes que resolvem a mesma dor. Tempo até o evento mede melhor o que você observou; métrica substituta prevê o que você não observou. Dá para usar as duas juntas, que é exatamente o que o Spotify fez.
Faça isso automático na Donnu
O obstáculo para adotar tempo até o evento quase nunca é a matemática, é a montagem: a maioria das plataformas de teste A/B guarda um sinalizador de conversão por usuário e descarta o carimbo de tempo. Quando alguém pergunta, meses depois, “quanto tempo aquele teste segurou o usuário a mais”, a resposta é que o dado não existe mais.
A Donnu mantém o carimbo de tempo do evento junto do sorteio do usuário, que é a condição mínima para reconstruir uma curva de sobrevivência de um teste que já terminou. Se a sua montagem atual não faz isso, o passo imediato e barato é começar a gravar hoje a data do evento por usuário, mesmo que você continue reportando retenção binária por enquanto: a coluna extra custa nada e é irrecuperável depois. Para conferir a leitura binária de uma data específica enquanto a curva não existe, a calculadora de significância resolve em um minuto, e a calculadora de tamanho de amostra diz quantos usuários aquela leitura exige.
Referências
- Chandar, P., St. Thomas, B., Maystre, L., Pappu, V., Sanchis-Ojeda, R., Wu, T., Carterette, B., Lalmas, M. e Jebara, T. Using Survival Models to Estimate User Engagement in Online Experiments. WWW 2022, Spotify. Fonte do enquadramento da retenção de longo prazo como problema de tempo até o evento, com o desfecho não observável no fim do teste A/B; da definição de censura à direita como o usuário ativo em todas as semanas, cujo tempo até a inatividade é registrado como o comprimento da janela de observação; do exemplo de duas coortes com tempo médio verdadeiro de 2 e 36 semanas em que ignorar os censurados na semana 10 produz subestimação severa; da premissa do modelo de Cox de que a censura é não informativa, satisfeita por um tempo de censura fixo; do corpus de 51 testes A/B rodados entre março e dezembro de 2020 com pelo menos 28 dias após período de entrada de 7 dias; do achado de que o poder discriminativo da retenção semanal na semana 4 é cerca do dobro do da semana 2 e de que as métricas previstas são mais sensíveis que as observadas; e do teste A/A com 432 valores-p de distribuição uniforme. mounia-lalmas.blog.
- Kohavi, R., Deng, A., Frasca, B., Longbotham, R., Walker, T. e Xu, Y. Trustworthy Online Controlled Experiments: Five Puzzling Outcomes Explained. KDD 2012, Microsoft. Fonte do ponto de que experimentos online recrutam usuários continuamente, em vez de terem um período de recrutamento antes do experimento, o que faz o tamanho de amostra crescer com a duração e cria janelas de observação desiguais entre usuários. exp-platform.com.
- Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. e Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013, Microsoft. Fonte da exigência de que o critério de decisão seja mensurável em prazos curtos, da ordem de duas semanas, ao mesmo tempo em que prediz objetivos de longo prazo, e da regra de que o placar final do experimento é fechado num múltiplo de semanas, usualmente duas. exp-platform.com.
- Deng, A. e Shi, X. Data-Driven Metric Development for Online Controlled Experiments: Seven Lessons Learned. KDD 2016, Microsoft. Fonte das duas qualidades obrigatórias de uma métrica de decisão, direcionalidade e sensibilidade, que são o critério pelo qual a troca de retenção binária por tempo até o evento deve ser julgada. exp-platform.com.
Leia também: Métrica substituta · Holdout de longo prazo · Maturidade de coorte · Atrito diferencial · Reduzindo churn com experimentação · Calculadora de significância · Read in English
Perguntas frequentes
- O que é uma métrica de tempo até o evento em teste A/B?
- É uma métrica em que o resultado não é "aconteceu ou não", e sim "quanto tempo levou até acontecer": tempo até a primeira compra, tempo até o cancelamento, tempo até o usuário ficar uma semana inteira sem abrir o produto. A diferença prática é que, no fim do teste, uma parte dos usuários ainda não teve o evento. Esses casos se chamam censurados à direita e são a razão pela qual a média simples não serve.
- Por que não dá para tirar a média do tempo até o evento?
- Porque a média calculada só sobre quem já teve o evento exclui exatamente os usuários que demoram mais, e isso puxa o número para baixo. Na simulação deste guia, a média ingênua deu 5,1523 semanas no controle e 5,3586 na variação, uma diferença de 0,2063 semana, enquanto a diferença verdadeira era de 1,4408 semana. O viés não é só de nível: ele apagou quase sete oitavos do efeito.
- O que é censura à direita?
- É o usuário que chega ao fim da janela de observação sem ter tido o evento. Você sabe que o tempo dele é maior que a janela, mas não sabe quanto. Chandar e coautores registram que, no caso do Spotify, a censura à direita ocorre quando o usuário esteve ativo em todas as semanas, e o tempo até a inatividade dele é registrado como o comprimento da janela de observação.
- O que Kaplan-Meier e log-rank resolvem?
- Kaplan-Meier estima a curva de sobrevivência usando cada usuário até o instante em que ele sai da observação, o que aproveita a informação parcial dos censurados em vez de descartá-la. O log-rank compara as duas curvas inteiras, semana a semana, em vez de comparar uma fatia só. Na simulação deste guia, o log-rank deu z de 10,9053 contra 7,8849 do teste binário de retenção na semana 4, sobre os mesmos dados.
- O que é RMST e por que ele é mais fácil de comunicar que a razão de risco?
- RMST é o tempo médio de sobrevivência restrito a uma janela: a área sob a curva de Kaplan-Meier até um horizonte que você escolhe. Ele sai em unidade de tempo, então a resposta vira "a variação segurou o usuário 0,5423 semana a mais dentro de 12 semanas", que qualquer pessoa entende. A razão de risco de 0,8397 do mesmo teste é correta e mais compacta, mas exige explicar o que é risco instantâneo.
- Vale a pena trocar retenção binária por tempo até o evento?
- Vale quando a decisão é sobre permanência e a métrica binária escolhe uma data arbitrária. A retenção em D7 e a retenção em D30 podem discordar, e escolher uma delas depois de ver o resultado é uma porta aberta para viés. A curva inteira não tem essa escolha. O custo é operacional: exige registrar a data do evento por usuário, não só um sinalizador no fim do teste.