In questa pagina: Scopri come configurare l’attività Attendi per sospendere un percorso per una durata relativa o fino a una data calcolata personalizzata prima dell’esecuzione dell’attività successiva.
Puoi utilizzare un’attività Wait per definire una durata prima di eseguire l’attività successiva. La durata massima di attesa è di 90 giorni.
È possibile impostare tre tipi di attività Attendi:
- Un’attesa basata su una durata relativa. Ulteriori informazioni
- Una data personalizzata, utilizzando le funzioni per calcolarla. Ulteriori informazioni
- Un’attesa di ottimizzazione dell’ora di invio. Ulteriori informazioni
Consigli wait-recommendations
Utilizza queste raccomandazioni per mantenere le attese prevedibili e sicure.
Attività di attesa multiple multiple-wait-activities
Quando utilizzi più attività Wait in un percorso, tieni presente che il timeout globale per i percorsi è di 91 giorni, il che significa che i profili vengono sempre eliminati dal massimo percorso 91 giorni dopo l’immissione. Ulteriori informazioni sono disponibili in questa pagina.
Una persona può accedere a un’attività Wait solo se nel percorso è rimasto abbastanza tempo per completare la durata dell’attesa prima del timeout di 91 percorsi.
Attendere e rientrare wait-reentrance
È consigliabile non utilizzare le attività Wait per bloccare il rientro. Utilizza invece l’opzione Consenti rientro a livello di proprietà del percorso. Ulteriori informazioni sono disponibili in questa pagina.
Modalità di attesa e test wait-test-mode
In modalità di test, il parametro Wait time in test (Tempo di attesa nel test) consente di definire la durata di ogni attività Wait. Il tempo predefinito è di 10 secondi. In questo modo potrai ottenere rapidamente i risultati del test. Ulteriori informazioni sono disponibili in questa pagina.
Canali attendi e mobili wait-mobile-channels
Se desideri visualizzare un messaggio in-app poco dopo aver inviato una notifica push, utilizza un’attività Attendi per consentire la propagazione del tempo di payload del messaggio in-app. In genere si consiglia un’attesa di 5-15 minuti, ma i tempi esatti possono variare a seconda della complessità del payload e delle esigenze di personalizzazione.
Configurazione wait-configuration
Configura qui la durata e il tempo di attesa.
Attesa durata duration
Selezionare il tipo Durata per impostare la durata relativa dell’attesa prima dell’esecuzione dell’attività successiva. La durata massima è di 90 giorni.
Attesa personalizzata custom
Seleziona il tipo Personalizzato per definire una data personalizzata, utilizzando un’espressione avanzata basata su un campo proveniente da un evento o una risposta a un’azione personalizzata. Non è possibile definire direttamente una durata relativa, ad esempio 7 giorni, ma è possibile utilizzare le funzioni per calcolarla se necessario (ad esempio, 2 giorni dopo l’acquisto).
L’espressione nell’editor deve fornire un formato dateTimeOnly. Consulta questa pagina. Per ulteriori informazioni sul formato dateTimeOnly, vedere questa pagina.
Si consiglia di utilizzare date personalizzate specifiche per i profili ed evitare di utilizzare la stessa data per tutti. Ad esempio, non definire toDateTimeOnly('2024-01-01T01:11:00Z'), ma toDateTimeOnly(@event{Event.productDeliveryDate}) specifico per ciascun profilo. Tieni presente che l’utilizzo di date fisse può causare problemi nell’esecuzione del percorso. Ulteriori informazioni sull’impatto delle attività Attendi sulla velocità di elaborazione del percorso in questa sezione.
dateTimeOnly, tenere presente quanto segue:- È possibile utilizzare direttamente un'espressione
dateTimeOnlyo convertirla utilizzando una funzione, ad esempio:toDateTimeOnly(@event{Event.offerOpened.activity.endTime})dove il valore del campo è nel formato2023-08-12T09:46:06Z. - Il fuso orario è definito nelle proprietà del percorso. Di conseguenza, non è possibile dall’interfaccia utente puntare a un timestamp ISO-8601 completo che combina l’offset di ora e fuso orario, ad esempio
2023-08-12T09:46:06.982-05. Ulteriori informazioni - Durante la creazione di un'espressione di attesa personalizzata con
toDateTimeOnly(), not aggiungereZo un offset del fuso orario (ad esempio,-05:00). L’espressione deve fare riferimento al fuso orario configurato nel percorso senza indicatori di fuso orario espliciti, altrimenti i profili potrebbero bloccarsi nell’attività Attendi.
| table 0-row-2 1-row-2 2-row-2 | |
|---|---|
| Esempio | |
| Corretto | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00")) |
| Errato | toDateTimeOnly(concat(toString(toDateOnly(nowWithDelta(2, "days"))),"T10:00:00Z")) ❌ (contiene Z) |
Per verificare che l’attività Attendi funzioni come previsto, puoi utilizzare gli eventi dei passaggi. Ulteriori informazioni.
Attesa ottimizzazione dell’ora di invio sto-wait
Seleziona il tipo Ottimizzazione dell’ora di invio per consentire all’intelligenza artificiale di Adobe di determinare il tempo ottimale per continuare con l’attività successiva nel percorso, in base al comportamento di coinvolgimento previsto di ciascun profilo. In questo modo si utilizza lo stesso modello di ottimizzazione dell’ora di invio delle azioni E-mail e push, ma l’attesa viene separata dall’invio stesso. L’attività che segue l’attesa può essere qualsiasi attività, ad esempio un’azione Personalizzata, anziché essere associata solo a un’azione E-mail o Push.
Aggiornamento profilo dopo l’attesa profile-refresh
Quando un profilo viene parcheggiato in un’attività Wait in un percorso che inizia con un’attività Read Audience, il percorso aggiorna automaticamente gli attributi del profilo da Servizio profili unificato (UPS) per recuperare i dati disponibili più recenti.
- Alla voce percorso: i profili utilizzano i valori degli attributi dello snapshot del pubblico valutato all’avvio del percorso.
- Dopo un nodo di attesa: il percorso esegue una ricerca per recuperare i dati di profilo più recenti da UPS, non i dati snapshot precedenti. Ciò significa che gli attributi del profilo possono essere cambiati dall’inizio del percorso.
Questo comportamento assicura che le attività a valle utilizzino le informazioni correnti del profilo dopo un periodo di attesa. Tuttavia, potrebbero verificarsi risultati imprevisti se si prevede che il percorso utilizzi solo i dati snapshot originali durante l’esecuzione.
Esempio: se un profilo è idoneo per un pubblico “cliente silver” all’inizio del percorso, ma viene aggiornato a “cliente gold” durante un’attesa di 3 giorni, le attività successive all’attesa visualizzeranno lo stato “cliente gold” aggiornato.
Nodo di attesa automatico auto-wait-node
Ogni attività esperienza in entrata (messaggio in-app, esperienza basata su codice o scheda) viene fornita con un’attività Wait di 3 giorni. Poiché i messaggi in entrata terminano automaticamente quando un profilo raggiunge la fine del percorso, si presume che gli utenti debbano visualizzarlo almeno per 3 giorni. Puoi rimuovere questa attività Attendi o modificarne la configurazione, se necessario.
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.