Sur cette page : découvrez comment configurer l’activité Attente pour suspendre un chemin d’accès pendant une durée relative ou jusqu’à une date calculée personnalisée avant l’exécution de l’activité suivante.
Vous pouvez utiliser une activité Attente pour définir une durée avant l’exécution de l’activité suivante. La durée d’attente maximale est de 90 jours.
Vous pouvez définir trois types d’activités Attente :
- Attente en fonction d’une durée relative. En savoir plus
- Date personnalisée, avec des fonctions pour la calculer. En savoir plus
- Une attente d’optimisation de l’heure d’envoi. En savoir plus
Recommandations wait-recommendations
Utilisez ces recommandations pour garantir la prévisibilité et la sécurité des attentes.
Activités Attente multiples multiple-wait-activities
Lorsque vous utilisez plusieurs activités Attente dans un parcours, gardez à l’esprit que le délai d’expiration global du parcours est de 91 jours, ce qui signifie qu’un profil quittera toujours le parcours au maximum 91 jours après y être entré. En savoir plus sur cette page.
Un individu ne peut rejoindre une activité Attente que s’il dispose de suffisamment de temps restant dans le parcours pour compléter la durée d’attente avant le délai d’expiration de 91 jours du parcours.
Attente et rentrée wait-reentrance
La bonne pratique est de ne pas utiliser d’activités Attente pour bloquer une rentrée. Utilisez plutôt l’option Autoriser la rentrée au niveau des propriétés du parcours. En savoir plus sur cette page.
Attente et mode test wait-test-mode
En mode test, le paramètre Durée d’attente en test vous permet de définir la durée de chaque activité Attente. La valeur par défaut est de 10 secondes. Vous obtiendrez ainsi rapidement les résultats du test. En savoir plus sur cette page.
Attente et canaux mobiles wait-mobile-channels
Si vous souhaitez afficher un message in-app peu après l’envoi d’une notification push, utilisez une activité Attente pour permettre à la payload du message in-app de se propager. En règle générale, une attente de 5 à 15 minutes est recommandée, mais les heures exactes peuvent varier en fonction de la complexité de la payload et des besoins de personnalisation.
Configuration wait-configuration
Configurez la durée et le minutage de l’attente ici.
Durée de l’attente duration
Sélectionnez le type de Durée pour définir la durée relative de l’attente avant l’exécution de l’activité suivante. La durée maximum est de 90 jours.
Attente personnalisée custom
Sélectionnez le type Personnalisée pour définir une date personnalisée à l’aide d’une expression avancée basée sur un champ provenant d’un événement ou d’une réponse d’action personnalisée. Vous ne pouvez pas définir directement une durée relative (par exemple, 7 jours) mais vous pouvez utiliser des fonctions pour la calculer si nécessaire (par exemple, 2 jours après l’achat).
L’expression figurant dans l’éditeur doit fournir un format dateTimeOnly. Consultez cette page. Pour plus d’informations sur le format dateTimeOnly, consultez cette page.
La bonne pratique consiste à utiliser des dates personnalisées spécifiques à vos profils, et d’éviter d’utiliser la même date pour tous les profils. Par exemple, ne définissez pas toDateTimeOnly('2024-01-01T01:11:00Z'), mais plutôt toDateTimeOnly(@event{Event.productDeliveryDate}), qui est spécifique à chaque profil. Gardez à l’esprit que l’utilisation de dates fixes peut entraîner des problèmes d’exécution de votre parcours. Découvrez l’impact des activités d’attente sur le taux de traitement des parcours dans cette section.
dateTimeOnly, tenez compte des points suivants :- Vous pouvez utiliser directement une expression de
dateTimeOnlyou effectuer une conversion à l’aide d’une fonction, par exemple :toDateTimeOnly(@event{Event.offerOpened.activity.endTime})où la valeur du champ se trouve dans le2023-08-12T09:46:06Zde formulaire. - Le fuseau horaire est défini dans les propriétés du parcours. Par conséquent, il n’est pas possible à partir de l’interface utilisateur de pointer vers un horodatage ISO-8601 complet qui combine l’heure et le décalage de fuseau horaire, tel que
2023-08-12T09:46:06.982-05. En savoir plus - Lors de la création d’une expression d’attente personnalisée avec
toDateTimeOnly(), n’ajoutez pas deZou de décalage de fuseau horaire (par exemple,-05:00). L’expression doit référencer le fuseau horaire configuré du parcours sans indicateurs de fuseau horaire explicites. Dans le cas contraire, les profils peuvent être bloqués dans l’activité d’attente.
| table 0-row-2 1-row-2 2-row-2 | |
|---|---|
| Exemple | |
| Correct | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00")) |
| Incorrect | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00Z")) ❌ (contient du Z) |
Pour vérifier que l’activité d’attente fonctionne comme prévu, vous pouvez utiliser des événements d’étape. En savoir plus.
Attente d’optimisation de l’heure d’envoi sto-wait
Sélectionnez le type Optimisation de l’heure d’envoi pour permettre à l’IA d’Adobe de déterminer le moment optimal pour passer à l’activité suivante dans le chemin, en fonction du comportement d’engagement prédit de chaque profil. Cette méthode utilise le même modèle optimisation de l’heure d’envoi que les actions E-mail et Push, mais découple l’attente de l’envoi lui-même. L’activité qui suit l’attente peut être n’importe quelle activité, telle qu’une action personnalisée, plutôt que d’être liée uniquement à une action E-mail ou Push.
Actualisation du profil après l’attente profile-refresh
Lorsqu’un profil est mis dans une activité Attente dans un parcours commençant par une activité Lecture d’audience, le parcours actualise automatiquement les attributs du profil à partir du service de profil unifié (UPS) pour récupérer les dernières données disponibles.
- À l’entrée du parcours : les profils utilisent des valeurs d’attribut de l’instantané d’audience qui a été évalué au démarrage du parcours.
- Après un nœud d’attente : le parcours effectue une recherche pour récupérer les dernières données de profil d’UPS, et non les anciennes données d’instantané. Cela signifie que les attributs de profil peuvent avoir changé depuis le début du parcours.
Ce comportement garantit que les activités en aval utilisent les informations de profil actuelles après une période d’attente. Cependant, cela peut produire des résultats inattendus si vous prévoyez que le parcours n’utilise que les données d’instantané d’origine pendant l’exécution.
Exemple : si un profil est qualifié pour une audience « client ou cliente Silver » au début du parcours, mais passe à « client ou cliente Gold » pendant une attente de 3 jours, les activités après l’attente verront le statut « client ou cliente Gold » mis à jour.
Nœud d’attente automatique auto-wait-node
Chaque activité d’expérience entrante (message in-app, expérience basée sur du code ou vignette) est fournie avec une activité Attente de 3 jours. Comme les messages entrants se terminent automatiquement lorsqu’un profil atteint la fin du parcours, nous supposons que vous souhaitez que vos utilisateurs et utilisatrices la voient pendant au moins 3 jours. Vous pouvez supprimer cette activité Attente ou modifier sa configuration si nécessaire.
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.