DocumentaciónJourney OptimizerGuía de Journey Optimizer

Resolución de problemas de ejecución de recorrido activo troubleshooting-execution

Última actualización: 23 de octubre de 2026
  • Se aplica a:
  • Journey Orchestration

Creado para:

  • Intermedio
  • Usuario

En esta página: Aprenda a solucionar problemas de ejecución de un recorrido activo, incluida la comprobación de que se envían eventos, la confirmación de la entrada de perfiles y el progreso en el recorrido, y la comprobación de que se envían mensajes.

style
shade-box

En esta sección, aprenderá a solucionar problemas de eventos de recorrido, comprobar si los perfiles han introducido el recorrido, cómo navegan por él y si se envían mensajes.

También puede solucionar errores antes de probar o publicar un recorrido. Aprenda a solucionar errores antes de probar o publicar su recorrido.

Si usa acciones entrantes, aprenda a solucionarlas en Solucionar problemas de acciones entrantes en recorrido.

Compruebe que los eventos se envían correctamente checking-that-events-are-properly-sent

El punto de partida de un recorrido es siempre un evento. Puede hacer pruebas con herramientas como Postman.

Puede comprobar si la llamada API que envía a través de estas herramientas se envía correctamente o no. Si vuelve a recibir un error, significa que la llamada tiene un problema. Vuelva a comprobar la carga útil, el encabezado (y especialmente el ID de organización) y la dirección URL de destino. Puede preguntar a su administrador cuál es la dirección URL correcta para visitar.

Los eventos no se insertan directamente del origen a los recorridos. De hecho, los recorridos dependen de las API de ingesta de transmisión de Adobe Experience Platform. Como resultado, en caso de problemas relacionados con el evento, puede consultar Adobe Experience Platform documentación para la solución de problemas de las API de ingesta de transmisión.

Si el recorrido no puede habilitar el modo de prueba con el error ERR_MODEL_RULES_16, asegúrese de que el evento usado incluya un área de nombres de identidad al usar una acción de canal.

El área de nombres de identidad se utiliza para identificar los perfiles de prueba de forma exclusiva. Por ejemplo, si se usa el correo electrónico para identificar los perfiles de prueba, se debe seleccionar el área de nombres de identidad Correo electrónico. Si el identificador único es el número de teléfono, se debe seleccionar el área de nombres de identidad Teléfono.

Comprobar si las personas entran en el recorrido checking-if-people-enter-the-journey

El informe de recorridos mide las entradas de la gente en un recorrido en tiempo real.

Si se consigue enviar el evento pero no se ve ninguna entrada en el recorrido, hay un problema entre el envío del evento y la recepción del evento en el recorrido.

Puede comenzar la resolución de problemas con las preguntas siguientes:

  • ¿Seguro que el recorrido en el que espera el evento entrante está en modo de prueba o activo?

  • ¿Ha guardado el evento antes de copiar la carga útil de la previsualización de carga útil?

  • ¿Su carga útil de evento contiene un ID de evento?

  • ¿Ha marcado la dirección URL correcta?

  • ¿Ha seguido la estructura de carga útil de las API de ingesta de transmisión mediante la previsualización de estructura de carga útil del panel de configuración de evento? Ver Vista previa de la carga.

  • ¿Utilizó los pares clave-valor correctos en el encabezado del evento?

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

  • Tipos de datos de esquema y condición de evento: asegúrese de que los tipos de datos utilizados en su condición de evento (regla) coincidan con el esquema de evento. Los tipos no coincidentes (por ejemplo, cadena frente a entero) hacen que la evaluación de reglas falle y que se pierdan eventos. Ver Verificar identidad del evento.

  • Evento descartado - no se cumple la condición de calificación - Para los eventos basados en reglas, si la condición de calificación no se cumple con la carga útil del evento (por ejemplo, falta un campo obligatorio o está vacío, o falla una condición como isNotEmpty en un campo), el evento se recibe pero se descarta y el recorrido no se activa. Los registros y los seguimientos de Splunk pueden mostrar que el evento se recibió pero se descartó porque no cumplía la condición de calificación, con códigos de descarte como notSuitableInitialEvent. Este es el comportamiento esperado: si no se cumple la condición de calificación, el evento se descarta y el recorrido no se activa para ese perfil. Compruebe que la carga útil de evento contiene los campos y valores esperados y que la regla de la configuración de evento coincide con los datos que envía. Si el evento se activa mediante una acción personalizada desde otro recorrido, consulte Gestión de eventos de descarte y tiempos de espera inactivos en la solución de problemas de acciones personalizadas.

​>>
Para recorridos de calificación de audiencia con audiencias de streaming: Si usa una actividad de calificación de audiencia como punto de entrada de recorrido, tenga en cuenta que no todos los perfiles aptos para la audiencia entrarán necesariamente en la recorrido debido a factores de tiempo, salidas rápidas de la audiencia o si los perfiles ya estaban en la audiencia antes de la publicación. Más información sobre consideraciones de tiempo para la calificación de audiencias de streaming.

Verificar identidad del evento verify-event-identity-and-rule-data-types

Al configurar un recorrido basado en eventos, confirme que el campo de identidad de la carga útil coincide con el área de nombres seleccionado en el evento. Si el evento incluye campos para la coincidencia de perfiles, compruebe que mayúsculas y minúsculas y tipo de datos en la condición de evento coincidan exactamente con los datos de entrada. Por ejemplo, si el esquema de eventos define roStatus como una cadena, la regla de recorrido también debe evaluarla como una cadena. Los tipos de datos no coincidentes (por ejemplo, cadena frente a entero) hacen que la evaluación de reglas falle y que se eliminen eventos válidos. Del mismo modo, si el evento tiene una condición de calificación (por ejemplo, un campo no debe estar vacío), los eventos que no cumplan esa condición se descartarán y no almacenarán en déclencheur el recorrido; los registros pueden mostrar códigos de descarte como notSuitableInitialEvent.

Para validar la condición de evento en Journey Optimizer, utilice la vista previa de carga útil en la configuración de evento y asegúrese de que los tipos y valores de la regla coinciden con la estructura de carga útil. Obtenga información sobre cómo previsualizar la carga útil y configurar eventos basados en reglas.

Solución de problemas de transiciones del modo de prueba troubleshooting-test-transitions

Si los perfiles de prueba no progresan a través del recorrido en el modo de prueba o el flujo visual no muestra flechas verdes que indiquen la progresión del paso, el problema puede estar relacionado con la validación de la transición. En esta sección se explica cómo diagnosticar y resolver problemas comunes del modo de prueba.

Los perfiles de prueba no progresan test-profiles-not-progressing

Si los perfiles de prueba entran en el recorrido pero no avanzan más allá del paso inicial, compruebe lo siguiente:

  • fecha de inicio del Recorrido - La causa más común es cuando la fecha de inicio del recorrido se establece en el futuro. Los perfiles de prueba se descartan inmediatamente si la hora actual no coincide con la ventana fechas/hora de inicio y finalización de la recorrido, lo que genera la entrada de registro: DISPATCHER DISCARD #16 — unqualified on journey version enablements. Para resolver:

    • Compruebe que la fecha de inicio del recorrido no esté establecida en el futuro
    • Asegúrese de que la hora actual se encuentre dentro de la ventana de fecha activa del recorrido
    • Si es necesario, establezca temporalmente la fecha de inicio a una hora anterior al momento actual para realizar la prueba y, a continuación, restáurela antes de publicar

  • Configuración del perfil de prueba - Confirme que el perfil está marcado correctamente como perfil de prueba en Adobe Experience Platform. Consulte cómo crear perfiles de prueba para obtener más información.

  • El área de nombres de identidad no coincide: una falta de coincidencia de área de nombres provoca una caída silenciosa: el evento se acepta y devuelve una respuesta correcta, pero el perfil nunca entra en la recorrido y no aparece ningún error en la interfaz de usuario. Asegúrese de que el espacio de nombres del Identificador de perfil coincida exactamente con el espacio de nombres definido en el esquema de eventos (distingue mayúsculas de minúsculas). Consulte el formato de expresión de identificador de perfil para obtener detalles.

Indicadores de transición nulos null-transition-indicators

Durante la solución de problemas técnicos, puede encontrar una propiedad isValidTransition establecida en null en los detalles técnicos del recorrido. Esta propiedad solo de interfaz de usuario no afecta al procesamiento back-end ni al rendimiento del recorrido. Sin embargo, un valor nulo puede indicar:

  • Configuración incorrecta del Recorrido: la fecha de inicio del recorrido se establece en el futuro, lo que provoca que los eventos de prueba se descarten sin aviso
  • Transición dañada: en casos excepcionales, es posible que sea necesario volver a conectar los nodos de recorrido

Si encuentra problemas de transición persistentes:

  1. Compruebe que la fecha de inicio del recorrido es la actual
  2. Desactivar y reactivar el modo de prueba
  3. Si el problema persiste, considere la posibilidad de duplicar los nodos de recorrido afectados y reconectarlos
  4. Para casos sin resolver, comuníquese con la atención al cliente con los registros de recorrido, los identificadores de perfil afectados y los detalles sobre la transición nula
NOTE
Los eventos enviados fuera de la ventana de fecha activa del recorrido se descartan silenciosamente con la entrada de registro DISPATCHER DISCARD #16 — unqualified on journey version enablements y sin error de interfaz de usuario. Compruebe siempre primero la configuración del tiempo de recorrido al solucionar problemas de progresión de perfiles de prueba.

Comprobar cómo navegan las personas por el recorrido checking-how-people-navigate-through-the-journey

La creación de informes de recorrido mide el progreso de las personas dentro de un recorrido. Es fácil identificar dónde y por qué detuvieron a una persona.

Compruebe lo siguiente:

  • ¿Se debe a una condición que excluye a la persona? Por ejemplo, la condición es “género = hombre” y la persona es mujer. Esta comprobación puede realizarla un usuario empresarial si la condición no es demasiado compleja.
  • ¿Se debe a que una llamada a una fuente de datos no responde? Cuando el recorrido está en prueba, esta información se puede ver en los registros del modo de prueba. Cuando el recorrido está activo, un administrador puede probar las llamadas directas a la fuente de datos y comprobar la respuesta recibida. Un administrador también puede realizar el duplicado del recorrido y probarlo.
TIP
También puede usar la habilidad Rastrear perfil de Recorrido en Compañero de trabajo para investigar un recorrido publicado. Pregunte cuántos perfiles han entrado en cada nodo y cómo se dividen entre ramas, qué perfiles han fallado y por qué, o qué ruta ha seguido un solo perfil. Más información sobre las habilidades de los compañeros de trabajo para los recorridos

Eventos descartados debido a una instancia de recorrido bloqueada max-instance-stack-events-reached

Si ve eventos descartados con el motivo maxInstanceStackEventsReached, el tiempo de ejecución de recorrido ha alcanzado su límite interno de pila de eventos por perfil de 10 eventos para una versión de recorrido específica. Se trata de una protección de seguridad que evita que se apilen demasiados eventos pendientes mientras se sigue procesando otro evento para el mismo perfil.

Este es no un límite de tiempo o de rendimiento. Se produce cuando la instancia de recorrido del perfil se bloquea en un paso de larga ejecución (por ejemplo, una espera larga, un enriquecimiento o reintentos de acción personalizados) y los eventos del mismo perfil, que también se utilizan en esa recorrido, se acumulan más allá del límite de 10 eventos.

Para identificarlo, consulte los eventos de paso del recorrido donde el motivo de descarte sea igual a maxInstanceStackEventsReached (por ejemplo, en serviceEvents.stateMachine.eventType o campos similares). Obtenga más información acerca de los tipos de eventos descartados en la lista de campos de eventos de paso. Para los campos de los eventos de paso de recorrido, vea la Referencia de esquema de Adobe Journey Optimizer.

Lo que puedes hacer

  • Reduzca las esperas largas o los pasos lentos en rutas que pueden volver a déclencheur con frecuencia.
  • Deduplique o devuelva eventos ascendentes cuando sea posible.
  • Divida los escenarios de larga duración en varios recorridos para evitar el apilamiento.

Comprobar que los mensajes se envíen correctamente checking-that-messages-are-sent-successfully

Si las personas recorren el recorrido correctamente pero no reciben mensajes que deberían recibir, puede comprobar lo siguiente:

  • Journey Optimizer ha tenido en cuenta correctamente la solicitud para enviar el mensaje. Los usuarios empresariales pueden acceder al mensaje que se supone que se debe enviar y comprobar si la hora de la última ejecución corresponde al tiempo de ejecución de su recorrido. También pueden consultar las últimas llamadas o eventos de API recibidas.
  • Journey Optimizer ha enviado correctamente el mensaje. Compruebe los informes de recorrido para asegurarse de que no hay errores.

En el caso de un mensaje enviado mediante una acción personalizada, lo único que se puede comprobar durante la prueba de recorrido es el hecho de que la llamada del sistema de la acción personalizada produce un error o no. Si la llamada al sistema externo asociada con la acción personalizada no genera un error pero no conduce al envío de un mensaje, investigue del lado del sistema externo.

NOTE
Para las acciones nativas del canal de Journey Optimizer, consulte el conjunto de datos de evento de comentarios de mensajes para confirmar el estado de envío, como sent o bounce. En Adobe Journey Optimizer, sent es el estado relevante para los resultados de envío de mensajes correctos; el valor delivered no se utiliza en los conjuntos de datos de evento de comentarios de mensajes de Adobe Journey Optimizer. Para las acciones personalizadas, consulte el conjunto de datos Evento de paso de Recorrido para confirmar que Journey Optimizer ejecutó la acción correctamente: una llamada HTTP correcta no confirma por sí misma que el sistema externo entregó un mensaje. Aprenda a elegir el conjunto de datos correcto para su caso de uso.

Explicación de las entradas duplicadas en eventos de paso de Recorrido duplicate-step-events

Utilice esta sección para comprender por qué pueden aparecer filas duplicadas en eventos de paso de recorrido.

¿Por qué veo varias entradas con la misma instancia de recorrido, perfil, nodo y ID de solicitud? duplicate-entries-why

Al consultar los datos de eventos de paso del recorrido, puede observar ocasionalmente lo que parecen ser entradas de registro duplicadas para la misma ejecución del recorrido. Estas entradas comparten valores idénticos para:

  • profileID - La identidad del perfil
  • instanceID: el identificador de instancia de recorrido
  • nodeID: el nodo de recorrido específico
  • requestID - El identificador de la solicitud

Sin embargo, estas entradas tienen diferentes valores de _id, que es el indicador clave que distingue este escenario de la duplicación de datos real.

¿Qué causa este comportamiento? duplicate-entries-cause

Esto ocurre debido a las operaciones de escalado automático del servidor (también llamadas “reequilibrio”) en la arquitectura de microservicios de Adobe Journey Optimizer. Durante períodos de alta carga u optimización del sistema:

  1. Un evento de paso de recorrido comienza a procesarse y se registra en el conjunto de datos de eventos de paso de Recorrido
  2. Una operación de escalado automático redistribuye la carga de trabajo entre instancias de servicio
  3. Otra instancia de servicio puede volver a procesar el mismo evento y crear una segunda entrada de registro con un _id diferente

Se trata de un comportamiento esperado del sistema y funciona según lo diseñado.

¿Afecta a la ejecución del recorrido o a la entrega de mensajes? duplicate-entries-impact

Nº El impacto se limita únicamente al registro. Adobe Journey Optimizer tiene mecanismos de deduplicación integrados en la capa de ejecución de mensajes que garantizan:

  • Solo un mensaje (correo electrónico, mensaje móvil, notificación push, etc.) se envía a cada perfil
  • Las acciones se ejecutan solo una vez
  • La ejecución del recorrido se realiza correctamente

Puede comprobarlo consultando los ajo_message_feedback_event_dataset o comprobando los registros de ejecución de acciones. Verá que solo se envió un mensaje, a pesar de las entradas de evento de paso de recorrido duplicadas.

¿Cómo puedo identificar estos casos en mis consultas? duplicate-entries-queries

Al analizar los datos de eventos de paso de recorrido:

  1. Compruebe el campo _id: Los duplicados verdaderos en el nivel de sistema tendrían el mismo _id. Valores diferentes de _id indican entradas de registro independientes del escenario de reequilibrio descrito anteriormente.

  2. Verificar entrega de mensajes: haga referencia cruzada con datos de comentarios de mensajes para confirmar que solo se envió un mensaje:

    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. Agrupar por identificadores únicos: Al contar las ejecuciones, use _id para obtener recuentos precisos:

    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>'

¿Qué debo hacer si observo esto? duplicate-entries-action

Este es un comportamiento normal del sistema y no se requiere ninguna acción. El registro duplicado no indica un problema con la configuración del recorrido o la entrega de mensajes.

Si está creando informes o análisis basados en eventos de paso de recorrido:

  • Usar _id como clave principal para contar eventos únicos
  • Referencia cruzada con conjuntos de datos de comentarios de mensajes al analizar el envío de mensajes
  • Tenga en cuenta que el análisis de tiempo puede mostrar entradas agrupadas con segundos de diferencia

Para obtener más información sobre la consulta de eventos de paso de Recorrido, vea Ejemplos de consultas.

Solucionar discrepancias de métricas del panel dashboard-metrics

Si las métricas mostradas en el panel Información general no coinciden con el número real de recorridos en la pestaña Examinar, compruebe lo siguiente:

  • Asegúrese de que los recorridos en cuestión hayan tenido tráfico en las últimas 24 horas, ya que los recorridos sin actividad reciente se excluyen del panel.
  • Compruebe que dispone de los permisos de acceso adecuados para ver todos los recorridos de su organización.
  • Conceda un máximo de 30 minutos para que las métricas se actualicen después de realizar cambios en los recorridos.

Si persisten las discrepancias, póngase en contacto con el Soporte técnico de Adobe con capturas de pantalla de las pestañas Información general y Examinar para realizar una investigación.

Parámetros de seguimiento que muestran marcadores de posición vacíos en recorridos cerrados tracking-parameters-closed-journeys

Si las direcciones URL de seguimiento en los correos electrónicos enviados contienen marcadores de posición vacíos como cid=em-acou-adob{}, esto puede indicar que no se pudo resolver un campo de contexto como context.system.source.actionId. Esto sucede cuando se cierra un recorrido y no se ha vuelto a publicar después de un cambio de producto relevante: solo los recorridos que se han vuelto a publicar rellenan correctamente estos campos de contexto en las direcciones URL de seguimiento.

Para resolver esto, vuelva a publicar el recorrido (cree una nueva versión y publíquelo) o quite la referencia al campo de contexto afectado de los parámetros de seguimiento de URL en la configuración del canal o del contenido del correo electrónico.

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 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 maxInstanceStackEventsReached discard reason for blocked journey instances
  • Identify and correctly query duplicate Journey Step Events entries that have different _id values
  • 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 enablements and 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 _id values (separate log entries from the rebalancing scenario)
  • Do not confuse: sent ≠ delivered — in Adobe Journey Optimizer Message Feedback Event datasets, sent is the relevant status for successful message delivery outcomes and the delivered value 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 maxInstanceStackEventsReached mean? — 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, and requestID but different _id values are expected system behavior from backend auto-scaling; the impact is limited to logging, and only one message is sent. Verify with ajo_message_feedback_event_dataset.
  • Q: Why do tracking URLs in emails show empty placeholders like cid=em-acou-adob{}? — A context field such as context.system.source.actionId could 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)
recommendation-more-help
journey-optimizer-help