Timing is where orchestration implementations often break down. The rules can be correct and destinations configured properly, but results can still feel wrong because different timing concepts get confused. This guide explains each timing concept and how they differ.
Time windows in conditions
Time windows are part of rule definitions. They control whether an event qualifies based on recency.
Note that "Has not purchased in 30 days" is a recency statement, not a lifetime statement. Someone who made a purchase 31 days ago would match this condition.
Example | What it means |
|---|---|
Viewed product in the last 3 days | The event must have occurred within the window |
Started checkout in the last 2 hours | Very recent activity only |
Has not purchased in the last 30 days | No purchase event in the window (may have purchased before) |
Audience expiration time
Expiration removes profiles from an audience after a period of inactivity, even if they originally qualified. Expiration is most useful for intent audiences and retargeting pools where you want membership to decay naturally.
Note that expiration only trims the tail. If entry logic is too broad, expiration alone won't give you a focused audience.
Concept | What it controls |
|---|---|
Time window in the entry condition | Who qualifies now |
Expiration time | How long someone stays in after the qualifying activity stops |
Journey waits and delays
Journeys can include wait steps that pause before the next action or evaluation. A wait step is a deliberate pause in the sequence, not a time window. Wait steps control when the next step happens, not which profiles qualify.
Example flow:
Enter the journey on the cart started event.
Wait 2 hours.
Check if the purchase is completed.
If not, send a reminder.
Wait steps are used for:
Giving customers time to complete actions naturally.
Avoiding immediate repetitive messaging.
Coordinating across channels with different delivery timings.
Data freshness and ingestion latency
Orchestration timing is limited by when data actually arrives. Data freshness and latency matter because:
A journey might trigger before the purchase event is tracked by the data activation platform, making it look like the customer didn't convert.
A suppression audience might not update until the CRM sync completes.
Orchestration reacts as quickly as it can to available data. The speed of reaction depends on how quickly source systems provide signals.
Data type | Typical latency |
|---|---|
Web tracking events | Near real-time |
Server-side events | Depends on implementation (seconds to minutes) |
CRM updates | Often in a batch, can be hours |
Billing confirmations | Often in a batch, can be hours to daily |
Destination update cadence
Even if orchestration updates immediately, destinations may not. This is why "real-time suppression" needs careful expectations.
Updates are real-time from the platform to the destination, but not necessarily in real time across every destination.
Destination behavior | What to expect |
|---|---|
Near real-time | Updates within minutes |
Scheduled sync | Updates on a defined schedule (hourly, daily) |
Destination matching | Destination applies its own rules that may delay the effect |
Historical processing and lookback
Historical processing evaluates an audience or journey definition against past data to backfill memberships.
Situation | What happens |
|---|---|
New audience created | It may look empty until historical processing runs |
Audience with a long time window | Backfill may include many profiles from historical data |
Rule changes | Changing time windows can significantly change the population size |
Historical processing is covered in detail in Historical processing.
Common timing issues
Issue | What happens | Fix |
|---|---|---|
Confusing the time window with the expiration | The audience behaves unexpectedly over time | Understand what events or attributes control entry or exit conditions |
Wait step is too short | Messages sent before the customer has time to convert | Test the wait durations against typical behavior |
Expecting real-time when data is batch with delay | Journey triggers before conversion arrives | Adjust the wait times or improve data freshness |
Assuming the destination is instantly refreshing their audience and serving the ads based on the refreshed audience | Suppression doesn't take effect immediately | Understand the destination sync behavior |