Wait for Condition - Zeotap docs

Overview

The Wait for Condition node holds a user in a journey until a profile attribute updates or a specified event fires — within a maximum wait window that you configure. It is a gate with a single output. Only users who meet the condition pass through to the next node. Users who do not qualify before the window expires are dropped from the journey, and remain visible in analytics.

Wait for Condition compared with Delay

Both nodes pause a user mid-journey, but they solve different problems.

	Delay node	Wait for Condition node
Type	Time-based	State-based
Behaviour	Pauses for a fixed duration. The user always continues once the timer ends — no condition is checked.	Holds the user until a condition on their profile is met. Users who do not qualify are dropped once the window expires.
Use when	You need a timed gap between messages and no state check.	You are suppressing sends to converters, waiting for a value to compute, or gating on state.

See Add a Delay for the time-based node.

Not the same as Add a Condition. Add a Condition tests the condition at the moment the user arrives at the node and routes them straight away. Wait for Condition waits for the condition to become true, holding the user until it does or until the window expires.

Key characteristics

Characteristic	Detail
Single output connector	No second path is needed for users who do not qualify, so the canvas stays clean.
Exponential backoff retries	The condition is re-checked on a `10 × 2ⁿ` second interval — frequent at first, then progressively further apart.
Default maximum wait of 1 Day	Configurable from a dropdown. Users who do not qualify within the window are dropped.
Passes through exactly once	A user passes the first time the condition is met, regardless of any later fluctuation in the value.

Add the node to a journey

Open your journey in the Journey Builder

Navigate to Orchestrate → Journeys and open or create a journey. The journey must be in Draft or Edit mode.

Add the node from the action picker

Click the + connector below any node to open the Choose an action menu, then select Wait for condition. The tooltip confirms what the node does: “Hold the user in the flow until a profile attribute updates or an event fires — within a max wait window.”

Set the Max Wait window

At the top of the configuration panel, the Max Wait section shows a dropdown set to 1 Day by default. Select a different duration if your condition needs longer — or shorter — to resolve. Users who do not meet the condition within this window are dropped from the journey.

Build your condition

In the Add a Condition section, use the condition builder — the same one you know from audiences — to define when a user qualifies. Choose a condition type (attributes, events or IDs), set the operator and value, and add further conditions with AND/OR logic, nested blocks or NOT.

Save the node and connect its output

Click Add Wait For Condition to save. The chip on the canvas updates to summarise your condition. Connect the output connector to the next node — that path carries qualifying users only.

Users who do not meet the condition within the maximum wait window are dropped from the journey automatically. Their status is trackable in journey analytics, and you do not need to configure a second path or any downstream action for them.

Example configurations

Condition	What it waits for	Why you would use it
Have Certain Attributes — `Customer_Consent` Equal `yes`	Consent being recorded on the profile	Hold the user until consent is on file before sending a marketing message.
Performed an event — `checkout_complete` where `product_id` Equal `product_x`	A purchase of one specific product	Suppression: hold before a follow-up push until the user buys the promoted product.
Have Certain Attributes — `customer_tier` Is not null	A derived attribute finishing its computation	Wait until the value is ready before downstream personalisation reads it.

Use Add Nested Block when you need grouped compound logic — for example, (A AND B) OR (C AND D). The outer AND/OR controls how the blocks relate to each other; the inner AND/OR controls the conditions within a block.

How the node re-checks the condition

Each user’s condition is re-evaluated on an exponential backoff schedule. The interval is 10 × 2ⁿ seconds, where n is the retry number — 20, 40, 80, 160, 320 seconds and so on. Checks are frequent at the start, which suits conditions that resolve quickly, and space out as time passes.

Retry (n)	Interval	Cumulative time elapsed
1	20 seconds	~20 seconds
2	40 seconds	~60 seconds
3	80 seconds	~2 minutes
4	160 seconds (~3 minutes)	~5 minutes
5	320 seconds (~5 minutes)	~10 minutes
6	640 seconds (~11 minutes)	~21 minutes
7	1,280 seconds (~21 minutes)	~42 minutes
8	2,560 seconds (~43 minutes)	~85 minutes
9	5,120 seconds (~85 minutes)	~2.8 hours
10	10,240 seconds (~2.8 hours)	~5.7 hours
11	20,480 seconds (~5.7 hours)	~11.4 hours
12	40,960 seconds (~11.4 hours)	~22.8 hours

What this means in practice: a condition that resolves quickly — a derived attribute recomputing, for instance — is picked up within the first minute or so and the user moves on. A condition that takes hours, such as a purchase inside a 24-hour window, is checked at widening intervals rather than continuously for the whole wait. Twelve retries span roughly 22.8 hours, so a user sitting in the default 1-day window is checked about a dozen times before it expires.

Passing through exactly once

Each user passes through the node exactly once. If the value fluctuates after the condition has been met — the attribute reverts and matches again, or the same event fires a second time — the user is not unblocked a second time. The first resolution is the trigger; later changes are ignored.

When the maximum wait window expires

Users who have not qualified when the window expires are dropped from the journey. There is no second output path to configure on the canvas. Dropped users appear in journey analytics and stay fully trackable, and they do not hold up any other user in the journey.

Track users at the node

Every user who enters a Wait for Condition node is tracked from entry to exit, with three statuses:

Status	What it means
Waiting	The user is currently held at the node, with their condition being re-checked on the backoff schedule.
Passed Through	The condition was met within the window and the user has continued to the next node.
Dropped	The window expired without the condition being met. No downstream action is required.

For per-node visibility across the whole journey, see Understand Metrics.

Reading your drop rate

What you see	Likely cause	What to try
High drop rate	The window is too short, or this audience rarely meets the condition.	Increase the maximum wait, or review the condition against your audience’s profile data.
Most users qualify near the end of the window	The attribute or event is arriving slowly.	Check for latency upstream in your data pipeline, and consider widening the window slightly.
Very high pass-through rate	Most users already meet the condition when they arrive.	Consider moving the condition upstream, into the journey’s entry criteria.
Zero pass-through	The condition is misconfigured, or the attribute or event is not being ingested.	Verify the attribute name, operator and value, then check that the event is being ingested.

Calibrating the window. Run your first campaign with the default 1-day window and check analytics at the 24-hour mark. If most of your drops happened in the last couple of hours, a slightly longer window would have captured them. Two or three campaign cycles of this is usually enough to settle on the right duration.

Use cases

Suppressing a follow-up to users who converted

A user receives a promotional email for a product. Before the follow-up push goes out, you want to know whether they bought it — so that buyers are not pushed unnecessarily.

Add a Wait for Condition node between the Send Email node and the Send Push Notification node.
Set the condition to Performed an event — checkout_complete where product_id Equal product_x.
Leave Max Wait at the default of 1 Day.

Users who purchase pass through, so no follow-up push is sent to them. Users who do not purchase within the day are dropped from the journey.

Waiting for a derived attribute to finish computing

A CE attribute such as lifetime_value updates, and a downstream personalisation node reads the NCE attribute customer_tier derived from it. Recomputation takes time, and the personalisation node must not fire before the value is ready.

Add a Wait for Condition node between the update trigger and the node that reads customer_tier.
Set the condition to Have Certain Attributes — customer_tier Is not null.
Set Max Wait to a window that comfortably covers recomputation — for example, 2 hours.

Backoff retries begin immediately, checking after 20 seconds, then 40, then 80, so most recomputations are picked up within the first few retries. Users pass through as soon as the value is populated. Anyone whose attribute has not computed inside the window is dropped, which keeps stale data out of the personalisation node.

FAQs

What happens to users who do not meet the condition within the window?

They are dropped from the journey. There is no second output path to configure. Dropped users appear in journey analytics and stay fully trackable, and they do not hold up any other user in the journey.

How quickly is a user unblocked once their condition is met?

The node retries on exponential backoff — after 20 seconds, then 40, 80, 160, 320 and so on. Conditions that resolve in the first few minutes are typically caught within the first several retries. Conditions that take hours are checked at widening intervals.

What is the difference between AND and OR in the condition builder?

AND requires every condition in the block to be true before the user qualifies. OR needs only one of them. Toggle between the two at the top-left of each condition block, and use nested blocks for compound logic.

What does the NOT button do?

NOT inverts the whole condition block: users who would not otherwise match are the ones who qualify. For example, NOT (Customer_Consent Equal yes) passes users through when consent is explicitly not yes.

Can a user pass through the node more than once?

No. A user passes through only the first time their condition is met, even if the value fluctuates afterwards. Later attribute changes and repeated event fires do not re-trigger the node.

Can I use this node alongside the Delay node?

Yes — both can be combined in sequence in the same journey. For example, a 30-minute Delay for a cool-down period, followed by a Wait for Condition node that checks for a purchase before the follow-up is sent.

Why does the retry interval grow over time?

So that fast-resolving conditions are caught within the first minute while slower ones are not checked every few seconds for hours on end. Backing off keeps the node responsive where it matters and predictable over long windows.

​Overview

​Wait for Condition compared with Delay

​Key characteristics

​Add the node to a journey

​Example configurations

​How the node re-checks the condition

​Passing through exactly once

​When the maximum wait window expires

​Track users at the node

​Reading your drop rate

​Use cases

​Suppressing a follow-up to users who converted

​Waiting for a derived attribute to finish computing

​FAQs

​Related Topics

Add a Delay

Add a Condition

Understand Metrics

Add or Delete a Node

Overview

Wait for Condition compared with Delay

Key characteristics

Add the node to a journey

Example configurations

How the node re-checks the condition

Passing through exactly once

When the maximum wait window expires

Track users at the node

Reading your drop rate

Use cases

Suppressing a follow-up to users who converted

Waiting for a derived attribute to finish computing

FAQs

Related Topics