Nesta página: saiba como configurar a atividade de espera para pausar um caminho por uma duração relativa ou até uma data calculada personalizada antes da execução da próxima atividade.
Você pode usar uma atividade Wait para definir uma duração antes de executar a próxima atividade. A duração máxima de espera é de 90 dias.
Você pode definir três tipos de atividade Aguardar:
- Uma espera com base em uma duração relativa. Saiba mais
- Uma data personalizada, usando funções para calculá-la. Saiba mais
- Uma espera de otimização de tempo de envio. Saiba mais
Recomendações wait-recommendations
Use essas recomendações para manter as esperas previsíveis e seguras.
Várias atividades de espera multiple-wait-activities
Ao usar várias atividades Wait em uma jornada, esteja ciente de que o tempo limite global para jornada é de 91 dias, o que significa que os perfis estão sempre saindo do máximo da jornada 91 dias após terem inserido. Saiba mais nesta página.
Um indivíduo só poderá inserir uma atividade Aguardar se tiver tempo suficiente na jornada para concluir a duração da espera antes do tempo limite de jornada de 91 dias.
Espera e reentrada wait-reentrance
Uma prática recomendada para não usar as atividades Aguardar para bloquear a reentrada. Em vez disso, use a opção Permitir reentrada no nível de propriedades da jornada. Saiba mais nesta página.
Modo de espera e teste wait-test-mode
No modo de teste, o parâmetro Tempo de espera em teste permite definir o tempo que cada atividade de Espera durará. O tempo padrão é de 10 segundos. Isso garantirá que você obtenha os resultados do teste rapidamente. Saiba mais nesta página.
Canais de espera e móveis wait-mobile-channels
Se você quiser mostrar uma mensagem no aplicativo logo após enviar uma notificação por push, use uma atividade Aguardar para permitir que o tempo de carga da mensagem no aplicativo seja propagado. Normalmente, recomenda-se uma espera de 5 a 15 minutos, mas os tempos exatos podem variar dependendo da complexidade da carga útil e das necessidades de personalização.
Configuração wait-configuration
Configure a duração e o tempo de espera aqui.
Espera de duração duration
Selecione o tipo Duration para definir a duração relativa da espera antes da execução da próxima atividade. A duração máxima é de 90 dias.
Espera personalizada custom
Selecione o tipo Personalizado para definir uma data personalizada, usando uma expressão avançada com base em um campo proveniente de um evento ou uma resposta de ação personalizada. Não é possível definir uma duração relativa diretamente, por exemplo, 7 dias, mas você pode usar funções para calculá-la se necessário (por exemplo: 2 dias após a compra).
A expressão no editor deve fornecer um formato dateTimeOnly. Consulte esta página. Para obter mais informações sobre o formato dateTimeOnly, consulte esta página.
A prática recomendada é usar datas personalizadas específicas para seus perfis e evitar o uso da mesma data para todos. Por exemplo, não defina toDateTimeOnly('2024-01-01T01:11:00Z'), mas sim toDateTimeOnly(@event{Event.productDeliveryDate}), que é específico para cada perfil. Esteja ciente de que o uso de datas fixas pode causar problemas na execução da jornada. Saiba mais sobre o impacto das atividades de espera na taxa de processamento da jornada em esta seção.
dateTimeOnly, lembre-se do seguinte:- Você pode usar uma expressão
dateTimeOnlydiretamente ou convertê-la usando uma função — por exemplo:toDateTimeOnly(@event{Event.offerOpened.activity.endTime})onde o valor do campo está no formato2023-08-12T09:46:06Z. - O fuso horário está definido nas propriedades da jornada. Como resultado, não é possível que a interface aponte para um carimbo de data e hora ISO-8601 completo que mescla deslocamento de hora e fuso horário, como
2023-08-12T09:46:06.982-05. Saiba mais - Ao criar uma expressão de espera personalizada com
toDateTimeOnly(), não anexeZou um deslocamento de fuso horário (por exemplo,-05:00). A expressão deve fazer referência ao fuso horário configurado pela jornada sem designadores de fuso horário explícitos; caso contrário, os perfis podem ficar presos na atividade de espera.
| table 0-row-2 1-row-2 2-row-2 | |
|---|---|
| Exemplo | |
| Correto | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00")) |
| Incorreto | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00Z")) ❌ (contém Z) |
Para validar se a atividade de espera funciona como esperado, você pode usar os eventos da etapa. Saiba mais.
Espera de otimização de tempo de envio sto-wait
Selecione o tipo de Otimização de tempo de envio para permitir que a IA da Adobe determine o momento ideal para continuar com a próxima atividade no caminho, com base no comportamento de envolvimento previsto de cada perfil. Isso usa o mesmo modelo de Otimização de tempo de envio que as ações de email e push, mas desvincula a espera do próprio envio. A atividade após a espera pode ser qualquer atividade, como uma ação Personalizada, em vez de estar vinculada apenas a uma ação de Email ou Push.
Atualização de perfil após espera profile-refresh
Quando um perfil é estacionado em uma atividade Wait em uma jornada que começa com uma atividade Read Audience, a jornada atualiza automaticamente os atributos do perfil no UPS (Serviço de Perfil Unificado) para buscar os dados mais recentes disponíveis.
- Na entrada da jornada: os perfis usam valores de atributo do instantâneo de público-alvo que foi avaliado quando a jornada foi iniciada.
- Após um nó de espera: a jornada executa uma pesquisa para recuperar os dados de perfil mais recentes do UPS, não os dados de instantâneo mais antigos. Isso significa que os atributos de perfil podem ter sido alterados desde o início da jornada.
Esse comportamento garante que as atividades downstream usem informações atuais do perfil após um período de espera. No entanto, poderá produzir resultados inesperados se você esperar que a jornada use apenas os dados do instantâneo original durante toda a execução.
Exemplo: se um perfil se qualificar para um público-alvo de “cliente Silver” no início da jornada, mas atualizar para “cliente Gold” durante uma espera de 3 dias, as atividades após a espera verão o status atualizado de “cliente Gold”.
Nó de espera automático auto-wait-node
Cada atividade de experiência de entrada (mensagem no aplicativo, experiência baseada em código ou Cartão) vem com uma atividade de Aguardar de 3 dias. Como as mensagens de entrada terminam automaticamente quando um perfil atinge o final da jornada, pressupomos que você deseje que seus usuários a vejam pelo menos por 3 dias. Você pode remover esta atividade Aguardar ou alterar sua configuração, se necessário.
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.