等待活动 wait-activity

在此页面上:​了解如何将Wait活动配置为在相对持续时间或自定义计算日期之前暂停路径,直到下一次活动运行。

您可以使用​ 等待 ​活动定义持续时间,然后再执行下一个活动。 最长等待时间为​90天

您可以设置三种类型的​ 等待 ​活动:

推荐 wait-recommendations

使用这些建议可保持等待的可预测性和安全性。

多个等待活动 multiple-wait-activities

在历程中使用多个​ 等待 ​活动时,请注意,历程的全局超时为91天,这意味着用户档案始终在进入历程后91天内退出该历程。 请参阅此页面以了解详情。

仅当个人在历程中剩余的时间足以在91天历程超时之前完成等待持续时间时,个人才能进入​ 等待 ​活动。

等待并重新进入 wait-reentrance

不使用​ 等待 ​活动阻止重新进入的最佳实践。 请改用历程属性级别的​ 允许重入 ​选项。 请参阅此页面以了解详情。

等待和测试模式 wait-test-mode

在测试模式下,测试中的等待时间​参数允许您定义每个​ 等待 ​活动的持续时间。 默认时间为 10 秒。 这将确保您快速获得测试结果。 请参阅此页面以了解详情。

等待和移动渠道 wait-mobile-channels

如果要在发送推送通知后不久显示应用程序内消息,请使用​ 等待 ​活动以允许传播应用程序内消息有效负荷时间。 通常建议等待5-15分钟,但具体时间会因有效负载复杂性和个性化需求而异。

配置 wait-configuration

在此处配置等待时长和计时。

持续时间等待 duration

选择​ 持续时间 ​类型以设置下一个活动执行前等待的相对持续时间。 最长持续时间为​90天

定义等待持续时间

自定义等待 custom

选择​ 自定义 ​类型以使用基于来自事件或自定义操作响应的字段的高级表达式来定义自定义日期。 您不能直接定义相对持续时间,例如7天,但您可以根据需要使用函数计算相对持续时间(例如:购买后2天)。

使用表达式定义自定义等待

编辑器中的表达式应提供dateTimeOnly格式。 请参见此页面。 有关dateTimeOnly格式的详细信息,请参阅此页面

最佳实践是使用特定于您用户档案的自定义日期,并避免对所有用户使用相同的日期。 例如,不要定义toDateTimeOnly('2024-01-01T01:11:00Z'),而是要定义特定于每个配置文件的toDateTimeOnly(@event{Event.productDeliveryDate})。 请注意,使用固定日期可能会导致历程执行出现问题。 在本节中进一步了解等待活动对历程处理率的影响。

CAUTION
使用dateTimeOnly表达式时,请牢记以下几点:
  • 您可以直接使用dateTimeOnly表达式,或使用函数转换为该表达式 — 例如: toDateTimeOnly(@event{Event.offerOpened.activity.endTime}),其中字段值采用2023-08-12T09:46:06Z格式。
  • 在历程属性中定义​时区。 因此,从UI无法指向混合了时间和时区偏移的完整ISO-8601时间戳,例如2023-08-12T09:46:06.982-05了解详情
  • 使用toDateTimeOnly()生成自定义等待表达式时,​附加Z或时区偏移(例如,-05:00)。 表达式必须引用历程配置的时区,且不能使用明确的时区指示器,否则配置文件可能会卡在等待活动中。
table 0-row-2 1-row-2 2-row-2
示例
正确 toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00"))
不正确 toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00Z")) ❌ (包含Z

要验证等待活动是否按预期运行,您可以使用步骤事件。 了解详情

发送时间优化等待 sto-wait

定义等待持续时间

选择​ 发送时间优化 ​类型,以让Adobe的AI根据每个用户档案的预测参与行为确定继续路径中下一个活动的最佳时间。 这会使用与电子邮件和推送操作相同的发送时间优化模型,但会将等待与发送本身分离。 等待后的活动可以是任何活动,例如自定义操作,而不是仅与电子邮件或推送操作相关联。

了解发送时间优化如何工作以及如何为您的组织启用该优化的详细信息

IMPORTANT
发送时间优化无法查看安静时间规则。 仅当配置文件达到​ 消息 ​操作时才会评估安静时间,因此发送时间优化等待活动可以选择处于下游渠道操作的安静时间窗口内的最佳时间。 冲突仅在稍后发送消息时显示。

等待后配置文件刷新 profile-refresh

当配置文件驻留在以​ 读取受众 ​活动开始的历程中的​ 等待 ​活动时,该历程会自动从统一配置文件服务(UPS)中刷新配置文件的属性,以获取最新可用数据。

  • 在历程条目:配置文件使用历程启动时计算的受众快照中的属性值。
  • 在等待节点之后:历程执行查找以从UPS检索最新的配置文件数据,而不是旧的快照数据。 这意味着自历程开始以来,配置文件属性可能已更改。

此行为可确保下游活动在等待时段后使用当前配置文件信息。 但是,如果您希望历程在整个执行过程中仅使用原始快照数据,则可能会产生意外结果。

示例:如果配置文件在历程开始时符合“银级客户”受众的条件,但在3天等待期间升级到“金级客户”,则等待后的活动将看到更新的“金级客户”状态。

自动等待节点 auto-wait-node

每个入站体验活动(应用程序内消息、基于代码的体验或卡片)都包含3天​ 等待 ​活动。 当用户档案到达历程终点时,入站消息会自动结束,因此我们假定您希望用户至少在3天内看到该消息。 您可以删除此​ 等待 ​活动,或者根据需要更改其配置。

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 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 dateTimeOnly expression 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 dateTimeOnly format and must not include a Z suffix 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.
recommendation-more-help
journey-optimizer-help