Un événement arrive, la suite s’enchaîne

Événements natifs et métier

Deux origines, un même journal : ce que la plateforme constate, et ce que vos outils lui apprennent.

• Les événements natifs naissent de la plateforme : remise, ouverture, clic, rebond temporaire ou définitif, plainte, désinscription, inscription à une liste, acte de consentement accordé, entrée dans un segment, fin d’un parcours.
• Les événements métier viennent de vos outils — « commande passée », « rendez-vous pris », « devis demandé » — avec leur charge utile : un objet libre, borné en taille, conservé tel quel et lisible ensuite.
• Un appel liste les types d’événements qu’un espace a réellement reçus, avec leur nombre et leur dernière occurrence : on sait ce qui est disponible avant d’écrire une condition ou un template.
• Chaque événement poussé porte une clé d’idempotence : un rejeu ne le compte pas deux fois, et un incident réseau ne crée pas de doublon.
• Ouvertures et clics n’existent que pour les contacts dont le consentement de mesure est valide. Le pixel de délivrabilité, exempté, n’émet aucun événement : il n’écrit qu’une date.
• Une charge utile ne porte jamais de donnée sensible ni d’adresse : elle est stockée telle quelle et exposée au rendu des messages.

Les six endroits où un événement se lit

• Dans un segment : « a fait » ou « n’a pas fait » tel événement, éventuellement dans les N derniers jours.
• Dans un déclencheur, avec une condition sur la charge utile et sur la fiche.
• Dans une condition ou une attente, au milieu d’un parcours.
• Dans un template, par le dernier événement de chaque type — le montant de la dernière commande, la date du prochain rendez-vous.
• Dans le score du contact, quand la règle de l’espace lui attribue des points.
• Dans le journal d’événements, lu par appel avec filtres et curseur, ou poussé vers un webhook signé.

Contacts, segments et scoring

Une fiche, ses attributs, ses actes de consentement, ses appartenances — et un score qui dit où en est le prospect.

• Un contact porte des attributs typés, un identifiant externe facultatif, ses abonnements et son registre d’actes de consentement, un par finalité. Un refus est conservé comme preuve, jamais appliqué à l’envers.
• Une liste est une appartenance explicite : on y entre, on en sort, et l’inscription porte sa date et sa source.
• Un segment dynamique est une définition, pas un instantané : attributs, appartenances, consentements, événements métier, engagement, score. Il est recalculé à la demande, avec un aperçu du nombre de personnes visées avant tout envoi.
• Le score d’un contact est calculé par des règles propres à l’espace : des points pour une inscription, un consentement accordé, une remise, une ouverture ou un clic consentis ; des points retirés pour un rebond, une désinscription, une plainte. Une décroissance quotidienne empêche un prospect de rester chaud sans raison.
• Le score borné se lit dans un segment, dans une condition de parcours et dans un filtre de liste — et chaque variation est journalisée avec son motif.
• Une liste de suppression par espace retient les adresses auxquelles il ne faut plus jamais écrire : elle survit à la fiche dont elle provient.

Ce que le scoring ne prend jamais en compte

Le pixel de délivrabilité, exempté de consentement, ne produit aucun point : il ne peut alimenter qu’une date de dernière ouverture. Un contact qui n’a pas consenti à la mesure n’a donc ni point d’ouverture ni point de clic ; son score s’appuie sur ses actes explicites — inscription, consentements — et sur des signaux techniques de remise.

Le score est une donnée du contact comme une autre : il est restitué dans l’export du droit d’accès et détruit avec la fiche lorsqu’elle est anonymisée.

Ce qui sort d’office de toute audience

• Un contact désinscrit, opposé ou dont le consentement a été retiré pour la finalité concernée.
• Un contact anonymisé : la fiche subsiste, vide, et ne peut plus appartenir à aucun segment.
• Une adresse en liste de suppression, après un rejet définitif ou une plainte.
• Un contact sans consentement valide à la finalité dont dérive un segment fondé sur un attribut sensible.

Déclencheurs

Une règle courte, lisible d’un coup d’œil : quand cet événement arrive, si telle condition est vraie, fais ceci.

• Un déclencheur nomme un événement — métier ou natif — et une action : envoyer un message de service, ou inscrire le contact à une séquence active.
• Une condition facultative porte sur la charge utile de l’événement et sur la fiche : un montant, un pays, un attribut, un score. Elle est validée à la création ; une condition devenue invalide ne casse jamais l’appel qui a produit l’événement.
• Un délai facultatif, de zéro à trente jours, sépare l’événement de l’action — le temps de laisser la commande se confirmer.
• Un anti-doublon explicite : à chaque fois, une seule fois par contact, ou au plus une fois par période.
• Mettre un déclencheur en pause l’arrête immédiatement, y compris pour les exécutions déjà en file.
• Chaque décision est écrite au journal du contact : déclenché, écarté — avec la raison, condition ou anti-doublon —, exécuté avec la référence du message ou de l’inscription, ou en échec avec son code.
• Un déclencheur ne contourne rien : liste de suppression, consentement par finalité, quotas, fenêtres d’envoi et montée en charge s’appliquent comme partout ailleurs.

Séquences de nurturing et parcours

Un parcours est un graphe : des déclencheurs, des étapes, et des objectifs de conversion qui y mettent fin dès qu’ils sont atteints.

On entre dans un parcours par une inscription à une liste, par l’appartenance à un segment, par un appel d’API ou par un événement métier — et un même parcours peut porter plusieurs de ces entrées à la fois. Chaque inscription suit ensuite son propre chemin, à son propre rythme.

Un objectif de conversion est la raison d’être du parcours : dès que l’événement attendu arrive — « commande passée », « rendez-vous pris », un clic sur une offre, l’entrée dans un segment de clients —, l’inscription s’arrête, même au milieu d’une attente. On ne relance pas quelqu’un qui vient d’acheter, et la conversion est comptée à part.

Une règle traverse toute la grammaire : trois issues, jamais deux. Une étape qui dépend d’une ouverture ou d’un clic distingue « l’a fait », « ne l’a pas fait à temps » et « ne peut pas être mesuré ». Un contact non mesurable — parce qu’il n’a pas consenti à la mesure — n’est jamais compté comme n’ayant pas ouvert, et prend sa branche sans attendre.

La grammaire des étapes

• Envoi d’un template, avec son domaine expéditeur vérifié et son lien de désinscription — et, si on le demande, une relance bornée lorsqu’aucune ouverture n’arrive.
• Attente relative (trois jours, en jours ouvrés si besoin), datée (le 15 à 9 h), calculée depuis une date de la fiche (trente jours après la dernière commande) ou jusqu’à une fenêtre d’envoi.
• Attente d’un événement — une ouverture, un clic sur un lien précis, une remise, un événement métier, une inscription, un consentement — bornée par un délai maximal, avec sa sortie de repli.
• Condition sur les attributs, les appartenances, les consentements, le score, le dernier événement de chaque type, ou ce qui s’est passé dans ce parcours : a ouvert le message de l’étape 1, a cliqué tel lien.
• Aiguillage à plusieurs sorties, répartition aléatoire pondérée, branches parallèles avec point de jonction, et test A/B avec mesure par variante.
• Mise à jour de la fiche — poser un attribut, entrer ou sortir d’une liste, jamais toucher au consentement —, appel de webhook, sortie explicite.
• Objectifs de conversion : dès qu’un objectif est atteint, l’inscription s’arrête, où qu’elle en soit, et la sortie en porte la raison.

Ce qui garantit qu’un message ne part pas deux fois

Une étape produit au plus un envoi pour une inscription donnée : la déduplication est portée par la file d’exécution, pas par la mémoire d’un processus. Un redémarrage, un rejeu ou une double notification ne redonnent pas un deuxième message. Une relance demandée explicitement porte sa propre clé, numérotée et plafonnée.

Rien de ce qui touche à l’envoi ne se fait dans le temps d’une requête HTTP : tout passe par la file. Une simulation déroule au contraire le parcours entier sans rien envoyer, en montrant les chemins pris et les dates atteintes.

Campagnes

Un envoi unique vers une liste ou un segment, préparé, prévisualisé, puis exécuté.

• Une campagne vise une liste ou un segment, avec un aperçu de l’audience — le nombre de personnes retenues, et celles qui sont écartées, avec la raison.
• Elle s’exécute immédiatement ou à une date choisie, dans les fenêtres d’envoi et les quotas de l’espace.
• Le contenu est un template marketing : lien de désinscription obligatoire, domaine expéditeur vérifié.
• La mesure suit les mêmes règles que partout : les taux sont rapportés à la population consentante.
• Une campagne ne modifie pas les parcours en cours : un contact peut en recevoir une tout en étant enrôlé, sous réserve des règles de pression de l’espace.

Messages de service

Un message unitaire, adressé à une personne parce qu’elle vient de faire quelque chose.

• Un reçu, une confirmation, un rappel de rendez-vous, une réinitialisation : base juridique contractuelle, distincte de la prospection.
• Jamais mesuré : aucun pixel de performance, aucune réécriture de lien, aucun événement d’engagement — et l’option est forcée, pas laissée au choix de l’appelant.
• Déclenché par un appel d’API ou par un déclencheur d’événement, avec une clé d’idempotence pour que le rejeu ne double pas le message.
• Le contenu lit la charge utile de l’événement qui l’a provoqué : le numéro de commande, le montant, la date du rendez-vous.
• Séparé des envois de prospection dans les statistiques comme dans les exports : les deux régimes ne sont jamais additionnés.

Mesure et conversion

Des taux qui disent ce qu’ils mesurent, une population de référence affichée à côté, et des conversions comptées à part.

• Les objectifs atteints sont comptés par parcours : combien d’inscriptions sont sorties parce que la conversion est arrivée, et à quelle étape elles en étaient.
• Les taux d’ouverture et de clic sont calculés sur la population consentante, jamais sur le nombre d’envois : le dénominateur est publié avec le résultat.
• Statistiques par parcours et par étape, par campagne, par variante d’un test A/B, par domaine expéditeur.
• Exports de statistiques et du journal d’événements, à la demande ou planifiés, en CSV ou en JSON, sans donnée personnelle.
• Les compteurs servis aux rôles d’exploitation de la plateforme passent sous un seuil d’affichage : en dessous de vingt personnes, le nombre est masqué, et les taux qui s’en déduiraient aussi.
• Les agrégats survivent à l’anonymisation d’un contact : ils n’ont jamais porté que des identifiants et des nombres.