DocumentationJourney OptimizerGuide de Journey Optimizer

Résoudre les problèmes d’exécution de votre parcours actif troubleshooting-execution

Last update: Wed Nov 12 2025 00:00:00 GMT+0000 (Coordinated Universal Time)
  • S'applique à :
  • Journey Orchestration
  • Rubriques :

Créé pour :

  • Intermédiaire
  • Utilisateur ou utilisatrice

Dans cette section, découvrez comment résoudre les problèmes liés aux événements de parcours, vérifier si les profils ont accédé à votre parcours, comment ils le parcourent et si des messages sont envoyés.

Vous pouvez également résoudre les erreurs avant de tester ou de publier un parcours. Découvrez comment procéder sur cette page.

Si vous utilisez des actions entrantes, découvrez comment résoudre les problèmes liés à ces dernières sur cette page.

Vérifier l’envoi correct des événements checking-that-events-are-properly-sent

Le point de départ d'un parcours est toujours un événement. Il est possible d'effectuer des tests à l'aide d'outils tels que Postman.

Vous pouvez ainsi vérifier si l'appel d'API émis via ces outils est correctement envoyé ou non. Si vous obtenez une erreur en retour, cela signifie que votre appel a rencontré un problème. Vérifiez à nouveau la payload, l'en-tête (et en particulier l'identifiant d'organisation) et l'URL de destination. Vous pouvez demander à votre administrateur l'URL appropriée pour l'accès.

Les événements ne sont pas directement transmis de la source aux parcours. En effet, les parcours s’appuient sur les API d’ingestion en flux continu d’Adobe Experience Platform. En cas de problèmes relatifs aux événements, vous pouvez consulter la documentation d’Adobe Experience Platform pour la résolution des problèmes liés aux API d’ingestion en flux continu.

Si votre parcours ne parvient pas à activer le mode test avec l’erreur ERR_MODEL_RULES_16, assurez-vous que l’événement utilisé inclut un espace de noms d’identité lors de l’utilisation d’une action de canal.

L’espace de noms d’identité est utilisé pour identifier de manière unique les profils de test. Par exemple, si l'e-mail est utilisé pour identifier les profils de test, l’espace de noms d’identité E-mail doit être sélectionné. Si l’identifiant unique est le numéro de téléphone, l’espace de noms d’identité Téléphone doit être sélectionné.

Vérifier si les personnes rejoignent le parcours checking-if-people-enter-the-journey

Les rapports produits par Journey donnent des mesures en temps réel des entrées des visiteurs dans un parcours.

Si l’événement a été envoyé avec succès, mais que vous ne voyez aucune entrée dans le parcours, cela signifie qu’une erreur s’est produite entre l’envoi de l’événement et la réception de l’événement dans le parcours.

Pour résoudre votre problème, commencez par répondre aux questions suivantes :

  • Êtes-vous certain que le parcours où vous attendez l'événement entrant est en mode test ou actif ?

  • Avez-vous enregistré l'événement avant de copier la payload depuis l'aperçu de la payload ?

  • La payload d'événement contient-elle un identifiant d'événement ?

  • Avez-vous atteint la bonne URL ?

  • Avez-vous appliqué la structure de payload des API d'ingestion en flux continu en utilisant l'aperçu de la structure de payload dans le volet de configuration des événements ? Voir cette page.

  • Avez-vous utilisé les paires clé-valeur appropriées dans l’en-tête de l’événement ?

    code language-none 
    X-gw-ims-org-id - your organization's ID
Content-type - application/json

Vérifier comment les gens naviguent dans le parcours checking-how-people-navigate-through-the-journey

Les rapports produits par Journey mesurent la progression des individus dans un parcours. Il est très facile d'identifier où et pourquoi une personne s'est arrêtée.

Les éléments à vérifier sont les suivants :

  • La situation est-elle due à une condition excluant la personne concernée ? Par exemple, la condition est « genre = masculin » et la personne est une femme. Si la condition n'est pas trop complexe, un utilisateur chargé de la conception de parcours peut effectuer cette vérification.
  • La situation est-elle due à une source de données qui ne répond pas ? Lorsque le parcours est en test, ces informations apparaissent dans les journaux du mode test. Lorsque le parcours est actif, un administrateur peut tester les appels directs à la source de données et vérifier la réponse reçue. Il peut également dupliquer le parcours et le tester.

Vérifier que les messages sont bien envoyés checking-that-messages-are-sent-successfully

Si les personnes progressent correctement dans le parcours sans recevoir les messages qu’ils devraient recevoir, vous pouvez vérifier les points suivants :

  • Journey Optimizer a correctement pris en compte la demande d'envoi. Les utilisateurs professionnels peuvent accéder au message censé être envoyé et vérifier si l’heure de la dernière exécution correspond à l’heure d’exécution de votre parcours. Ils peuvent également vérifier les derniers appels/événements d’API reçus.
  • Journey Optimizer a envoyé le message avec succès. Vérifiez les rapports sur les parcours pour vous assurer qu’il n’y a aucune erreur.

Dans le cas d’un message envoyé par le biais d’une action personnalisée, le seul élément vérifiable pendant le test du parcours est l’apparition ou non d’une erreur suite à l’appel du système à l’aide d’une action personnalisée. Si l’appel au système externe associé à l’action personnalisée n’entraîne pas d’erreur, mais ne déclenche pas l’envoi d’un message, certaines vérifications doivent être effectuées du côté du système externe.

Comprendre les entrées en double dans les événements d’étape de Parcours duplicate-step-events

Pourquoi est-ce que je vois plusieurs entrées avec les mêmes ID d’instance de parcours, de profil, de nœud et de requête ?

Lors de l’interrogation des données d’événements d’étape de Parcours, vous pouvez occasionnellement observer ce qui semble être des entrées de journal en double pour la même exécution de parcours. Ces entrées partagent des valeurs identiques pour :

  • profileID - Identité du profil
  • instanceID - Identifiant de l’instance de parcours
  • nodeID - Nœud de parcours spécifique
  • requestID - Identifiant de la requête

Cependant, ces entrées ont des valeurs de _id différentes, qui est l’indicateur clé qui distingue ce scénario de la duplication réelle des données.

Qu’est-ce qui provoque ce comportement ?

Cela se produit en raison des opérations de mise à l’échelle automatique du serveur principal (également appelées « rééquilibrage ») dans l’architecture des microservices de Adobe Journey Optimizer. Pendant les périodes de forte charge ou d’optimisation du système :

  1. Un événement d’étape de parcours commence le traitement et est consigné dans le jeu de données Événements d’étape de Parcours .
  2. Une opération de mise à l’échelle automatique redistribue la charge de travail entre les instances de service
  3. Le même événement peut être retraité par une autre instance de service, créant ainsi une seconde entrée de journal avec une _id différente

Il s’agit d’un comportement système attendu qui fonctionne comme prévu.

Y a-t-il un impact sur l'exécution du parcours ou la diffusion des messages ?

Non. L’impact se limite à la journalisation uniquement. Adobe Journey Optimizer dispose de mécanismes de déduplication intégrés au niveau de la couche d’exécution des messages qui garantissent :

  • Un seul message (email, SMS, notification push, etc.) est envoyé à chaque profil
  • Les actions sont exécutées une seule fois
  • L’exécution du parcours se déroule correctement

Vous pouvez le vérifier en interrogeant les ajo_message_feedback_event_dataset ou en vérifiant les journaux d’exécution d’action. Vous verrez qu’un seul message a été réellement envoyé, malgré les entrées d’événement d’étape de parcours en double.

Comment puis-je identifier ces cas dans mes requêtes ?

Lors de l’analyse des données d’événements d’étape de Parcours :

  1. Vérifiez le champ _id : les vrais doublons au niveau du système auraient le même _id. Des valeurs de _id différentes indiquent des entrées de journal distinctes du scénario de rééquilibrage décrit ci-dessus.

  2. Vérifier la diffusion du message : effectuez une référence croisée avec les données des commentaires du message pour confirmer qu’un seul message a été envoyé :

    code language-sql 
    SELECT
  timestamp,
  _experience.customerJourneyManagement.messageExecution.messageExecutionID,
  _experience.customerJourneyManagement.messageDeliveryfeedback.feedbackStatus
FROM ajo_message_feedback_event_dataset
WHERE
  _experience.customerJourneyManagement.messageExecution.journeyVersionID = '<journeyVersionID>'
  AND TO_JSON(identityMap) like '%<profileID>%'
ORDER BY timestamp DESC;

  3. Regrouper par identifiants uniques : lors du comptage des exécutions, utilisez _id pour obtenir des décomptes précis :

    code language-sql 
    SELECT
  COUNT(DISTINCT _id) as unique_executions
FROM journey_step_events
WHERE
  _experience.journeyOrchestration.stepEvents.journeyVersionID = '<journeyVersionID>'
  AND _experience.journeyOrchestration.stepEvents.profileID = '<profileID>'

Que dois-je faire si j'observe ceci ?

Il s’agit d’un comportement normal du système et aucune action n’est requise. La journalisation en double n’indique aucun problème au niveau de la configuration du parcours ou de la diffusion des messages.

Si vous créez des rapports ou des analyses en fonction d’événements d’étape de Parcours :

  • Utiliser _id comme clé primaire pour compter les événements uniques
  • Référencement croisé avec les jeux de données de commentaires des messages lors de l’analyse de la diffusion des messages
  • Gardez à l’esprit que l’analyse de minutage peut afficher des entrées en cluster à quelques secondes d’intervalle

Pour plus d’informations sur l’interrogation des événements d’étape de Parcours, voir Exemples de requêtes.

recommendation-more-help
b22c9c5d-9208-48f4-b874-1cefb8df4d76