等待活動 wait-activity

在此頁面上:​瞭解如何設定「等待」活動,讓路徑暫停相對期間或直到自訂計算日期為止,再執行下一個活動。

您可以使用​ 等待 ​活動,在執行下一個活動之前定義持續時間。 等待持續時間上限為​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