Campagnes

Les campagnes envoient des parcours email pilotés par votre flux d’événements : un événement déclencheur démarre un parcours, les étapes envoient des emails après des délais configurables, et un événement de sortie y met fin plus tôt (“objectif atteint”). Les événements de livraison reviennent dans vos analytics sous forme d’événements $email_*, donc le funnel d’une campagne est interrogeable comme n’importe quelle autre donnée.

Les parcours sont pour l’instant linéaires : déclencheur → (délai → email) → (délai → email) → … Les parcours avec embranchements, les plages de silence et l’envoi tenant compte du fuseau horaire sont sur la roadmap.

Anatomie d’une campagne

Élément	Ce qu’il fait
Événement déclencheur	Un nom d’événement qui démarre un parcours pour la personne qui l’a fait (p. ex. cart_abandoned)
Filtres du déclencheur	Conditions optionnelles sur les propriétés de l’événement déclencheur, combinées en AND. Opérateurs : exact, icontains
Cohorte d’audience	Cohorte optionnelle : seuls ses membres peuvent entrer dans le parcours
Étapes	Chaque étape = délai + email (sujet + template du corps). Le délai de l’étape 1 compte depuis le déclencheur
Événement de sortie	Si la personne le fait avant la fin du parcours, celui-ci s’arrête (goal met) et plus aucun email ne part
Ré-entrée	never (un seul parcours par personne, à vie) ou after N days (ré-entrée possible une fois le parcours précédent terminé depuis ≥ N jours)
Frequency cap	Nombre max de messages à une personne dans une fenêtre glissante (en heures) — compté toutes campagnes confondues, pour que des parcours qui se chevauchent ne s’empilent pas

Règles de confiance pour le déclenchement

• Les personnes identifiées exigent des événements vérifiés pour déclencher un parcours. Si la vérification d’identité ne passe pas pour un utilisateur, ses événements arrivent quand même dans les analytics mais ne démarreront pas de campagnes — envoyer un email sur la foi d’un événement falsifiable est exactement le mode de défaillance pour lequel la vérification existe. Les événements anonymes peuvent déclencher normalement.
• Les événements de sortie n’exigent pas de vérification. Sortir est la direction sûre : mieux vaut perdre un email que d’en envoyer un embarrassant.
• Pour les déclencheurs qui doivent être des faits (paiement reçu, abonnement annulé), envoyez l’événement déclencheur côté serveur avec une clé secrète.

Variables de template

Les sujets et corps d’email acceptent deux espaces de noms de variables :

Bonjour {{person.first_name}},

vous avez laissé {{event.item_count}} articles dans votre panier.

• {{person.x}} — les traits de la personne au moment de l’envoi.
• {{event.y}} — les propriétés de l’événement déclencheur, figées au moment du déclenchement. Un parcours se souvient de l’événement qui l’a démarré, même si les données de la personne ont changé depuis.

Les valeurs sont échappées en HTML ; les variables non résolues sont rendues comme chaînes vides. Il n’y a pas de logique (ni conditions ni boucles) — les templates ne font que de la substitution.

Garanties d’envoi

• Exactly-once par étape. Chaque envoi réserve un slot unique (journey, step) dans un registre de messages avant de parler au fournisseur d’email, et l’envoi lui-même porte une clé d’idempotence. Réessais, crashs et workers concurrents ne peuvent pas dupliquer un email.
• Liste de suppression. Les hard bounces et les plaintes pour spam suppriment l’adresse définitivement, automatiquement (les soft bounces suppriment au troisième). Les adresses supprimées sont ignorées au moment de l’envoi, et vous pouvez ajouter des suppressions manuelles dans le panel.
• Vérification de sortie de dernière seconde. Même après qu’un envoi est planifié, le dispatcher revérifie l’état du parcours avant d’envoyer — un événement de sortie arrivé entre-temps arrête quand même l’email.
• Mettre en pause arrête l’horloge, pas les parcours. Mettre une campagne en pause bloque les nouvelles entrées et gèle la progression ; les parcours existants conservent leur état. La réactivation traite immédiatement les étapes en retard (avec toutes les vérifications de sortie et de suppression). La pause n’annule pas les parcours.

Les événements email dans vos analytics

Les webhooks de livraison du fournisseur sont convertis en événements attribués à la même personne : $email_sent, $email_delivered, $email_opened, $email_clicked, $email_bounced, $email_complained — chacun étiqueté avec la campagne, le parcours et l’étape. La page de détail de la campagne s’en sert pour son funnel (envoyé → livré → ouvert → cliqué), et vous pouvez les utiliser partout : cohortes de personnes ayant cliqué, flags ciblant les non-ouvreurs, et ainsi de suite.

Broadcasts

Une campagne avec une cohorte d’audience peut aussi être envoyée en une fois comme broadcast à toute la cohorte (en respectant les règles de ré-entrée, la suppression et les frequency caps). Les parcours sont créés en masse et suivent les mêmes étapes et les mêmes garanties.

Envois de test

L’éditeur de campagne peut envoyer une seule étape à une adresse de votre choix sans créer de parcours ; les envois de test sont exclus du comptage du frequency cap.