Journeys and audiences normally evaluate profiles from the moment they're published. Historical processing lets you look back over a defined period to backfill profiles that would've qualified before the orchestration object existed or was changed.
Historical processing is useful because real data activation implementations rarely start from a clean slate, but most likely, there is data of previous behavior and profiles that need to be backfilled into the system. Journeys are often published after data has been flowing for weeks or months.
Historical processing is typically used in 3 situations:
New journey or audience: You want it to be useful on day 1 by including recent qualifying profiles.
Rule changes: Entry conditions changed, and you want to catch profiles that now qualify.
Goal or exit changes: Logic was updated, and you want the current state to align with the new definition.
Example: A retailer publishes an abandoned cart journey today. Without historical processing, only carts abandoned from today onward can enter. With historical processing, they can include people who abandoned their carts in the last 14 days or in any other defined period of time for which you have data.
Historical processing actions
Historical processing can either backfill entries, re-evaluate goals, or re-evaluate exit conditions, depending on your use case.
Backfill entry
The backfill entry finds profiles that would've matched the entry condition during the selected lookback period and adds them to the journey or audience.
What to expect:
Backfilled profiles enter at the start of the journey.
It does not re-run earlier steps for profiles already in the journey.
After backfill, profiles continue forward based on new events.
Re-evaluate goals
Goal re-evaluation checks whether profiles already in a journey should be counted as having reached a goal based on historical events.
Note that only events that happened after the profile entered the journey are considered for goals. A purchase before entry does not count.
Re-evaluate exit conditions
When you re-evaluate the exit conditions, the system checks whether profiles that are already in a journey should have exited based on the exit condition.
Note that only events that happened after the profile entered the journey are considered for exit. If an event satisfies both the goal and the exit, the goal is applied first.
Practical implications
Audiences
When a new audience is created with a time-based condition (for example, "viewed product in the last 7 days"), it may look empty until historical processing runs. After processing, the audience will include profiles that match based on historical data.
Changing time windows on an existing audience can significantly change population size after reprocessing.
Journeys
Backfilled profiles enter at the journey start, not at the step where they would've been if they entered earlier. This means:
If your journey has a 2-hour wait as the first step, backfilled profiles will wait 2 hours from their backfill entry, not from when they originally qualified.
Backfilled profiles may receive messages about events that happened days ago.
Consider whether backfilling makes sense for time-sensitive use cases.
What historical processing does not do
Historical processing isn't a full replay, and it doesn't:
Re-run every step for every profile from the beginning.
Push profiles already in the journey back through earlier steps.
Guarantee that destinations behave as if actions happened in the past.
The intent is practical correction and backfilling, not perfect historical simulation.
Historical processing batch job
Historical processing runs as a batch job:
The system schedules and processes the historical data in batches.
You can cancel the processing while scheduled.
Once running, the processing can't be canceled.
If the journey or audience is edited after a run is scheduled, the scheduled run uses the version that was active when scheduled. Later edits are not applied to that run. To apply the latest edits to the run, cancel the scheduled run and trigger another one.
Lookback windows
Historical processing typically supports short to medium lookback windows, up to a defined maximum.
What gets evaluated depends on the rule type:
Event-based: Uses event timestamps, so lookback window matters
Profile attributes: Current state, so lookback may not change the outcome
Common considerations for historical processing
Situation | What to consider |
|---|---|
Time-sensitive journey | Backfilled profiles may receive messages about old events |
Large lookback window | May include many profiles, increasing volume suddenly |
Audience rule change | The population may shift significantly after reprocessing |
Goal and exit changes | Only post-entry events are re-evaluated |