Entenda os e-mails de marketing e transacionais disparados por eventos, com um modelo prático de payloads, publicação e elegibilidade verificada mais tarde.
Um e-mail disparado por gatilho começa com algo que aconteceu: um cadastro, uma falha no pagamento de uma fatura, uma exportação concluída ou outro evento que o seu sistema consegue descrever. Esse evento dá o contexto de uma mensagem.
O gatilho não decide se a mensagem é de marketing ou transacional. Quem decide é a finalidade da mensagem e a relação com o destinatário. Um recibo e uma oferta de upgrade podem sair do mesmo produto e ainda assim precisar de regras de envio diferentes.
Escolha um nome que descreva uma ação ou uma condição verificada. Declare os campos de que o e-mail precisa e teste payloads representativos. Evite um evento que signifique coisas diferentes dependendo do serviço que o enviou.
Por exemplo, um evento de pedido concluído pode trazer o endereço do destinatário, a referência do pedido e um link para ele. Deixe dados sensíveis ou desnecessários fora do payload. A referência da API documenta os formatos de requisição aceitos.
O modelo de automação do Brew conecta um gatilho a etapas como o envio de um e-mail. Crie e revise o rascunho e depois publique a automação, antes de esperar que eventos de produção a executem. O post sobre automação de e-mail com IA mostra quais fluxos de ciclo de vida montar primeiro, do cadastro ao reengajamento.
Uma sequência de boas-vindas que promove um produto é marketing. Um recibo de pedido ou uma mensagem de segurança da conta que o usuário solicitou pode ser transacional. Mensagens mistas exigem uma avaliação do objetivo principal; acrescentar uma pequena promoção não resolve automaticamente a questão jurídica, nem para um lado nem para o outro.
Deixe as informações essenciais da conta fáceis de encontrar. Use a finalidade de domínio de envio adequada e teste o comportamento da inscrição. Leia o guia de e-mails transacionais para entender a distinção e os requisitos dos provedores indicados nos links.
No marketing, verifique a permissão e respeite o status de descadastro e de supressão. Um evento correspondente não é permissão para enviar e-mails a qualquer pessoa cujo endereço apareça no payload.
Digamos que você queira lembrar um usuário em período de teste que não concluiu a configuração depois de seis dias. O evento de cadastro sabe o que era verdade no momento do cadastro. Ele não consegue prever se o usuário vai terminar amanhã.
Para a verificação do sexto dia no Brew, um nó Filtro ou Divisão por condição pode ler os campos atuais do contato no Brew por meio de contact.<name>. Defina e sincronize os campos de ativação e de assinatura e confira-os depois da espera. Campos do evento como payload.activated continuam com os valores originais do evento. Se o estado necessário fica fora do Brew, faça a sua aplicação verificá-lo no sexto dia e disparar um novo evento de lembrete só quando o usuário ainda for elegível.
A mesma regra vale quando a condição é “não comprou” ou “ainda está no plano gratuito”. O guia da sequência de conversão de períodos de teste explica o padrão do lado da aplicação.
Teste a requisição do evento, a execução da automação e o e-mail recebido. Inclua campos ausentes, novas tentativas, destinatários de teste privados e uma mudança de estado que deveria impedir um envio posterior.
Com provedores conectados, use os nomes reais dos eventos deles. A página do Stripe lista os eventos compatíveis com o Brew e explica por que a opção Sincronizar nome completo não tem relação com a publicação de uma automação.
Quando o caminho funcionar, mantenha a sequência fácil de entender. Um conjunto pequeno de eventos explícitos e mensagens revisadas é mais fácil de manter do que uma automação longa cujas condições ninguém consegue explicar.
