En esta página: Comparar simulación de Recorrido, modo de prueba de Recorrido y ejecución en seco de Recorrido. Aprenda cuál se adapta a la fase actual de creación de un recorrido, desde una iteración rápida durante el diseño hasta una comprobación final previa al lanzamiento en comparación con la audiencia en directo.
Adobe Journey Optimizer le ofrece tres formas de validar un recorrido antes de que se ponga en marcha. No son intercambiables: cada uno utiliza un tipo diferente de datos, se adapta a una fase diferente de la compilación y conlleva diferentes consecuencias en el mundo real. Comprender la diferencia por adelantado le ayuda a evitar dos errores comunes. La primera es dedicar tiempo a crear perfiles de prueba cuando lo haría una simulación rápida. La segunda es suponer que un paso de validación es completamente “seguro” cuando aún puede contactar bandejas de entrada reales o hacer llamadas salientes reales.
Esta página se centra en la validación del flujo de recorrido y la lógica de ramificación. Para obtener una imagen completa de las capacidades de prueba y aprobación, incluida la vista previa de contenido, el procesamiento de correo electrónico y las comprobaciones de correo no deseado, los experimentos A/B y los flujos de trabajo de aprobación, consulte Probar, validar y aprobar.
¿Es nuevo en validación? Empiece aquí quick-pick
Si no está seguro de qué método se aplica a usted, responda a esta pregunta:
- Todavía estoy diseñando mi recorrido y deseo validar rápidamente la lógica de una rama, sin crear perfiles de prueba. → Usar Simulación De Recorrido.
- Quiero validar manualmente la lógica de mi borrador de recorrido paso a paso, usando perfiles reales (pero designados como prueba). → Usar modo de prueba de Recorrido.
- Estoy a punto de publicar y deseo una comprobación final de los volúmenes esperados con respecto a mi audiencia de producción real, sin ponerme en contacto con nadie. → Usar Recorrido en seco.
¿Todavía no estás seguro, o quieres la imagen completa? Siga leyendo: cada método se explica en detalle a continuación.
Los tres métodos de validación validation-methods
Cuándo se debe usar: Iteración rápida durante el diseño del recorrido, especialmente justo antes de un plazo o al probar nuevas ramas o rutas. También funciona bien como método de validación continuo siempre que no resulta práctico crear un perfil de prueba adecuado para su caso de uso.
Simulación de Recorrido valida su recorrido con usuarios simulados temporales, sin necesidad de crear o esperar a que se propaguen los perfiles de prueba reales de Adobe Experience Platform (AEP). Puede crear usuarios simulados manualmente o permitir que AI genere automáticamente los eventos de prueba que necesita su recorrido y los asocie a los usuarios simulados adecuados, lo que activa el recorrido en segundos.
Mecánica clave:
- Los usuarios simulados no son perfiles reales en AEP; también puede guardarlos en el inventario para reutilizarlos en simulaciones futuras en lugar de crearlos desde cero cada vez.
- No se evalúan los criterios de salida, las políticas de consentimiento, la restricción de frecuencia/recorrido, la exclusión/supresión y las horas de inactividad.
- Las acciones personalizadas y las llamadas a fuentes de datos externas siguen realizando llamadas salientes reales, no se burlan de ellas.
| note important |
|---|
| IMPORTANT |
| La simulación envía mensajes reales a las direcciones de ejecución (correo electrónico, teléfono, token push) configuradas en los usuarios simulados; por ejemplo, su propia dirección de correo electrónico. Utiliza la misma canalización de entrega que la producción. No contacta con clientes reales ni actualiza datos de perfil en directo, pero los mensajes en sí son reales. |
Perfecto para: Validar una nueva rama (por ejemplo, dos nuevas rutas de directiva de decisión) sin esperar la propagación del perfil de prueba de AEP.
➡️ Introducción a la simulación de recorrido | Simular su recorrido
Cuándo se debe usar: Verificación manual de la rama y la lógica de mensaje paso a paso, con perfiles reales (pero designados como prueba) recorriendo el recorrido de borrador.
Modo de prueba de Recorrido le permite validar un recorrido de borrador usando perfiles de prueba de AEP persistentes. Para confirmar que la lógica de ramificación y la mecánica de envío de mensajes funcionan según lo diseñado antes de que cualquier audiencia de producción toque el recorrido, active los eventos manualmente desde la interfaz.
Mecánica clave:
- Solo los perfiles marcados como “perfiles de prueba” en el Perfil del cliente en tiempo real pueden introducir un recorrido en el modo de prueba de Recorrido.
- El modo de prueba de recorrido solo está disponible para recorridos de borrador que utilicen un espacio de nombres, ya que debe comprobar en AEP si una persona es un perfil de prueba.
- Un máximo de 100 perfiles de prueba pueden entrar en un recorrido durante una sola sesión de prueba y los eventos solo se pueden activar desde la interfaz, no desde sistemas externos a través de la API.
- Al deshabilitar el modo de prueba de Recorrido se eliminan todos los perfiles que ingresaron a la recorrido y se borran los informes.
| note important |
|---|
| IMPORTANT |
| El modo de prueba de recorrido envía mensajes reales a las bandejas de entrada reales de los perfiles de prueba, utilizando la misma canalización de entrega que la producción. No se pone en contacto con clientes reales, pero tampoco es una simulación "en seco": asegúrese de que los perfiles de prueba utilizan direcciones que controla. |
Problema: La creación y propagación de nuevos perfiles de prueba de AEP lleva tiempo. Simulación de Recorrido ofrece una alternativa rápida que no requiere ningún perfil de prueba. Resulta útil no solo mientras espera a que los perfiles se propaguen, sino que, en cualquier momento, la creación de un perfil de prueba adecuado para su caso de uso no es práctica.
Cuándo se debe usar: Una comprobación final y realista de la producción justo antes de publicar.
Ejecución en seco durante el Recorrido es un modo especial de publicación de recorrido que ejecuta el recorrido con datos de segmentación y audiencia de producción real, sin ponerse en contacto con clientes reales ni actualizar información de perfil. El recorrido se activa como un recorrido activo y los perfiles fluyen a través de ramas y nodos exactamente como lo harían en la producción. Sin embargo, se omiten nodos de acción, como correo electrónico, SMS y acciones personalizadas.
Mecánica clave:
- Utiliza la audiencia de producción real, para que vea el alcance real y la segmentación a escala (por ejemplo, detectar un error en el que una rama entera recibe inesperadamente cero perfiles).
- En cada activación, para recuperar las métricas más rápido puede deshabilitar las actividades de espera y, para mantener la recorrido en silo completo, puede deshabilitar las llamadas a fuentes de datos externas.
- Actualmente, esta es una característica de disponibilidad limitada que se está implementando globalmente a lo largo del tiempo.
Perfecto para: Detectar problemas como nodos de condición mal escritos o audiencias que inesperadamente no llegan a una rama, justo antes de activar la recorrido.
¿Qué método debería utilizar? decision-guide
Comience con una pregunta sencilla: ¿ya tiene perfiles de prueba que se ajusten a su caso de uso? Si es así, Modo de prueba de Recorrido le permite validar paso a paso con ellos. Si no, o si no es práctico crearlos para este caso de uso en particular, Simulación de Recorrido te validará en segundos.
Más allá de esta opción, la respuesta suele responder a una pregunta más: ¿hasta dónde se acerca la producción?
Si todavía está iterando en el diseño de recorrido — probando una rama nueva, comparando con un plazo — use Simulación de Recorrido. No necesita perfiles reales y se ejecuta en segundos. También sigue siendo una opción válida más adelante en la compilación, siempre que no sea práctico crear perfiles de prueba adecuados para el caso de uso. Recuerde que envía mensajes reales a las direcciones de ejecución configuradas en los usuarios simulados.
Si necesita comprobar manualmente la bifurcación y la lógica de mensajes paso a paso y desea crear o reutilizar perfiles de prueba de AEP, use Modo de prueba de Recorrido. Solo recuerde que envía mensajes reales a las bandejas de entrada reales de esos perfiles de prueba.
Si está a punto de publicar y desea una comprobación final de los volúmenes esperados con respecto a la audiencia de producción real, use Ejecución en seco del Recorrido. Nunca se pone en contacto con nadie ni cambia ningún dato de perfil.
Comparación rápida quick-comparison
Ninguno de estos métodos contacta con clientes reales. Los datos de perfil tampoco se tocan en todos los casos, excepto en que el modo de prueba de Recorrido actualiza los perfiles de prueba utilizados para ejecutarlos (no los perfiles reales del cliente).
Errores comunes que se deben evitar common-mistakes
- Suponiendo que la simulación de Recorrido es completamente “segura”. Es la forma más rápida de realizar pruebas, pero sigue enviando mensajes reales a la dirección de ejecución configurada en cada usuario simulado, normalmente en su propia bandeja de entrada. No suponga que no se envía nada.
- Creando perfiles de prueba de AEP cuando la simulación de Recorrido funcionaba. Si solo necesita validar una nueva rama o ruta de política de decisión rápidamente, la simulación omite la espera de la propagación del perfil de prueba por completo: el modo de prueba Guardar Recorrido para cuando realmente necesite perfiles de prueba reales.
- Tratando el modo de prueba de Recorrido como “seco”. Los perfiles del modo de prueba de recorrido reciben mensajes reales a través de la canalización de entrega de producción. Asegúrese de que los perfiles de prueba solo utilicen las direcciones que controla.
- Se espera que la ejecución en seco del Recorrido detecte problemas de contenido o envío. La ejecución en seco omite los nodos de acción por completo: valida el alcance de la audiencia y la lógica de rama, no el contenido del mensaje ni la mecánica de envío. Para ello, utilice el modo de simulación o el modo de prueba de Recorrido.
- Olvidando el requisito del área de nombres para el modo de prueba de Recorrido. El modo de prueba de recorrido solo funciona en recorridos de borrador que utilizan un área de nombres, ya que Journey Optimizer necesita un área de nombres para comprobar si un perfil está marcado como perfil de prueba.
Próximos pasos next-steps
- Introducción a la simulación de recorrido — Ejecute su primera simulación
- Probar el recorrido — Activar el modo de prueba de Recorrido con perfiles de prueba de AEP
- Ejecución en seco de Recorrido: ejecute una ejecución en seco realista para la producción
- Publicar su recorrido: Requisitos previos y proceso de publicación
- Introducción a recorrido: Información general sobre aspectos básicos y funcionalidades
- Preguntas frecuentes sobre Journey Orchestration — Preguntas frecuentes respondidas
- Probar, validar y aprobar: entorno de prueba y aprobación completo, que incluye vista previa de contenido, comprobaciones de procesamiento/correo no deseado, experimentos y flujos de trabajo de aprobación
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 compares the three journey validation methods in Adobe Journey Optimizer — Journey Simulation, Journey Test mode, and Journey Dry run. It provides a one-question quick pick, a decision guide, a quick-comparison table, and a list of common mistakes to help users choose the right one for their current stage of building a journey.
Intents:
- Choose the correct validation method for a given stage of journey building
- Compare Journey Simulation, Journey Test mode, and Journey Dry run side by side
- Understand when to use Journey Simulation for fast iteration without real test profiles
- Understand when to use Journey Test mode for step-by-step manual validation with real test profiles
- Understand when to use Journey Dry run for a final pre-launch check against production data
- Understand which validation methods send real messages or contact real customers
- Avoid common mistakes when picking or using a validation method
Glossary:
- Journey Simulation: A validation method that uses temporary simulated users, manually created or auto-generated, to test a journey without needing real AEP test profiles. (product-specific)
- Journey Test mode: A validation method that uses persistent AEP test profiles, flagged in Real-Time Customer Profile, to manually walk through a draft journey’s branch and message logic. (product-specific)
- Journey Dry run: A publication mode that runs a journey against real production audience data without contacting customers or updating profile data; action nodes are bypassed. (product-specific)
- Simulation Agent: The mechanism that automatically generates test events and matches them to simulated users during Journey Simulation. (product-specific)
Guardrails:
- Journey Test mode is only available for draft journeys that use a namespace, and supports a maximum of 100 test profiles per session
- Journey Test mode events can only be fired from the interface, not from external systems via API
- Journey Test mode sends real messages to test profiles’ real inboxes using the production delivery pipeline
- Disabling Journey Test mode removes all profiles that entered the journey and clears its reporting
- Journey Simulation does not evaluate exit criteria, consent policies, frequency/journey capping, opt-out/suppression, or quiet hours
- Journey Simulation’s custom actions and external data source calls are real, not mocked
- Journey Simulation sends real messages to the execution addresses (email, phone, push token) configured on the simulated users, using the same delivery pipeline as production
- Unlike Journey Simulation, Journey Dry run never sends real messages
- Journey Dry run is currently a Limited Availability feature, being rolled out globally over time
- Journey Dry run bypasses action nodes (email, SMS, custom actions) but still routes profiles through branches and nodes using real production data
Terminology:
- Canonical name: Journey Simulation — variants: simulate, simulation mode
- Canonical name: Journey Test mode — variants: Test mode, journey testing, test your journey
- Canonical name: Journey Dry run — variants: dry run, dry run mode
- Do not confuse: Journey Simulation (temporary simulated users, no AEP test profiles needed, sends real messages to the simulated users’ configured execution addresses) ≠ Journey Test mode (persistent AEP test profiles, sends real messages to those profiles’ real inboxes) ≠ Journey Dry run (real production audience data, no contact, no profile update, action nodes bypassed, never sends real messages)
FAQ:
- Q: Which validation method should I use while I am still designing a journey? — Use Journey Simulation; it needs no real test profiles and runs in seconds, making it ideal for fast iteration.
- Q: Does Journey Simulation send real messages? — Yes. Simulation delivers real messages to the execution addresses (email, phone, push token) configured on the simulated users, often the tester’s own address. It uses the same delivery pipeline as production, but it does not contact real customers or update live profile data.
- Q: Does Journey Test mode send real emails or SMS? — Yes. Journey Test mode delivers real messages to the actual inboxes of your test profiles, using the same delivery pipeline as production. It does not contact real customers, but the messages themselves are real.
- Q: Does Journey Dry run send any messages? — No. Dry run bypasses action nodes such as email, SMS, and custom actions, so profiles flow through the journey logic without any message being sent.
- Q: I need to validate a new branch quickly before a deadline. Which method fits? — Journey Simulation; it generates simulated users on demand (or reuses ones saved to the inventory) instead of requiring you to pre-create and wait for real test profiles.
- Q: Is Journey Dry run available to everyone? — It is currently a Limited Availability feature being rolled out globally over time; check availability for your organization.
- Q: Can I fire Journey Test mode events from an external system? — No; in Journey Test mode, events can only be fired from the interface, not from external systems via API.