Multi-Armed Bandits para Teste de Preço (2026)

Teste de preço é o único lugar em que o “custo de mostrar a variação perdedora” deixa de ser abstração: cada visitante que vê o preço errado é uma venda ou uma margem perdida agora, não um dado que você vai interpretar depois. É esse fato que puxa os multi-armed bandits, e o Thompson Sampling em especial, para dentro das conversas de preço com muito mais frequência do que para dentro de um teste de headline ou de cor de botão. Este guia explica por que a métrica de recompensa tem que ser receita por visitante e não taxa de conversão, traz um exemplo trabalhado calculado no mesmo motor de estatística que roda as calculadoras deste blog, e é honesto sobre a única coisa que o bandit continua não entregando: um veredito estatístico formal e defensável.

Este texto é um filho do guia multi-armed bandits x teste A/B, que cobre o trade-off geral, e conversa de perto com o guia completo de teste A/B de preço, que trata do lado clássico da decisão.

Por que teste de preço sangra diferente de um teste de texto

Todo teste A/B com divisão fixa paga um custo de oportunidade enquanto roda: metade do tráfego continua vendo a variação que vai se revelar a mais fraca, pelo tempo que o teste levar até atingir o tamanho de amostra planejado. Para uma headline ou uma cor de CTA, esse custo costuma ser pequeno e recuperável, alguns pontos percentuais de conversão numa métrica que zera no teste seguinte.

Teste de preço é outro animal. A perda de mostrar o preço errado não é sinal suave, é dinheiro: quem vê um preço alto demais para converter simplesmente vai embora, e quem vê um preço baixo demais converte a uma taxa que subestima o que o negócio poderia ter cobrado daquela mesma pessoa. Os dois sentidos do erro se acumulam linearmente com cada visitante que passa pelo teste enquanto a divisão fixa se mantém e, diferente de um teste de headline, em geral não dá para “recuperar depois”: quem sai com uma experiência ruim de preço raramente volta para tentar uma melhor.

É o mesmo trade-off que o guia de bandits x teste A/B descreve em termos gerais: o bandit reduz o custo de oportunidade da divisão fixa deslocando tráfego para o braço que está performando melhor enquanto o teste ainda roda, ao preço de não produzir um veredito estatístico clássico no fim. Preço é simplesmente o caso em que esse custo de oportunidade é mais literal e mais caro, e por isso o exemplo mais nítido de quando o trade-off vale a pena.

A métrica de recompensa que importa: receita por visitante

Aqui está a armadilha em que um teste de preço ingênuo cai: se você otimiza puramente por taxa de conversão, o preço mais barato testado vai vencer quase por construção. Baixar preço quase sempre aumenta a fatia de visitantes que compra. Isso não significa que aumenta a receita.

A métrica que de fato responde “qual preço é melhor para o negócio” é a receita por visitante (RPV): a taxa de conversão multiplicada pelo preço cobrado de cada visitante que converte. Um preço que converte menos gente ainda pode ser a escolha mais forte se converter com valor alto o bastante para mais do que compensar a conversão menor. É exatamente o caso de métrica numérica que a documentação de fornecedores trata de forma diferente de uma métrica binária: a documentação de suporte da Optimizely descreve rodar um bandit Epsilon-Greedy para métricas numéricas como receita, usando estimadores robustos de média, variância e assimetria da distribuição da métrica para construir os limites de confiança de que o algoritmo precisa, em vez da matemática mais simples que uma métrica de conversão binária permite.

Os números por trás dessa figura estão trabalhados passo a passo mais adiante, mas a direção do argumento vale em geral: escolher a métrica de recompensa não é formalidade num teste de preço, é o que decide qual preço você sobe.

Como o bandit protege margem com o teste ainda rodando

O bandit, no caso geral, realoca tráfego para o braço que está performando melhor na métrica de recompensa escolhida, em vez de segurar uma divisão fixa até chegar um tamanho de amostra pré-definido, como faz o teste A/B clássico. O Thompson Sampling, coberto em profundidade no guia de Thompson Sampling deste blog, é o algoritmo mais usado em sistemas bayesianos de produção: ele mantém uma distribuição de crença sobre a recompensa verdadeira de cada preço, sorteia um valor de cada distribuição a cada novo visitante e manda esse visitante para o preço que tirou o valor mais alto. Preços com poucos dados têm distribuições largas e incertas e continuam sendo sorteados com frequência; preços com muitos dados e recompensa claramente fraca têm distribuições estreitas e baixas, e são sorteados cada vez menos, sem nunca serem cortados de vez.

Aplicado a preço, esse comportamento cai direto em cima da dor: conforme a evidência se acumula de que um patamar de preço produz mais receita por visitante, o bandit manda mais tráfego para ele, o que significa menos gente vendo o preço fraco no resto do teste. Um teste A/B 50/50 clássico, ao contrário, mantém a divisão plana do primeiro ao último visitante de propósito, porque mexer na divisão no meio do caminho é justamente o que comprometeria o veredito formal que ele existe para produzir.

Bandit e teste A/B bayesiano compartilham a mesma matemática de fundo, a diferença é puramente o que se faz com ela: decidir tráfego em tempo real, como no bandit, ou reportar uma probabilidade e um veredito uma vez, no fim, como faz um teste A/B clássico bayesiano ou frequentista.

Exemplo trabalhado: o mesmo teste de preço, de três jeitos

Para sair do conceito, um cenário concreto, calculado com a mesma função significance do motor stats.ts que roda a calculadora logo abaixo.

O cenário: uma página de upgrade de trial para pago de um SaaS recebe 10.000 visitantes em uma semana. O preço A é o atual, 29 dólares por mês, convertendo a 8,0% (400 de 5.000 visitantes que viram esse preço). O preço B é um preço maior em teste, 39 dólares por mês, convertendo a 6,4% (320 de 5.000 visitantes). Esse tamanho de efeito exato, uma base de 8% caindo para 6,4%, uma queda relativa de 20%, exige cerca de 4.921 visitantes por variação para 80% de poder a 95% de confiança, pela fórmula congelada sampleSizePerVariant deste blog; os 5.000 por braço do cenário ficam logo acima desse patamar, então este é um teste bem dimensionado, ainda que sem margem sobrando, não uma amostra pequena de sorte.

Preço	Visitantes	Conversões	Taxa de conversão	Receita por visitante
A (29)	5.000	400	8,0%	2,32
B (39)	5.000	320	6,4%	2,50

O que diz o veredito clássico do teste A/B

Rode esses números exatos, 5.000 visitantes e 400 conversões para A, 5.000 visitantes e 320 conversões para B, na calculadora abaixo (ela usa o mesmo teste z de duas proporções do exemplo trabalhado) para ver o veredito você mesmo:

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.

Fazendo a conta na mão: a taxa combinada é de 7,2%, o erro padrão fica em torno de 0,00517 e o escore z em cerca de -3,10, o que dá um valor-p bilateral de aproximadamente 0,002, bem abaixo do limiar usual de 0,05. Lido só pela taxa de conversão, este é um resultado estatisticamente significativo, e A é o vencedor declarado, já que converte a uma taxa maior, com intervalo de confiança de 95% sobre a diferença de aproximadamente -2,6 a -0,6 ponto percentual, uma faixa que exclui o zero.

Esse veredito é significativo e é também a resposta errada de negócio, se a pergunta real era qual preço dá mais dinheiro. A receita por visitante de A é 8,0% vezes 29, ou 2,32. A de B é 6,4% vezes 39, ou 2,50, um ganho relativo de cerca de +7,6% a favor de B. Um teste de preço que reportasse só o veredito de conversão acima subiria com confiança o preço de menor margem. É exatamente por isso que o sinal de recompensa precisa ser receita por visitante desde o começo, e não taxa de conversão com um lembrete mental de “conferir receita depois”: quando o teste A/B fixo declara um vencedor de conversão, o preço errado já pode parecer validado.

O mesmo tráfego total, rodado como bandit

Agora pegue os mesmos 10.000 visitantes e a mesma janela de uma semana, mas deixe um bandit realocar tráfego para B (o preço de maior receita) conforme a evidência se acumula, ilustrado aqui em três fases em vez de continuamente, para manter a aritmética auditável:

Fase	Dias	Visitantes (aprox.)	Fatia para B (maior receita)	Fatia para A
1: ainda incerto	1 a 2	~2.857	50%	50%
2: evidência crescendo	3 a 5	~4.286	70%	30%
3: evidência forte	6 a 7	~2.857	85%	15%

Somando as três fases, A recebe cerca de 3.143 visitantes e B cerca de 6.857. A receita esperada fica assim:

• A: 3.143 x 2,32 ≈ 7.292.
• B: 6.857 x 2,496 ≈ 17.115.
• Total ilustrativo do bandit: ≈ 24.407.

Compare com a divisão fixa 50/50 e com o teto teórico de mandar todo mundo para B desde o primeiro dia:

A vantagem do bandit aqui, cerca de 327, ou algo como 1,4% mais receita que a divisão fixa nessa semana, parece modesta nessa escala. Não é esse o número que vale guardar. O número que vale guardar é que esse ganho se acumula enquanto o preço estiver no ar e o tráfego continuar chegando, o que numa decisão de preço, diferente de um teste de headline pontual, costuma ser medido em meses ou anos, não em uma semana. Uma vantagem percentual pequena e estrutural sobre receita recorrente é coisa materialmente diferente da mesma vantagem percentual num teste que roda uma vez e acaba.

Repare também no que este exemplo trabalhado deliberadamente não faz: ele não usa o auxiliar incrementalRevenue do stats.ts, porque essa função multiplica uma diferença de taxa por um único ticket médio compartilhado, o que serve a um cenário de mesmo preço, como um teste de fluxo de checkout, e não a um cenário em que o próprio preço muda por braço. Reaproveitá-la aqui aplicaria a fórmula a um caso para o qual ela não foi feita; o caminho honesto, mostrado acima, é calcular a receita por visitante de cada preço separadamente e comparar os totais.

Bandits contextuais para preço por segmento

Um bandit simples procura um preço campeão para todo mundo. Um bandit contextual vai um passo além: escolhe o preço mostrado a cada visitante a partir de atributos como plano, porte da empresa, geografia ou histórico de uso, em vez de assumir que um preço serve igualmente bem a todos. A documentação da Optimizely sobre bandits contextuais descreve exatamente esse padrão, personalizando a decisão com atributos como dispositivo, localização ou sinais de comportamento em vez de servir a mesma variação para todos. O guia de bandit contextual deste blog entra na mecânica.

Em preço, isso mapeia numa situação real e comum: o preço que um cadastro individual self-serve tolera raramente é o preço que um comprador enterprise com linha de orçamento dedicada tolera, e um teste de preço único obriga a fazer a média entre os dois, o que pode esconder uma resposta legítima por segmento. Um bandit contextual pode, em princípio, aprender um preço efetivo diferente por segmento de forma contínua, em vez de exigir um teste A/B fixo separado para cada segmento que interessa.

Vale destacar aqui uma restrição específica e conferível, não uma genérica: a própria documentação da Optimizely sobre bandits contextuais afirma que receita não deve ser usada diretamente como métrica primária de otimização nesse modo, porque pode prejudicar a eficácia do modelo, ressalva que não se aplica a um bandit padrão não contextual. É exatamente o tipo de detalhe que muda entre versões do fornecedor, então trate como motivo para conferir a documentação atual antes de configurar um bandit contextual em torno de receita, não como regra permanente.

A personalização adicional também multiplica a questão de justiça tratada a seguir: um bandit contextual que converge silenciosamente para “o segmento X paga menos que o segmento Y” está fazendo exatamente o que mandaram ele fazer, otimizar a métrica de recompensa, e é justamente por isso que a decisão sobre quais atributos são aceitáveis para precificar não pode ser deixada para o algoritmo.

O lado jurídico e ético de testar preço

Esta seção é um alerta, não orientação jurídica; consulte seu advogado antes de subir qualquer personalização de preço, e saiba que isso muda por jurisdição e se move rápido. Dito isso, três coisas valem conhecer antes de otimizar preço por segmento:

• No Brasil, personalizar preço com dado pessoal cai sob a LGPD. A Lei 13.709/2018 exige base legal para o tratamento de dado pessoal e, no artigo 20, garante ao titular o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses, incluindo decisões destinadas a definir perfil pessoal. Somam-se a isso as regras gerais do Código de Defesa do Consumidor sobre informação clara e prática comercial, o que torna a transparência sobre o preço praticado uma questão de conformidade, não só de reputação.
• Reguladores fora do Brasil estão olhando para essa prática específica. Segundo um alerta a clientes do escritório WilmerHale sobre precificação personalizada, a Federal Trade Commission americana estudou a chamada precificação por vigilância, e a lei de divulgação de precificação algorítmica de Nova York, em vigor desde novembro de 2025, exige que empresas que definem preço usando dado pessoal do visitante informem isso na própria página. Vários outros estados americanos apresentaram projetos parecidos. Trate qualquer número ou lei citada aqui como fotografia de um momento e confirme a regra atual na sua jurisdição.
• A pergunta técnica e a jurídica são separadas, e as duas valem. Um bandit, contextual ou não, decidindo mostrar um preço maior a um segmento é uma decisão de negócio e jurídica fantasiada de questão estatística. O algoritmo vai otimizar a métrica e os atributos que você der a ele; decidir quais atributos são aceitáveis para precificar é decisão humana e documentada, não algo a inferir do que o modelo por acaso convergiu.

Nada disso é motivo para evitar experimento de preço. É motivo para manter uma decisão humana e documentada sobre quais atributos estão dentro dos limites, separada do algoritmo que otimiza dentro desses limites.

Quando o teste A/B clássico ainda é a escolha melhor

O bandit ganha o pão no ajuste contínuo de um preço dentro de uma faixa já aprovada, por exemplo calibrando percentual de desconto ou duração de trial para cima e para baixo conforme a evidência chega, onde o custo do palpite errado é recorrente e a decisão não precisa ser defendida para ninguém além do time que a toma.

O teste A/B clássico, com divisão fixa, continua sendo a ferramenta certa quando:

• A decisão precisa de veredito defensável. Uma decisão de preço no nível do conselho, como subir o preço de tabela de um plano principal, em geral pede um número com nível de confiança anexado, valor-p e intervalo de confiança, e não “a receita melhorou em relação à divisão igual”. É exatamente a frase que o guia de significância estatística deste blog percorre com um exemplo trabalhado comparável.
• O novo preço vai ser analisado por segmento ou canal depois. Uma divisão estável e conhecida permite perguntar, depois do fato, se o preço novo performou diferente por canal de aquisição ou por safra. A alocação do bandit, já tendo se deslocado sozinha durante o teste, torna esse fatiamento posterior mais difícil.
• A mudança é quase irreversível ou cara de desfazer. Reprecificar uma linha inteira de produto, ou tirar um preço legado herdado, é o tipo de decisão que se quer tomar uma vez, com resposta formal, em vez de ficar ajustando continuamente.

Muitos times usam os dois em sequência, e faz sentido: teste A/B clássico para decidir se o novo patamar de preço se sustenta, e bandit depois para seguir calibrando dentro da faixa que esse teste já aprovou.

Faça isso automático na Donnu

A tensão central deste guia é específica de preço: cada visitante que vê o preço perdedor durante um teste de divisão fixa é um golpe direto na margem ou uma venda perdida, não um sinal suave que dá para ignorar até o teste acabar. A Donnu já roda sobre um motor bayesiano nativo, a mesma fundação estatística de que um bandit como o Thompson Sampling precisa, e diz honestamente quando um teste de preço ainda não tem dado suficiente para confiar no veredito, em vez de deixar você ler um “vencedor” prematuro dentro do ruído e queimar margem subindo ele. Otimização contínua de preço no estilo bandit é o próximo passo natural desse mesmo motor, e é para onde o roadmap aponta para times que precisam continuar ajustando preço depois que o teste inicial já validou a faixa.

Comece um teste grátis de 14 dias e rode seu próximo teste de preço sobre uma base estatística construída para te contar a verdade sobre ele, não só o número que você queria ver.

Leia também: o guia completo de multi-armed bandits x teste A/B, o Thompson Sampling explicado em profundidade, o guia de teste A/B de preço e, em inglês, a versão original desta peça em multi-armed bandits for pricing tests.

Referências

• Optimizely. Maximize lift with multi-armed bandit optimizations (bandits não geram significância estatística; Epsilon-Greedy para métricas numéricas). support.optimizely.com.
• Optimizely. Stats accelerator overview (estimadores robustos de média, variância e assimetria para métricas numéricas como receita). support.optimizely.com.
• Optimizely. Contextual bandits (personalização por segmento e a ressalva sobre receita como métrica primária). support.optimizely.com.
• Brasil. Lei 13.709/2018 (Lei Geral de Proteção de Dados Pessoais), artigo 20, direito de revisão de decisões automatizadas. planalto.gov.br.
• WilmerHale. Personalized Pricing: What Business Lawyers Need to Know (estudo da FTC sobre precificação por vigilância e a lei de Nova York). wilmerhale.com.
• Mapping the Ethicality of Algorithmic Pricing: A Review of Dynamic and Personalized Pricing. Journal of Business Ethics, Springer Nature. link.springer.com.