Num funil de teste grátis, a prova que importa é que pessoas como o visitante começaram um teste e depois escolheram pagar. As compras verificadas chegam no fim desse funil pelo Stripe, o que significa que o sinal mais forte está disponível justamente onde a decisão mais difícil é tomada. Este post percorre o funil etapa por etapa e diz o que mostrar, o que pular e como manter tudo honesto.
O funil de teste e onde entra a prova
Um funil típico de SaaS self-service tem quatro etapas:
- Landing page ou página de marketing. O visitante está decidindo se vai testar.
- Cadastro. Ele está decidindo se vale a pena preencher o formulário.
- Onboarding e ativação. Ele está decidindo se o produto funciona para ele.
- Conversão para pago. Ele está decidindo se vale o dinheiro.
A prova social reduz o risco percebido, e o risco muda a cada etapa. No topo é "isso vai me fazer perder tempo?". No fundo é "isso vai me fazer perder dinheiro?". Combinar a prova com o risco é o jogo inteiro.
Etapas 1 e 2: o site de marketing e o cadastro
O site de marketing.
Aqui o visitante quer saber que o produto é real, que outras pessoas o usam e que testar custa pouco. Prova adequada:
- Notificações de compra verificada nas páginas de preços e de recursos, mostrando que pessoas estão convertendo para planos pagos. Como os registros vêm de webhooks assinados do Stripe, cada um leva a marca de Compra verificada com link para a sua página de verificação. Segmente com "só estas páginas" e um limite baixo por sessão, como descrito em /blog/social-proof-on-pricing-page.
- Um contador ao vivo na página de preços se ela for movimentada o bastante para passar do mínimo com regularidade. O contador mede os visitantes dos últimos 90 segundos e, caso contrário, se esconde.
- Prova estática na página: logos com permissão, uma contagem de contas com data, um link para /trust ou para a sua própria página de confiança.
Não use notificações no blog nem na documentação. Quem está lá está aprendendo, não decidindo.
O formulário de cadastro.
Mantenha o widget fora da própria página de cadastro ou, no máximo, permita uma única notificação logo no início. Um formulário é uma tarefa, e sobreposições durante uma tarefa custam cadastros concluídos. Se quiser tranquilizar na página de cadastro, coloque isso no texto ao lado do formulário: uma frase sobre quantas pessoas se cadastraram este mês, com data, é mais útil do que uma notificação deslizante e não interrompe a digitação.
Etapas 3 e 4: onboarding e conversão
Onboarding.
Dentro do produto, durante a primeira sessão, a atenção do visitante deve estar em chegar ao momento em que o produto prova o seu valor. Notificações de compra aqui são basicamente ruído, e recomendamos deixá-las desligadas.
A exceção é uma oferta de boas-vindas real e aplicada. Se contas novas recebem um preço reduzido por um período fixo após o cadastro, uma barra evergreen por visitante na página de cobrança é honesta e útil: ela conta a mesma janela que o seu cupom do Stripe aplica, persiste entre visitas e some quando a janela fecha. As condições que impedem que isso vire um dark pattern estão em /blog/evergreen-timers-without-dark-patterns. Não mostre a barra se a oferta não for realmente aplicada.
Conversão para pago.
É aqui que a prova verificada mostra o seu valor. Na página de cobrança ou de upgrade dentro do app:
- Notificações de compras de plano verificadas, limite baixo, intervalo longo. Um usuário em teste avaliando o upgrade vê que outras pessoas pagaram recentemente pelo plano que ele está considerando e pode clicar para ver de onde vêm esses dados.
- A barra evergreen, se existir uma oferta de boas-vindas e ela estiver dentro da janela.
- Nada de urgência falsa. Um usuário em teste já usou o produto e formou uma opinião; uma contagem regressiva que reinicia não vai mudá-la e pode invertê-la.
Como é "verificado" num negócio de assinatura
Num SaaS no Stripe, o evento verificado é o que o Stripe envia quando uma assinatura começa ou um pagamento é bem-sucedido. Inícios de teste não são compras e não recebem a marca de verificado; a marca é reservada a webhooks assinados que descrevem dinheiro trocando de mãos. Isso é uma vantagem. "Alguém começou um teste grátis" é um sinal fraco, e disfarçá-lo de compra seria enganoso. Se você quer mostrar cadastros em teste, rotule-os com clareza e mantenha-os separados.
| Evento | Fonte | Rótulo |
|---|---|---|
| Teste iniciado | O seu app | Não é uma compra; se mostrar, que seja como texto estático |
| Assinatura criada, pagamento bem-sucedido | Webhook assinado do Stripe | Compra verificada |
| Clientes antigos importados por CSV | Upload | Imported |
Como a cadeia funciona está em /blog/how-verified-purchase-notifications-work.
Medir sem se enganar
Funis de teste são longos, e a atribuição é onde os painéis de SaaS costumam exagerar. A contagem de pedidos assistidos pela prova da Provedly cruza um pedido verificado com um ID de visitante que viu uma notificação nos 30 dias anteriores, e nada mais. É um teto de influência, não uma afirmação de receita. Num funil de teste, leia como "dos testes que converteram, esta fatia viu prova antes" e rode de vez em quando um período liga/desliga para ver se tirar o widget muda a taxa de conversão. Detalhes e limites estão em /blog/measuring-proof-assisted-orders.
Uma observação sobre a janela de 30 dias: se o seu teste dura mais de 30 dias, algumas conversões vão cair fora dela e ser contadas como não assistidas. Nesse caso a contagem fica abaixo da realidade, que é a direção mais segura.
Uma configuração inicial
- Notificações em
/pricinge/features*, limite 3, intervalo de 30 segundos, padrões no desktop, reduzido no mobile. - Contador ao vivo só em
/pricing, só no desktop e só se o tráfego comportar. - Nada no cadastro, na documentação, no blog ou durante o onboarding.
- Notificações e, se for o caso, uma barra evergreen de boas-vindas na página de cobrança dentro do app.
- Stripe conectado para que toda notificação seja uma compra verificada; registros de amostra arquivados assim que os reais começarem a chegar.
O plano Free da Provedly inclui compras verificadas, um site, um widget e uma barra, com 2.000 impressões por mês, o que cobre um funil de teste pequeno. Os planos estão em /pricing.
Perguntas frequentes
Devo mostrar notificações do tipo "X pessoas começaram um teste hoje"?
Só se o número for real e estiver rotulado como teste, não como compra. A Provedly não verifica inícios de teste, então uma notificação assim levaria o rótulo Imported ou Sample, nunca a marca de verificado. Um texto estático com data costuma ser o formato melhor.
Onde as notificações mais ajudam num funil de teste?
Na página de preços antes do cadastro e na página de cobrança antes do upgrade. Os dois são momentos em que o visitante está pesando dinheiro contra valor, que é a pergunta que as compras verificadas respondem.
Posso rodar a prova dentro do app e no site de marketing com uma conta só?
O plano Free cobre um site e um widget. O Starter, a $9, cobre dois sites e cinco widgets, o que comporta um site de marketing mais um app em domínios separados.
Crie uma conta grátis na Provedly e conecte o Stripe: /register.