Segments

A segment is a named, reusable cohort of subscribers defined by rules over their attributes (country, tier, any property your SDKs report) and their behavior (events they did — or did not — perform). Once created, a segment is a target you can point sends at:

• as the audience of a send in Compose,
• as the audience of a campaign,
• as a journey trigger — "enters segment" and "exits segment" start runs from segment membership changes.

Segments differ from audience filters: a filter is an ad-hoc predicate attached to a single send, while a segment is a saved, named cohort — with behavioral (event) conditions that filters do not have.

You build segments under Segments in the dashboard.

Build a segment

1. Open Segments and give the segment a name (for example, dormant_30d).
2. Add conditions with the condition builder (below).
3. Watch the Estimated audience panel — it refreshes as you edit, showing how many subscribers currently match. Consent gaps are excluded at send time, not in the estimate.
4. Click Create segment. At least one condition is required.

The condition builder

A segment's rule is a group of conditions matched with all (every condition must hold) or any (one is enough). Three kinds of condition can be added:

Attribute conditions

An attribute condition compares a subscriber attribute against a value: pick the field (with autocomplete from the attribute keys seen in your data), an operator, and a value.

Operator	Meaning
equals / does not equal	exact comparison
is greater than / is at least / is less than / is at most	ordered comparison
is one of	matches any value in a comma-separated list

Numeric values are compared as numbers — orders_count is greater than 3 behaves as you expect.

Event conditions

An event condition matches on behavior: did an event, at least N times, within a window such as 30d, 24h, or 45m. Event names autocomplete from the events your integrations and SDKs have already sent — see server-side event tracking for getting events flowing.

Condition groups

+ Condition group nests a whole new all/any group inside the current one, and groups nest to any depth. This is how you express mixed logic like:

tier equals premium and (did purchase within 30d or did add_to_cart within 7d)

— an outer all group containing the attribute condition plus an inner any group with the two event conditions.

Plan limits on event conditions

Event conditions are validated against your plan when you save. Limits scale by tier — from 3 event conditions per segment, 30-day windows, and 5 auto-updating segments on entry plans, up to 25 conditions, all-time windows, and 100 auto-updating segments at the top tier.

A rule that exceeds a cap is rejected with a message naming the violated limit, so you always see exactly which cap applies to your plan.

Auto-updating vs. static segments

The Auto-updating toggle (a paid-tier feature) decides how membership behaves after creation:

• Auto-updating (dynamic) — membership is re-evaluated continuously as tracked events arrive: subscribers enter when they start matching and exit when they stop. These entered/exited transitions are exactly what journey segment triggers fire on, so use an auto-updating segment when a journey should react to the change.
• Static — membership is not kept up to date automatically as behavior changes.

The list marks each segment with a dynamic or static pill. Plans cap how many auto-updating segments you can have (limits above); on plans without the feature, creating one is rejected with an upgrade prompt.

Edit and delete

• Edit loads a segment back into the builder — change the name and conditions, then Save changes. The auto-updating setting cannot be changed after creation.
• Delete asks for an inline confirmation before removing the segment.

note

Segment names are unique within your workspace — saving a segment under a name you already use is rejected.