이 페이지에서: 상대 기간 동안 또는 다음 활동이 실행되기 전에 사용자 지정 계산된 날짜까지 경로를 일시 중지하도록 대기 활동을 구성하는 방법에 대해 알아봅니다.
다음 활동을 실행하기 전에 대기 활동을 사용하여 기간을 정의할 수 있습니다. 최대 대기 기간은 90일입니다.
다음 세 가지 유형의 대기 활동을 설정할 수 있습니다.
추천 wait-recommendations
이러한 권장 사항을 사용하여 기다림을 예측 가능하고 안전하게 유지합니다.
여러 대기 활동 multiple-wait-activities
여정에서 여러 대기 활동을 사용하는 경우 여정의 전역 시간 초과가 91일이므로 프로필이 입력한 후 항상 최대 91일 후에 여정에서 삭제됩니다. 이 페이지에서 자세히 알아보십시오.
개인은 91일 여정 제한 시간 전에 대기 기간을 완료할 수 있는 충분한 시간이 여정에 남아 있는 경우에만 대기 활동을 입력할 수 있습니다.
대기 및 재입장 wait-reentrance
대기 활동을 사용하여 다시 시작을 차단하지 않는 것이 좋습니다. 대신 여정 속성 수준에서 재입력 허용 옵션을 사용하십시오. 이 페이지에서 자세히 알아보십시오.
대기 및 테스트 모드 wait-test-mode
테스트 모드에서 테스트의 대기 시간 매개 변수를 사용하면 각 대기 활동이 지속되는 시간을 정의할 수 있습니다. 기본 시간은 10초입니다. 이렇게 하면 테스트 결과를 빠르게 얻을 수 있습니다. 이 페이지에서 자세히 알아보십시오.
대기 및 모바일 채널 wait-mobile-channels
푸시 알림을 보낸 직후 인앱 메시지를 표시하려면 대기 활동을 사용하여 인앱 메시지 페이로드 시간을 전파하도록 허용하십시오. 일반적으로 5~15분 정도 기다리는 것이 좋지만 정확한 시간은 페이로드 복잡성과 개인화 요구 사항에 따라 달라질 수 있습니다.
구성 wait-configuration
여기에서 대기 기간 및 시간을 구성합니다.
기간 대기 duration
Duration 유형을 선택하여 다음 활동을 실행하기 전 대기 시간의 상대적 기간을 설정하십시오. 최대 기간은 90일입니다.
사용자 지정 대기 custom
이벤트에서 가져온 필드 또는 사용자 지정 작업 응답을 기반으로 하는 고급 식을 사용하여 사용자 지정 날짜를 정의하려면 Custom 유형을 선택하십시오. 상대적 기간(예: 7일)을 직접 정의할 수는 없지만, 필요한 경우 함수를 사용하여 계산할 수 있습니다(예: 구매 후 2일).
편집기의 식은 dateTimeOnly 형식을 제공해야 합니다. 이 페이지를 참조하십시오. dateTimeOnly 형식에 대한 자세한 내용은 이 페이지를 참조하세요.
가장 좋은 방법은 프로필에만 해당되는 사용자 지정 날짜를 사용하고 모든 항목에 동일한 날짜를 사용하지 않는 것입니다. 예를 들어 toDateTimeOnly('2024-01-01T01:11:00Z')을(를) 정의하지 않고 각 프로필에 해당하는 toDateTimeOnly(@event{Event.productDeliveryDate})을(를) 정의하십시오. 고정 날짜를 사용하면 여정 실행에 문제가 발생할 수 있습니다. 이 섹션에서 대기 활동이 여정 처리 속도에 미치는 영향에 대해 자세히 알아보세요.
dateTimeOnly 식을 사용하여 작업할 때는 다음 사항에 유의하십시오.dateTimeOnly식을 직접 사용하거나 함수를 사용하여 해당 식으로 변환할 수 있습니다(예:toDateTimeOnly(@event{Event.offerOpened.activity.endTime}). 여기서 필드 값은2023-08-12T09:46:06Z형식입니다).- 표준 시간대이(가) 여정 속성에 정의되어 있습니다. 따라서 UI에서 시간 및 시간대 오프셋을 혼합하는 전체 ISO-8601 타임스탬프(예:
2023-08-12T09:46:06.982-05)를 지정할 수 없습니다. 자세히 알아보기 toDateTimeOnly()을(를) 사용하여 사용자 지정 대기 식을 작성하는 경우 not하여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가 각 프로필의 예측된 참여 동작을 기반으로 경로의 다음 활동을 계속할 최적의 시간을 결정하도록 합니다. 이 작업에서는 이메일 및 푸시 작업과 동일한 전송 시간 최적화 모델을 사용하지만, 대기 시간을 전송 자체와 분리합니다. 대기 후에 수행되는 활동은 이메일 또는 푸시 작업에만 연결되지 않고, 사용자 지정 작업과 같은 임의의 활동일 수 있습니다.
전송 시간 최적화의 작동 방식과 조직에 대해 보내는 방법에 대해 자세히 알아보세요.
대기 후 프로필 새로 고침 profile-refresh
프로필이 대상자 읽기 활동으로 시작하는 여정의 대기 활동에 주차되어 있으면 여정은 UPS(통합 프로필 서비스)에서 프로필의 특성을 자동으로 새로 고쳐 사용 가능한 최신 데이터를 가져옵니다.
- 여정 항목에서: 프로필은 여정 시작 시 평가된 대상 스냅숏의 특성 값을 사용합니다.
- 대기 노드 이후: 여정이 조회를 수행하여 이전 스냅숏 데이터가 아닌 UPS에서 최신 프로필 데이터를 검색합니다. 즉, 여정이 시작된 후 프로필 속성이 변경되었을 수 있습니다.
이 비헤이비어는 다운스트림 활동이 대기 기간 후에 현재 프로필 정보를 사용하도록 합니다. 그러나 여정이 실행 전체에서 원본 스냅샷 데이터만 사용할 것으로 예상하면 예기치 않은 결과가 발생할 수 있습니다.
예: 여정 시작 시 프로필이 “실버 고객” 대상의 자격을 갖지만 3일 대기 동안 "골드 고객"으로 업그레이드하면 대기 후 활동에서 업데이트된 “골드 고객” 상태를 보게 됩니다.
자동 대기 노드 auto-wait-node
각 인바운드 경험 활동(인앱 메시지, 코드 기반 경험 또는 카드)에는 3일 대기 활동이 제공됩니다. 프로필이 여정 끝에 도달하면 인바운드 메시지가 자동으로 종료되므로 사용자가 적어도 3일 동안 이를 볼 수 있다고 가정합니다. 이 대기 활동을 제거하거나 필요한 경우 구성을 변경할 수 있습니다.
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.