Entrée basée sur un déclencheur

Une entrée basée sur un déclencheur (Trigger-based entry) démarre le journey lorsqu’un utilisateur effectue un événement spécifique (par exemple, réalise une action spécifique).

Conseil

Vous pouvez ajouter plusieurs points d’entrée basés sur un déclencheur. Dans ce cas, n’importe lequel d’entre eux démarrera le journey.

Pour configurer une entrée basée sur un déclencheur, localisez l’élément d’entrée sur le canevas et sélectionnez l’événement qui servira de déclencheur.

Pour plus d’informations sur la configuration des événements, consultez la documentation sur les Événements.

Si l’événement sélectionné a des attributs, vous pouvez affiner les conditions d’entrée en utilisant ces attributs. Cliquez sur Ajouter une condition (Add condition) lors de la modification de l’élément, puis choisissez un attribut dans la liste déroulante et définissez son opérateur et sa valeur.

Pour les opérateurs disponibles, consultez la section Opérateurs de Tag par type.

Important

• Collaborez avec votre équipe de développement pour vous assurer que le HWID (Hardware ID) est correctement inclus dans votre requête API /postEvent pour l’Événement de Démarrage (Start Event) du journey. Sans cela, les utilisateurs ne pourront pas entrer dans le journey.
• L’UserID n’est pas applicable pour identifier les utilisateurs dans un customer journey.

Définir qui entre dans la campagne

Définissez quel(s) utilisateur(s) doi(ven)t entrer dans le journey lorsqu’un événement spécifique se produit.

Utilisez la liste déroulante Qui entre dans la campagne ? (Who enters the campaign?) pour choisir entre les deux modes disponibles :

Utilisateurs qui effectuent l’événement (par défaut)

L’utilisateur qui déclenche l’événement est celui qui entre dans le journey.

Exemple
Un utilisateur finalise un achat (événement CheckoutSuccess). Ce même utilisateur (par ex., User ID: 123) entre dans un journey post-achat qui inclut un message de remerciement, des recommandations de produits ou une enquête de satisfaction.

Utilisateurs à partir d’un attribut d’événement

Au lieu d’inscrire l’utilisateur qui a déclenché l’événement, vous pouvez passer un ou plusieurs User IDs dans un attribut d’événement personnalisé. Les utilisateurs listés dans cet attribut entreront dans le journey.

Pour cela, sélectionnez Utilisateurs à partir d’un attribut d’événement (Users from an event attribute) et choisissez une clé d’attribut (par ex., recipient_ids, target_user_id). Cette clé doit correspondre à la structure de votre charge utile (payload) d’événement.

Assistance d'un développeur requise

Pour utiliser correctement le mode Utilisateurs à partir d’un attribut d’événement (Users from an event attribute), votre application ou votre backend doit envoyer la structure de charge utile (payload) correcte. Veuillez partager les exemples ci-dessous avec votre équipe de développement.

Exemple de charge utile (payload) (un seul utilisateur)

{
  "application": "XXXXX-XXXXX",
  "event": "invitation",
  "attributes": {
      "targetId": 321
  },
  "userId": 123
}

L’utilisateur 321 (de targetId) entre dans le journey.

Exemple de charge utile (payload) (plusieurs utilisateurs)

Si vous fournissez plusieurs User IDs, utilisez un tableau JSON de chaînes de caractères.

{
    "application": "XXXXX-XXXXX",
    "event": "invitation",
    "attributes": {
        "targetIds": [1,2,3,4]
    },
    "userId": 123
}

Les utilisateurs 1, 2, 3 et 4 entreront dans le journey.

Cas d’utilisation

Notifications de commentaires

Lorsque quelqu’un commente la publication d’un utilisateur, le propriétaire de la publication est notifié.

Exemple : Un événement de commentaire inclut l’ID du propriétaire de la publication dans un attribut target_user_id. Cet utilisateur entre dans un journey pour recevoir la notification.

Programmes de parrainage

Lorsqu’un utilisateur parrainé s’inscrit ou effectue un achat, la personne qui l’a parrainé est ajoutée au journey.

Exemple : L’utilisateur 123 déclenche l’événement, et le parrain 456 (de l’attribut referrer_id) entre dans une campagne de récompense.

Achats de cadeaux

Lorsqu’un utilisateur achète un cadeau, le destinataire est ajouté à un journey en utilisant le recipient_user_id de la charge utile (payload) de l’événement.

Exemple : L’utilisateur 123 achète un cadeau pour l’utilisateur 456, qui reçoit alors une notification, un parcours d’intégration ou un message de remerciement.

Définir la disponibilité de l’entrée

Contrôlez quand les utilisateurs peuvent entrer dans un journey via une entrée basée sur un déclencheur. Vous avez deux options :

• Autoriser l’entrée à tout moment : Les utilisateurs peuvent entrer dans le journey chaque fois que l’événement déclencheur se produit.

• Limiter l’entrée à une période spécifique : Les utilisateurs ne peuvent entrer dans le journey que si l’événement déclencheur se produit dans la plage de dates sélectionnée.

  Lorsque vous limitez l’entrée, sélectionnez la date de début, la date de fin et le fuseau horaire. La fenêtre d’entrée commence à 00:00 à la date de début et se termine à 23:59 à la date de fin, en fonction du fuseau horaire choisi.

Contrôler le nombre de sessions qu’un utilisateur peut avoir en même temps

Décidez si chaque utilisateur peut rejoindre un seul journey à la fois, ou participer à plusieurs journeys en parallèle.

Choisissez l’une des options suivantes dans la liste déroulante :

• Une session active par utilisateur
• Plusieurs sessions actives par utilisateur

Une session active par utilisateur

Chaque utilisateur ne peut avoir qu’une seule session active dans la campagne. Il doit terminer ou quitter la session en cours avant d’en commencer une nouvelle.

Cas d’utilisation

• Parcours d’intégration où un utilisateur ne devrait pas redémarrer avant d’avoir terminé le journey en cours
• Rappels de renouvellement d’abonnement où les utilisateurs ne devraient pas recevoir de notifications qui se chevauchent
• Offres à durée limitée ou essais où une seule exécution de campagne active est autorisée par utilisateur
• Campagnes de collecte de feedback pour s’assurer que chaque utilisateur fournit son avis une seule fois avant de pouvoir y entrer à nouveau

Plusieurs sessions actives par utilisateur

Les utilisateurs peuvent avoir plus d’une session active dans une campagne. Chaque session doit être identifiée par un attribut d’événement unique (par ex., order_id, product_id).

Pour configurer cela :

1. Sélectionnez Plusieurs sessions actives par utilisateur (Multiple active sessions per user) dans la liste déroulante.

2. Choisissez un attribut d’identifiant de session (par ex., order_id, product_id). Cet attribut distinguera une session d’une autre.

Important

Cet attribut doit être inclus dans tous les événements pertinents du journey (par exemple, dans Attendre un déclencheur (Wait for trigger) ou les Objectifs de conversion (Conversion Goals)). Si l’attribut d’identifiant de session est manquant, le système ne peut pas lier l’événement à une session spécifique. À la place, l’événement sera appliqué à toutes les sessions actives pour cet utilisateur.

Exemple

• OrderPlaced avec order_id = "1001" → démarre la Session 1
• OrderPlaced avec order_id = "1002" → démarre la Session 2

Si un événement OrderReady est envoyé sans order_id, les sessions 1 et 2 seront toutes deux marquées comme « prêtes », même si une seule commande l’est réellement.

Cas d’utilisation

• Achats e-commerce : chaque commande démarre son propre journey, de sorte que plusieurs commandes d’un même utilisateur peuvent être suivies indépendamment. (attribut : order_id)
• Programmes de parrainage : chaque parrainage crée une nouvelle session, permettant à un utilisateur de parrainer plusieurs amis. (attribut : referral_id)
• Programmes de fidélité : suivez les points ou les récompenses de différentes transactions s’exécutant en parallèle. (attribut : transaction_id)
• Réservations de billets : chaque réservation lance son propre journey, afin que les utilisateurs puissent gérer plusieurs billets à la fois. (attribut : booking_id)
• Prise de rendez-vous : chaque rendez-vous est traité comme une session distincte. (attribut : appointment_id)

Contrôler si les utilisateurs peuvent réintégrer la campagne

Décidez de ce qui se passe lorsqu’un utilisateur déjà dans le journey déclenche à nouveau l’événement d’entrée.

Choisissez l’une des options suivantes dans la liste déroulante :

• Ne pas autoriser la réintégration (par défaut)
• Autoriser la réintégration

Ne pas autoriser la réintégration

Les utilisateurs qui sont déjà dans le journey ne le réintégreront pas. Si un utilisateur est dans une session active et déclenche à nouveau l’événement d’entrée, le nouveau déclencheur est ignoré et l’utilisateur continue sa session en cours.

Cas d’utilisation

• Séries de bienvenue et d’intégration où un nouvel utilisateur parcourt le journey une seule fois du début à la fin et conserve sa place s’il déclenche à nouveau l’événement au lieu d’être renvoyé au début
• Offres uniques où chaque client ne doit recevoir une promotion ou une réduction qu’une seule fois, même s’il déclenche l’événement plusieurs fois
• Parcours éducatifs et de maturation où les abonnés continuent de progresser dans le contenu sans redémarrer et recevoir à nouveau les mêmes e-mails

Autoriser la réintégration

Les utilisateurs qui sont déjà dans le journey seront retirés de leur session en cours et réintégrés avec une nouvelle session. Chaque fois qu’un utilisateur déclenche l’événement d’entrée, sa session en cours se termine et une nouvelle commence.

Cas d’utilisation

• Alertes de baisse de prix où le redémarrage doit prendre en compte le nouveau prix, et non continuer à notifier sur le prix obsolète de la session précédente
• Campagnes de reconquête où un utilisateur inactif qui revient doit toujours commencer par le premier message de la séquence

Note

La réintégration contrôle ce qui arrive aux utilisateurs qui sont déjà dans le journey. Cela n’affecte pas le nombre de sessions qu’un utilisateur peut exécuter en parallèle. Ceci est configuré sous Contrôler le nombre de sessions qu’un utilisateur peut avoir en même temps.

Une fois que vous avez configuré l’élément d’entrée, cliquez sur Appliquer (Apply) pour enregistrer les modifications.

Scénario d’exemple : Journey de commande e-commerce avec plusieurs sessions

Imaginez que vous souhaitiez envoyer des notifications pour chaque commande passée par un utilisateur. Chaque commande doit avoir sa propre session de journey. Pour ce faire, vous utiliserez l’événement OrderPlaced comme déclencheur et l’attribut order_id comme identifiant de session.

1. Créez l’événement OrderPlaced et assurez-vous qu’il inclut l’attribut order_id. En savoir plus sur la création d’événements

2. Définissez cet événement comme déclencheur pour votre journey.

3. Dans les paramètres de session, sélectionnez Plusieurs sessions actives par utilisateur (Multiple active sessions per user) et choisissez order_id comme identifiant de session.

Dans cette configuration, chaque nouvelle commande démarre une session de journey distincte.

• OrderPlaced avec order_id = 1001 démarre la Session 1
• OrderPlaced avec order_id = 1002 démarre la Session 2

4. Ensuite, ajoutez un élément Attendre un déclencheur pour suivre quand une commande est prête à être retirée ou livrée. Utilisez l’événement OrderReady, qui doit également inclure le même order_id. Cela garantit que chaque commande est mise à jour dans la bonne session :

• OrderReady avec order_id = 1001 s’applique uniquement à la Session 1
• OrderReady avec order_id = 1002 s’applique uniquement à la Session 2

Important

Si l’événement n’inclut pas order_id, le système ne peut pas savoir à quelle session il appartient, et l’événement s’appliquera à toutes les sessions actives pour cet utilisateur.

5. Enfin, ajoutez un objectif de conversion, par exemple l’événement OrderDelivered. Cet événement doit également inclure le même order_id afin qu’il puisse être associé à la bonne session.

• Si OrderDelivered inclut order_id = "1001", il enregistre une conversion pour la Session 1.
• Si OrderDelivered inclut order_id = "1002", il enregistre une conversion pour la Session 2.

Important

Si order_id est manquant, la conversion s’appliquera à toutes les sessions actives pour cet utilisateur au lieu de seulement celle prévue.