Documentation Journey Optimizer Guide de Journey Optimizer

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

Dernière mise à jour : 10 septembre 2026

S'applique à :
Journey Orchestration

Rubriques :
Parcours
Configuration

Créé pour :

Intermédiaire
Utilisateur/utilisatrice

Sur cette page : découvrez comment résoudre les problèmes d’exécution d’un parcours en direct, notamment en vérifiant que les événements sont envoyés, en confirmant la saisie des profils et leur progression dans le parcours et en vérifiant que les messages sont diffusés.

style

shade-box

Dans cette section, découvrez comment résoudre les problèmes liés aux événements de parcours, vérifier si des profils ont rejoint le parcours ainsi que leur progression, 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 dans 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 donc consulter la Adobe Experience Platform documentation pour la résolution des problèmes concernant les 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 ? Consultez 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`

Types de données de condition d’événement et de schéma - Assurez-vous que les types de données utilisés dans votre condition d’événement (règle) correspondent au schéma d’événement. Les types incohérents (par exemple, chaîne par rapport à entier) entraînent l’échec de l’évaluation des règles et la suppression des événements. Voir Vérification de l’identité des événements.
Événement ignoré - condition de qualification non remplie - Pour les événements basés sur des règles, si la condition de qualification n’est pas remplie par la payload de l’événement (par exemple, un champ obligatoire est vide ou manquant, ou une condition telle qu’une isNotEmpty sur un champ échoue), l’événement est reçu mais ignoré et le parcours n’est pas déclenché. Les journaux et les traces Splunk peuvent indiquer que l’événement a été reçu mais ignoré, car il ne remplissait pas la condition de qualification, avec des codes d’ignorance tels que notSuitableInitialEvent. C’est le comportement attendu : si la condition de qualification n’est pas remplie, l’événement est ignoré et le parcours n’est pas déclenché pour ce profil. Vérifiez que la payload de l’événement contient les champs et valeurs attendus et que la règle de la configuration de l’événement correspond aux données envoyées. Si l’événement est déclenché par une action personnalisée provenant d’un autre parcours, consultez Gestion des événements ignorés et des délais d’inactivité dans la section Dépannage des actions personnalisées.

>>
Pour les parcours de qualification d’audience avec audiences en streaming : si vous utilisez une activité de qualification d’audience comme point d’entrée d’un parcours, gardez à l’esprit que tous les profils correspondant aux critères de cette audience ne rejoindront pas nécessairement le parcours, en raison de facteurs de délai, de sorties rapides de l’audience ou du fait qu’ils se trouvaient déjà dans l’audience avant la publication. En savoir plus sur les considérations relatives au délai de qualification des audiences en streaming.

Vérifier l’identité d’un événement verify-event-identity-and-rule-data-types

Lors de la configuration d’un parcours basé sur un événement, vérifiez que le champ d’identité de la payload correspond à l’espace de noms sélectionné dans l’événement. Si l’événement inclut des champs pour la correspondance de profil, vérifiez que les casse de lettre et type de données de la condition d’événement correspondent exactement aux données entrantes. Par exemple, si le schéma d’événement définit roStatus comme une chaîne, la règle de parcours doit également l’évaluer comme une chaîne. Les types de données incohérents (par exemple, chaîne ou entier) entraînent l’échec de l’évaluation des règles et l’abandon d’événements valides. De même, si l’événement comporte une condition de qualification (par exemple, un champ doit être non vide), les événements qui ne remplissent pas cette condition sont ignorés et ne déclenchent pas le parcours ; les journaux peuvent afficher des codes d’ignorance tels que notSuitableInitialEvent.

Pour valider votre condition d’événement dans Journey Optimizer, utilisez l’aperçu de la payload dans la configuration de l’événement et assurez-vous que les types et les valeurs de la règle correspondent à la structure de la payload. Découvrez comment prévisualiser la payload et configurer des événements basés sur des règles.

Résoudre des problèmes liés aux transitions en mode test troubleshooting-test-transitions

Si les profils de test ne progressent pas dans votre parcours en mode test ou si le flux visuel n’affiche pas de flèches vertes indiquant la progression des étapes, le problème peut être lié à la validation de la transition. Cette section fournit des conseils sur le diagnostic et la résolution des problèmes courants en mode test.

Profils de test sans progression

Si les profils de test rejoignent le parcours mais ne progressent pas au-delà de l’étape initiale, vérifiez les points suivants :

Date de début du parcours : la cause la plus courante est lorsque la date de début du parcours est définie dans le futur. Les profils de test sont immédiatement ignorés si l’heure actuelle se situe en dehors de la fenêtre dates/heure de début et de fin configurée du parcours, produisant l’entrée de journal : DISPATCHER DISCARD #16 — unqualified on journey version enablements. Pour résoudre ce problème :
- Vérifiez que la date de début du parcours n’est pas définie dans le futur.
- Assurez-vous que l’heure actuelle se situe dans la fenêtre de date active du parcours.
- Si nécessaire, définissez temporairement la date de début à une heure antérieure au moment actuel pour le test, puis restaurez-la avant de la publier
Configuration du profil de test - Vérifiez que le profil est correctement marqué comme profil de test dans Adobe Experience Platform. Pour plus d’informations, voir Créer des profils de test.
Incompatibilité des espaces de noms d’identité - Une incohérence des espaces de noms entraîne un abandon silencieux : l’événement est accepté et renvoie une réponse de succès, mais le profil n’entre jamais dans le parcours et aucune erreur n’est visible dans l’interface utilisateur. Assurez-vous que l’espace de noms dans l’Identifiant de profil correspond exactement à l’espace de noms défini dans le schéma d’événement (sensible à la casse). Pour plus d’informations, voir Format d’expression d’identifiant de profil .

Indicateurs de transition à valeur nulle

Lors du dépannage technique, vous pouvez rencontrer une propriété isValidTransition définie sur null dans les détails techniques du parcours. Cette propriété réservée à l’interface d’utilisation n’a aucune incidence sur le traitement du serveur principal ni sur les performances du parcours. Cependant, une valeur nulle peut indiquer ce qui suit :

Mauvaise configuration du parcours : la date de début du parcours est définie dans le futur, ce qui entraîne l’abandon silencieux des événements de test.
Transition endommagée : dans de rares cas, les nœuds de parcours doivent être reconnectés.

Si vous rencontrez des problèmes de transition persistants :

Vérifiez que la date de début du parcours est correcte.
Désactivez et réactivez le mode test.
Si le problème persiste, pensez à dupliquer les nœuds de parcours concernés et à les reconnecter.
Pour les cas non résolus, contactez l’assistance avec les journaux de parcours, les identifiants de profil concernés et les détails sur la transition nulle

NOTE

Les événements envoyés en dehors de la fenêtre de date active du parcours sont silencieusement ignorés avec la DISPATCHER DISCARD #16 — unqualified on journey version enablements d’entrée de journal et aucune erreur d’interface utilisateur. Commencez toujours par vérifier votre configuration du timing du parcours lors du dépannage de la progression du profil de test.

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énements ignorés en raison d’une instance de parcours bloquée max-instance-stack-events-reached

Si des événements sont ignorés pour la maxInstanceStackEventsReached raison, l’exécution du parcours a atteint sa limite interne de pile d’événements par profil de 10 événements pour une version de parcours spécifique. Il s’agit d’un mécanisme de sécurisation qui empêche l’accumulation d’un trop grand nombre d’événements en attente pendant le traitement d’un autre événement pour le même profil.

Il ne s’agit pas d’une fenêtre temporelle ou d’une limite de débit. Cela se produit lorsque l’instance de parcours du profil est bloquée sur une étape de longue exécution (par exemple, une longue attente, un enrichissement ou des reprises d’action personnalisée) et que les événements du même profil, également utilisés dans ce parcours, s’accumulent au-delà de la limite de 10 événements.

Pour l’identifier, interrogez les événements d’étape de parcours où le motif d’abandon est égal à maxInstanceStackEventsReached (par exemple, dans des champs serviceEvents.stateMachine.eventType ou similaires). Pour en savoir plus sur les types d’événement ignorés, consultez la liste champ d’événement d’étape.

Ce que vous pouvez faire

Réduisez les longues attentes ou les étapes lentes sur les chemins qui peuvent se déclencher à nouveau fréquemment.
Dédupliquez ou rebondissez les événements en amont lorsque cela est possible.
Divisez les scénarios à long terme en plusieurs parcours pour éviter l’empilement.

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.

NOTE

Pour les actions de canal Journey Optimizer natives, interrogez le Jeu de données d’événement de retour de message pour confirmer le statut de la diffusion, tel que sent ou bounce. Pour les actions personnalisées, interrogez le jeu de données Événement d’étape de Parcours pour confirmer que Journey Optimizer a exécuté l’action avec succès : un appel HTTP réussi ne confirme pas en lui-même que le système externe a diffusé un message. Découvrez comment choisir le jeu de données approprié pour votre cas d’utilisation.

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

Utilisez cette section pour comprendre pourquoi des lignes en double peuvent apparaître dans les événements d’étape de Parcours.

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 parfois détecter des entrées de journal en double pour la même exécution de parcours. Ces entrées partagent des valeurs identiques pour les éléments suivants :

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 _id différentes, ce qui indique qu’il ne s’agit pas d’une duplication réelle des données.

Qu’est-ce qui provoque ce comportement ?

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

un événement d’étape de parcours commence à être traité et est enregistré dans le jeu de données Événements d’étape de parcours ;
une opération de mise à l’échelle automatique redistribue la charge de travail entre les instances de service ;
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 valeur _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 vérifier en interrogeant le ajo_message_feedback_event_dataset ou en consultant 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 :

Vérifier le champ _id : les vrais doublons au niveau du système auraient la même valeur _id. Des valeurs _id différentes indiquent qu’il s’agit d’entrées de journal distinctes du scénario de rééquilibrage décrit ci-dessus.

Vérifier la diffusion du message : comparez avec les données de feedback sur les messages 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;

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 :

Utilisez _id comme clé primaire pour compter les événements uniques.
Comparez avec les jeux de données de feedback sur les messages lors de l’analyse de la diffusion des messages.
Gardez à l’esprit que l’analyse temporelle peut afficher des entrées regroupées sur quelques secondes d’intervalle.

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

Résolution des problèmes liés aux incohérences des mesures du tableau de bord dashboard-metrics

Si les mesures affichées dans le tableau de bord Vue d’ensemble ne correspondent pas au nombre réel de parcours dans l’onglet Parcourir, vérifiez les points suivants :

Assurez-vous que les parcours en question ont eu du trafic au cours des dernières 24 heures, car les parcours sans activité récente sont exclus du tableau de bord.
Vérifiez que vous disposez des autorisations d’accès appropriées pour afficher tous les parcours de votre organisation.
Patientez jusqu’à 30 minutes pour que les mesures s’actualisent après avoir apporté des modifications à vos parcours.

Si les incohérences persistent, contactez l’assistance Adobe avec des captures d’écran des onglets Aperçu et Parcourir pour plus d’informations.

Paramètres de tracking affichant les espaces réservés vides dans les parcours fermés tracking-parameters-closed-journeys

Si les URL de tracking dans les e-mails envoyés contiennent des espaces réservés vides tels que cid=em-acou-adob{}, cela peut indiquer qu’un champ contextuel tel que context.system.source.actionId n’a pas pu être résolu. Cela se produit généralement lorsqu’un parcours a été fermé et n’a pas été republié après une modification de produit appropriée. Seuls les parcours republiés renseignent correctement ces champs de contexte dans les URL de suivi.

Pour résoudre ce problème, republiez le parcours (créez une nouvelle version et publiez-la) ou supprimez la référence au champ de contexte affecté des paramètres de tracking d’URL dans la configuration du canal ou le contenu de l’e-mail.

AI Knowledge Reference

This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.

For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.

TL;DR: This page is a comprehensive troubleshooting reference for live journey execution in Adobe Journey Optimizer, covering event delivery, profile entry failures, test mode transition issues, discarded events, duplicate step event logs, message delivery checks, and dashboard metric discrepancies.

Intents:

Diagnose why events are not triggering journey entry by checking payload structure, headers, and qualification conditions
Verify whether profiles are entering and progressing through a live or test-mode journey
Resolve test mode transition failures caused by future start dates or misconfigured identity namespaces
Understand and handle the maxInstanceStackEventsReached discard reason for blocked journey instances
Identify and correctly query duplicate Journey Step Event log entries caused by backend auto-scaling
Investigate missing messages by checking journey reporting and custom action call results
Fix empty tracking URL placeholders in emails from closed journeys

Glossary:

Journey Step Events: A dataset that logs each step a profile executes within a journey, used for reporting and debugging (product-specific)
notSuitableInitialEvent: A discard code indicating an event was received but dropped because the qualification condition was not met (product-specific)
maxInstanceStackEventsReached: A discard code indicating the per-profile journey instance event stack limit of 10 has been exceeded (product-specific)
isValidTransition: A UI-only property in journey technical details; a null value may indicate a future start date or corrupted node connection, but does not affect backend processing (product-specific)
Qualification condition: A rule defined on an event that must be satisfied for the event to trigger a journey; events failing this condition are discarded
Rebalancing: A backend auto-scaling operation in AJO microservices that can create duplicate Journey Step Event log entries with different _id values

Guardrails:

Events sent outside the journey’s active date/time window are silently discarded with no error message
The per-profile journey instance event stack limit is 10 events; exceeding this causes events to be discarded with maxInstanceStackEventsReached
Duplicate Journey Step Event entries with different _id values are expected system behavior and do not indicate message duplication
Dashboard Overview metrics only include journeys with traffic in the last 24 hours; metrics may take up to 30 minutes to refresh
Closed journeys that have not been republished after a product change may produce empty placeholders in tracking URLs

Terminology:

Canonical name: Journey Step Events — Acronym: none — variants: step events, journey execution logs
Canonical name: Qualification condition — Acronym: none — variants: event qualification rule, event condition
Synonyms: “rebalancing” = “auto-scaling” (backend operation causing duplicate log entries)
Do not confuse: “duplicate _id” ≠ “duplicate log entries from rebalancing” — true duplicates share the same _id; rebalancing duplicates have different _id values

FAQ:

Q: Why are my events not triggering a journey even though they are being sent successfully? — Check that the journey is live or in test mode, the payload matches the event schema structure, the qualification condition is satisfied, and the correct headers (X-gw-ims-org-id, Content-type) are included.
Q: Why do test profiles enter the journey but not advance past the first step? — The most common cause is a journey start date set in the future; events are silently discarded outside the active date window. Also verify the test profile flag and identity namespace match.
Q: What does maxInstanceStackEventsReached mean? — The journey runtime has hit the internal 10-event stack limit for a specific profile instance, typically because a long-running step is blocking processing. Reduce long waits, deduplicate upstream events, or split the scenario into multiple journeys.
Q: I see duplicate rows in Journey Step Events — is something wrong? — No. Duplicate entries with different _id values are expected and result from backend auto-scaling. Only one message is actually sent; verify with the ajo_message_feedback_event_dataset.
Q: Why do tracking URLs in emails show empty placeholders like cid=em-acou-adob{}? — The journey was closed and not republished after a product change; context fields cannot be resolved. Republish the journey or remove the affected context field reference from the URL tracking parameters.
Q: Why does the Overview dashboard show different numbers than the Browse tab? — The dashboard only counts journeys with traffic in the last 24 hours, metrics take up to 30 minutes to refresh, and access permissions may limit visibility.

recommendation-more-help

journey-optimizer-help