What this covers
This is the operational how of segmentation: defining segments that hold, keeping them correct and current, and keeping the data under them clean enough to send on. The models that decide how you divide an audience in the first place, RFM, value, behavioural, propensity, live in segmentation models, and the data layer underneath all of it, capture, identity, and the single customer view, lives in customer data and identity. This file does not repeat that theory; it tells you how to build and run the segments once a model has chosen the cut.
Dynamic versus static segments
A dynamic segment updates automatically as subscriber data changes: membership is a rule the platform re-evaluates, so contacts join and leave without anyone touching the list. A static segment has fixed membership set at creation and changes only when someone edits it.
Prefer dynamic segments for anything driven by behaviour or state, because they keep themselves current and cannot drift out of date. Reserve static segments for the cases a rule cannot express or should not: a fixed test or holdout cell whose membership must not move mid-experiment, a one-off list from an external source (an event attendee export), or a manually curated VIP list.
A dynamic segment is a rule expression over profile and event fields. Write the rule, not a vague description. Worked definitions:
- Recently engaged buyers.
opened_email within last 30 days AND lifetime_value > [your high-value cutoff]. A value-weighted re-engagement audience. - Lapsing best customers.
last_purchase_date between 90 and 180 days ago AND lifetime_value in top quartile. The at-risk best-customer cut from segmentation models, made sendable. - Onboarding incomplete.
signup_date within last 14 days AND onboarding_completed = false AND email_consent = true. Drives the welcome flow in automation and sequences. - Active SMS-permissioned.
sms_consent = true AND last_click within last 60 days AND country = [region]. Channel grant plus engagement, so an SMS send only ever reaches the permissioned and warm.
Two practical rules when writing expressions. Be explicit about time windows (last 30 days, not recently), because a vague window becomes a different segment on every platform. And always carry the consent and suppression conditions into the rule itself, so a segment can never resolve to a contact you may not message.
Segment overlap and the cascade into frequency
Confirm whether segments overlap before combining or sending them together. Free users and users who have not completed onboarding are not mutually exclusive; adding them double-counts the audience, and worse, a contact who sits in several concurrently scheduled segments receives several sends in the same window. Overlap is therefore not just a counting error, it is a frequency problem: it is one of the main ways a programme over-contacts a subset of its list without any single campaign looking heavy.
How to check for overlap before a send window:
- List every segment scheduled to send in the same window (say the coming week).
- For each pair, compute the intersection: count the contacts that appear in both. Most platforms expose this as an AND of the two segment rules, or an audience-overlap report.
- Flag any contact landing in more than the per-tier cap from orchestration and frequency. The cap, not the overlap count, is the threshold that matters.
- Resolve, do not just observe. Apply the contact strategy: let the frequency cap and the priority order decide which send that contact actually receives, and suppress the rest for the window. Transactional always wins; promotional yields first. The detailed priority order lives in orchestration and frequency.
The fix is not to redraw every segment to be mutually exclusive, which is rarely possible. It is to let a single contact strategy arbitrate overlap at send time, so the cap is enforced across all segments at once rather than within each one.
The cost of segmentation
Segmentation trades statistical power for relevance. Below list sizes in the low thousands the trade is usually a loss, because each segment becomes too small to test or to send to reliably. Targeted segments do earn their keep when they are large enough to send to, consistently outperforming undifferentiated broadcasts on engagement and revenue per recipient. For the minimum cell a test actually needs, defer to volume thresholds rather than any fixed number; size a test cell to a realistic win before you split, not after. See also segmentation has real costs.
Data hygiene and SLAs
Hygiene is the foundation the rest sits on: a clean list is what makes segments accurate and sends deliverable. Run it to a service level, not on remembering to, so the standard is a written threshold rather than a habit.
- Hard bounces: suppress immediately. A hard bounce means the address is dead. Auto-suppress it the moment it is reported and never re-send, certainly before the next send to that segment fires. A hard bounce that is still in the audience on the following send is an SLA breach.
- Complaints and unsubscribes: suppress immediately, treat as permanent. Feed both into the suppression list at once and never reactivate. These are also legal obligations, not just hygiene; see the suppression workflow in consent and preferences. Suppression has to travel beyond the sending channels too: a contact removed here must also drop out of any ad-platform audience sync, or you are pursuing in paid someone you stopped emailing.
- Sunset by inactivity window. Define dormancy as no open, click, or purchase across a set window (a sensible default is 90 days), run the re-engagement sequence, then move any contact who does not respond to a sunset segment, suppressed from broadcast. This protects the engaged cohort rather than shrinking the asset, because dormant contacts drag sender-level reach. Keep the criteria identical to the sunset logic in automation and sequences so the flow and the segment agree. The full lifecycle this hygiene step sits inside, decay, re-engagement, and sunsetting as one practice, is database health and sunsetting.
See engagement is the new deliverability.
Merge identities carefully
When two records resolve to one person and get merged, the merge itself is a data-quality risk: a bad merge tag mapping, or a merge that picks the wrong field as the survivor, silently corrupts the profile that every downstream segment and merge field reads. Treat merge and dedup as a controlled operation, not a background convenience: define which record wins per field, preserve the consent and suppression state of both records (a merge must never resurrect a suppressed contact), and spot-check merged profiles. The identity mechanics live in customer data and identity.
Personalisation and merge tags
A merge tag is a placeholder replaced with subscriber-specific data at send time. A dynamic content block displays differently based on subscriber data. Personalisation is a real lever, but it depends on clean data: a merge tag firing a blank, a default, or a wrong value is worse than no personalisation at all, which is why the data layer comes first.
QA every merge field and dynamic block before a send goes live. The checklist:
- Test for blanks and defaults. Send to seed contacts that deliberately have the field missing, empty, and populated. Confirm the missing and empty cases render the fallback, not
Hi ,or a raw[FIRST_NAME]token. - Confirm fallback content exists for every tag. Every merge field needs a sensible default.
Hi {{ first_name | default: "there" }}rendersHi therewhen the name is missing, neverHi. - Validate field mapping. Confirm the tag points at the field you think it does. A common failure is a tag mapped to the wrong source field, so it renders a real but wrong value (someone else’s first name, a stale address), which no blank-check catches.
- Check dynamic-content branches. Each branch must have a defined audience and a fallback branch for contacts who match none, so nobody receives an empty block. Worked example: a block showing a recommended category renders the recommended category when
top_categoryis set, and a default best-sellers block when it is empty, so the slot is never blank.
This is the same merge-field check the pre-launch testing list in automation and sequences calls for; run it for broadcasts too, not only flows.
Privacy and the consent audit cadence
Privacy is integral to operations, not a separate compliance task bolted on after. Every segment and every send reads contact data, so the lawful basis and consent state must be correct in the same records the segments query. Hold a documented lawful basis for every contact, keep records of how and when consent was obtained, and honour opt-outs immediately. The capture mechanics, the suppression workflow, and the regime details live in consent and preferences; declared preferences captured there are also zero-party data you can target on.
Audit the data and consent state on a cadence rather than waiting for a problem to surface it:
- Profile completeness. Track the fill rate of the fields your segments depend on (consent flags, engagement dates, value fields). A field your targeting relies on that is blank for much of the list is a silent segmentation failure.
- Deduplication. Periodically scan for duplicate identities and merge them under the controlled process above, so one person is not counted, contacted, or suppressed as two.
- Lawful basis and consent date. Confirm every contact carries a recorded lawful basis and a consent timestamp, and that channel grants are stored separately (email permission is not SMS permission). Flag any contact missing a basis for review or suppression.
Set the cadence to your volume and risk; the point is that it is scheduled, with a written threshold, not triggered by an incident.
Related
- Segmentation models
- Customer data and identity
- Orchestration and frequency
- Automation and sequences
- Database health and sunsetting
- Audience sync
- Consent and preferences
- Segmentation has real costs
- Volume thresholds
- Legislation and compliance