# 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).
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](/fr/product/audience-data-and-segmentation/events/).
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** 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 les [Opérateurs de Tag par type](/fr/product/audience-data-and-segmentation/segmentation/create-segments/by-tags/#tag-operators-by-type).
## 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 ?** 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`](/fr/product/pushwoosh-knowledge-hub/users-userids/) 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** et choisissez une clé d'attribut (par ex., `recipient_ids`, `target_user_id`). Cette clé doit correspondre à la structure de votre payload d'événement.
##### Exemple de payload (utilisateur unique)
```json
{
"application": "XXXXX-XXXXX",
"event": "invitation",
"attributes": {
"targetId": 321
},
"userId": 123
}
```
L'utilisateur `321` (de `targetId`) entre dans le journey.
##### Exemple de payload (utilisateurs multiples)
Si vous fournissez plusieurs User IDs, utilisez un tableau JSON de chaînes de caractères.
```javascript
{
"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` du payload de l'événement.
**Exemple** L'utilisateur `123` achète un cadeau pour l'utilisateur `456`, qui reçoit alors une notification, un flux 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
* **Flux 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 rentrer à 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** 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.
**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 se déroulant 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`)*
* **Planification 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 qui est 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 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
* **Flux é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
Une fois que vous avez configuré l'élément d'entrée, cliquez sur **Appliquer** pour enregistrer les modifications.
## Exemple de scénario : 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](/fr/product/audience-data-and-segmentation/events/#implementation)
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** 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 le déclencheur](/fr/product/customer-journey/journey-elements/flow-controls/wait-for-trigger/) 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**
5. Enfin, ajoutez un [objectif de conversion](/fr/product/customer-journey/journey-settings/#conversion-goals), 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**.
## 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 ?** 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`](/fr/product/pushwoosh-knowledge-hub/users-userids/) 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** et choisissez une clé d'attribut (par ex., `recipient_ids`, `target_user_id`). Cette clé doit correspondre à la structure de votre payload d'événement.
##### Exemple de payload (utilisateur unique)
```json
{
"application": "XXXXX-XXXXX",
"event": "invitation",
"attributes": {
"targetId": 321
},
"userId": 123
}
```
L'utilisateur `321` (de `targetId`) entre dans le journey.
##### Exemple de payload (utilisateurs multiples)
Si vous fournissez plusieurs User IDs, utilisez un tableau JSON de chaînes de caractères.
```javascript
{
"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` du payload de l'événement.
**Exemple** L'utilisateur `123` achète un cadeau pour l'utilisateur `456`, qui reçoit alors une notification, un flux 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
* **Flux 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 rentrer à 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** 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.
**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 se déroulant 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`)*
* **Planification 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 qui est 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 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
* **Flux é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
Une fois que vous avez configuré l'élément d'entrée, cliquez sur **Appliquer** pour enregistrer les modifications.
## Exemple de scénario : 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](/fr/product/audience-data-and-segmentation/events/#implementation)
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** 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 le déclencheur](/fr/product/customer-journey/journey-elements/flow-controls/wait-for-trigger/) 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**
5. Enfin, ajoutez un [objectif de conversion](/fr/product/customer-journey/journey-settings/#conversion-goals), 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**.
