The rule builder defines who qualifies for audiences and journeys. Conditions are evaluated against profiles to determine membership, entry, or decision outcomes. This reference article covers operators, grouping logic, and common patterns.
How conditions work
A condition is a set of rules evaluated against a profile.
In an audience, the condition determines who is a member.
In a journey, conditions determine entry and decision points.
The same rule builder is used across both audiences and journeys. What differs is how often conditions are evaluated and what happens when a condition is met.
Building blocks
Conditions are built based on profile attributes and events. Most useful conditions combine both.
Purpose | Time relevance | Examples | |
|---|---|---|---|
Attributes | Describe who a profile is | Persist until updated | Customer status Loyalty tier Country Consent status Contract end date |
Events | Describe what a profile did | Time-stamped | Page view Product view Add to cart Purchase Login |
Operators
Operator | Use with | What it checks |
|---|---|---|
Equals | Attributes, event properties | Exact match |
Does not equal | Attributes, event properties | Not an exact match |
Contains | Text attributes | Substring present |
Greater than / Less than | Numeric values, dates | Comparison |
Is set / Is not set | Any | Whether value exists |
In list | Attributes | Value is one of multiple options |
Has occurred | Events | Event happened (with optional time window) |
Has not occurred | Events | The event did not happen (in the time window) |
Count greater than / less than | Events | Number of occurrences |
Boolean logic
The rule builder allows for Boolean logic, such as the ones listed below:
AND
All conditions in the group must be true.
Use for: Narrowing criteria, combining intent with eligibility.
Example: Customer status = active AND viewed product in the last 7 days.
OR
Any condition in the group can be true.
Use for: Defining alternatives, multiple qualifying behaviors.
Example: Viewed product A OR viewed product B OR viewed product C.
Inverse (NOT)
Negates a condition.
Use for: Exclusions, absence of behavior.
Example: Has NOT purchased in the last 30 days.
Grouping rules
Use parentheses or nested groups to control evaluation order. When mixing AND and OR, always use explicit grouping.
Correct: (A AND B) OR (C AND D)
Matches profiles that have A and B, or profiles that have C and D.
Incorrect: A AND B OR C AND D (without grouping)
May evaluate unexpectedly due to operator precedence.
Time windows
Most event-based rules need a time window. Without a time window, the rule may be too broad.
Rule | What it matches |
|---|---|
Viewed product in the last 7 days | Anyone who viewed recently |
Viewed product (no window) | Anyone who has ever viewed |
Has not purchased in the last 30 days | No purchase in the window, but may have purchased before |
Has never purchased | No purchase event ever |
Note
A common mistake is assuming "has not done X in 30 days" means "never did X".
Condition examples
Good examples
Use Case | Condition |
|---|---|
Retarget product viewers | Event: product_viewed in the last 7 days AND Event: purchase_completed has not occurred in the last 7 days |
Existing customers | Attribute: customer_status equals "active." |
High-value cart abandoners | Event: add_to_cart in the last 24 hours AND Event: purchase_completed has not occurred in the last 24 hours AND Attribute: value_tier equals "high". |
Problematic examples
Condition | Problem | Fix |
|---|---|---|
Event: | Matches everyone who ever viewed | Add time window |
| Too broad, includes all viewers regardless of status | Use AND or restructure logic |
Has not purchased in the last 30 days (intended as "never purchased") | Will still match customers who purchased 31+ days ago | Use "has never occurred" or "is not set". |
Common mistakes in condition setup
Mixing AND and OR without grouping:
Unintended logic when operators are combined without explicit parentheses.
To avoid unintended logic, always group related conditions explicitly.
Negation errors:
Writing "NOT (A OR B)" when you mean "(NOT A) AND (NOT B)".
Fix by testing the negated conditions with known profiles to verify behavior.
Time windows missing:
Event rules without time constraints match all historical behavior.
To fix, add appropriate time windows for behavioral rules.
Overly complex conditions:
Conditions with many nested groups are hard to debug and maintain.
To fix, break complex logic into multiple simpler audiences and combine them.