En esta página: Aprenda a validar el recorrido antes de publicar mediante simulación con usuarios simulados o modo de prueba con perfiles de prueba para detectar errores de forma temprana.
¿No está seguro de que el modo de prueba sea el adecuado para usted? Comparar las tres opciones de validación.
Una vez creado el recorrido, puede probarlo antes de publicarlo. Adobe Journey Optimizer ofrece el “Modo de prueba” como una forma de ver los perfiles de prueba a medida que se mueven por el recorrido, detectando posibles errores antes de la activación. La ejecución de pruebas rápidas le permite comprobar que los recorridos funcionan correctamente para que pueda publicarlos con confianza.
Solo los perfiles de prueba pueden introducir un recorrido en el modo de prueba. Puede crear nuevos perfiles de prueba o convertir los perfiles existentes en perfiles de prueba. Obtenga más información acerca de los perfiles de prueba en esta sección.
Adobe Recorrido Optimizer ofrece dos formas de probar y validar el recorrido:
-
Simulation: establezca el recorrido en Simulation y utilice usuarios simulados (perfiles temporales que cree o genere sobre la marcha sin perfiles creados previamente en Adobe Experience Platform).
-
Modo de prueba: los perfiles persistentes se han marcado explícitamente como perfiles de prueba en Adobe Experience Platform. Se pueden reutilizar en varias sesiones de prueba. Se recomienda este método para realizar pruebas con datos de perfil coherentes y predefinidos. Aprenda a crear perfiles de prueba.
Notas importantes important_notes
Revise estas notas antes de ejecutar pruebas en el recorrido.
Limitaciones generales
- Solo perfiles de prueba: solo los individuos marcados como “perfiles de prueba” en el servicio Perfil del cliente en tiempo real pueden entrar en un recorrido en modo de prueba. Aprenda a crear perfiles de prueba.
- Requisito de área de nombres: el modo de prueba solo está disponible para los recorridos de borrador que utilizan un área de nombres. El modo de prueba necesita comprobar si una persona que entra en el recorrido es un perfil de prueba o no y, por lo tanto, debe poder llegar a Adobe Experience Platform.
- Límite de perfiles: un máximo de 100 perfiles de prueba pueden entrar en un recorrido durante una sola sesión de prueba.
- Activación de eventos: los eventos solo se pueden activar desde la interfaz. Los eventos no se pueden activar desde sistemas externos mediante una API.
- Audiencias de carga personalizadas: el modo de prueba de Recorrido no admite audiencia de carga personalizada enriquecimiento de atributos.
Comportamiento durante y después de las pruebas
- Deshabilitando el modo de prueba: cuando deshabilita el modo de prueba, se quitan todos los perfiles que estén actualmente en la recorrido o que hayan entrado anteriormente en ella y se borran los informes.
- Flexibilidad de reactivación: puede habilitar y deshabilitar el modo de prueba tantas veces como sea necesario.
- Desactivación automática: los Recorridos que permanecen inactivos en modo de prueba durante más de una semana salen automáticamente del modo de prueba y vuelven al estado Borrador. No se pierde contenido del recorrido; solo finaliza la sesión del modo de prueba.
- Edición y publicación: mientras el modo de prueba esté activo, no puede modificar el recorrido. Sin embargo, puede publicar directamente el recorrido, sin necesidad de desactivar el modo de prueba antes.
- Envío de mensajes: en el modo de prueba, los mensajes se envían a las bandejas de entrada reales de los perfiles de prueba utilizando la misma canalización de envío que la producción. Esto difiere de Ejecución en seco del Recorrido, que simula la ejecución del recorrido sin enviar mensajes ni activar acciones del canal real. Ninguno de los métodos duplica todos los aspectos de un envío en directo; utilice un entorno de ensayo para la validación completa de extremo a extremo.
Ejecución
- Comportamiento de división: cuando el recorrido alcanza una división, la rama superior siempre se selecciona en modo de prueba. Esto no refleja la ruta seleccionada estadísticamente durante la ejecución en directo. Reordene las ramas si desea probar una ruta diferente.
- Programación de eventos: si el recorrido incluye varios eventos, almacene en déclencheur cada evento en secuencia. Si se envía un evento demasiado pronto (antes de que termine el primer nodo de espera) o demasiado tarde (después del tiempo de espera configurado), se descartará el evento. A continuación, el perfil se envía a una ruta de tiempo de espera. Confirme siempre que las referencias a los campos de carga útil de evento sigan siendo válidas enviando la carga útil dentro de la ventana definida.
- Ventana de fecha activa. Asegúrese de que la ventana fechas/hora de inicio y finalización configurada en el recorrido incluya la hora actual al iniciar el modo de prueba. De lo contrario, los eventos de prueba desencadenados se descartan silenciosamente con el mensaje de registro
DISPATCHER DISCARD #16 — unqualified on journey version enablements. Para evitarlo durante la prueba, establezca temporalmente la fecha de inicio de la recorrido a una hora anterior al momento actual y, a continuación, restáurela antes de publicarla. Obtenga más información acerca de la solución de problemas de este problema en esta página. - Eventos de reacción: para los eventos de reacción con tiempo de espera, el tiempo de espera mínimo y predeterminado es de 40 segundos.
- Conjuntos de datos de prueba: los eventos activados en el modo de prueba se almacenan en conjuntos de datos dedicados etiquetados de la siguiente manera:
JOtestmode - <schema of your event> - Infraestructura compartida: el modo de prueba se ejecuta en la misma infraestructura que la producción. Durante los períodos de alto tráfico, es posible que observe retrasos en los envíos de correo electrónico o en el procesamiento de eventos. En este caso, compruebe los paneles de tráfico de la plataforma o vuelva a intentar las pruebas durante las horas de menor actividad.
Activar el modo de prueba
Utilice el método Modo de prueba cuando quiera probar su recorrido con perfiles de prueba preexistentes que ya ha creado en Adobe Experience Platform.
-
Para activar el modo de prueba, haga clic en el botón Simular y seleccione Modo de prueba.
-
Si el recorrido tiene al menos una actividad Wait, establezca el parámetro Wait time para definir el tiempo que cada actividad de espera y el tiempo de espera del evento durarán en el modo de prueba. El tiempo predeterminado es 10 segundos para esperas y tiempos de espera de evento. Esto garantizará que obtenga los resultados de la prueba rápidamente.
note NOTE Cuando se utiliza un evento de reacción con un tiempo de espera en un recorrido, el tiempo de espera predeterminado y el valor mínimo son 40 segundos. Consulte esta sección. -
Use el botón Déclencheur un evento para configurar y enviar eventos al recorrido.
-
Configure los diferentes campos esperados. En el campo Identificador de perfil, escriba el valor del campo usado para identificar el perfil de prueba. Puede ser la dirección de correo electrónico, por ejemplo. Asegúrese de enviar eventos relacionados con los perfiles de prueba. Consulte esta sección.
-
Una vez recibidos los eventos, haga clic en el botón Mostrar registro para ver el resultado de la prueba y verificarlo. Consulte esta sección.
-
Si hay algún error, desactive el modo de prueba, modifique el recorrido y pruebe de nuevo. Una vez realizadas las pruebas, puede publicar el recorrido. Consulte esta página.
Ejemplo trabajado: validar un recorrido simple test-walkthrough
El siguiente ejemplo muestra cómo probar un recorrido que comienza con un evento unitario, envía un correo electrónico, espera 10 minutos y, a continuación, envía una notificación push.
Para validar el recorrido de extremo a extremo:
-
Active el modo de prueba haciendo clic en Modo de prueba en la esquina superior derecha. El lienzo cambia al modo de prueba y aparece un botón Déclencheur y evento.
-
Establezca Tiempo de espera en 10 segundos para que el nodo de espera se complete rápidamente durante la prueba.
-
Haga clic en Déclencheur un evento, seleccione el evento e introduzca un identificador de perfil de prueba (por ejemplo, la dirección de correo electrónico de un perfil marcado como perfil de prueba en Adobe Experience Platform).
-
Haga clic en Enviar. El flujo visual aparece en el lienzo y se vuelve verde a medida que el perfil progresa en cada paso.
-
Haga clic en Mostrar registro y confirme lo siguiente en la salida JSON:
currentstepcoincide con la actividad en la que espera que esté el perfil.phasemuestrarunningmientras el perfil se encuentra en un nodo de espera yfinishedcuando llega al final.- No hay
actionExecutionErrorsentradas presentes.
-
Después de 10 segundos, actualice el registro. El perfil debería haber avanzado más allá del nodo de espera y haber activado la acción push.
-
Cuando todos los pasos muestren
finishedy no se registren errores, desactive el modo de prueba y publique el recorrido.
- El identificador de perfil que especificó está marcado como perfil de prueba en Adobe Experience Platform.
- Las fechas de inicio y finalización configuradas del recorrido incluyen la hora actual. Los eventos activados fuera de esta ventana se descartan de forma silenciosa. Más información.
Solucionar problemas del modo de prueba troubleshoot-test-mode
Utilice esta tabla para autodiagnosticar errores comunes del modo de prueba antes de abrir un ticket de asistencia.
@{<EventName>.identityMap.entry('<NamespaceName>').first().id}. <NamespaceName> debe coincidir exactamente con el esquema de eventos (distingue mayúsculas de minúsculas). Consulte Requisitos previos.DISPATCHER DISCARD #16 — unqualified on journey version enablementsERR_MODEL_RULES_16Activación de eventos firing_events
Use el botón Déclencheur un evento para configurar un evento que hará que una persona entre en el recorrido.
Requisitos previos trigger-events-prerequisites
Como requisito previo, debe saber qué perfiles están marcados como perfiles de prueba en Adobe Experience Platform. De hecho, el modo de prueba solo permite estos perfiles en el recorrido.
El evento debe contener un ID. El ID esperado depende de la configuración del evento. Puede ser un ECID o una dirección de correo electrónico, por ejemplo. El valor de esta clave debe agregarse en el campo Identificador de perfil.
El valor Identificador de perfil debe coincidir exactamente con la identidad almacenada en el esquema de eventos. El formato utilizado para hacer referencia a una identidad en la carga útil de evento es el siguiente:
@{<EventName>.identityMap.entry('<NamespaceName>').first().id}
Reemplace <NamespaceName> con el área de nombres exactamente como se define en el esquema de evento (por ejemplo, Email o Phone). 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 el recorrido y no aparece ningún error en la interfaz de usuario. Si un perfil no aparece en los registros de prueba después de activar un evento, compruebe que el área de nombres del Identificador de perfil coincida exactamente con el área de nombres del esquema de evento.
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.
-
Cuando se almacena en déclencheur un evento en modo de prueba, se genera un evento real, lo que significa que también se producirá en otros recorridos que escuchen este evento.
-
Asegúrese de que cada evento en el modo de prueba se active en el orden correcto y dentro de la ventana de espera configurada. Por ejemplo, si hay una espera de 60 segundos, el segundo evento debe activarse solo después de que haya transcurrido esa espera de 60 segundos y antes de que caduque el límite de tiempo de espera.
Configuración de evento trigger-events-configuration
Si el recorrido contiene varios eventos, utilice el menú desplegable para seleccionar un evento. A continuación, configure para cada evento los campos pasados y la ejecución del envío del evento. La interfaz le ayuda a pasar la información correcta en la carga útil de evento y garantiza que el tipo de información sea correcto. El modo de prueba guarda los últimos parámetros utilizados en una sesión de prueba para su uso posterior.
La interfaz de le permite pasar parámetros de evento simples. Si desea pasar colecciones u otros objetos avanzados en el evento, puede seleccionar Vista de código para ver el código completo de la carga útil y modificarlo. Por ejemplo, puede copiar y pegar información de evento preparada por un usuario técnico.
Un usuario técnico también puede utilizar esta interfaz para componer cargas útiles de eventos y eventos de déclencheur sin tener que utilizar una herramienta de terceros.
Al hacer clic en el botón Enviar, comienza la prueba. La progresión del individuo en el recorrido se representa mediante un flujo visual. El camino se vuelve verde progresivamente a medida que el individuo se mueve a través del recorrido. Si se produce un error, se muestra un símbolo de advertencia en el paso correspondiente. Puede colocar el cursor sobre él para mostrar más información sobre el error y acceder a los detalles completos (cuando estén disponibles).
Cuando se selecciona un perfil de prueba diferente en la pantalla de configuración de evento y se vuelve a ejecutar la prueba, el flujo visual se borra y muestra la ruta del nuevo individuo.
Al abrir un recorrido en prueba, la ruta mostrada corresponde a la última prueba ejecutada.
Modo de prueba para recorridos basados en reglas test-rule-based
El modo de prueba también está disponible para recorridos que utilizan un evento basado en reglas. Para obtener más información sobre los eventos basados en reglas, consulte esta página.
Al activar un evento, la pantalla Configuración de evento le permite definir los parámetros de evento que se pasarán en la prueba. Para ver la condición de ID de evento, haga clic en el icono de información de objeto en la esquina superior derecha. También hay disponible información del objeto junto a cada campo que forma parte de la evaluación de reglas.
Modo de prueba para eventos empresariales test-business
Cuando use evento empresarial, use el modo de prueba para almacenar en déclencheur una sola entrada de perfil de prueba en la recorrido, simular el evento y pasar el id. de perfil correcto. Debe pasar los parámetros de evento y el identificador del perfil de prueba que va a introducir el recorrido en la prueba. En el modo de prueba, no hay ningún modo de “Vista de código” disponible para los recorridos basados en eventos empresariales.
Tenga en cuenta que cuando se déclencheur un evento empresarial por primera vez, no se puede cambiar la definición de evento empresarial en la misma sesión de prueba. Solo puede hacer que la misma persona o una persona diferente entren en el recorrido pasando el mismo identificador u otro. Si desea cambiar los parámetros de evento empresarial, debe detener e iniciar de nuevo el modo de prueba.
Ver registros viewing_logs
El botón Mostrar registro le permite ver los resultados de la prueba. Esta página muestra la información actual del recorrido en formato JSON. Un botón permite copiar nodos completos. Debe actualizar manualmente la página para actualizar los resultados de la prueba del recorrido.
Se muestra el número de individuos (técnicamente denominados instancias) que están actualmente dentro del recorrido. Se muestra la siguiente información para cada individuo:
- Id: el ID interno del individuo en la recorrido. Se puede utilizar con fines de depuración.
- currentstep: el paso en el que se encuentra el individuo en el recorrido. Recomendamos añadir etiquetas a las actividades para identificarlas más fácilmente.
- currentstep > phase: el estado del recorrido del individuo (en ejecución, finalizado, error o tiempo de espera agotado). Consulte a continuación para obtener más información.
- currentstep > extraInfo: descripción del error y otra información contextual.
- currentstep > fetchErrors: información sobre errores de datos de recuperación que se produjeron durante este paso.
- externalKeys: el valor de la fórmula clave definida en el evento.
- richData: los datos que el recorrido ha recuperado si el recorrido usa orígenes de datos.
- transitionHistory: la lista de pasos que siguió el individuo. Para los eventos, se muestra la carga útil.
- actionExecutionErrors : información sobre los errores que se produjeron.
Estos son los diferentes estados del recorrido de un individuo:
- En ejecución: el individuo se encuentra actualmente en el recorrido.
- Finalizado: el individuo se encuentra al final del recorrido.
- Error: el individuo se detuvo en el recorrido debido a un error.
- Se agotó el tiempo de espera: el individuo se detuvo en el recorrido debido a un paso que tomó demasiado tiempo.
Cuando se activa un evento con el modo de prueba, se genera automáticamente un conjunto de datos con el nombre del origen.
El modo de prueba crea automáticamente un Evento de experiencia y lo envía a Adobe Experience Platform. El nombre de la fuente para este evento de experiencia es “Eventos de prueba de Journey Orchestration”.
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 explains how to use Test mode in Adobe Journey Optimizer to validate a journey with persistent test profiles before publishing, including activating test mode, triggering events, reading logs, and handling business and rule-based events.
Intents:
- Activate Test mode on a draft journey to validate it with pre-existing AEP test profiles
- Configure and trigger events for test profiles using the Trigger an event interface
- Override Wait activity durations in test mode to accelerate journey progression
- Read and interpret the Show log JSON output to verify profile progression and identify errors
- Test rule-based journeys and business event journeys in test mode
- Understand the limitations and behavioral differences of Test mode compared to Simulation
Glossary:
- Test mode: A journey validation state that allows persistent AEP test profiles to traverse a draft journey before it is published (product-specific)
- Test profiles: Profiles explicitly flagged as test profiles in the Adobe Experience Platform Real-time Customer Profile Service; the only profile type permitted to enter a journey in test mode (product-specific)
- Visual flow: The canvas representation that turns green to show the path a test profile has followed through the journey
- Show log: A test mode feature that displays journey execution state in JSON format for each test profile instance (product-specific)
- Journey Orchestration Test Events: The source name under which test mode experience events are stored in Adobe Experience Platform
Guardrails:
- Only profiles flagged as test profiles in AEP can enter a journey in test mode
- Test mode requires the journey to use a namespace to verify test profile identity
- Maximum 100 test profiles per single test session
- Events can only be triggered from the test mode UI; external API triggering is not supported
- Custom upload audience attribute enrichment is not supported in test mode
- Events triggered in Test mode generate real experience events that can also trigger other journeys listening to the same event
- In Test mode, Wait activities and most event timeouts default to 10 seconds; Reaction event timeouts default to a minimum of 40 seconds
- Automatic deactivation — Journeys that remain inactive in test mode for over a week automatically exit test mode and return to Draft status. No journey content is lost; only the test mode session ends.
- Journey edits are blocked while test mode is active, but direct publishing is allowed
- At a split, the top branch is always selected; reorder branches to test different paths
- Reaction event timeout minimum and default wait time is 40 seconds
- Events sent outside the journey’s configured start/end date window are silently discarded
- Disabling test mode removes all profiles from the journey and clears reporting
Terminology:
- Canonical name: Test mode — Acronym: none — variants: test mode, journey test mode
- Canonical name: Test profiles — Acronym: none — variants: test users (Simulation UI label only)
- Synonyms: “Show log” = test results log; “visual flow” = canvas path visualization
- Do not confuse: “Test mode” ≠ “Simulation” — Test mode uses persistent AEP test profiles; Simulation uses temporary simulated users generated on the fly
FAQ:
- Q: Who can enter a journey in test mode? — Only profiles explicitly flagged as test profiles in the Adobe Experience Platform Real-time Customer Profile Service.
- Q: How many test profiles can run in a single test session? — A maximum of 100 test profiles per test session.
- Q: What happens when I disable test mode? — All profiles currently in or previously entered in the journey are removed and reporting is cleared.
- Q: Can I edit a journey while test mode is active? — No. The journey cannot be modified while test mode is active, but you can publish it directly without deactivating test mode first.
- Q: Why are my test events being silently discarded? — Events triggered outside the journey’s configured active date/time window are silently discarded. Verify the journey start and end dates include the current time.
- Q: What does the phase field in the test log indicate? — It shows the profile’s current status: running (active in journey), finished (reached end), error (stopped due to error), or timed out (stopped due to timeout).