Utiliser des ID de liaison pour établir une corrélation entre les déclencheurs

Article
01/31/2024

Les parcours répétables basés sur des déclencheurs peuvent être répétés par un client sans qu’il ait terminé le parcours précédent. Prenons l’exemple d’un parcours qui envoie des confirmations de rendez-vous et des rappels. Lorsqu’une personne s’inscrit pour son premier rendez-vous, elle saisit le parcours et reçoit une confirmation. Elle continue à attendre pendant le parcours jusqu’à ce qu’elle reçoive un rappel un jour avant le rendez-vous. Pendant ce temps, la même personne pouvait s’inscrire pour un deuxième rendez-vous. Le participant au parcours recommencera le même parcours une deuxième fois pour le deuxième rendez-vous. En d’autres termes, la même personne traverse maintenant deux instances du même parcours.

Dans une telle situation, si le participant au parcours annule l’un des rendez-vous, il ne doit quitter que le parcours associé au rendez-vous annulé. Par exemple, s’il annule le premier rendez-vous, il doit quitter le parcours associé au premier rendez-vous mais continuer celui associé au deuxième rendez-vous. Si vous utilisez les événements prêts à l’emploi basés sur Dataverse, le comportement est automatique et aucune autre action n’est nécessaire. Toutefois, si vous utilisez des déclencheurs personnalisés, vous devez configurer le déclencheur pour identifier correctement l’instance spécifique du parcours à laquelle le déclencheur doit être associé.

Utilisation de l’attribut bindingId pour identifier de manière unique chaque instance du parcours

Chaque déclencheur personnalisé a un attribut facultatif bindingId qui peut être utilisé pour lier le déclencheur à des instances spécifiques d’un parcours. Quand l’attribut bindingId n’est pas présent, le déclencheur agit sur toutes les instances du parcours auquel la personne participe. Par exemple, si la personne s’est inscrite à deux rendez-vous mais en annule un, et si le déclencheur annulé n’a pas utilisé d’attribut bindingId, cette personne quittera les deux instances du parcours. Si vous avez l’intention d’utiliser des déclencheurs dans des parcours répétables, il est fortement recommandé d’inclure un bindingId dans le déclencheur.

Lorsque le déclencheur qui démarre un trajet contient un bindingId, cet ID est utilisé pour identifier l’instance de parcours. Pour identifier l’instance de parcours, tout autre événement doit utiliser le même bindingId. Le format du bindingId est le suivant : {entityType}/{entityId}. Par exemple, si votre événement de début est une entité Rendez-vous nommée Rendez-vous confirmé et qu’il a l’entityId 123, le bindingID est Appointment/123. Votre événement de sortie Rendez-vous annulé doivt avoir le même type d’entité et doit utiliser le même bindingId (Appointment/123) pour identifier de manière unique l’instance de parcours.

Si vous utilisez uniquement des déclencheurs personnalisés dans le parcours, vous pouvez vous fier à des chaînes uniques pour identifier les instances de parcours.

Note

Un déclencheur personnalisé agira sur toutes les instances d’un parcours auquel quelqu’un participe si le bindingID est manquant ou si la liaison concerne un type d’entité différent.

Corréler les déclencheurs personnalisés et les événements prêts à l’emploi ou les événements commerciaux personnalisés

Si vous souhaitez utiliser une combinaison de déclencheurs personnalisés et d’événements commerciaux prêts à l’emploi ou personnalisés, bindingId utilise un formatage spécial pour identifier de manière unique le tableau et la ligne de Dataverse. Par exemple, votre parcours pourrait commencer par l’événement prêt à l’emploi Opportunité créée. Vous pouvez ensuite utiliser un déclencheur personnalisé nommé Opportunité gagnée pour l’événement de sortie. Le déclencheur personnalisé Opportunité gagnée doit contenir un bindingId qui suit le modèle de l’événement Opportunité créée pour identifier de manière unique chaque instance.

Chaque fois qu’un parcours commence par un événement commercial prêt à l’emploi ou personnalisé, chaque instance du parcours peut être identifiée de manière unique par le modèle {entityType}/{unique row ID}. Ce modèle doit être inclus dans l’attribut bindingId de n’importe quel déclencheur personnalisé pour établir une corrélation entre les déclencheurs personnalisés et les événements commerciaux prêts à l’emploi ou personnalisés.

Dans le cas du déclencheur personnalisé Opportunité gagnée, le bindingId pourrait être :

bindingId = opportunity/{unique ID of the opportunity row}

Si les déclencheurs personnalisés suivent le modèle de bindingID décrit ci-dessus, ils peuvent être utilisés pour identifier l’instance exacte du parcours, même lorsqu’ils sont utilisés avec d’autres événements commerciaux. Quand le bindingId est implémenté, il agit sur toutes les instances du parcours.

Note

La liaison ne fonctionne que sur les mêmes types d’entités.

Comment ajouter un bindingId à un déclencheur personnalisé

Vous pouvez modifier l’attribut bindingID dans l’extrait de code pour un déclencheur personnalisé.

Pour accéder à l’extrait de code d’un déclencheur personnalisé existant :

Accédez à Customer Insights - Journeys>Engagement>Déclencheurs.
Sélectionnez le déclencheur personnalisé auquel vous souhaitez ajouter un bindingId.
Sélectionnez Accéder à l’extrait de code.
Copiez l’extrait et collez-le dans l’éditeur de code de votre choix. Modifier l’attribut bindingId selon les formats mentionnés ci-dessus (une chaîne unique si vous l’utilisez uniquement avec des déclencheurs personnalisés ou {table_name}/{unique row ID} lors de la corrélation entre des déclencheurs personnalisés et des événements prêts à l’emploi ou des événements commerciaux personnalisés).

Vous pouvez suivre les mêmes étapes d’ajout d’un bindingId lors de la création d’un nouveau déclencheur personnalisé.

Interprétation de bindingId

Le caractère / est réservé. On suppose toujours que le bindingId a un format séparé par des / et tout début ou fin/ sera supprimé. De plus, il n’y aura aucune / dans le résultat. L’application essaie toujours de l’interpréter selon le format {entityType}/{entityId}.

Exemples :

"A/B"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"A"
will be interpreted as 
{entityType = ""}/{entityId = "A"}

"A/B/C" 
will be interpreted as 
{entityType = "AB"}/{entityId = "C"}

""
will be interpreted as 
{entityType = ""}/{entityId = ""}

"A/B/"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"///A/B////"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

Algorithme de comparaison :

[Case 0] trigger has bindingId = "", meaning no restriction at all
    Always resume.
[Case 1] entityType matches, and entityId matches:
    Resume.
[Case 2] entityType matches, but entityId doesn't match:
    No resume.
[Case 3] entityType doesn't match trigger:
    It doesn't make sense to apply binding, so we fall back to what we have now and let it resume the journey instance.