このページ：では、次のアクティビティが実行される前に、相対期間またはカスタムの計算日までパスを一時停止するように待機アクティビティを設定する方法を説明します。
待機アクティビティを使用すると、次のアクティビティを実行するまでの期間を定義できます。 最大の待機期間は 90 日です。
3種類の待機 アクティビティを設定できます。
レコメンデーション wait-recommendations
予測可能かつ安全な待機を維持するために、これらの推奨事項を使用してください。
複数の待機アクティビティ multiple-wait-activities
ジャーニーのグローバルタイムアウトが 91 日なので（つまり、プロファイルはジャーニーにエントリしてから最大 91 日後に必ずジャーニーからドロップアウトするので）、1 つのジャーニーで複数の 待機 アクティビティを使用する場合は注意が必要です。 詳しくは、このページを参照してください。
個人が 待機 アクティビティにエントリできるのは、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}) を定義します。 固定日付を使用すると、ジャーニーの実行に問題が生じる可能性があります。 待機アクティビティがジャーニーの処理率に与える影響について詳しくは、この節を参照してください。
dateTimeOnly式を使用する場合は、次の点に注意してください。dateTimeOnly式を直接使用するか、関数を使用して変換できます。例：toDateTimeOnly(@event{Event.offerOpened.activity.endTime})。フィールド値は2023-08-12T09:46:06Z形式です。- タイムゾーンは、ジャーニープロパティで定義されています。 その結果、時間とタイムゾーンのオフセットを組み合わせた完全なISO-8601 タイムスタンプ（
2023-08-12T09:46:06.982-05など）をUIからポイントすることはできません。 詳細情報 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
Send-Time Optimization タイプを選択すると、各プロファイルの予測エンゲージメント動作に基づいて、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.