En esta página: Aprenda a configurar la actividad Espera para pausar una ruta durante un tiempo relativo o hasta una fecha calculada personalizada antes de que se ejecute la siguiente actividad.
Puede usar una actividad Wait para definir una duración antes de ejecutar la siguiente actividad. La duración máxima de espera es de 90 días.
Puede establecer tres tipos de actividad Wait:
- Una espera basada en una duración relativa. Más información
- Una fecha personalizada, con funciones para calcularla. Más información
- Una espera de optimización del tiempo de envío. Más información
Recomendaciones wait-recommendations
Utilice estas recomendaciones para mantener las esperas predecibles y seguras.
Varias actividades de espera multiple-wait-activities
Cuando use varias actividades Wait en un recorrido, tenga en cuenta que el tiempo de espera global para recorridos es de 91 días, lo que significa que los perfiles siempre abandonan el máximo de recorrido 91 días después de que ingresaron al mismo. Obtenga más información en esta página.
Un individuo puede ingresar a una actividad Wait solo si le queda tiempo suficiente en el recorrido para completar la espera antes del tiempo de espera de 91 días.
Espera y reentrada wait-reentrance
Una práctica recomendada es no usar las actividades Wait para bloquear la reentrada. En su lugar, use la opción Permitir la reentrada en el nivel de propiedades de recorrido. Obtenga más información en esta página.
Modo de espera y prueba wait-test-mode
En el modo de prueba, el parámetro Tiempo de espera en prueba le permite definir el tiempo que durará cada actividad de Wait. El tiempo predeterminado es 10 segundos. Esto garantizará que obtenga los resultados de la prueba rápidamente. Obtenga más información en esta página.
Canales de espera y móviles wait-mobile-channels
Si desea mostrar un mensaje en la aplicación poco después de enviar una notificación push, use una actividad de Espera para permitir que se propague el tiempo de carga del mensaje en la aplicación. Normalmente se recomienda una espera de 5 a 15 minutos, pero los tiempos exactos pueden variar según la complejidad de la carga útil y las necesidades de personalización.
Configuración wait-configuration
Configure la duración y el tiempo de espera aquí.
Duración de espera duration
Seleccione el tipo Duration para establecer la duración relativa de la espera antes de la ejecución de la siguiente actividad. La duración máxima es de 90 días.
Espera personalizada custom
Seleccione el tipo Custom para definir una fecha personalizada, usando una expresión avanzada basada en un campo proveniente de un evento o una respuesta de acción personalizada. No puede definir una duración relativa directamente, por ejemplo, 7 días, pero puede utilizar funciones para calcularla si es necesario (p. ej.: 2 días después de la compra).
La expresión en el editor debe proporcionar un formato dateTimeOnly. Consulte esta página. Para obtener más información sobre el formato dateTimeOnly, consulte esta página.
Una práctica recomendada es utilizar fechas personalizadas específicas para los perfiles y evitar utilizar la misma fecha para todos. Por ejemplo, no defina toDateTimeOnly('2024-01-01T01:11:00Z'), sino toDateTimeOnly(@event{Event.productDeliveryDate}), que es específico de cada perfil. Tenga en cuenta que el uso de fechas fijas puede causar problemas en la ejecución del recorrido. Obtenga más información acerca del impacto de las actividades de espera en la tasa de procesamiento de recorrido en esta sección.
dateTimeOnly, tenga en cuenta lo siguiente:- Puede utilizar una expresión
dateTimeOnlydirectamente o convertirla a ella mediante una función, por ejemplo:toDateTimeOnly(@event{Event.offerOpened.activity.endTime}), donde el valor del campo está en el formulario2023-08-12T09:46:06Z. - La zona horaria está definida en las propiedades del recorrido. Como resultado, desde la interfaz de usuario no es posible señalar una marca de tiempo ISO-8601 completa que combine el desplazamiento de hora y zona horaria, como
2023-08-12T09:46:06.982-05. Más información - Al crear una expresión de espera personalizada con
toDateTimeOnly(), haga not anexarZo un desplazamiento de zona horaria (por ejemplo,-05:00). La expresión debe hacer referencia a la zona horaria configurada del recorrido sin indicadores de zona horaria explícitos; de lo contrario, los perfiles pueden quedarse atascados en la actividad de espera.
| table 0-row-2 1-row-2 2-row-2 | |
|---|---|
| Ejemplo | |
| Correcto | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00")) |
| Incorrecto | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00Z")) ❌ (contiene Z) |
Para validar que la actividad de espera funciona según lo esperado, puede utilizar eventos de paso. Más información.
Espera de optimización del tiempo de envío sto-wait
Seleccione el tipo Optimización del tiempo de envío para permitir que la IA de Adobe determine el tiempo óptimo para continuar con la siguiente actividad de la ruta, según el comportamiento de participación predicho de cada perfil. Utiliza el mismo modelo de optimización del tiempo de envío Send-Time que las acciones de correo electrónico y push, pero desvincula la espera del propio envío. La actividad que sigue a la espera puede ser cualquier actividad, como una acción personalizada, en lugar de estar vinculada únicamente a una acción de correo electrónico o push.
Actualización de perfil tras esperar profile-refresh
Cuando un perfil está estacionado en una actividad Wait en un recorrido que comienza con una actividad Read Audience, el recorrido actualiza automáticamente los atributos del perfil desde el servicio Unified Profile Service (UPS) para recuperar los datos disponibles más recientes.
- En la entrada de recorrido: los perfiles utilizan valores de atributo de la instantánea de audiencia que se evaluó cuando se inició el recorrido.
- Después de un nodo de espera: el recorrido realiza una búsqueda para recuperar los datos de perfil más recientes de UPS, no los datos de instantánea más antiguos. Esto significa que los atributos del perfil pueden haber cambiado desde que comenzó el recorrido.
Este comportamiento garantiza que las actividades descendentes utilicen la información de perfil actual después de un periodo de espera. Sin embargo, puede producir resultados inesperados si espera que el recorrido utilice únicamente los datos de instantánea originales durante la ejecución.
Ejemplo: Si un perfil se califica para una audiencia de “cliente plata” al inicio del recorrido, pero se actualiza a “cliente oro” durante una espera de 3 días, las actividades posteriores a la espera verán el estado actualizado de “cliente oro”.
Nodo de espera automático auto-wait-node
Cada actividad de experiencia entrante (mensaje en la aplicación, experiencia basada en código o tarjeta) viene con una actividad de Espera de 3 días. Como los mensajes entrantes finalizan automáticamente cuando un perfil llega al final del recorrido, suponemos que desea que los usuarios lo vean al menos durante 3 días. Puede quitar esta actividad Wait o cambiar su configuración si es necesario.
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 configure the Wait activity in a journey to pause profile progression for a relative duration or until a custom calculated date before executing the next step.
Intents:
- Add a Wait activity to pause a journey for a fixed relative duration (up to 90 days)
- Configure a custom Wait using an advanced expression to delay until a profile-specific calculated date
- Understand how Wait activities interact with the journey global timeout (91 days)
- Use the Wait time in test parameter to speed up test mode validation
- Understand how profile attributes are refreshed after a Wait node in Read Audience journeys
- Use Send-Time Optimization within a Wait activity to determine the optimal time before continuing to any downstream activity
Glossary:
- Wait activity: A journey orchestration activity that pauses profile progression for a specified duration or until a calculated date before the next activity executes (product-specific)
- Duration wait: A Wait type that sets a relative time period to pause, with a maximum of 90 days (product-specific)
- Custom wait: A Wait type that uses a
dateTimeOnlyexpression derived from profile or event data to define a specific future date/time for resumption (product-specific) - Send-time optimization wait: A Wait type that uses Adobe’s Send-Time Optimization AI model to select the optimal time to continue to the next activity, decoupled from any message send (product-specific)
- Automatic wait node: A 3-day Wait activity automatically inserted after inbound experience activities (In-app, Code-based, Card) to keep the profile in the journey long enough to view the content (product-specific)
- Wait time in test: A journey test mode parameter that overrides actual wait durations (default 10 seconds) so test results are returned quickly (product-specific)
Guardrails:
- The maximum wait duration is 90 days.
- Profiles are dropped from a journey after 91 days (global timeout), regardless of pending wait activities.
- A profile can only enter a Wait activity if enough time remains in the journey to complete the wait before the 91-day timeout.
- Do not use Wait activities to block reentrance; use the Allow reentrance option in journey properties instead.
- Custom wait expressions must use
dateTimeOnlyformat and must not include aZsuffix or explicit time zone offset. - Using a fixed static date (e.g.,
toDateTimeOnly('2024-01-01T01:11:00Z')) in a custom wait can cause issues; use profile-specific dynamic dates instead. - Profile attributes are refreshed from the Unified Profile Service after a wait node in Read Audience journeys, which may produce unexpected results if snapshot consistency is expected.
- Send-Time Optimization within a Wait activity has no visibility into quiet hours rules; if a downstream channel action is protected by a quiet hours rule set to discard messages, the profile can be removed from the message delivery and exited from the journey.
Terminology:
- Canonical name: Wait activity — Acronym: none — variants: Wait node, wait step
- Synonyms: “Duration wait” = “relative wait”; “Custom wait” = “expression-based wait”
- Do not confuse: “Duration wait” (relative, e.g. 3 days from now) ≠ “Custom wait” (absolute calculated date from profile data)
FAQ:
- Q: What is the maximum duration for a Wait activity? — The maximum wait duration is 90 days; profiles are also subject to the 91-day global journey timeout.
- Q: How does test mode handle Wait activities? — In test mode, the “Wait time in test” parameter overrides the actual wait duration; the default is 10 seconds so tests complete quickly.
- Q: Why should I avoid appending Z to a custom wait expression? — Adding Z or a time zone offset to a
toDateTimeOnly()expression can cause profiles to get stuck in the wait activity; the expression must rely on the journey’s configured time zone. - Q: Are profile attributes updated after a Wait node? — Yes, in journeys starting with Read Audience, the journey refreshes profile attributes from the Unified Profile Service after the wait, so downstream activities may see updated values rather than the original audience snapshot data.
- Q: What is the automatic wait node? — A 3-day Wait activity automatically inserted after inbound experience activities (In-app, Code-based, Card) to ensure profiles remain in the journey long enough to see the message; it can be removed or reconfigured as needed.
- Q: Does the Send-Time Optimization Wait activity know about quiet hours? — No. Quiet hours are only evaluated at the message action, so the Wait activity can pick a time inside a quiet-hours window. Depending on the quiet hours rule, the message is then queued until quiet hours end, or discarded, which also exits the profile from the journey.