Auf dieser Seite: Erfahren Sie, wie Sie Fehler bei der Ausführung einer Live-Journey beheben können, indem Sie beispielsweise überprüfen, ob Ereignisse gesendet werden, Profile bestätigen, die in die Journey eintreten und sie durchlaufen, und überprüfen, ob Nachrichten zugestellt werden.
In diesem Abschnitt erfahren Sie, wie Sie Fehler bei Journey-Ereignissen beheben und wie Sie prüfen, ob Profile in Ihre Journey eingetreten sind, wie sie diese durchlaufen und ob Nachrichten gesendet werden.
Sie können auch Fehler beheben, bevor Sie eine Journey testen oder veröffentlichen. Erfahren Sie mehr unter Fehlerbehebung vor dem Testen oder Veröffentlichen Ihres Journey.
Wenn Sie eingehende Aktionen verwenden, erfahren Sie unter „Fehlerbehebung bei eingehenden Aktionen in ", wie Sie diese können.
Überprüfen, ob Ereignisse ordnungsgemäß gesendet werden checking-that-events-are-properly-sent
Der Ausgangspunkt einer Journey ist stets ein Ereignis. Sie können mithilfe von Tools wie Postman Tests durchführen.
Sie können prüfen, ob der API-Aufruf, den Sie über diese Tools versenden, richtig gesendet wurde oder nicht. Wenn Sie einen Fehler erhalten, bedeutet das, dass es bei Ihrem Aufruf ein Problem gibt. Überprüfen Sie erneut die Payload, die Kopfzeile (insbesondere die Organisations-ID) sowie die Ziel-URL. Sie können Ihren Administrator nach der richtigen URL fragen.
Ereignisse werden von der Quelle nicht direkt an Journeys weitergeleitet. Journeys benötigen dazu stattdessen die Streaming-Aufnahme-APIs von Adobe Experience Platform. Darum können Sie bei Problemen mit Ereignissen die Fehlerbehebung für Streaming-Aufnahme-APIs in der Adobe Experience Platform Dokumentation nutzen.
Wenn Ihre Journey den Testmodus nicht aktivieren kann und dabei der Fehler ERR_MODEL_RULES_16 ausgegeben wird, stellen Sie im Falle von Kanalaktionen sicher, dass das verwendete Ereignis einen Identity-Namespace enthält.
Der Identity-Namespace dient dazu, die Testprofile eindeutig zu identifizieren. Wenn beispielsweise die E-Mail-Adresse zur Identifizierung der Testprofile verwendet wird, sollte der Identity-Namespace E-Mail ausgewählt werden. Wenn die eindeutige Kennung die Telefonnummer ist, sollte der Identity-Namespace Telefon ausgewählt werden.
Überprüfen, ob Personen in die Journey eintreten checking-if-people-enter-the-journey
Berichte zu Journey messen den Eintritt von Personen in eine Journey auf Echtzeitbasis.
Wenn Sie das Ereignis erfolgreich versenden, aber keinen Eintritt in die Journey sehen können, bedeutet das, dass es zwischen dem Senden und Empfangen des Ereignisses in der Journey zu Problemen kommt.
Sie können die Fehlerbehebung mit den folgenden Fragen beginnen:
-
Sind Sie sicher, dass sich die Journey, bei der Sie das eingehende Ereignis erwarten, im Testmodus befindet oder live ist?
-
Haben Sie das Ereignis gespeichert, bevor Sie die Payload aus der Payload-Vorschau kopiert haben?
-
Enthält die Payload des Ereignisses eine Ereignis-ID?
-
Haben Sie die richtige URL aufgerufen?
-
Haben Sie die Payload-Struktur der Streaming-Aufnahme-APIs mithilfe der Payload-Strukturvorschau im Ereigniskonfigurationsbereich befolgt? Siehe Vorschau der Payload.
-
Haben Sie im Header Ihres Ereignisses die richtigen Schlüssel-Wert-Paare verwendet?
code language-none X-gw-ims-org-id - your organization's ID Content-type - application/json -
Ereignisbedingung und Schemadatentypen: Stellen Sie sicher, dass die in Ihrer Ereignisbedingung (Regel) verwendeten Datentypen mit dem Ereignisschema übereinstimmen. Nicht übereinstimmende Typen (z. B. String vs. Ganzzahl) führen dazu, dass die Regelauswertung fehlschlägt und Ereignisse verworfen werden. Siehe Überprüfen der Ereignisidentität.
-
Ereignis verworfen – Qualifizierungsbedingung nicht erfüllt: Wenn die Qualifizierungsbedingung bei regelbasierten Ereignissen von der Ereignis-Payload nicht erfüllt wird (z. B. ein Pflichtfeld ist leer oder fehlt oder eine Bedingung wie
isNotEmptyauf einem Feld schlägt fehl), wird das Ereignis empfangen, aber verworfen und die Journey wird nicht ausgelöst. Protokolle und Splunk-Traces können anhand von Verwerfungs-Codes wienotSuitableInitialEventanzeigen, dass das Ereignis empfangen, aber aufgrund einer nicht erfüllten Qualifizierungsbedingung verworfen wurde. Dies ist das erwartete Verhalten: Wenn die Qualifizierungsbedingung nicht erfüllt ist, wird das Ereignis verworfen und die Journey wird für dieses Profil nicht ausgelöst. Überprüfen Sie, ob die Ereignis-Payload die erwarteten Felder und Werte enthält und ob die Regel in der Ereigniskonfiguration mit den gesendeten Daten übereinstimmt. Wenn das Ereignis durch eine benutzerdefinierte Aktion einer anderen Journey ausgelöst wird, finden Sie weitere Informationen unter Verarbeiten von Verwerfen-Ereignissen und Leerlauf-Zeitüberschreitungen in der Fehlerbehebung für benutzerdefinierte Aktionen.
>>
Für Journeys zur Zielgruppenqualifizierung mit Streaming-Zielgruppen: Wenn Sie eine Aktivität zur Zielgruppenqualifizierung als Eintrittspunkt für die Journey verwenden, beachten Sie, dass nicht unbedingt alle für die Zielgruppe qualifizierten Profile auch in die Journey eintreten. Dies kann an Zeitfaktoren oder kurzfristigen Ausstiegen aus der Zielgruppe liegen oder daran, dass sich Profile bereits vor der Veröffentlichung in der Zielgruppe befanden. Erfahren Sie mehr zu Überlegungen zum Timing bei der Qualifizierung von Streaming-Zielgruppen.
Überprüfen der Ereignisidentität verify-event-identity-and-rule-data-types
Stellen Sie beim Konfigurieren einer ereignisbasierten Journey sicher, dass das Identitätsfeld der Payload mit dem im Ereignis ausgewählten Namespace übereinstimmt. Wenn das Ereignis Felder zum Abgleichen von Profilen enthält, überprüfen Sie, ob Groß-/Kleinschreibung und Datentyp in der Ereignisbedingung genau mit den eingehenden Daten übereinstimmen. Wenn das Ereignisschema beispielsweise roStatus als String definiert, muss die Journey-Regel dies auch als String auswerten. Nicht übereinstimmende Datentypen (z. B. String vs. Ganzzahl) führen dazu, dass die Regelauswertung fehlschlägt und gültige Ereignisse verworfen werden. Wenn das Ereignis eine Qualifizierungsbedingung aufweist (z. B. ein Feld, das nicht leer sein darf), werden Ereignisse, die diese Bedingung nicht erfüllen verworfen und lösen die Journey nicht aus. Protokolle können dann Verwerfungs-Codes wie notSuitableInitialEvent anzeigen.
Um Ihre Ereignisbedingung in Journey Optimizer zu überprüfen, verwenden Sie die Payload-Vorschau in der Ereigniskonfiguration und stellen Sie sicher, dass die Typen und Werte in der Regel mit der Payload-Struktur übereinstimmen. Erfahren Sie, wie Sie die Payload in der Vorschau anzeigen und regelbasierte Ereignisse konfigurieren.
Fehlerbehebung bei Transitionen im Testmodus troubleshooting-test-transitions
Wenn Testprofile im Testmodus in Ihrer Journey nicht vorankommen oder der visuelle Fluss keine grünen Pfeile anzeigt, die den Fortschritt durch die Schritte angeben, kann das Problem mit der Transitionsvalidierung zusammenhängen. Dieser Abschnitt enthält Anleitungen zur Diagnose und Behebung gängiger Testmodusprobleme.
Testprofile schreiten nicht voran test-profiles-not-progressing
Wenn Testprofile in die Journey eintreten, aber nicht über den ursprünglichen Schritt hinausgehen, überprüfen Sie Folgendes:
-
Journey-Startdatum – Die häufigste Ursache ist, dass das Startdatum der Journey in der Zukunft liegt. Testprofile werden sofort verworfen, wenn die aktuelle Zeit außerhalb des für die Journey konfigurierten Fensters für Start- und Enddatum/-zeit liegt, und es wird der folgende Protokolleintrag generiert:
DISPATCHER DISCARD #16 — unqualified on journey version enablements. Behebung:- Stellen Sie sicher, dass das Startdatum der Journey nicht in der Zukunft liegt
- Stellen Sie sicher, dass die aktuelle Uhrzeit in das aktive Datumsfenster der Journey fällt
- Falls erforderlich, legen Sie das Startdatum zum Testen vorübergehend auf einen Zeitpunkt vor dem aktuellen Zeitpunkt fest und stellen Sie es dann vor der Veröffentlichung wieder um
-
Testprofilkonfiguration: Vergewissern Sie sich, dass das Profil in Adobe Experience Platform korrekt als Testprofil gekennzeichnet ist. Weitere Informationen finden Sie unter So erstellen Sie Testprofile.
-
Nicht übereinstimmende Identity-Namespaces: Nicht übereinstimmende Namespaces verursachen ein Verwerfen im Hintergrund. Das Ereignis wird akzeptiert und gibt eine Erfolgsantwort zurück, aber das Profil tritt nie in die Journey ein und in der Benutzeroberfläche wird kein Fehler angezeigt. Stellen Sie sicher, dass der Namespace in Profilkennung genau mit dem im Ereignisschema definierten Namespace übereinstimmt (unter Berücksichtigung von Groß-/Kleinschreibung). Weitere Informationen finden Sie unter Ausdrucksformat für Profilkennung.
Null-Transitionsindikatoren null-transition-indicators
Bei der technischen Fehlerbehebung kann eine isValidTransition-Eigenschaft auftreten, die in den technischen Details der Journey auf null gesetzt ist. Diese Eigenschaft betrifft ausschließlich die Benutzeroberfläche und hat keine Auswirkungen auf die Backend-Verarbeitung oder die Journey-Leistung. Ein Nullwert kann jedoch auf Folgendes hinweisen:
- Fehlerhafte Journey-Konfiguration – Das Journey-Startdatum ist für die Zukunft festgelegt, sodass Testereignisse im Hintergrund verworfen werden
- Beschädigte Transition – In seltenen Fällen müssen Journey-Knoten möglicherweise erneut verbunden werden
Wenn dauerhafte Probleme mit der Transition auftreten:
- Überprüfen Sie, ob das Startdatum der Journey aktuell ist
- Deaktivieren und reaktivieren Sie den Testmodus
- Wenn das Problem weiterhin besteht, duplizieren Sie die betroffenen Journey-Knoten und verbinden Sie sie erneut
- Wenden Sie sich bei ungelösten Problemen mit Journey-Protokollen, den betroffenen Profil-IDs und Details zur Nulltransition an den Support
DISPATCHER DISCARD #16 — unqualified on journey version enablements verworfen. Überprüfen Sie bei der Fehlerbehebung im Zusammenhang mit dem Fortschritt des Testprofils immer zuerst die Timing-Konfiguration Ihrer Journey.Überprüfen, wie Personen durch die Journey navigieren checking-how-people-navigate-through-the-journey
Berichte zu Journey messen den Fortschritt von Kontakten innerhalb einer Journey. So können Sie leicht ermitteln, wo und warum eine Person gestoppt wurde.
Überprüfen Sie Folgendes:
- Ist das Problem auf eine Bedingung zurückzuführen, mit der die Person ausgeschlossen wird? Beispiel: Die Bedingung lautet „Geschlecht = männlich“, während die Person eine Frau ist. Die Prüfung kann von einem Business-Anwender vorgenommen werden, solange die Bedingung nicht zu komplex ist.
- Ist das Problem auf einen Aufruf einer Datenquelle zurückzuführen, die nicht reagiert? Wenn sich die Journey im Test befindet, können diese Informationen in Testmodusprotokollen angezeigt werden. Wenn die Journey live ist, kann ein Administrator direkte Aufrufe an die Datenquelle testen und die erhaltene Antwort überprüfen. Alternativ kann ein Administrator die Journey duplizieren und dann testen.
Aufgrund von blockierter Journey-Instanz verworfene Ereignisse max-instance-stack-events-reached
Wenn Ereignisse mit dem Grund maxInstanceStackEventsReached verworfen werden, hat die Journey-Laufzeit das interne Limit des Ereignisstapels pro Profil von 10 Ereignissen für eine bestimmte Journey-Version erreicht. Dies ist ein Schutzmechanismus, der verhindert, dass sich zu viele ausstehende Ereignisse ansammeln, während ein anderes Ereignis für dasselbe Profil noch verarbeitet wird.
Dies ist kein Zeitfenster oder Durchsatz-Limit. Dies tritt auf, wenn die Journey-Instanz des Profils bei einem lang andauernden Schritt blockiert wird (z. B. lange Wartezeiten, Anreicherung oder erneute Versuche benutzerdefinierter Aktionen) und Ereignisse für dasselbe Profil, die ebenfalls in dieser Journey verwendet werden, sich über das Limit von 10 Ereignissen hinaus anstauen.
Um dies zu identifizieren, fragen Sie Journey-Schrittereignisse ab, bei denen der Verwerfungsgrund maxInstanceStackEventsReached ist (z. B. in serviceEvents.stateMachine.eventType oder ähnlichen Feldern). Weitere Informationen über Typen verworfener Ereignisse finden Sie in der Liste der Schrittereignisfelder. Die Felder für die Journey-Schrittereignisse finden Sie in der Adobe Journey Optimizer-Schemareferenz.
Was Sie tun können
- Verkürzen Sie lange Wartezeiten oder lang andauernde Schritte auf Pfaden, die häufig erneut ausgelöst werden können.
- Deduplizieren oder entprellen Sie vorgelagerte Ereignisse nach Möglichkeit.
- Teilen Sie lange Szenarien in mehrere Journeys auf, um Stapelungen zu vermeiden.
Überprüfen, ob Nachrichten erfolgreich gesendet werden checking-that-messages-are-sent-successfully
Wenn Personen die Journey zwar richtig durchlaufen, aber nicht die vorgesehenen Nachrichten erhalten, können Sie Folgendes prüfen:
- Journey Optimizer hat die Anfrage zum Senden der Nachricht korrekt berücksichtigt. Ein Business-Anwender kann auf die zu sendende Nachricht zugreifen und prüfen, ob der Zeitpunkt der letzten Ausführung mit der Ausführungszeit Ihrer Journey übereinstimmt. Außerdem kann er die neuesten eingegangenen API-Aufrufe/-Ereignisse prüfen.
- Journey Optimizer hat die Nachricht erfolgreich gesendet. Überprüfen Sie die Journey-Berichte, um sicherzustellen, dass keine Fehler aufgetreten sind.
Bei einer Nachricht, die über eine benutzerdefinierte Aktion gesendet wird, kann während des Journey-Tests nur geprüft werden, ob der Systemaufruf der benutzerdefinierten Aktion zu einem Fehler führt oder nicht. Wenn der Aufruf an das externe System, das mit der benutzerdefinierten Aktion verknüpft ist, nicht zu einem Fehler führt, aber nicht zum Senden einer Nachricht, untersuchen Sie das externe System entsprechend.
sent oder bounce zu bestätigen. In Adobe Journey Optimizer ist sent der relevante Status für erfolgreiche Versandergebnisse von Nachrichten; der Wert delivered wird nicht in Ereignisdatensätzen für Nachrichten-Feedback in Adobe Journey Optimizer verwendet. Fragen Sie bei benutzerdefinierten Aktionen den Datensatz für Journey-Schrittereignisse ab, um zu bestätigen, dass Journey Optimizer die Aktion erfolgreich ausgeführt hat. Ein erfolgreicher HTTP-Aufruf bestätigt für sich genommen noch nicht, dass das externe System eine Nachricht gesendet hat. Informationen zum Auswählen des richtigen Datensatzes für Ihren Anwendungsfall.Informationen zu doppelten Einträgen in Journey-Schrittereignissen duplicate-step-events
In diesem Abschnitt erfahren Sie, warum doppelte Zeilen beim Journey von Schrittereignissen angezeigt werden können.
Warum sehe ich mehrere Einträge mit derselben Journey-Instanz, demselben Profil, demselben Knoten und derselben Anfrage-ID? duplicate-entries-why
Bei der Abfrage von Journey-Schritt-Ereignisdaten können Sie gelegentlich feststellen, was doppelte Protokolleinträge für dieselbe Journey-Ausführung zu sein scheinen. Diese Einträge haben identische Werte bei:
profileID– der ProfilidentitätinstanceID– der Journey-InstanzkennungnodeID– dem spezifischen Journey-KnotenrequestID– der Anfragekennung
Diese Einträge weisen jedoch unterschiedliche _id-Werte auf, was der Schlüsselindikator ist, der dieses Szenario von tatsächlicher Datenduplizierung unterscheidet.
Was verursacht dieses Verhalten? duplicate-entries-cause
Die Ursache sind automatische Backend-Skalierungsvorgänge (auch als „Rebalancing“ bezeichnet) in der Microservices-Architektur von Adobe Journey Optimizer. In Zeiten von hoher Auslastung oder Systemoptimierung gilt Folgendes:
- Ein Journey-Schrittereignis beginnt mit der Verarbeitung und wird im Datensatz für Journey-Schrittereignisse protokolliert
- Durch einen automatischen Skalierungsvorgang wird die Workload auf verschiedene Dienstinstanzen verteilt
- Dasselbe Ereignis kann von einer anderen Dienstinstanz erneut verarbeitet werden, wodurch ein zweiter Protokolleintrag mit einer anderen
_iderstellt wird
Dies ist ein erwartetes Systemverhalten und funktioniert wie vorgesehen.
Hat dies Auswirkungen auf die Ausführung von Journeys oder den Nachrichtenversand? duplicate-entries-impact
Nein. Die Auswirkungen sind auf die Protokollierung beschränkt. Adobe Journey Optimizer verfügt auf der Nachrichtenausführungsebene über integrierte Deduplizierungsmechanismen, die Folgendes sicherstellen:
- Nur eine Nachricht (E-Mail, Mobile-Nachricht, Push-Benachrichtigung usw.) wird an jedes Profil gesendet
- Aktionen werden nur einmal ausgeführt
- Journey-Ausführung läuft korrekt ab
Sie können dies prüfen, indem Sie den ajo_message_feedback_event_dataset abfragen oder die Aktionsausführungsprotokolle konsultieren. Sie werden sehen, dass trotz der doppelten Journey-Schrittereigniseinträge tatsächlich nur eine Nachricht gesendet wurde.
Wie kann ich diese Fälle in meinen Abfragen erkennen? duplicate-entries-queries
Beim Analysieren von Journey-Schritt-Ereignisdaten:
-
Prüfen Sie das
_id-Feld: Echte Duplikate auf Systemebene würden denselben Wert für_idaufweisen. Unterschiedliche Werte für_idweisen auf separate Protokolleinträge aus dem oben beschriebenen Rebalancing-Szenario hin. -
Prüfen Sie den Nachrichtenversand: Sehen Sie sich auch die Daten zum Nachrichten-Feedback an, um sich zu vergewissern, dass nur eine Nachricht gesendet wurde:
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; -
Gruppieren Sie nach eindeutigen Kennungen: Verwenden Sie beim Zählen von Ausführungen
_id, um genaue Zahlen zu erhalten: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>'
Was sollte ich tun, wenn mir das auffällt? duplicate-entries-action
Dies ist ein normales Systemverhalten. Es ist keine Aktion erforderlich. Die Duplikatprotokollierung weist nicht auf ein Problem mit Ihrer Journey-Konfiguration oder dem Nachrichtenversand hin.
Wenn Sie Berichte oder Analysen basierend auf Journey-Schrittereignissen erstellen:
- Verwenden Sie
_idals Primärschlüssel für die Zählung eindeutiger Ereignisse - Sehen Sie sich bei der Analyse des Nachrichtenversands auch Datensätze mit Nachrichten-Feedback an
- Beachten Sie, dass bei der Zeitanalyseauswertung Einträge innerhalb von Sekunden gruppiert angezeigt werden können
Weitere Informationen zum Abfragen von Journey-Schrittereignissen finden Sie unter Beispiele für Abfragen.
Fehlerbehebung bei Diskrepanzen der Dashboard-Metriken dashboard-metrics
Wenn die im Dashboard Übersicht angezeigten Metriken nicht mit der tatsächlichen Anzahl der Journeys auf der Registerkarte Durchsuchen übereinstimmen, überprüfen Sie Folgendes:
- Stellen Sie sicher, dass in den betreffenden Journeys in den letzten 24 Stunden Traffic aufgetreten ist, da Journeys ohne aktuelle Aktivität nicht im Dashboard angezeigt werden.
- Vergewissern Sie sich, dass Sie über die entsprechenden Zugriffsberechtigungen verfügen, um alle Journeys in Ihrem Unternehmen anzuzeigen.
- Nach Änderungen an Ihren Journeys kann es bis zu 30 Minuten dauern, bis die Metriken aktualisiert werden.
Wenn Diskrepanzen weiterhin bestehen, wenden Sie sich an den Adobe-Support und stellen Sie Screenshots der Registerkarten „Übersicht“ und „Durchsuchen“ für die Analyse bereit.
Tracking-Parameter zeigen leere Platzhalter in geschlossenen Journeys tracking-parameters-closed-journeys
Wenn Tracking-URLs in gesendeten E-Mails leere Platzhalter wie cid=em-acou-adob{} enthalten, kann dies darauf hindeuten, dass ein Kontextfeld wie context.system.source.actionId nicht aufgelöst werden konnte. Dies geschieht, wenn eine Journey geschlossen wurde und nach einer entsprechenden Produktänderung nicht erneut veröffentlicht wurde - nur erneut veröffentlichte Journey füllen diese Kontextfelder in Tracking-URLs korrekt aus.
Um dies zu beheben, veröffentlichen Sie die Journey entweder erneut (erstellen Sie eine neue Version und veröffentlichen Sie diese) oder entfernen Sie den Verweis auf das betroffene Kontextfeld aus den URL-Tracking-Parametern in der Kanalkonfiguration oder im E-Mail-Inhalt.
Verwandte Themen related
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 troubleshooting reference for live journey execution in Adobe Journey Optimizer, covering event delivery, profile entry, test mode transition issues, discarded events, duplicate journey step event entries, message delivery checks, dashboard metric discrepancies, and empty tracking parameter placeholders.
Intents:
- Diagnose why events are not entering a journey by checking payload structure, headers, event condition data types, and qualification conditions
- Verify whether profiles are entering and progressing through a journey in test mode or live
- Resolve test profiles that do not progress, using the journey start date, test profile configuration, and identity namespace checks
- Understand and handle the
maxInstanceStackEventsReacheddiscard reason for blocked journey instances - Identify and correctly query duplicate Journey Step Events entries that have different
_idvalues - Investigate missing messages by checking journey reporting, message feedback, and custom action call results
- Fix empty tracking URL placeholders in emails from closed journeys
Glossary:
- Journey Step Events: The dataset to which journey step events are logged; queried to find discard reasons and duplicate rows, and to confirm that Journey Optimizer executed a custom action (product-specific)
- notSuitableInitialEvent: A discard code that logs can show when an event was received but discarded because it did not meet the qualification condition (product-specific)
- maxInstanceStackEventsReached: A discard reason that appears when the journey runtime reaches its internal per-profile event stack limit for a specific journey version (see Guardrails) (product-specific)
- isValidTransition: A UI-only property in the journey’s technical details; the page states it does not impact backend processing or journey performance, and a null value can indicate a journey misconfiguration (start date set in the future) or a corrupted transition (product-specific)
- Qualification condition: A condition on rule-based events; when the event payload does not satisfy it (for example, a required field is empty or missing), the event is received but discarded and the journey is not triggered
- Rebalancing: A backend auto-scaling operation in Adobe Journey Optimizer’s microservices architecture that can cause the same event to be reprocessed by another service instance, creating a second log entry with a different
_id
Guardrails:
- Events sent outside the journey’s active date window are discarded silently with the log entry
DISPATCHER DISCARD #16 — unqualified on journey version enablementsand no UI error - The journey runtime has an internal per-profile event stack limit of 10 events for a specific journey version; events beyond it are discarded with
maxInstanceStackEventsReached. This is not a time-window or throughput limit - The namespace in the Profile Identifier must match the namespace defined in the event schema exactly (case-sensitive); a mismatch causes a silent drop: the event is accepted and returns a success response, but the profile never enters the journey and no error is surfaced in the UI
- Overview dashboard metrics only include journeys that had traffic in the last 24 hours; allow up to 30 minutes for metrics to refresh after changes
- Only republished journeys correctly populate context fields in tracking URLs; a closed journey that was not republished after a relevant product change can show empty placeholders
Terminology:
- Canonical name: Journey Step Events — variants: journey step events, Journey Step Events dataset, step events
- Synonyms: “rebalancing” = “auto-scaling” (the backend operation that can create duplicate log entries)
- Do not confuse: entries with the same
_id(duplicates at system level) ≠ entries with different_idvalues (separate log entries from the rebalancing scenario) - Do not confuse:
sent≠delivered— in Adobe Journey Optimizer Message Feedback Event datasets,sentis the relevant status for successful message delivery outcomes and thedeliveredvalue is not used
FAQ:
- Q: Why are my events not entering a journey even though they are sent successfully? — Check that the journey is in test mode or live, that the event was saved before copying the payload from the payload preview, that the payload has an event id and follows the streaming ingestion APIs payload structure, that the URL and the header key-value pairs (
X-gw-ims-org-id,Content-type) are right, that the data types in the event condition match the event schema, and that the qualification condition is satisfied. - Q: Why does the journey fail to enable test mode with
ERR_MODEL_RULES_16? — Ensure the event used includes an identity namespace when using a channel action. - Q: Why do test profiles enter the journey but not advance past the initial step? — The most common cause is a journey start date set in the future; events outside the active date window are discarded silently. Also check the test profile configuration and the identity namespace.
- Q: What does
maxInstanceStackEventsReachedmean? — The journey runtime has reached its internal per-profile event stack limit of 10 events for a specific journey version, because the profile’s journey instance is blocked on a long-running step. Reduce long waits or slow steps, deduplicate or debounce upstream events, or split long-running scenarios into multiple journeys. - Q: I see duplicate rows in journey step events - is something wrong? — No. Entries with the same
profileID,instanceID,nodeID, andrequestIDbut different_idvalues are expected system behavior from backend auto-scaling; the impact is limited to logging, and only one message is sent. Verify withajo_message_feedback_event_dataset. - Q: Why do tracking URLs in emails show empty placeholders like
cid=em-acou-adob{}? — A context field such ascontext.system.source.actionIdcould not be resolved because the journey was closed and not republished after a relevant product change. Republish the journey, or remove the reference to the affected context field from the URL tracking parameters. - Q: Why does the Overview dashboard show different numbers than the Browse tab? — Check that the journeys had traffic in the last 24 hours, that you have the access permissions to view all journeys in your organization, and allow up to 30 minutes for metrics to refresh.
Related pages:
- Troubleshooting errors before testing or publishing a journey: Troubleshoot errors before testing or publishing your journey (building-journeys/troubleshooting.md)
- Troubleshooting inbound actions: Troubleshoot inbound actions in journeys (building-journeys/troubleshooting-inbound.md)
- Understanding journey step events: Journey step events (reports/journey-step-events-overview.md)
- Journey error codes: Error codes reference (building-journeys/error-codes-reference.md)