Auf dieser Seite Erfahren Sie, wie Sie die Warteaktivität so konfigurieren, dass sie einen Pfad für eine relative Dauer oder bis zu einem benutzerdefinierten berechneten Datum anhält, bevor die nächste Aktivität ausgeführt wird.
Mit einer Aktivität vom Typ Warten können Sie eine Dauer definieren, nach deren Ablauf die nächste Aktivität ausgeführt wird. Die maximale Wartezeit beträgt 90 Tage.
Sie können drei Arten von Warten-Aktivitäten festlegen:
- Eine Wartezeit basierend auf einer relativen Dauer. Weitere Informationen
- Ein benutzerdefiniertes Datum, das mithilfe von Funktionen berechnet wird. Weitere Informationen
- Wartezeit bei der Sendezeitoptimierung. Weitere Informationen
Recommendations wait-recommendations
Verwenden Sie diese Empfehlungen, um Wartezeiten vorhersehbar und sicher zu halten.
Mehrere Warteaktivitäten multiple-wait-activities
Achten Sie bei der Verwendung mehrerer Aktivitäten vom Typ Warten in einer Journey darauf, dass der globale Timeout für Journeys 91 Tage beträgt, d. h., Profile werden immer spätestens 91 Tage nach ihrem Eintritt aus der Journey ausgeschlossen. Weitere Informationen finden Sie auf dieser Seite.
Ein Kontakt kann nur dann eine Aktivität vom Typ Warten annehmen, wenn noch genügend Zeit bleibt, um die Wartezeit vor Ablauf des 91-tägigen Timeouts der Journey zu beenden.
Warten und erneuter Eintritt wait-reentrance
Eine Best Practice, um keine Aktivitäten vom Typ Warten zu verwenden, um den erneuten Eintritt zu blockieren. Verwenden Sie stattdessen die Option Erneuten Eintritt erlauben auf der Ebene der Journey-Eigenschaften. Weitere Informationen finden Sie auf dieser Seite.
Warten und Testmodus wait-test-mode
Im Testmodus können Sie mit dem Parameter Wartezeit im Test die Dauer jeder Aktivität vom Typ Warten festlegen. Der Standardwert ist 10 Sekunden. Dadurch erhalten Sie die Testergebnisse schnell. Weitere Informationen finden Sie auf dieser Seite.
Warte- und Mobile-Kanäle wait-mobile-channels
Wenn Sie eine In-App-Nachricht nach dem Versand einer Push-Benachrichtigung anzeigen möchten, verwenden Sie eine Aktivität Warten, damit die Payload-Zeit der In-App-Nachricht weitergegeben wird. Normalerweise wird eine Wartezeit von 5 bis 15 Minuten empfohlen. Die genauen Zeiten können jedoch je nach Payload-Komplexität und Personalisierungsanforderungen variieren.
Konfiguration wait-configuration
Hier Wartezeit und Timing konfigurieren.
Dauer der Wartezeit duration
Wählen Sie den Typ Dauer, um die relative Dauer der Wartezeit vor der Ausführung der nächsten Aktivität auszuwählen. Die maximale Wartezeit beträgt 90 Tage.
Benutzerdefinierte Wartezeit custom
Wählen Sie den Typ Benutzerdefiniert aus, um ein benutzerdefiniertes Datum zu definieren. Dabei verwenden Sie einen erweiterten Ausdruck, der auf einem von einem Ereignis oder einer benutzerdefinierten Aktion stammenden Feld basiert. Sie können eine relative Dauer nicht direkt definieren, z. B. 7 Tage, aber Sie können Funktionen verwenden, um sie bei Bedarf zu berechnen (z. B. 2 Tage nach Kauf).
Der Ausdruck im Editor sollte ein dateTimeOnly-Format aufweisen. Weitere Informationen finden Sie auf dieser Seite. Weitere Informationen zum Format „TimeOnly“ finden Sie auf dieser Seite.
Es empfiehlt sich, benutzerdefinierte Datumsangaben zu verwenden, die spezifisch für Ihre Profile sind, und zu vermeiden, dass für alle Profile dasselbe Datum verwendet wird. Definieren Sie beispielsweise nicht toDateTimeOnly('2024-01-01T01:11:00Z'), sondern toDateTimeOnly(@event{Event.productDeliveryDate}), was für jedes Profil spezifisch ist. Beachten Sie, dass die Verwendung von festen Datumsangaben Probleme bei der Ausführung der Journey verursachen kann. Weitere Informationen zur Auswirkung von Warteaktivitäten auf die Journey-Verarbeitungsrate finden Sie in diesem Abschnitt.
dateTimeOnly Ausdrücken Folgendes:- Sie können einen
dateTimeOnly-Ausdruck direkt verwenden oder ihn mithilfe einer Funktion in ihn konvertieren, z. B.toDateTimeOnly(@event{Event.offerOpened.activity.endTime}), wenn sich der Feldwert im2023-08-12T09:46:06Zbefindet. - Die Zeitzone wird in den Journey-Eigenschaften definiert. Daher ist es nicht möglich, von der Benutzeroberfläche aus auf einen vollständigen ISO-8601-Zeitstempel zu verweisen, der Zeit- und Zeitzonenversatz mischt, z. B.
2023-08-12T09:46:06.982-05. Weitere Informationen - Beim Erstellen eines benutzerdefinierten Warteausdrucks mit
toDateTimeOnly()dürfen Sie nichtZoder einen Zeitzonenversatz anhängen (z. B.-05:00). Der Ausdruck muss auf die konfigurierte Zeitzone der Journey ohne explizite Zeitzonenbezeichner verweisen, da andernfalls Profile in der Warteaktivität stecken bleiben können.
| table 0-row-2 1-row-2 2-row-2 | |
|---|---|
| Beispiel | |
| Richtig | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00")) |
| falsch | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00Z")) ❌ (enthält Z) |
Um zu überprüfen, ob die Warteaktivität erwartungsgemäß funktioniert, können Sie Schritt-Ereignisse verwenden. Weitere Informationen.
Optimierungswartezeit für den Versandzeitpunkt sto-wait
Wählen Sie den Sendezeitoptimierung-Typ aus, damit die KI von Adobe den optimalen Zeitpunkt für den Fortgang der nächsten Aktivität im Pfad basierend auf dem prognostizierten Interaktionsverhalten jedes Profils bestimmen kann. Hierbei wird dasselbe Modell Sendezeitoptimierung wie für die E-Mail- und Push-Aktionen verwendet, aber die Wartezeit wird vom Versand selbst entkoppelt. Die Aktivität, die der Wartezeit folgt, kann eine beliebige Aktivität sein, z. B. eine benutzerdefinierte Aktion, anstatt nur mit einer E-Mail- oder Push-Aktion verknüpft zu sein.
Profilaktualisierung nach Wartezeit profile-refresh
Wenn ein Profil bei einer Aktivität des Typs Warten in einer Journey geparkt wird, die mit einer Aktivität des Typs Zielgruppe lesen beginnt, aktualisiert die Journey automatisch die Profilattribute von Unified Profile Service (UPS), um die neuesten verfügbaren Daten abzurufen.
- Bei Journey-Eintritt: Profile verwenden Attributwerte aus dem Zielgruppen-Snapshot, der beim Starten der Journey ausgewertet wurde.
- Nach einem Warteknoten: Die Journey führt eine Suche durch, um die neuesten Profildaten von UPS abzurufen, nicht die älteren Snapshot-Daten. Dies bedeutet, dass sich die Profilattribute möglicherweise seit dem Beginn der Journey geändert haben.
Dadurch wird sichergestellt, dass nachgelagerte Aktivitäten nach einer Wartezeit aktuelle Profilinformationen verwenden. Dies kann jedoch zu unerwarteten Ergebnissen führen, wenn Sie davon ausgehen, dass die Journey während der gesamten Ausführung nur die Original-Snapshot-Daten verwendet.
Beispiel: Wenn sich ein Profil beim Journey-Start für eine Zielgruppe des Typs„Silber-Kundschaft“ qualifiziert, aber während einer 3-tägigen Wartezeit zu „Gold-Kundschaft“ aufsteigt, wird bei Aktivitäten nach der Wartezeit der aktualisierte Status „Gold-Kundschaft“ angezeigt.
Automatischer Warteknoten auto-wait-node
Jede Aktivität für eingehende Erlebnisse (In-App-Nachricht, Code-basiertes Erlebnis oder Karte) geht mit einer 3-tägigen Warteaktivität einher. Da eingehende Nachrichten automatisch enden, wenn ein Profil das Ende der Journey erreicht, ist davon auszugehen, dass Sie möchten, dass Ihre Benutzenden sie mindestens 3 Tage lang sehen. Sie können bei Bedarf diese Warteaktivität entfernen oder ihre Konfiguration ändern.
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.