Teste A/B: Trial para Pago no Fluxo de Upgrade
Como testar A/B o fluxo de upgrade de trial para pago no seu SaaS: onde testar, o que exige cautela e como medir sem viés de coorte incompleta.
📚 Este artigo faz parte do guia Growth Experimentation para SaaS: o Playbook Completo de PLG.
Testar A/B o fluxo de upgrade de trial para pago parece um teste comum: trocar um texto, medir quem virou pagante, declarar um vencedor. Na prática, é um dos experimentos que mais engana quem lê o painel cedo demais, porque a métrica que decide tudo, a conversão de trial para pago, só existe de verdade depois que o ciclo inteiro do trial de cada usuário já rodou. Este artigo é um capítulo prático dentro do guia de growth experimentation para SaaS: onde ficam os pontos de decisão do upgrade, o que é seguro testar rápido, o que exige cautela redobrada, e como medir sem cair na armadilha da coorte incompleta.
Onde ficam os pontos de decisão do upgrade
Num produto self-serve, o usuário em trial encontra o convite para pagar em pelo menos quatro lugares distintos, cada um com uma função diferente:
- Prompt in-app. Aparece dentro do produto, normalmente depois que o usuário esbarra num limite ou tenta usar uma funcionalidade paga. É o ponto de maior contexto: a pessoa acabou de sentir a falta daquilo.
- Paywall (suave ou rígido). Uma tela ou modal que bloqueia o avanço até a decisão de pagar. Paywall suave deixa contornar ou adiar; paywall rígido não deixa passar sem escolher um plano.
- E-mail de fim de trial. A sequência que dispara conforme o trial se aproxima do fim, normalmente com urgência crescente (aviso de 7 dias, de 2 dias, do último dia).
- Página de preços dentro do produto. A tela para onde qualquer um dos pontos acima leva o usuário quando ele decide seguir em frente. Segundo a Kissmetrics, quem clica em “fazer upgrade” precisa ver ali “uma página de preços clara e simples, que deixa óbvio qual plano escolher”, não uma segunda decisão difícil logo depois da primeira.
O timing de cada prompt importa tanto quanto o lugar. A Kissmetrics e a Appcues convergem no mesmo princípio: gatilhos por comportamento (o usuário acabou de completar uma ação que indica valor percebido) funcionam melhor do que gatilhos por calendário (mostrar o prompt sempre no dia 5, não importa o que o usuário fez). Um exemplo citado pela Appcues: dispare um e-mail de tutorial rápido 48 horas depois da conta ser criada se o usuário ainda não criou o primeiro projeto, em vez de esperar um dia fixo do calendário.
O que é seguro testar e o que exige cautela redobrada
Nem todo elemento do fluxo de upgrade tem o mesmo risco. Alguns podem ser testados com a mesma leveza de qualquer teste de CRO; outros mexem direto em receita e pedem mais rigor, amostra maior e um teste mais longo.
| Seguro de testar rápido | Exige cautela redobrada |
|---|---|
| Copy do prompt de upgrade (texto, tom, benefícios listados) | O preço em si (valor cobrado, moeda, forma de exibir o número) |
| Timing do prompt (logo após a ação-chave versus no dia seguinte) | Estrutura de planos e tiers (o que entra em cada plano) |
| Desconto ou urgência no fim do trial (ex.: condição especial nas últimas 48 horas) | Qualquer mudança que faça clientes pagarem valores diferentes na mesma janela |
| Layout e posição do banner de paywall in-app | Mudanças que afetam contratos ou cobranças já em andamento |
| Assunto e CTA do e-mail de fim de trial | Alterar o preço mostrado para quem já está no meio da decisão de compra |
| Número de dias de trial (7, 14 ou 30) |
Testar preço não é proibido, é apenas mais caro de fazer com honestidade. Segundo o próprio glossário estatístico deste blog, quanto menor o efeito que você quer detectar, maior a amostra necessária, e efeitos em receita por usuário costumam ser mais sutis do que efeitos em taxa de conversão de clique. Antes de rodar qualquer teste de preço, calcule o tamanho de amostra pelo guia completo de teste A/B ou pela calculadora de tamanho de amostra, e prepare-se para um teste mais longo do que os de copy.
O item “número de dias de trial” merece uma ressalva mesmo estando na coluna segura: ele não muda o preço cobrado, mas muda quanto tempo você precisa esperar para ler o resultado de cada coorte, porque a variação com trial mais longo simplesmente demora mais para “fechar” o ciclo de cada usuário. Isso não é um motivo para evitar o teste, é um motivo para planejar a duração certa dele, o assunto da próxima seção.
Como medir a conversão trial para pago sem se enganar
A métrica primária correta para esse teste é a taxa de conversão de trial para pago: quantos usuários que iniciaram o trial em cada variação terminaram pagando. O problema não está na fórmula, está no momento em que você olha para ela.
O problema da censura
Numa coorte de usuários que entraram no teste em datas diferentes, quem entrou há pouco tempo ainda está dentro do período de trial quando você faz a leitura. Esse usuário não converteu, mas também não teve a chance de não converter: ele simplesmente ainda não chegou ao fim do próprio ciclo. Tratar esse usuário como “não converteu” no meio da análise é um erro clássico de medição, chamado de censura: você está contando como resultado negativo algo que, na verdade, ainda é desconhecido.
A ChartMogul documenta esse efeito com um exemplo real: a mesma coorte de usuários, medida em momentos diferentes, mostrou 5% de conversão aos 30 dias, 9% aos 45 dias e 16% aos 90 dias. Não é que a conversão “aumentou” com o tempo num sentido mágico: é que boa parte dos usuários daquela coorte simplesmente ainda não tinha terminado de decidir quando a primeira medição foi feita. Segundo a própria ChartMogul, calcular a conversão comparando apenas os trials e as conversões de um mesmo mês, sem considerar o ciclo de cada coorte, é “simples demais para ser útil ou precisa”.
A correção prática é simples de enunciar e fácil de esquecer na hora de rodar o teste: só entra na comparação a coorte cujo trial já fechou por completo. Se o trial dura 14 dias, um usuário que começou o teste há 5 dias ainda não tem um resultado válido, positivo ou negativo, e deveria ficar de fora da leitura até completar o próprio ciclo.
Um teste de prompt de upgrade, com números reais
Imagine um SaaS self-serve com trial de 14 dias e uma taxa de conversão trial para pago de 15%, dentro da faixa que a Userpilot relata (citando dados da ChartMogul) para produtos B2B, que vai de 6-10% no percentil mediano a 15-20% no percentil mais alto do mercado. A hipótese: reescrever o prompt in-app que aparece quando o usuário esbarra num limite do plano gratuito, adicionando um exemplo concreto do que ele ganha ao fazer upgrade, deve aumentar a conversão em pelo menos 15% em termos relativos, de 15% para 17,25%.
Rodando esses números na mesma fórmula de duas proporções deste blog (95% de confiança, 80% de poder, teste bilateral), o tamanho de amostra necessário é de aproximadamente 4.193 trials por variação. Com um volume de 1.000 novos trials por semana, dividido entre as duas variações, juntar essa amostra leva cerca de 59 dias. Mas esse não é o prazo real do teste: o último usuário que entrar no teste no dia 59 ainda precisa completar os próprios 14 dias de trial antes de ter um resultado válido. A leitura final e limpa só acontece por volta do dia 73, exatamente duas semanas depois de a amostra “bater a meta”.
Ajuste a taxa de conversão, o efeito que você quer detectar e o volume semanal do seu próprio produto para ver como isso muda no seu caso:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Suponha que o teste realmente rodou até o fim e o controle registrou 629 conversões em 4.193 trials, contra 723 conversões em 4.193 trials na variação com o novo prompt. A taxa do controle fica em 15,0%, a da variação em 17,2%, uma melhora relativa de aproximadamente 15%, exatamente o efeito que o teste foi desenhado para detectar. Aplicando o mesmo teste z de duas proporções usado em toda calculadora deste blog, o escore z fica perto de 2,79 e o valor-p bilateral perto de 0,005, bem abaixo do limite de 0,05. Para o passo a passo dessa conta, veja como declarar significância estatística sem se enganar.
Erros comuns ao testar o fluxo de trial para pago
| Erro | Por que distorce o resultado |
|---|---|
| Comparar coortes com duração de trial diferente | Uma coorte de trial de 30 dias medida no dia 20 parece pior que uma coorte de 7 dias já fechada, mas a segunda simplesmente teve mais tempo para se resolver |
| Contar “ainda em trial” como “não converteu” | Infla artificialmente a taxa de não conversão da coorte mais recente, achatando o resultado do teste para baixo sem motivo real |
| Rodar o teste do prompt ao mesmo tempo que outra mudança de produto | Um redesenho de onboarding ou uma mudança na página de preços rodando em paralelo contamina qual das duas mudanças moveu a métrica |
| Encerrar a leitura assim que a amostra é atingida | Ignora que a última coorte enrolada ainda não teve o ciclo de trial inteiro para se resolver, ver a seção de censura acima |
| Trocar a métrica no meio do caminho | Migrar de “conversão paga” para “cliques no prompt” só porque o segundo número “deu vitória” primeiro é o mesmo erro de pescaria de qualquer teste A/B |
O segundo erro da lista (rodar outra mudança de produto ao mesmo tempo) é especialmente comum em times de growth que têm várias equipes mexendo no onboarding, no pricing e no fluxo de upgrade na mesma semana. Se outra equipe está testando ou lançando algo que também afeta o momento entre o início do trial e a decisão de pagar, isolar qual mudança causou qual efeito deixa de ser possível. Trate o calendário de mudanças no fluxo de upgrade como um recurso compartilhado, não um free-for-all.
Automatize isso na Donnu
Testar o fluxo de upgrade de trial para pago é o tipo de experimento que mais pune quem lê o painel cedo demais: a métrica que decide receita real fica incompleta até o ciclo do trial fechar para a última coorte, e declarar um vencedor antes disso é decidir com base em usuários que ainda nem tiveram a chance de converter. A Donnu ajuda na parte que dá para automatizar dessa disciplina: o motor estatístico da Donnu calcula a amostra antes de você rodar o teste, e o snippet leve não trava a página de upgrade nem o e-mail transacional que dispara o prompt. A decisão de esperar o ciclo do trial fechar antes de ler o resultado continua sendo sua, e é exatamente essa etapa que mais times pulam.
Comece um teste grátis de 14 dias e meça o seu próprio fluxo de upgrade sem cair na armadilha da coorte incompleta.
Leia também: Growth experimentation para SaaS · Como fazer um teste A/B passo a passo · Como declarar significância estatística sem se enganar
Referências
- ChartMogul. Make trial-to-paid conversion rates meaningful with Cohorts. chartmogul.com/blog/make-trial-to-paid-conversion-rates-meaningful-with-cohorts.
- Userpilot. SaaS Average Free Trial Conversion Rate: Benchmarks. userpilot.com/blog/saas-average-conversion-rate.
- Kissmetrics. Trial to Paid Conversion: Strategies That Move Users Past the Paywall. kissmetrics.io/blog/trial-to-paid-conversion.
- Appcues. Free trial conversion rate: benchmarks and 12 strategies to improve. appcues.com/blog/free-to-paid-conversion-strategies.
Perguntas frequentes
- Posso testar o número de dias do trial (7, 14 ou 30) como um teste A/B comum?
- Sim, é um dos elementos mais seguros de testar, mas com uma armadilha de medição: a variação com trial mais longo demora mais para fechar o ciclo de cada coorte, então o teste como um todo precisa rodar por mais tempo antes de qualquer leitura ser justa. Nunca compare a conversão de uma coorte de 7 dias já fechada com uma coorte de 30 dias ainda em andamento: espere o mesmo número de dias corridos desde o início do trial para as duas variações antes de comparar.
- Por que a taxa de conversão trial para pago cai quando eu meço no meio do teste?
- Porque parte dos usuários que entraram no teste mais recentemente ainda está dentro do período de trial e não teve a chance de converter nem de deixar o trial expirar. Contar esses usuários como "não converteu" é um erro de censura: eles não são um resultado negativo, são um resultado ainda desconhecido. A ChartMogul documenta isso com números reais de uma coorte: 5% de conversão medida aos 30 dias, 9% aos 45 dias e 16% aos 90 dias, o mesmo grupo de usuários, só que lido em momentos diferentes do ciclo.
- É seguro testar o preço em si dentro do fluxo de upgrade?
- Não do mesmo jeito que se testa copy ou timing de um prompt. Mudar o valor cobrado afeta receita diretamente, pode gerar problemas de paridade de preço entre clientes que pagaram valores diferentes na mesma janela, e normalmente exige uma amostra maior e um teste mais longo para ser lido com segurança, porque o efeito em ARPU costuma ser mais sutil do que o efeito em taxa de conversão. Calcule a amostra necessária antes de rodar esse tipo de teste, não depois.
- Qual métrica deveria decidir um teste no prompt de upgrade: cliques, ativação ou conversão paga?
- Conversão trial para pago é a métrica primária, porque é a única que reflete receita de verdade. Cliques no prompt e ativação de funcionalidades são métricas secundárias, úteis para entender o "porquê" de um resultado, mas não devem decidir sozinhas se uma variação venceu: é comum uma variação gerar mais cliques e, ainda assim, converter menos em pagamento.
- Quanto tempo, no mínimo, um teste no fluxo de trial para pago deveria rodar?
- O tempo para juntar a amostra calculada mais a duração inteira do trial da última coorte que entrou no teste. Se o seu trial dura 14 dias e o último usuário entrou no teste no dia 59 de coleta, você só tem uma leitura limpa e completa no dia 73, não no dia 59. Encerrar antes disso é decidir com parte dos dados ainda censurada.