Dynamic Segmentation: Real-Time List Updates
Segments that recalculate themselves, where they beat static lists, and the timing bug that sends the wrong email.
On this page
The short version
- A dynamic segment recalculates itself; a static one is a snapshot that begins going stale the moment it is saved.
- The timing bug: a segment evaluated when a send is scheduled rather than when it goes out will include people who have since left it, and exclude people who have since joined.
- Dynamic is right for almost everything. Static is right when you need a fixed cohort, and that case is rarer than the number of static lists in most accounts suggests.
A static segment is a list of people captured at one moment. A dynamic segment is a rule that produces a list whenever it is asked. The difference sounds procedural and produces very different outcomes over months.
Static segments rot. The subscriber who unsubscribed, the one who has since bought, the one who moved from cooling to active — none of that is reflected, and the segment quietly becomes a description of the past.
When each is right
| Situation | Use | Why |
|---|---|---|
| Ongoing campaigns and flows | Dynamic | Membership should reflect now |
| Engagement tiers | Dynamic | People move between them constantly |
| A/B test groups | Static | The cohort must not change mid-test |
| Holdout groups | Static | The comparison depends on stability |
| Event attendees | Static | It is a record of a past fact |
| A one-off import | Static | It describes a batch, not a rule |
| Suppression lists | Dynamic where possible | New unsubscribes must be picked up |
Rules that quietly stop matching
A dynamic segment is only as good as the rule, and rules break silently when the world underneath them changes.
The common causes: a URL the rule matched on changed during a site restructure, a tag was renamed, a custom field was replaced, a product SKU changed, an event stopped firing after a tracking update.
In every case the segment does not error — it simply returns fewer and fewer people, and eventually zero. A campaign to an empty segment sends nothing and reports success, which is why this can persist for months.
The cheap defence is an alert on segment size. Any segment that drops below a fraction of its usual membership should notify someone, because the alternative is discovering it at the quarterly review.
Overlap and precedence
Dynamic segments overlap by nature, and a subscriber matching four of them will receive four emails unless something prevents it.
Two mechanisms are needed. A precedence rule saying which segment wins when several match — written down, not held in someone's head. And a frequency cap per subscriber across all sends, so that even a precedence failure cannot produce four emails in a day.
The cap is the more important of the two, because it fails safe. A precedence rule protects against the cases you anticipated; a cap protects against the ones you did not.
Testing a rule before trusting it
Build the segment, look at the count, and then look at twenty actual members. The count tells you the rule ran; the twenty tell you whether it ran correctly.
This catches the classic errors immediately — an AND that should have been an OR, a date comparison the wrong way round, a rule that matched everyone because a condition was never applied. All of them produce a plausible-looking count and an obviously wrong membership.
Then check the boundary: find someone who just barely qualifies and someone who just barely does not, and confirm each is on the right side. Boundary errors are the ones that survive a casual review.
Dynamic segment check
- Rules evaluate at send time, verified by test rather than assumed
- Twenty actual members were inspected, not just the count
- Boundary cases checked on both sides
- An alert fires if segment size collapses
- Precedence between overlapping segments is written down
- A per-subscriber frequency cap exists across all sends
- Rules are reviewed when the site, products or tracking change
Frequently asked questions
Is there a performance cost to dynamic segments?
On large lists with complex rules, yes — evaluation takes time and can delay a send. Simplify the rule or precompute a flag rather than reverting to a static list, which trades a delay for staleness.
How do I keep a record of who received a past campaign?
From the send log, not from the segment. The segment describes who matches now; the log describes who was sent to then, and conflating them is how reporting goes wrong.
Should suppression lists be dynamic?
Wherever possible. A static suppression list misses everyone who unsubscribed since it was built, which is the one failure in this area with legal consequences.