Nested All/Any Conditions Explained
How to read, build and test nested ALL/ANY conditions in email segments without accidentally widening an audience, excluding valid subscribers or undermining deliverability.
Email segmentation builders often use friendly labels such as ALL, ANY, AND and OR. The labels look straightforward until a segment contains more than two rules. Add an exclusion, a date range or a second group and a small change can turn a narrow campaign audience into a much larger one.
Nested ALL/ANY conditions solve that problem. They let you place related rules into groups, then decide how those groups relate to one another. In effect, they provide the parentheses in a normal logical expression.
This matters beyond reporting convenience. A segment determines who receives a campaign or enters an automated journey. If it includes people who did not expect the message, the likely results are weaker response, more unsubscribes and more complaints. Google advises senders to mail people who want their messages, monitor complaint rates and consider removing recipients who do not engage; it also says bulk senders should keep user-reported spam rates below 0.1% and avoid reaching 0.3%. Google’s email sender guidelines make segmentation a practical part of responsible sending, not simply a targeting feature.
What ALL and ANY mean
A condition is one test applied to a contact. For example:
- is subscribed to email marketing;
- lives in the United Kingdom;
- has purchased in the last 90 days;
- has not received a campaign in the last seven days.
ALL means every condition in that group must be true. It is the same basic idea as logical AND.
ANY means at least one condition in that group must be true. It is the same basic idea as logical OR.
For a simple segment, the result is intuitive:
| Logic | Conditions | Who qualifies? |
|---|---|---|
| ALL | Subscribed; purchased in the last 90 days | Only subscribers who have purchased recently |
| ANY | Located in Manchester; located in Leeds | People in either city |
The difficulty begins when a segment needs both ideas. Consider a retailer promoting an in-store event in either Manchester or Leeds, but only to email subscribers who bought recently. The intended audience is:
Subscribed
AND purchased in the last 90 days
AND (city is Manchester OR city is Leeds)
The city rules belong together in an ANY group. The subscription status, purchase recency and city group belong together under ALL.
In a visual segment builder, it may read as:
- Match ALL of the following:
- Can receive email marketing
- Placed order at least once in the last 90 days
- Match ANY of the following:
- City equals Manchester
- City equals Leeds
That inner group is a nested condition. It stops the location alternatives from loosening the rest of the audience definition.
Why grouping changes the outcome
Without nesting, marketers can accidentally express a different rule from the one they intended. Suppose the builder evaluates this flat sequence:
Subscribed AND purchased recently AND city is Manchester OR city is Leeds
Depending on the platform’s logic rules, this may be interpreted as:
(Subscribed AND purchased recently AND city is Manchester)
OR city is Leeds
That would include everyone in Leeds, including people who are not eligible for marketing or have not purchased recently. Some platforms make grouping explicit; others constrain the way a mixture of AND and OR can be built. Do not assume that conditions are read left to right in the way a sentence is read. Inspect the groups the interface has actually created and, where available, use the platform’s preview or segment count.
For example, Mailchimp distinguishes between ordinary segments with one overall match type and advanced segments that combine AND/OR logic across groups. Its advanced-segmentation documentation also notes a two-level group limit, which is a useful reminder that each email platform has its own implementation limits. Mailchimp’s segmentation documentation describes this distinction. Salesforce Marketing Cloud Engagement similarly allows filter statements to be placed into subgroups using AND and OR operators. Salesforce’s Journey Builder filter guidance is a clear example of nested grouping in practice.
Read a nested segment from the outside in
The easiest way to review a complex audience is to start with the outermost group. Ask: what must be true for everyone who receives this email? Then move into each nested group and ask what alternatives or refinements it contributes.
Take this segment:
ALL of:
- can receive email marketing
- has not received a campaign in the last 5 days
- ANY of:
- viewed product category "running" in the last 14 days
- purchased product category "running" in the last 365 days
- NONE of:
- has an open support case tagged "delivery issue"
Read it as one sentence: send to marketable contacts who have had five days without a campaign, who either browsed running products recently or bought them in the past year, and who do not currently have a delivery issue under investigation.
The segment is not saying that someone must have both browsed and bought. The inner ANY group deliberately permits either signal. It is also not saying that every past customer should receive the campaign: the eligibility, contact-pressure and service exclusions still apply to everyone because they sit in the outer ALL group.
Use groups for alternatives, not for unrelated rules
A useful design habit is to make each group answer one business question.
Location alternatives
If an event is available in Bristol, Cardiff or Exeter, use an ANY group for the locations:
ALL of:
- subscribed to email
- ANY of: Bristol, Cardiff, Exeter
Equivalent intent signals
Different actions can show the same broad interest. A travel brand may treat “searched a holiday in Greece” and “downloaded the Greece guide” as alternative signals:
ALL of:
- subscribed to email
- ANY of:
- searched Greece holidays in the last 30 days
- downloaded Greece guide in the last 60 days
Keep the time frames visible. A recent search and a guide download from three years ago are not equivalent signals, even if the rules are joined by ANY.
Eligibility guardrails
Consent status, global suppression status, hard-bounce status, frequency caps and transactional conflicts are usually universal requirements. Put them in the outer ALL group, rather than repeating them inside every alternative. This reduces the chance that one branch of an ANY group bypasses a safety condition.
For platforms where a segment can contain profiles that cannot be emailed, make the sendable status explicit. Klaviyo, for instance, advises adding a marketing-receivability condition with an AND connector when an accurate contactable count is needed. Klaviyo’s segment conditions reference also explains that only top-level event properties are segmentable, which can affect whether a seemingly valid rule can be built at all.
The common negative-condition trap
Negative rules need special care because an ANY group can make them unexpectedly broad.
Imagine the intended audience is people outside both the UK and Ireland. The correct rule is:
Country is not United Kingdom
AND country is not Ireland
Why AND? A person in Ireland is indeed “not United Kingdom”, so they would pass the first test. A person in the UK is “not Ireland”, so they would pass the second. If the two tests are joined with ANY, almost everybody qualifies, including people in the very countries meant to be excluded.
Where the platform supports it, a single operator such as “country is none of: United Kingdom, Ireland” is clearer and less error-prone. If it does not, use separate negative conditions joined by ALL. Klaviyo illustrates this exact issue in its explanation of AND/OR logic for negative conditions. Its segmentation guide is worth sharing with anyone who regularly builds exclusions.
The same principle applies to suppression logic. “Has not purchased product A” OR “has not purchased product B” does not exclude purchasers of both products; nearly every customer will satisfy at least one side. Translate the desired business rule into a plain sentence before choosing the connector.
Be precise about time windows and event counts
ALL/ANY logic controls the relationship between conditions. It does not repair vague conditions.
“Opened an email in the last 30 days” may be a weak engagement measure, particularly where automatic privacy features or security systems can create an open without a clear human reading signal. For high-stakes audience expansion or reputation recovery, use stronger evidence where available: a click, an authenticated-site visit, a purchase, a preference update or a combination of signals. Keep the resulting definition understandable to the people who must review it.
Also distinguish these statements:
- Purchased at least once in the last 90 days: a recency rule.
- Purchased at least twice in the last 90 days: a frequency rule.
- Purchased a running shoe in the last 90 days: a property-filtered event rule.
- Purchased running shoes or trail shoes in the last 90 days: potentially an ANY group, unless the platform can apply a single “one of” product-category filter.
Event filters can be more complicated than profile fields. Check whether multiple filters must be true of the same event, whether they can be satisfied by separate events, and whether the platform evaluates rolling dates at send time or when the segment is calculated. These details are product-specific and can change the result materially.
Test the logic before sending
A segment count is useful but insufficient. A plausible total can still contain the wrong people. Review a small set of contacts that represent the edges of the logic:
- a subscribed recent buyer in one of the permitted cities — should qualify;
- a subscribed recent buyer outside those cities — should not qualify;
- a person in a permitted city who is unsubscribed — should not qualify;
- a person matching both inner alternatives — should qualify once, not twice;
- a person who meets an inclusion rule but is under a frequency cap or global suppression — should not qualify.
Write these as test cases before opening the segment builder. This separates the business decision from the interface and makes peer review faster. If the platform supports saved segment definitions, keep the plain-English purpose alongside the rule: “Recent running interest in the North, excluding recent campaign recipients”, rather than “Segment v12 final final”.
When the audience will be unusually large, newly reactivated or directed towards a mailbox provider where performance has been weak, start carefully. Google recommends consistent sending, gradual volume increases and monitoring of server responses, spam rate and reputation as volume grows. Its guidance on increasing send volume is especially relevant after a segmentation change that substantially widens reach.
When nested logic becomes a deliverability control
Segmentation cannot compensate for missing consent, poor authentication or an unhealthy sending infrastructure. It can, however, prevent known risks from being added to an otherwise sound campaign. A well-structured outer group can require permission, exclude suppressions, enforce contact-pressure limits and confine a test or promotional send to people with credible recent interest.
That is particularly valuable during deliverability recovery. The aim is not to manipulate mailbox-provider protections or disguise unwanted mail. It is to make sure permission-based messages go first to recipients most likely to recognise and value them, while monitoring feedback and placement. Where needed, Email Foundry can review the segment logic alongside authentication, suppression handling, provider-level pacing and engagement evidence as part of a managed recovery programme.
The core rule is simple: use ALL for requirements that every recipient must meet; use ANY for genuinely interchangeable alternatives; and use nesting to show exactly where those alternatives begin and end. If the segment cannot be explained in one accurate sentence, simplify it or document it before it is used to send.
Frequently asked questions
What is the difference between ALL/ANY and AND/OR in an email segment?
They usually mean the same thing. ALL corresponds to AND: every condition must be true. ANY corresponds to OR: at least one condition must be true. The important question is the level at which the connector applies: individual rules, a nested group, or the whole segment.
Should unsubscribe and suppression rules sit inside an ANY group?
Usually no. Sendability, consent, global suppressions and hard-bounce exclusions are normally universal guardrails. Put them in the outer ALL group so that no alternative branch can admit a contact who should not receive marketing email.
Why do negative rules often need ALL logic?
With exclusions, each individual negative condition can be true for people you still mean to exclude. For example, someone in Ireland is not in the UK, and someone in the UK is not in Ireland. Joining those two rules with ANY would include both. Use ALL, or a single “none of” operator where available.
How can I check that a nested segment is correct?
Translate the rules into a plain-English sentence, then test known edge-case contacts: people who meet one alternative, both alternatives, neither alternative and people who otherwise qualify but are unsubscribed or suppressed. Review sample members, not only the total count.
Sources and further reading
- Email sender guidelines — Google
- Email sender guidelines FAQ — Google
- Segments — Mailchimp
- Create a filter — Salesforce
- Getting started with segments — Klaviyo
- Segment conditions reference — Klaviyo