Monte uma sequência de conversão do teste grátis guiada pelo uso do produto: evento de ativação, um objetivo por e-mail, elegibilidade e testes de saída.
Um e-mail de conversão do período de teste deve responder ao que o usuário fez. Quem ainda não criou um projeto precisa de ajuda com a configuração. Quem usa o produto todo dia precisa de uma explicação clara do plano pago. Mandar a mesma contagem regressiva para as duas pessoas ignora essa diferença.
Este guia separa a estrutura da sequência da lógica da aplicação que decide quem deve receber cada e-mail.
Escolha uma ação que mostre que o usuário chegou ao primeiro resultado útil do produto. Ela precisa ser específica o bastante para o seu back-end registrar: um projeto criado, uma importação concluída ou um colega de equipe convidado. Uma visualização de página raramente basta sozinha.
Registre o horário do cadastro, o fim do período de teste, a ativação e o status de pagamento no sistema que é dono desses dados. Trate os campos de contato da plataforma de e-mail como dados sincronizados, não como prova de que um fluxo iniciado antes está lendo o estado atualizado.
| Mensagem | Quando é útil | Elegibilidade verificada na hora do envio |
|---|---|---|
| Boas-vindas | Depois do cadastro ou da verificação | A conta existe e pode receber esta mensagem |
| Ajuda com a configuração | Cerca de dois dias depois, ajustado ao seu produto | Não ativou |
| Próxima ação útil | Depois da ativação | Ativou e não concluiu essa ação |
| Fim do período de teste | Antes do prazo real do período de teste | O período de teste continua ativo e a conta não é paga |
| Último acompanhamento | Depois do fim do período de teste, se fizer sentido | Continua sem pagar, elegível e com permissão para receber e-mails de marketing |
Esses momentos são pontos de partida para testar, não intervalos com o melhor desempenho medido. Informe o prazo real do período de teste e o que acontece depois dele. Não invente escassez nem dê a entender que vai haver uma cobrança quando não há nenhuma forma de pagamento cadastrada.
Em um fluxo do Brew disparado por evento, payload.activated lê o evento original, enquanto contact.activated lê o valor atual do campo do contato do destinatário no Brew no momento em que um nó Filtro ou Divisão por condição é executado. Para pular os lembretes de configuração depois da ativação, declare esse campo booleano, mantenha-o sincronizado a partir do seu produto e verifique contact.activated equals false depois de cada etapa Aguardar relevante. Um valor ausente não equivale a false; teste esse caso separadamente.
Essas leituras usam o contato armazenado no Brew, não o banco de dados da sua aplicação nem uma consulta em tempo real ao Stripe. Receber um evento de ativação ou de pagamento não cancela automaticamente uma execução anterior. O grafo precisa de uma condição antes de cada envio que depende do estado.
Para dados que ficam fora do Brew, faça a sua aplicação agendar uma tarefa. Quando chegar a hora, leia a conta ou a fatura atual e dispare um evento personalizado separado no Brew só se o destinatário ainda for elegível. Inclua nesse novo evento os dados atuais de que a personalização precisa.
Por exemplo, um lembrete agendado pela aplicação funciona como no roteiro abaixo: depois que o cadastro é efetivado, a aplicação dispara o evento de boas-vindas; quando a tarefa de lembrete vence, ela lê a conta atual e termina sem disparar nenhum evento de e-mail se a pessoa já ativou ou pagou, ou dispara o evento de lembrete de configuração com os dados atuais se ela ainda for elegível.
Signup committed → fire welcome event
Reminder job becomes due → read current account
Already activated or paid → finish without firing an email event
Still eligible → fire setup-reminder event with current dataUse o ID real do gatilho que o Brew retornou e o esquema declarado do gatilho. Siga o guia de configuração de automações e a documentação sobre contratos de payload tipados. Use o mecanismo de idempotência documentado nas novas tentativas de disparo de eventos.
Se o Stripe gerencia o período de teste, os eventos de assinatura dele dão o contexto de cobrança. A integração com o Stripe oferece gatilhos para os eventos compatíveis, entre eles o customer.subscription.trial_will_end. A ativação no produto continua sendo responsabilidade da sua aplicação, a menos que você envie essa informação separadamente.
Para um lembrete posterior relacionado a pagamento, confira o registro atual no Stripe. Atualizar o cartão com sucesso não prova que uma fatura foi paga. Coordene com os e-mails que o próprio Stripe envia, para que o cliente receba um único aviso para cada finalidade.
Comece pela situação real do destinatário. Explique uma ação útil e coloque um link direto para ela. Um e-mail de configuração pode oferecer um exemplo curto e um endereço para respostas. Um e-mail sobre o plano pago deve descrever o limite ou o recurso relevante e o preço real, com um link para os preços atuais.
Mantenha o consentimento de marketing, o comportamento de descadastro e a finalidade do domínio alinhados com a mensagem. Um cadastro no período de teste não justifica e-mails promocionais sem relação com ele.
Teste o que acontece quando um contato ativa ou paga antes de cada verificação de elegibilidade. Com condições de contato, atualize os campos relevantes no Brew durante a espera e confirme que o lembrete é ignorado. Com verificações agendadas pela aplicação, confirme que as contas não elegíveis não geram um evento de lembrete. Teste também novas tentativas, prorrogações do período de teste, exclusão de conta, descadastros e campos ausentes. Confira tanto os logs da aplicação quanto o histórico de execuções do Brew.
Avalie a ativação e a conversão em assinatura paga com os dados do seu produto, e as falhas de entrega com a plataforma de e-mail. As taxas de abertura sozinhas não mostram se a sequência ajudou quem está no período de teste. Veja exemplos no guia de sequência de boas-vindas e a divisão da implementação no guia MCP vs API REST.
