Transformez vos e-mails en revenus avec Brew.
Comprenez les e-mails marketing et transactionnels déclenchés par événement, avec un modèle concret : payloads, publication et éligibilité différée.
Un e-mail déclenché part de quelque chose qui s’est produit : une inscription, un échec de paiement d’une facture, un export terminé ou tout autre événement que votre système sait décrire. Cet événement fournit le contexte d’un message.
Ce n’est pas le déclencheur qui détermine si le message est marketing ou transactionnel, mais la finalité du message et la relation avec le destinataire. Un reçu et une incitation à passer à une offre supérieure peuvent venir du même produit tout en relevant de règles d’envoi différentes.
Choisissez un nom qui décrit une action ou une condition vérifiée. Déclarez les champs dont l’e-mail a besoin et testez des payloads représentatifs. Évitez un événement dont le sens change selon le service qui l’a envoyé.
Par exemple, un événement de commande finalisée peut contenir l’adresse du destinataire, la référence de la commande et un lien vers celle-ci. Laissez les données sensibles ou inutiles hors du payload. La référence de l’API documente les formats de requête pris en charge.
Dans le modèle d’automatisation de Brew, un déclencheur est relié à des étapes comme l’envoi d’un e-mail. Créez et relisez le brouillon, puis publiez l’automatisation avant d’attendre des événements de production qu’ils l’exécutent. L’article Automatisation e-mail par l’IA indique quelles séquences de cycle de vie construire en premier, de l’inscription à la réactivation.
Une séquence de bienvenue qui fait la promotion d’un produit relève du marketing. Un reçu de commande ou un message de sécurité du compte demandé par l’utilisateur peut être transactionnel. Les messages mixtes exigent d’évaluer leur finalité principale ; ajouter une petite promotion ne tranche pas automatiquement la question juridique, dans un sens comme dans l’autre.
Rendez les informations essentielles sur le compte faciles à trouver. Choisissez le bon usage d’envoi pour le domaine et testez le comportement des abonnements. Lisez notre guide des e-mails transactionnels pour cette distinction et les exigences des fournisseurs mises en lien.
Pour le marketing, vérifiez le consentement et respectez les statuts de désabonnement et d’exclusion. Un événement correspondant n’autorise pas à écrire à toute personne dont l’adresse figure par hasard dans le payload.
Imaginons que vous vouliez relancer un utilisateur en essai qui n’a pas terminé la configuration au bout de six jours. L’événement d’inscription sait ce qui était vrai au moment de l’inscription. Il ne peut pas prédire si l’utilisateur terminera demain.
Pour la vérification à J+6 dans Brew, un « Filtre » ou un « Embranchement » conditionnel peut lire les champs actuels du contact Brew via contact.<name>. Définissez et synchronisez les champs d’activation et d’abonnement, puis vérifiez-les après l’attente. Les champs de l’événement, comme payload.activated, contiennent toujours les valeurs de l’événement d’origine. Si l’état requis se trouve hors de Brew, faites-le vérifier par votre application à J+6, et ne déclenchez un nouvel événement de rappel que si l’utilisateur remplit toujours les conditions.
La même règle s’applique quand la condition est « n’a pas acheté » ou « est toujours sur l’offre gratuite ». Le guide de la séquence d’essai explique comment procéder côté application.
Testez la requête d’événement, l’exécution de l’automatisation et l’e-mail reçu. Incluez des champs manquants, des nouvelles tentatives, des destinataires de test privés et un changement d’état qui doit empêcher un envoi ultérieur.
Pour les fournisseurs connectés, utilisez leurs noms d’événements réels. La page Stripe liste les événements pris en charge par Brew et explique pourquoi le paramètre « Synchroniser le nom complet » n’a rien à voir avec la publication d’une automatisation.
Une fois le parcours fonctionnel, gardez une séquence compréhensible. Un petit ensemble d’événements explicites et de messages relus est plus facile à maintenir qu’une longue automatisation dont personne ne sait expliquer les conditions.
