Teste A/B de Paywall Mobile: um Guia Prático
Teste paywall mobile: onde posicionar o gatilho, hard x soft paywall, a métrica que decide e a estatística certa para apps iOS e Android.
📚 Este artigo faz parte do guia Teste A/B em Apps Mobile: o Guia Completo (iOS + Android).
Um teste A/B de paywall mobile compara duas versões de como e quando você pede para o usuário pagar, medindo qual gera mais conversão de assinatura sem destruir a retenção depois. É o teste que mais decide a receita de um app de assinatura, e é também o mais fácil de ler errado, porque um paywall mais agressivo quase sempre eleva a conversão do primeiro momento, mesmo quando piora o negócio no agregado. Este artigo é filho do teste A/B em apps mobile (o guia completo do cluster) e assume a mesma base estatística explicada lá: unidade de aleatorização por dispositivo, feature flag remota no lugar de deploy instantâneo e cuidado redobrado com SRM entre versões de app.
Se o seu foco ainda é a primeira experiência do usuário antes de chegar ao paywall, veja também o guia de teste A/B de onboarding mobile, porque onde o paywall aparece dentro do onboarding é, na prática, uma decisão conjunta dos dois experimentos.
Onde posicionar o paywall no app
O timing do paywall é a variável isolada que mais muda o resultado de um teste de monetização mobile, mais até do que o texto ou o design da tela. Três momentos concentram a maior parte dos testes reais:
- Antes do onboarding (paywall imediato, hard). O usuário vê a oferta de assinatura antes de sequer usar o produto, às vezes com um trial de prazo fixo embutido. Converte melhor entre quem já chegou decidido a pagar (tráfego pago qualificado, por exemplo), mas afasta parte de quem só queria experimentar, reduzindo o volume total que chega a ativar.
- Depois do “aha moment” (paywall no meio do funil). O usuário já sentiu o valor central do produto (completou a primeira ação relevante, viu o primeiro resultado) antes de ver qualquer oferta. Tende a converter uma base menor, mas mais convencida, porque a decisão de pagar já vem depois de uma experiência real, não de uma promessa.
- Ao atingir um limite de uso (soft paywall). O usuário usa uma versão gratuita real até esbarrar num teto (um número de buscas, um limite de itens salvos, um recurso premium específico), e só então vê a oferta. É o modelo mais comum em apps de produtividade e ferramentas, porque deixa o produto provar valor antes de cobrar.
Hard paywall x soft paywall: o que cada um testa
Hard e soft paywall não são só posições diferentes no funil, são modelos de negócio diferentes, e testar um contra o outro é uma decisão maior do que testar copy ou cor de botão.
| Critério | Hard paywall | Soft paywall (freemium) |
|---|---|---|
| Acesso ao produto sem pagar | Nenhum, ou só um trial com prazo fixo | Real, até um limite de uso ou recurso |
| Conversão trial/free para pago (mediana, RevenueCat) | 10,7% em D35 | 2,1% |
| Top 10% dos apps (RevenueCat) | 38,7% | não medido no mesmo corte pela RevenueCat |
| Volume de instalações que chega a experimentar o valor | Menor (quem não converte, sai cedo) | Maior (produto gratuito real segura mais gente) |
| O que testar tipicamente | Duração do trial, momento do prompt, mensagem de urgência | Onde fica o limite, o que é gratuito, o gatilho de exibição da oferta |
| Risco principal | Afastar usuário que só queria experimentar | Nunca converter quem já recebe valor de graça |
Segundo o mesmo relatório da RevenueCat, mesmo dentro do modelo hard paywall a duração do trial muda muito o resultado: trials de 17 a 32 dias convertem a uma mediana de 42,5%, contra 25,5% em trials de menos de 4 dias, e 55% dos cancelamentos de trials de 3 dias já acontecem no dia 0, antes mesmo do usuário experimentar o produto por um dia inteiro. Isso não decide qual duração é certa para o seu produto, mas mostra que “quanto tempo dar de trial” é, ele mesmo, uma variável de teste tão relevante quanto o texto do paywall.
O que testar no paywall mobile
Quatro variáveis concentram a maior parte dos testes de paywall com efeito real mensurável:
- A mensagem. O que o paywall promete (economia de tempo, um recurso específico, prova social) muda a percepção de valor antes mesmo do preço aparecer. Teste um benefício concreto contra uma lista de recursos genérica.
- A posição do gatilho. Quando o paywall aparece (por tempo de uso, por tentativa de usar um recurso, por número de sessões) muda quem o vê e em que estado de intenção.
- Hard paywall x soft paywall. Como já detalhado, é o teste de maior impacto e também o de maior risco, porque muda o modelo de aquisição, não só a tela.
- Apresentação dos planos: anual x mensal. Qual plano vem pré-selecionado, como o anual é ancorado (preço por mês equivalente, desconto percentual, economia em valor absoluto) e a ordem de exibição dos planos afetam tanto a conversão quanto o plano escolhido, o que muda o LTV mesmo sem mudar a conversão bruta.
Sobre o último ponto: testar qual plano vem pré-selecionado por padrão costuma ter um efeito desproporcional ao esforço de implementação, porque a maioria dos usuários aceita a opção já marcada em vez de trocar ativamente. Isso também é o ponto onde a Apple é mais rígida: a App Store Review Guideline 3.1.2 exige que o valor total cobrado seja o elemento de preço mais visível e legível da tela de compra, com qualquer preço promocional, trial ou cálculo de desconto exibido em posição subordinada e menor. Na prática, isso restringe testes que tentem esconder ou reduzir a proeminência do preço cheio para empurrar o plano anual, o mesmo tipo de variação que passaria sem problema num paywall web.
A métrica que decide: conversão free-to-paid e retenção pós-conversão
O princípio é o mesmo de qualquer teste de paywall ou pricing na web: a métrica primária é a conversão de free (ou trial) para pago, sempre acompanhada de um guardrail de retenção pós-conversão, porque converter mais gente que cancela rápido depois não é vitória, é só adiar a perda. A nuance mobile está em dois pontos que quase não existem num checkout web:
- Cancelamento é mais fácil dentro do app store. A Apple exige que o cancelamento de uma assinatura seja feito pelo gerenciador de assinaturas da própria conta Apple, o app do desenvolvedor nem tem acesso para processar esse cancelamento diretamente. O Google também garante o cancelamento pela Play Store, mas sua política de assinaturas passou a exigir que o próprio app do desenvolvedor ofereça um caminho de cancelamento fácil, em no máximo dois toques, proibindo padrões de design que escondam ou dificultem essa opção. Nos dois casos, quem controla o quanto o cancelamento pode ser dificultado não é o desenvolvedor, ao contrário de um checkout web, onde o próprio produto controla o fluxo (e às vezes dificulta de propósito), o que quer dizer que um paywall agressivo tende a mostrar o efeito de cancelamento mais rápido em mobile do que na web.
- Reembolso via loja tem prazo próprio, fora do seu controle. Segundo o suporte do Google Play, assinaturas são reembolsáveis dentro de 48 horas da compra inicial pelo processo padrão de solicitação; depois disso, cancelar impede cobranças futuras, mas não devolve o período já pago. A Apple, segundo o próprio suporte oficial, recomenda que o pedido de reembolso seja feito em até 14 dias mas tecnicamente aceita solicitações de até 90 dias da compra, avaliando cada caso individualmente. Nenhuma das duas janelas é definida pelo seu produto, então qualquer cálculo de receita líquida de um teste de paywall precisa considerar esse prazo específico da loja, não o prazo de reembolso que você usaria num checkout próprio.
Trate esses dois pontos como guardrail, não só como nota de rodapé: um paywall vencedor na conversão bruta que também eleva reembolso e cancelamento no primeiro mês pode estar apenas comprimindo no tempo uma receita que já ia embora de qualquer forma.
Particularidades mobile que mudam o teste
Três fatores específicos de mobile ameaçam a leitura de um teste de paywall que já passaria despercebido num teste de site:
SRM entre versões de app
Se a variação do paywall depende de uma versão nova do app ou de uma configuração remota que ainda não chegou a todo mundo, uma fatia da base cai no controle por padrão (ou nem entra no teste), sem que ninguém tenha decidido isso de propósito. Um exemplo com números reais: um teste de paywall configurado para 50/50 deveria expor 5.000 usuários a cada variação, de um total de 10.000 que chegaram ao momento do paywall numa semana. Como a variação nova só renderiza em versões de app iguais ou mais recentes que a atualização, o resultado observado foi 6.200 usuários na variação de controle e 3.800 na variação nova. O qui-quadrado de aderência para essa divergência ((6200-5000)² / 5000 + (3800-5000)² / 5000) dá aproximadamente 576, um valor muito acima do limiar crítico de significância a 1% (6,63 com 1 grau de liberdade), ou seja, uma divisão dessa magnitude é, na prática, impossível de acontecer por acaso. A causa mais provável é técnica (versão de app ou cache de configuração remota), não estatística, e nenhum resultado de conversão desse teste deveria ser confiável até a causa ser corrigida.
Latência de propagação da configuração remota
Mesmo quando a variação do paywall não depende de nova versão de binário (só de uma flag lida via remote config), o dispositivo precisa buscar essa configuração antes de exibi-la, e esse processo não é instantâneo. Um app em segundo plano por dias, ou num dispositivo com economia agressiva de bateria, pode continuar mostrando a versão antiga do paywall por bem mais tempo que o esperado. Trate os primeiros dias de qualquer teste de paywall como um período de propagação, não como amostra válida a ser somada sem checagem à leitura final.
Regras de loja sobre preço no paywall
Além da Guideline 3.1.2 da Apple já citada, o Google Play oferece nativamente a ferramenta Price experiments no Play Console, feita para testar preço com tráfego real; o próprio Google recomenda esperar a significância estatística antes de aplicar a variação vencedora, mas essa aplicação é manual (um botão que o desenvolvedor aciona), não automática, e essa ferramenta hoje é limitada a produtos avulsos (in-app products) dentro do app, não ao preço da assinatura do paywall em si. A Apple não tem uma ferramenta nativa equivalente de teste de preço dentro do App Store Connect; testar preço, copy e layout do paywall no iOS depende do seu próprio mecanismo de remote config, respeitando os limites da Guideline 3.1.2 sobre proeminência do valor cobrado.
Um exemplo trabalhado com números reais
Cenário: um app com paywall soft (o usuário usa de graça até um limite, depois vê a oferta) converte hoje 7% dos usuários que veem o paywall de free para pago. O time redesenha a mensagem e o momento do gatilho, esperando uma melhora relativa de 20% (de 7% para cerca de 8,4%). Com 95% de confiança e 80% de poder, os mesmos padrões usados em toda calculadora deste blog, ajuste os números abaixo para o seu próprio cenário:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Rodando esse cálculo na mesma matemática da calculadora (sampleSizePerVariant), o resultado é 5.691 usuários por variação (11.382 no total, contando quem realmente vê o paywall, não o total de instalações do app). Se 1.800 usuários por semana chegam ao momento do paywall (um volume realista para um app de porte médio numa tela de conversão, bem abaixo do total de instalações), a duração do teste fica em 45 dias, cerca de seis semanas e meia, para as duas variações fecharem a amostra.
Agora veja o que acontece se o time decide olhar o resultado cedo, com só um terço da amostra calculada (1.897 por variação), com taxas de conversão observadas quase idênticas às do cenário completo:
| Amostra completa (5.691 por variação) | Amostra parcial, ⅓ (1.897 por variação) | |
|---|---|---|
| Taxa A (controle) | 6,99% | 7,01% |
| Taxa B (variação) | 8,40% | 8,38% |
| Melhora relativa observada | +20,1% | +19,5% |
| Valor-p | 0,0049 | 0,113 |
| Intervalo de confiança da diferença | +0,43 a +2,38 pontos | −0,33 a +3,07 pontos |
| Veredito | Significativo, B vence | Inconclusivo |
A melhora observada é praticamente a mesma nos dois casos (a variação nova realmente parece cerca de 20% melhor), mas o veredito muda por completo: com a amostra completa, o valor-p fica em 0,0049 e o intervalo de confiança da diferença não cruza zero, entre 0,43 e 2,38 pontos percentuais, um resultado sólido. Com um terço da amostra, o valor-p sobe para 0,113, acima do limiar de 0,05, e o intervalo cruza zero (vai de −0,33 a +3,07 pontos), ou seja, ainda é plausível que o novo paywall não faça diferença nenhuma. Isso não significa que o teste parcial “deu errado”, significa que faltou amostra para o mesmo efeito real virar evidência estatística, e é exatamente por isso que a duração calculada de 45 dias existe: para não decidir de olho no painel no meio do caminho.
Erros comuns em teste de paywall mobile
| Erro | Por que acontece | Consequência |
|---|---|---|
| Medir só conversão, sem guardrail de retenção | A conversão do primeiro momento é mais fácil de ver do que o cancelamento de semanas depois | Paywall “vencedor” que na verdade só acelerou uma perda de receita que já ia acontecer |
| Não segmentar SRM por versão de app | A variação nova só chega a quem já atualizou, e isso passa despercebido no agregado | Resultado de conversão inválido, mesmo parecendo “limpo” à primeira vista |
| Confundir teste de ASO com teste de paywall | Os dois comparam “duas versões de algo”, mas em pontos diferentes do funil | Otimizar ícone e screenshot não move a conversão de assinatura dentro do app, e vice-versa |
| Ignorar o prazo de propagação da configuração remota | A flag é lida no próximo sync do app, não instantaneamente | Primeiros dias do teste contaminados com usuários ainda vendo a versão antiga |
| Testar variações de preço que escondem o valor cobrado no iOS | Pressa em replicar um teste que funcionaria num paywall web | Risco de rejeição na revisão da Apple por violar a Guideline 3.1.2 |
| Declarar vencedor com amostra parcial | Ansiedade de lançar rápido, olhando o painel antes da hora | Mesmo efeito real pode aparecer como inconclusivo só por falta de amostra, como no exemplo trabalhado acima |
ASO e paywall: duas coisas diferentes
É comum confundir os dois porque ambos “testam duas versões de alguma coisa relacionada ao app”. Teste de ASO (App Store Optimization) roda na ficha da loja, antes da instalação: a Apple oferece isso como Product Page Optimization no App Store Connect, testando só elementos visuais (ícone, screenshots, vídeo de preview), e o Google, como Store listing experiments no Google Play Console, que vai além do visual e também testa texto (descrição curta e descrição completa), os dois com tráfego real de busca e navegação da loja. O que decide um teste de ASO é a taxa de conversão de visualização da ficha em instalação. Teste de paywall in-app roda depois, dentro do produto já instalado, e o que decide é a conversão de free (ou trial) para pago. Um app pode ganhar um teste de ASO e continuar com o mesmo paywall fraco, ou o contrário: são otimizações independentes, sobre métricas diferentes, e vale rodar as duas, mas nunca tratar uma como substituta da outra.
Faça isso automático na Donnu
Este guia cobriu o que muda de verdade quando o teste de paywall sai de um checkout web e entra no app: hard x soft paywall como decisão de modelo de negócio, SRM que costuma nascer de versão de app desatualizada, latência de propagação de configuração remota e regras de loja sobre a proeminência do preço cobrado, tudo isso além da mesma disciplina de amostra e significância que vale para qualquer teste A/B.
A Donnu hoje é uma ferramenta focada no lado web e client-side: snippet leve que nunca trava a página, dimensionamento de amostra automático e estatística bayesiana honesta. Ela não testa paywall dentro de um app nativo iOS/Android, e este guia não afirma o contrário. Se o seu produto tem uma camada web que participa da jornada de pagamento (uma landing page que vende o plano antes da instalação, um checkout web complementar, uma área logada acessada também pelo navegador), a Donnu já aplica esse mesmo rigor estatístico a essa fatia com um teste grátis de 14 dias.
Leia também: Teste A/B em Apps Mobile: o Guia Completo (iOS + Android) · Teste A/B de Onboarding Mobile
Referências
- RevenueCat. State of Subscription Apps 2026. Benchmarks de conversão de trial/free para pago por modelo de paywall e duração de trial, com base em mais de 100 mil apps. revenuecat.com/state-of-subscription-apps.
- Google Play Console. Price experiments. Página oficial sobre a ferramenta nativa de teste A/B de preço de produtos avulsos (in-app products), com aplicação manual da variação vencedora recomendada após significância estatística; hoje não cobre preço de assinatura. play.google.com/console/about/price-experiments.
- Apple Developer. App Review Guidelines (seção 3.1.2, Subscriptions). Regras oficiais sobre proeminência do valor cobrado e informação de assinatura na tela de compra. developer.apple.com/app-store/review/guidelines.
- Apple Support. Request a refund for apps or content that you bought from Apple. Prazo e processo oficial de solicitação de reembolso de compras e assinaturas. support.apple.com/en-us/118223.
- Google Play Help. Apps, games, & in-app purchases (including subscriptions) refund policies. Janela de 48 horas e processo de solicitação de reembolso para assinaturas no Google Play. support.google.com/googleplay/answer/15574908.
- Google Play Console. Store listing experiments. Teste A/B nativo da ficha de listagem (ícone, feature graphic, screenshots, vídeo e também descrição curta e completa), distinto do teste de paywall dentro do app. play.google.com/console/about/store-listing-experiments.
- Apple. Product Page Optimization. Recurso do App Store Connect que testa variações de ícone, screenshots e vídeo de preview da ficha, também distinto do paywall in-app. developer.apple.com/app-store/product-page-optimization.
Perguntas frequentes
- Qual o melhor momento para mostrar o paywall num app mobile?
- Não existe momento universal, é por isso que isso é um teste, não uma escolha de design. Três posições concentram a maior parte dos testes: antes do onboarding (paywall imediato, hard), depois do "aha moment" (quando o usuário já sentiu o valor central do produto) e ao atingir um limite de uso (soft paywall, o usuário usa de graça até um teto e só então vê a oferta). Cada uma converte diferente dependendo de quão rápido o seu produto entrega valor perceptível; meça pela conversão free-to-paid real, não pela taxa de clique no botão de assinar.
- Qual a diferença entre hard paywall e soft paywall?
- Hard paywall bloqueia o acesso ao produto até o usuário assinar (ou, no máximo, libera um trial com prazo fixo antes de cobrar). Soft paywall deixa o usuário usar uma versão gratuita real, com limite de uso ou de recursos, e só mostra a oferta paga quando esse limite aparece ou quando o usuário tenta uma função premium. Segundo a RevenueCat, no relatório State of Subscription Apps, apps com hard paywall convertem a uma mediana de 10,7% de trial para pago em D35, contra 2,1% em apps com modelo freemium (soft paywall), uma diferença de cerca de 5 vezes, mas isso não decide sozinho qual modelo é certo para o seu produto: hard paywall também tende a reduzir o volume total de instalações que chegam a experimentar o app.
- A métrica de um teste de paywall é só a conversão free-to-paid?
- Não, e tratar só a conversão como métrica primária é o erro mais caro nesse tipo de teste. A conversão free-to-paid decide o teste, mas sempre lida junto com um guardrail de retenção pós-conversão (o assinante continua pagando nos meses seguintes, ou cancela rápido) e, em mobile, com a taxa de reembolso via loja, porque cancelar e pedir reembolso dentro do app store é mais fácil para o usuário do que em qualquer checkout web, e um paywall agressivo pode inflar a conversão do primeiro momento e derrubar a receita real semanas depois.
- O que é SRM entre versões de app e por que isso ameaça um teste de paywall?
- SRM (Sample Ratio Mismatch) é quando a divisão observada entre variações diverge da configurada por um problema de coleta, não por acaso. No paywall, a causa mais comum é a variação nova depender de uma versão de app ou de uma configuração remota que ainda não chegou a uma fatia da base: esses usuários caem no controle por padrão (ou nem entram no teste), inflando um lado sem que ninguém tenha decidido isso de propósito. Sempre segmente o checador de SRM por versão de app antes de confiar em qualquer resultado de conversão do paywall.
- Teste de paywall in-app é a mesma coisa que teste de ASO?
- Não, são mecanismos completamente diferentes. Teste de paywall roda dentro do app já instalado, depois que o usuário abriu o produto, e mede conversão de assinatura. Teste de ASO (App Store Optimization), como o Product Page Optimization da Apple ou o Store listing experiments do Google Play, roda na ficha da loja, antes da instalação, e mede conversão de visualização em instalação. A Apple testa só elementos visuais (ícone, screenshots, vídeo de preview); o Google Play vai além e também testa texto (descrição curta e descrição completa) além do visual. Nenhum dos dois testa preço nem o fluxo de assinatura dentro do produto.
- Posso testar preço de assinatura mobile do mesmo jeito que testo copy do paywall?
- Tecnicamente sim, mas com mais cautela regulatória do que um teste de copy ou de posição do gatilho. O Google Play Console tem uma ferramenta nativa chamada Price experiments, mas hoje ela cobre preço de produtos avulsos (in-app products), não o preço de assinatura em si; para assinatura, o Google oferece outros mecanismos, como aumento de preço com aviso prévio aos assinantes atuais, não um teste A/B de preço nesse formato. Do lado da Apple, a App Store Review Guideline 3.1.2 exige que o valor cobrado seja o elemento de preço mais visível e legível da tela, com qualquer texto de trial ou preço promocional em posição subordinada, o que limita quais variações de layout de preço são seguras de testar num paywall iOS sem correr risco de rejeição.