Como Testar A/B o Preço do seu Produto: o Guia Completo

Testar A/B o preço do seu produto é medir, com tráfego real dividido aleatoriamente, se um valor diferente do atual muda o comportamento de compra o bastante para valer a pena, decidindo sempre pela receita gerada e não apenas pela taxa de conversão. É o mesmo método estatístico de qualquer teste A/B, mas com uma diferença que muda tudo: aqui a variável testada afeta diretamente quanto cada cliente paga, então a métrica que decide o teste, os cuidados éticos e o próprio desenho do experimento precisam ser outros. Este guia cobre o assunto do início ao fim: por que preço não se testa como copy, como montar o desenho sem contaminar os grupos, por que receita por visitante (RPV) substitui a conversão como métrica primária, como calcular amostra e duração quando o número que importa é receita, e como tratar ancoragem, paywall, desconto, upsell e o par assinatura contra pagamento único. Sempre cobrindo e-commerce e SaaS separadamente, porque são dois jogos de preço diferentes.

Por que testar preço é diferente de testar copy ou UI

Um teste de botão, título ou imagem tenta melhorar a conversão sem tocar no valor que o cliente entrega em troca. Um teste de preço muda os dois lados da equação ao mesmo tempo: mexe em quanto entra (receita por venda) e em quantas vendas acontecem (conversão), e os dois efeitos costumam apontar em direções opostas.

Isso cria três diferenças práticas que nenhum teste de copy precisa considerar:

• O efeito é direto em receita, não só em engajamento. Um botão pior custa cliques perdidos; um preço errado custa receita todo santo dia que o teste roda, para o lado que “perde”, inclusive durante a fase experimental.
• Preço carrega percepção de valor, não é só um número. A mesma oferta parece mais ou menos valiosa dependendo do preço ao lado dela (efeito de ancoragem), então testar preço isolado do contexto de apresentação (parcelamento, comparação com outro plano, garantia) mede menos do que parece.
• Preço muda QUEM compra, não só QUANTOS compram. Um preço mais alto tende a filtrar para um cliente com orçamento maior e, em SaaS, muitas vezes menor churn; um preço mais baixo traz volume, mas pode trazer também o cliente errado, que cancela ou pede reembolso mais cedo. Julgar isso só pela conversão do dia 1 esconde o efeito de médio prazo.

Os cuidados éticos e legais antes de rodar um teste de preço

Preço é a única variável de teste A/B em que “duas pessoas pagaram valores diferentes pela mesma coisa, ao mesmo tempo” pode virar um problema de confiança e, dependendo de como for feito, de conformidade. O caso mais citado da história do e-commerce é da própria Amazon: em 2000, a empresa testou descontos aleatórios entre 20% e 40% em 68 títulos de DVD, e quando compradores de um fórum notaram que estavam pagando mais que outros usuários, a reação foi imediata. A Amazon reembolsou uma média de 3,10 dólares para quase 6.900 clientes e encerrou o teste, com o próprio Jeff Bezos afirmando publicamente que a empresa nunca testaria preços com base em dados demográficos do cliente, segundo reportagem da época na CNN.

O ponto não é que testar preço seja proibido, é comum e legítimo. O ponto é que a forma importa:

• Aleatoriedade simples e de curto prazo tende a ser aceita; segmentar preço por dado pessoal (localização, dispositivo, histórico de navegação, perfil demográfico) de forma opaca é o que gera reação, e é também o tipo de prática que a LGPD trata com mais rigor quando envolve tratamento de dado pessoal para decisão automatizada que afeta o consumidor economicamente. Documente a base legal e seja capaz de explicar o critério, se perguntado.
• Transparência é a defesa mais forte. Um estudo da Comissão Europeia de 2018 sobre segmentação de mercado online, testando 160 sites de e-commerce em 8 países, encontrou diferença de preço em apenas 6% dos casos testados, com mediana de diferença de menos de 1,6%, mas identificou que a maioria dos consumidores vê a personalização de preço com desconfiança quando não é avisada dela. A prática mais segura, do ponto de vista tanto legal quanto de marca, é testar preço por variação aleatória de curto prazo (o desenho A/B clássico), não por perfilamento individual permanente.
• Cliente existente nunca deveria “descobrir” que paga mais que um cliente novo sem aviso. Em SaaS isso é ainda mais sensível, porque a relação é contínua: aumentar o preço silenciosamente para quem já assina, sem comunicação e sem período de transição, é o tipo de decisão que gera cancelamento em massa e dano de reputação bem maior do que o ganho de receita testado.

Nenhuma dessas cautelas substitui a estatística do teste. Elas são a régua de “posso rodar isso” que vem antes da régua de “o resultado é confiável”.

Como desenhar um teste de preço sem contaminar os grupos

Um teste A/B de copy tem um risco de contaminação relativamente baixo: se o mesmo visitante ver A e depois B, o pior que acontece é ruído. Um teste de preço tem um risco mais sério, porque preço é algo que as pessoas comparam entre si, ativamente:

• Cross-contamination entre variantes. Se dois usuários da mesma empresa, ou do mesmo grupo social, virem preços diferentes para o mesmo plano, um deles vai perceber e reclamar, e a percepção de injustiça contamina a decisão de compra dos dois, não só do que “perdeu”. Isole a atribuição por conta/organização em B2B, não por sessão individual, quando a compra é decidida em grupo.
• Cohort (coorte) contra teste simultâneo. Um desenho por coorte muda o preço no tempo (mês 1 com preço A, mês 2 com preço B) e compara os grupos; é mais fácil de implementar, mas mistura o efeito do preço com o efeito de sazonalidade, canal de aquisição e qualquer outra coisa que mudou entre os dois períodos. O desenho simultâneo (A e B rodando ao mesmo tempo, sorteio aleatório) isola de verdade o efeito do preço, e é o que este guia recomenda como padrão, reservando o cohort para quando o produto realmente não permite dois preços ativos ao mesmo tempo (por exemplo, um app store que só aceita um preço público por vez).
• Visitante novo contra visitante existente. Teste preço no funil de aquisição (quem ainda não é cliente): landing page, checkout de primeira compra, tela de upgrade de trial para pago. Nunca aplique a variação retroativamente a quem já paga o preço atual sem comunicação e sem transição, tanto por ética quanto porque o comportamento de quem já confia no produto não é comparável ao de quem está decidindo comprar pela primeira vez.

RPV: por que receita por visitante decide melhor que conversão

Aqui está a armadilha estatística central de qualquer teste de preço: um preço mais alto quase sempre reduz a conversão, e ainda assim pode ser a variante certa, porque o que importa não é quantas pessoas compram, é quanta receita o tráfego total gera.

A métrica que captura isso é a receita por visitante (RPV): receita total dividida pelo número de visitantes, o mesmo denominador de uma taxa de conversão, mas com o numerador em dinheiro em vez de contagem de eventos. RPV é, na prática, o produto de duas coisas: RPV = taxa de conversão × ticket médio (ou receita média por cliente pagante). Um preço mais alto tende a puxar o primeiro termo para baixo e o segundo para cima; qual efeito vence só a conta de RPV revela.

A tabela abaixo resume qual métrica primária faz sentido para cada tipo comum de teste de preço:

Tipo de teste de preço	Métrica primária recomendada	Por que não usar só conversão
Preço cheio (plano ou produto)	Receita por visitante (RPV)	Preço afeta ticket e conversão em direções opostas
Desconto ou cupom	Receita por visitante, líquida do desconto	Conversão sobe com desconto quase sempre; a pergunta é se a receita líquida também sobe
Paywall / limite do freemium	Taxa de conversão para pago + RPV de longo prazo	Afrouxar o paywall aumenta ativação mas pode reduzir a urgência de pagar
Upsell / cross-sell	Receita incremental por visitante (ticket adicional)	A conversão do item principal já aconteceu; o que muda é o valor adicional
Assinatura x pagamento único	Receita projetada por cliente (LTV), não só receita do primeiro mês	O pagamento único parece maior no dia 1 e pode perder para a assinatura em 6 a 12 meses

Guardrails continuam obrigatórios num teste de preço, talvez mais que em qualquer outro tipo: monitore reembolso, chargeback, cancelamento nos primeiros 30 dias e, em SaaS, churn nos primeiros dois ou três ciclos de cobrança. Um preço que aumenta a RPV no curto prazo mas dispara o cancelamento no segundo mês não é um vencedor, é um problema adiado. Se o tema de fundo aqui é estatística de significância em geral (valor-p, intervalo de confiança, erro Tipo I e Tipo II), o guia de significância estatística cobre a base que este artigo assume conhecida.

Tamanho de amostra e duração quando a métrica é receita

A conta de amostra de um teste A/B comum assume uma métrica binária: converteu ou não converteu. Receita não é binária, é um número contínuo com um detalhe incômodo: a distribuição de receita por visitante é fortemente assimétrica, porque a maioria dos visitantes gera zero (não compra), e uma minoria gera valores altos, às vezes muito acima da média. Ron Kohavi e coautores, no livro de referência Trustworthy Online Controlled Experiments, chamam atenção justamente para esse tipo de métrica: métricas de receita tendem a ter variância inflada por poucos valores extremos, e a prática recomendada é capar (limitar) os valores mais altos ou usar testes menos sensíveis a outliers antes de calcular significância, sob risco de um único cliente de ticket muito alto decidir o teste sozinho.

Na prática, para o desenho da maioria dos times, duas abordagens convivem:

1. Aproximação por proporção, quando a decisão de preço afeta principalmente a conversão (o caso mais comum de testar “preço A converte X%, preço B converte Y%” olhando primeiro se a diferença de conversão é real, e só depois multiplicando pelo ticket de cada lado para chegar à receita). A calculadora de tamanho de amostra abaixo, baseada no teste de duas proporções, serve bem como piso mínimo para esse cenário; ela informa quantos visitantes por variação e quantos dias você precisa dado o tráfego semanal.
2. Teste direto sobre a receita, quando o ticket varia muito entre clientes (planos com upsell, e-commerce com carrinho de tamanho variável): nesse caso a amostra necessária tende a ser maior que a de uma métrica binária equivalente, porque a variância da receita por visitante é maior que a variância de uma taxa de conversão com a mesma média, e o efeito muitas vezes é sutil (poucos pontos percentuais de RPV). Trate o resultado de qualquer calculadora de proporção como piso, não como teto, quando o ticket for muito variável, e prefira rodar mais tempo do que o mínimo calculado.

Ajuste os campos abaixo para a sua taxa de conversão atual, o efeito mínimo que valeria a pena detectar e o seu tráfego semanal:

Taxa de conversão atual%Efeito mínimo detectávelrelativo (%)absoluto (pp)Confiança909599%Poder8090%Visitantes por semana (total)Testebilateralunilateral

-Visitantes por variação

-Total (2 variações)

-Duração estimada

Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.

Um exemplo concreto de como isso se aplica a preço: imagine um SaaS testando a tela de upgrade de trial para pago com o preço atual (que converte 5% do tráfego) contra um preço 10% mais barato, torcendo para que a queda de preço aumente a conversão o bastante para compensar. Com taxa base de 5%, efeito mínimo detectável de 10% relativo, 95% de confiança e 80% de poder, são necessários cerca de 31.234 visitantes por variação; com 10.000 visitantes por semana no funil de trial, o teste leva cerca de 44 dias para acumular amostra, cerca de seis semanas, bem mais que os “vamos testar por uma semana e ver” que costumam aparecer em teste de preço malfeito.

Declarando o vencedor: exemplo trabalhado ponta a ponta

Use os mesmos números já carregados na calculadora de significância abaixo para reproduzir o cálculo: controle (A) com 210 conversões em 4.200 visitantes e variação (B) com 273 em 4.200.

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

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.

Passo a passo, tratando isso como um teste de conversão para trial pago:

• Taxa de A: 210 ÷ 4.200 = 5,00%. Taxa de B: 273 ÷ 4.200 = 6,50%. Melhora relativa de conversão: +30%.
• Valor-p bilateral ≈ 0,003, bem abaixo de 0,05: a diferença de conversão é estatisticamente significativa, B converte mais.

Agora a etapa que um teste de preço exige e um teste de copy não: multiplique pelo preço de cada variação antes de declarar o vencedor. Se A cobra R$ 99/mês e B cobra R$ 79/mês (um desconto para tentar elevar a conversão), a receita do período seria: A = 210 × R$ 99 = R$ 20.790; B = 273 × R$ 79 = R$ 21.567. Nesse cenário, B ainda vence também em receita total (RPV de A = R$ 4,95; RPV de B = R$ 5,14), então o desconto valeu a pena. Mas repare que a diferença de RPV (cerca de 3,7%) é bem mais estreita que a diferença de conversão (30%): se o desconto de B fosse maior, por exemplo R$ 65/mês, a receita de B cairia para R$ 17.745, abaixo de A, e a mesma vitória “estatisticamente significativa” em conversão se tornaria uma derrota em receita. É exatamente esse tipo de inversão que a métrica de RPV existe para pegar, e que olhar só o valor-p da conversão nunca mostraria sozinho.

Ancoragem de preço: a percepção decide antes do número

Antes de qualquer estatística, o preço já foi julgado por comparação. Ancoragem de preço é o efeito pelo qual a mesma quantia parece mais barata ou mais cara dependendo do que está ao lado dela: um plano de R$ 199 parece caro sozinho e parece uma pechincha ao lado de um plano de R$ 499 apresentado como referência. Isso significa que testar um número isolado, sem testar também a apresentação (ordem dos planos, plano “âncora” mais caro exibido primeiro, comparação lado a lado), mede só parte do efeito real de uma mudança de preço. Testar preço e ancoragem juntos, ou pelo menos saber qual dos dois está mudando quando o resultado aparece, evita atribuir a um número um efeito que veio do arranjo visual ao redor dele. Para o desenho completo de como estruturar esse teste (ordem de planos, âncoras decoy, isolamento de variável), veja o guia completo -> ancoragem de preço em teste A/B.

Paywall e freemium: o teste de preço mais delicado do SaaS

Testar o paywall de um modelo freemium (onde fica o limite entre o que é grátis e o que exige pagamento) é um teste de preço disfarçado de teste de produto. Apertar o limite (menos uso grátis) tende a aumentar a conversão para pago, mas também aumenta o abandono de quem nunca chegaria a pagar; afrouxar o limite faz o oposto. A métrica primária correta aqui também não é a conversão isolada de um único ponto do funil, é a combinação de ativação, conversão para pago e retenção de médio prazo, porque um paywall mais apertado pode “empurrar” gente para pagar cedo demais, antes de sentir valor suficiente, e gerar cancelamento no primeiro ciclo. O desenho de teste, os limites que fazem sentido testar primeiro e como medir isso sem confundir ativação com receita estão no guia completo -> teste A/B de paywall e freemium.

Descontos e promoções: teste o desconto, não só o preço

Um desconto é, estatisticamente, um teste de preço com prazo de validade e uma âncora embutida (o preço “de tabela” riscado ao lado do preço com desconto). Os cuidados específicos:

• Meça a receita líquida do desconto, nunca só o volume de vendas. Um cupom de 30% que dobra o volume pode ainda assim gerar menos receita líquida que o preço cheio, dependendo da margem e do quanto do aumento de vendas veio de gente que compraria de qualquer forma (efeito conhecido como cannibalization, canibalização de vendas que já aconteceriam).
• Cuidado com o efeito de âncora do desconto em testes futuros. Um público que viu o produto com 30% de desconto tende a ancorar naquele valor como “o preço justo”, dificultando testar o preço cheio de novo no mesmo público depois.
• Em e-commerce, teste o tipo de desconto (percentual x valor fixo x frete grátis) além do tamanho dele: a percepção de valor de “R$ 30 de desconto” e “10% de desconto” no mesmo carrinho pode gerar conversão diferente mesmo quando o valor final é idêntico.
• Em SaaS, desconto de aquisição (primeiro ciclo mais barato) precisa ser testado junto com a métrica de renovação no preço cheio, porque um desconto agressivo de entrada pode trazer cliente que nunca pretendia pagar o valor integral, inflando a conversão inicial e o churn de renovação ao mesmo tempo.

Upsell e cross-sell: testando o preço do que vem depois

Upsell (oferecer uma versão maior ou mais completa) e cross-sell (oferecer um item complementar) são testes de preço que acontecem depois da decisão de compra principal já estar tomada, o que muda a métrica de interesse: não é mais a conversão do item principal, é a receita incremental por visitante que já comprou (ou já está comprando). Pontos de atenção:

• Teste o momento da oferta, não só o preço dela: um upsell antes do pagamento (no carrinho) e um upsell depois da confirmação (pós-venda) têm taxas de aceitação e sensibilidade a preço bem diferentes, porque o estado de decisão do cliente muda no meio do fluxo.
• Guardrail obrigatório: taxa de conclusão do pedido principal. Um upsell agressivo pode aumentar a receita de quem aceita, mas assustar parte de quem não aceitaria e fazer essa parte abandonar o pedido inteiro; se isso acontece, a receita incremental do upsell não compensa a receita perdida do pedido principal.
• Em SaaS, cross-sell de um módulo ou add-on deveria ser medido também pela retenção de quem adicionou, não só pela adesão inicial: um add-on que ninguém usa de fato tende a virar motivo de cancelamento no ciclo seguinte, quando o cliente revisa a fatura.

Assinatura ou pagamento único: a decisão que muda a curva de receita

Testar “assinatura contra pagamento único” para o mesmo produto não é um teste de preço simples, é um teste do formato da receita ao longo do tempo, e julgar isso pela receita do primeiro mês costuma enganar. Um pagamento único de R$ 500 parece maior, no dia 1, que uma assinatura de R$ 50/mês; mas se a assinatura mediana dura 12 meses, ela gera R$ 600, mais que o pagamento único, e ainda deixa margem para upsell ao longo da relação. A métrica primária correta para esse tipo de teste é a receita projetada por cliente (uma aproximação de LTV), calculada com a duração média observada ou estimada, nunca a receita do primeiro ciclo isolada. Isso exige rodar o teste por tempo suficiente para observar ao menos um ou dois ciclos de renovação (ou modelar a curva de retenção com dados históricos), porque decidir com uma semana de dados de pagamento único contra assinatura é comparar coisas em estágios de maturação completamente diferentes.

E-commerce x SaaS: dois jogos de preço diferentes

Os princípios estatísticos são os mesmos, mas o que testar e o risco de cada erro mudam bastante entre os dois modelos:

Dimensão	E-commerce	SaaS
O que geralmente se testa	Preço do item, frete, desconto, parcelamento	Preço do plano, limite do paywall, período de cobrança (mensal x anual)
Métrica primária	Receita por visitante (RPV) da sessão de compra	Receita por visitante do funil de trial/cadastro, e depois LTV projetado
Janela de decisão	Curta, a compra acontece numa sessão ou poucos dias	Longa, a decisão real só aparece nos primeiros ciclos de cobrança/churn
Maior risco do teste malfeito	Canibalizar margem com desconto que não precisava existir	Cliente errado entrando por preço baixo e cancelando cedo, inflando churn
Onde a ancoragem pesa mais	Página de produto e carrinho (comparação com concorrente)	Tela de planos (comparação entre os próprios planos da empresa)

Erros comuns que arruínam um teste de preço

Erro	Por que distorce o resultado	Correção
Julgar só pela conversão	Ignora que preço maior pode gerar mais receita com menos vendas	Trate RPV como métrica primária, conversão como secundária
Ignorar LTV e olhar só a receita do primeiro ciclo	Um preço mais baixo pode parecer vencedor no mês 1 e perder feio no mês 6 por causa do churn	Meça retenção e receita projetada, não só a receita imediata
Amostra pequena demais para uma diferença sutil	Diferenças de RPV costumam ser menores, em pontos percentuais, que diferenças de conversão	Calcule a amostra com a calculadora deste guia e trate o número como piso, não teto
Misturar preço com ancoragem sem perceber	Atribui ao número um efeito que veio da apresentação ao redor dele	Isole a variável ou documente que os dois estão sendo testados juntos
Aplicar preço novo a cliente existente sem aviso	Gera cancelamento e dano de reputação desproporcional ao ganho testado	Teste só no funil de aquisição; migre a base com comunicação e transição
Rodar por poucos dias porque “a diferença de receita já apareceu”	Receita por visitante costuma ter variância maior; um pico isolado de ticket alto engana cedo	Respeite a duração calculada e rode ciclos completos, nunca só os “dias bons”

Faça isso automático na Donnu

O trabalho que este guia descreveu (calcular o impacto de receita de uma mudança de preço, não só a conversão, e garantir amostra estatisticamente válida antes de decidir) é manual, chato de repetir a cada teste, e é exatamente onde a maioria dos testes de preço erra: decide cedo demais, com base no número errado. A Donnu dimensiona a amostra antes de você rodar, mede o teste com estatística bayesiana honesta e mostra o resultado sem esconder que RPV e conversão podem apontar para lados diferentes, para você decidir pela receita de verdade, não pela métrica que “deu vitória” primeiro.

Comece um teste grátis de 14 dias e rode o seu primeiro teste de preço com o desenho certo desde o início. Para aprofundar a base estatística usada aqui, veja o guia de significância estatística, o guia completo de otimização de conversão (CRO) e o guia completo de teste A/B. Fique também de olho nos guias dedicados de ancoragem de preço e paywall freemium, que aprofundam os dois pontos mais delicados citados aqui. Prefere calcular direto: calculadora de tamanho de amostra e calculadora de significância estatística.

Referências

• Marn, M. V. & Rosiello, R. L. Managing Price, Gaining Profit. Harvard Business Review, set./out. 1992. hbr.org/1992/09/managing-price-gaining-profit.
• CNN. Amazon apologizes for random DVD price test. 28 set. 2000. cnn.com.
• European Commission. Consumer market study on online market segmentation through personalised pricing/offers in the European Union. 2018. commission.europa.eu.
• 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.