Atribuindo Receita ao Vencedor do seu Teste A/B
Como atribuir receita teste A/B ao vencedor certo: RPV vs receita total, sazonalidade, outliers de ticket e receita incremental anualizada.
📚 Este artigo faz parte do guia GA4 e Teste A/B: o Guia Completo de Integração.
Quando um teste A/B termina e o relatório mostra a variação B com mais receita total que a variação A, a tentação é declarar vencedor e implementar na hora. O problema é que receita total bruta, sozinha, não prova causalidade nenhuma: ela não controla o tamanho da amostra nem o ticket médio, os dois fatores que já discutimos em detalhe no guia completo de GA4 e teste A/B como parte do que uma ferramenta de analytics mostra mas não decide sozinha. Este guia foca só na etapa final desse processo: como atribuir receita ao vencedor certo de um teste A/B, isolando o que veio da variação do que veio de amostra desigual, sazonalidade e outliers de ticket alto.
Por que “a variação com mais receita” não prova nada sozinha
Receita total é a soma de tudo que uma variação gerou num período. Ela parece a métrica mais óbvia para decidir um teste, porque no fim das contas é o que entra no caixa. Mas receita total tem um defeito estrutural: ela cresce com o número de visitantes, não só com a qualidade da variação. Duas variações podem ter a mesma taxa de conversão e o mesmo ticket médio, e ainda assim uma delas mostrar receita total muito maior, simplesmente porque recebeu mais tráfego naquele período (alocação desigual, atraso no início de uma das variações, ou até um teste que roda em fases diferentes).
A métrica que isola esse efeito é a receita por visitante (RPV): receita total dividida pelo número de visitantes daquela variação, no mesmo período. É o mesmo denominador de uma taxa de conversão, só que o numerador é dinheiro em vez de contagem de eventos.
Um exemplo concreto ajuda a fixar por que isso importa. Suponha um teste de checkout rodando com alocação de tráfego desigual entre as duas variações (um cenário comum quando o teste começa com um rollout gradual):
A tabela abaixo mostra os números completos por trás do gráfico:
| Variação | Visitantes | Receita total | RPV (receita ÷ visitantes) |
|---|---|---|---|
| A (controle) | 6.000 | R$ 13.200 | R$ 2,20 |
| B | 9.000 | R$ 17.100 | R$ 1,90 |
| Diferença | +50% de tráfego em B | +29,5% em B | -13,6% em B |
A variação B levou 50% mais visitantes no mesmo recorte, e isso sozinho já explica a receita total maior. Olhando pela receita por visitante, o quadro se inverte: A converte melhor e/ou tem ticket médio melhor por pessoa que passou pela página, mesmo tendo recebido menos tráfego. Sem controlar por tamanho de amostra, qualquer leitura de “quem teve mais receita” está comparando maçã com laranja.
RPV como métrica primária, não a receita total bruta
Uma vez que RPV é o denominador certo, vale entender de onde ele vem. RPV não é uma métrica nova, é o produto de duas que você já conhece:
RPV = taxa de conversão × ticket médio (receita média por pedido)
Isso explica por que RPV é a métrica de decisão mais honesta para qualquer teste que mexe em receita: uma variação pode converter pior e ainda vencer em RPV, se o ganho de ticket médio compensar a perda de volume, e o oposto também é verdadeiro. Julgar só pela conversão, como já vimos em outro guia deste blog, ignora metade da equação; julgar só pela receita total ignora a outra metade (o tamanho da amostra). RPV é o único dos três que responde à pergunta certa: “cada visitante que passou por essa variação valeu mais em dinheiro?”.
Isso não significa que RPV seja perfeito. Ele tende a ter variância maior que uma taxa de conversão simples, justamente porque incorpora o valor do pedido, que costuma ser bem mais disperso que um evento binário de sim/não. Por isso RPV nunca deveria ser lido sozinho, sem um teste de significância por trás (mais adiante neste guia reproduzimos esse cálculo passo a passo). E, antes de calcular qualquer RPV, é preciso garantir que o número de visitantes contado por variação vem do mesmo tipo de evento nas duas pontas, o que já cobrimos em detalhe no guia de como rastrear eventos de teste A/B no GA4: sem um evento de impressão consistente por variação, o denominador do RPV já nasce torto.
Isolando o efeito do teste da sazonalidade
RPV resolve o problema do tamanho de amostra, mas não resolve um segundo problema, igualmente comum: comparar variações que rodaram em janelas de tempo diferentes. Um erro frequente é ler a receita da variação B no relatório do mês corrente e comparar com a receita que a variação A tinha antes de ser trocada, semanas ou meses atrás. Essa comparação mistura dois efeitos que não dá para separar depois: o que veio da variação testada e o que veio do calendário (feriado, dia de pagamento, campanha de mídia paga rodando em paralelo, temporada de vendas do setor).
A regra é simples de enunciar e fácil de esquecer na prática: A e B precisam rodar simultaneamente, na mesma janela de tempo, com o tráfego dividido entre as duas ao mesmo tempo, nunca em sequência. Só assim qualquer diferença de RPV observada pode ser atribuída à variação em si, e não ao momento em que cada uma rodou.
| Cenário de comparação | O que ele mede de verdade | Válido para atribuir receita ao teste? |
|---|---|---|
| A e B rodando ao mesmo tempo, tráfego dividido simultaneamente | Efeito da variação, isolado do calendário | Sim |
| A no mês passado, B substituindo A este mês | Efeito da variação misturado com o efeito do calendário (sazonalidade, campanhas, feriados) | Não |
| A e B ao mesmo tempo, mas em fontes de tráfego diferentes (A só orgânico, B só pago) | Efeito da variação misturado com o efeito do canal de aquisição | Não, a menos que a fonte de tráfego também seja controlada |
| A e B ao mesmo tempo, mesma fonte de tráfego, mesma janela | Efeito da variação, isolado do calendário e do canal | Sim |
Um detalhe que aparece com frequência em times que fazem uma migração gradual de uma página antiga para uma nova: se a variação nova entra em produção substituindo a antiga em vez de rodar em paralelo com ela, tecnicamente não existe mais um teste A/B, existe um antes-e-depois. Antes-e-depois pode ser útil como sinal direcional, mas não permite atribuir com confiança nenhuma diferença de receita à mudança, porque o calendário sempre está junto no “depois” e nunca esteve junto no “antes”.
O problema dos outliers de ticket alto
Diferente de uma taxa de conversão, que é sempre 0 ou 1 por visitante, receita por pedido pode variar muito: a maioria dos pedidos fica perto do ticket médio, e um pedido isolado de valor muito alto pode sozinho puxar a média de uma variação para cima, sem representar o comportamento típico de quem passou por ali. Segundo Kohavi, Tang e Xu, em Trustworthy Online Controlled Experiments, métricas de receita costumam ter distribuição de cauda pesada exatamente por esse motivo, e limitar (winsorizar) o peso de valores extremos é uma prática padrão em experimentação para reduzir a variância sem descartar dados. Um estudo técnico mais recente sobre métricas de monetização em experimentos de ranqueamento (Pokharna e colegas, arXiv 2606.04110, 2026) reforça o ponto: em métricas de receita, uma fração muito pequena dos usuários de maior valor pode dominar a variância do teste inteiro, o suficiente para distorcer o cálculo de significância se não for tratada.
Um exemplo com números reais ilustra o tamanho do problema. Suponha 12 pedidos registrados na variação B durante a janela do teste, sendo 11 deles próximos do ticket típico da loja e 1 deles um pedido corporativo isolado de R$ 5.400:
Os 12 valores usados aqui foram: R$ 89, R$ 120, R$ 145, R$ 99, R$ 156, R$ 110, R$ 134, R$ 99, R$ 125, R$ 143, R$ 118 e o pedido de R$ 5.400. A média dos 12 valores é R$ 561,50; a mediana é R$ 122,50; e a média recalculada sem o pedido de R$ 5.400 cai para R$ 121,64, quase idêntica à mediana. Se você usasse a média com o outlier para calcular o ticket médio dessa variação e projetar receita, estaria projetando com base num número que nenhum outro pedido daquela janela chega perto de reproduzir.
A saída prática, documentada tanto no livro de Kohavi, Tang e Xu quanto no estudo técnico citado acima, não é descartar o pedido grande (ele é uma venda real, e descartá-lo sem critério vira manipulação de dado): é reportar a mediana ao lado da média, ou capar (winsorizar) valores acima de um percentil alto (o 99º é uma referência comum na literatura de experimentação) antes de calcular o ticket médio que alimenta a projeção de receita. Isso preserva o pedido na contagem de conversões, mas evita que ele sozinho decida o resultado do teste.
Exemplo trabalhado: da significância à receita anualizada
O caminho completo para atribuir receita a um vencedor de teste A/B tem duas etapas, e as duas precisam acontecer nessa ordem: primeiro confirmar que a diferença de conversão é estatisticamente significativa (não apenas ruído de amostra), e só depois projetar o que essa diferença vale em receita ao longo de um ano. Pular a primeira etapa e ir direto para a segunda é como projetar receita de um resultado que talvez nem seja real.
Suponha um teste no checkout de uma loja: a variação A (controle) teve 8.000 visitantes e 320 conversões; a variação B teve 8.000 visitantes e 376 conversões, rodando na mesma janela de tempo, sem outliers de ticket relevantes nesse recorte.
- Taxa de A: 320 ÷ 8.000 = 4,00%. Taxa de B: 376 ÷ 8.000 = 4,70%.
- Melhora relativa: (0,0470 − 0,0400) ÷ 0,0400 = +17,5%.
- Taxa combinada p̄: (320 + 376) ÷ 16.000 = 4,35%.
- Erro padrão: √[0,0435 · 0,9565 · (1÷8.000 + 1÷8.000)] ≈ 0,003225.
- Escore z: (0,0470 − 0,0400) ÷ 0,003225 ≈ 2,17.
- Valor-p (bilateral) ≈ 0,030.
Com valor-p de 0,030 (abaixo do corte de 0,05) e o intervalo de confiança de 95% da diferença variando de aproximadamente +0,07 a +1,33 pontos percentuais (sem cruzar o zero), o resultado é estatisticamente significativo: a variação B converte mais, e não é só ruído de amostra pequena. Só agora, com a significância confirmada, faz sentido projetar o que esse ganho vale em receita. Confira a mesma conta na calculadora abaixo, colando os números do seu próprio relatório:
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.
Com a significância confirmada, o próximo passo é a calculadora de ROI de testes A/B deste blog, que usa exatamente esta conta: multiplicar o ganho de taxa de conversão pelo ticket médio e pelo tráfego anual projetado. Supondo que essa página recebe 100.000 visitantes por mês (1.200.000 por ano) e o ticket médio da loja é R$ 180, a receita incremental anualizada de trocar A por B é:
receita incremental = tráfego anual × (taxa alvo − taxa atual) × ticket médio
receita incremental = 1.200.000 × (0,0470 − 0,0400) × 180 = R$ 1.512.000 por ano
A tabela resume os dois cálculos, do teste de significância até a projeção de receita:
| Etapa | Entrada | Resultado |
|---|---|---|
| Significância (teste z de duas proporções) | 8.000/320 (A) vs. 8.000/376 (B) | z ≈ 2,17 · p ≈ 0,030 · significativo · B vence |
| Intervalo de confiança de 95% da diferença | mesmos dados acima | +0,07 a +1,33 pontos percentuais |
| Receita incremental anualizada | tráfego 1.200.000/ano · ticket médio R$ 180 | R$ 1.512.000 por ano |
Repare que a receita incremental projetada aqui usa a diferença de taxa de conversão, não a receita total observada durante o teste: é assim que a projeção fica imune ao tamanho da amostra que o teste efetivamente teve. O teste rodou com 8.000 visitantes por variação para provar que o efeito é real; a projeção de R$ 1.512.000 por ano usa esse efeito comprovado aplicado ao tráfego real do funil, não ao tráfego pequeno do experimento.
Faça isso automático na Donnu
Tudo que este guia descreveu (separar RPV de receita total, garantir que as duas variações rodam na mesma janela de tempo, tratar outliers de ticket com bom senso e só projetar receita depois de confirmar significância) é trabalho manual que a maioria dos times refaz do zero a cada teste, e é exatamente onde a atribuição de receita mais erra: decide cedo demais, com o número errado. Na Donnu, a divisão de tráfego entre variações acontece sempre na mesma janela de tempo por construção (não existe “rodar A em um mês e B no outro”), e o cálculo de significância honesto fica disponível assim que a amostra permite, para você nunca confundir receita total com receita por visitante, nem comemorar um ganho antes de ele ser estatisticamente real.
Comece um teste grátis na Donnu e deixe a divisão de tráfego simultânea e o cálculo de significância por conta da ferramenta, enquanto você foca em decidir com o número certo: RPV, não receita total. Para o panorama completo de como analytics e teste A/B se encaixam, veja o guia completo de GA4 e teste A/B.
Referências
- Optimizely. Revenue per visitor (definição, RPV como produto de conversão e ticket médio, e aviso sobre ruído da métrica). optimizely.com/optimization-glossary/revenue-per-visitor.
- Kohavi, R., Tang, D. & Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoio em experimentguide.com.
- Pokharna, H. et al. Variance Reduction for Heavy-Tailed Monetization Metrics in Ranking Experiments via Post-Stratification. arXiv, 2026. arxiv.org/html/2606.04110.
Leia também: GA4 e teste A/B: o guia completo de integração · Como rastrear eventos de teste A/B no GA4 · Calculadora de ROI de testes A/B
Perguntas frequentes
- Por que a variação com mais receita total nem sempre é a vencedora real de um teste A/B?
- Porque receita total bruta não controla dois fatores que mudam o resultado sozinhos: o tamanho da amostra (mais visitantes tendem a gerar mais receita bruta mesmo com desempenho por visitante pior) e o ticket médio (um único pedido grande pode inflar o total sem representar o comportamento típico da variação). A métrica que isola o efeito real é a receita por visitante (RPV): receita total dividida pelos visitantes daquela variação, no mesmo período de tempo.
- O que é RPV (receita por visitante) e por que ele deveria ser a métrica primária, não a receita total?
- RPV é a receita total gerada dividida pelo número de visitantes no mesmo período, e equivale, na prática, à taxa de conversão multiplicada pelo ticket médio. Segundo o glossário da Optimizely, RPV é a quantidade de dinheiro gerada a cada visita ao site, e pode subir tanto pela conversão quanto pelo ticket médio. Como RPV normaliza pelo número de visitantes, ele permite comparar variações com volumes de tráfego diferentes sem que o tamanho da amostra distorça a leitura, embora a própria Optimizely alerte que RPV pode ser um indicador ruidoso, por isso ele precisa ser lido junto de um teste de significância, nunca isolado.
- Um pedido de ticket muito alto no meio do teste pode inviabilizar a leitura de receita?
- Sim, e é um risco real em métricas de receita, diferente de taxa de conversão, que é sempre 0 ou 1 por visitante. Segundo Kohavi, Tang e Xu, em Trustworthy Online Controlled Experiments, métricas de receita costumam ter distribuição de cauda pesada, e capar (winsorizar) valores extremos é uma prática padrão para reduzir a influência de outliers sem descartar os usuários. Um estudo técnico de 2026 sobre métricas de monetização em experimentos de ranqueamento (Pokharna e colegas, arXiv 2606.04110) mostra que uma fração muito pequena de usuários de altíssimo valor pode dominar a variância de receita de um teste inteiro. Na prática: reporte a mediana ao lado da média, e considere winsorizar valores acima de um percentil alto, mantendo o pedido na contagem mas limitando o quanto ele pesa na comparação.
- Posso comparar a receita da variação B em um mês com a receita da variação A registrada em outro mês?
- Não, essa comparação não isola o efeito do teste. Sazonalidade (datas comemorativas, dia de pagamento, campanhas de mídia paralelas, clima) muda o comportamento de compra de forma independente da variação testada, então qualquer diferença de receita entre janelas de tempo diferentes mistura o efeito do teste com o efeito do calendário. A regra é rodar A e B na mesma janela de tempo, simultaneamente, e só então comparar RPV entre eles.