Costs
Part of Notes on email segmentation from the field
Common email segmentation questions on count, size and refresh
Common email segmentation questions about count, group size and refresh: how many segments to keep, how small a group can be and how often to rebuild them.
What to take away
- Keep a segment only when it supports a distinct customer decision with enough evidence, volume, control and ownership.
- A small group is not more relevantit can be noisy, untestable or identifiable, so set a minimum size first.
- Match refresh to data latency and decision timing, and measure the real source-to-send delay.
- Overlap, retirement and testing rules decide whether the numbers can be trusted.
Three questions decide whether a segment library stays usable: how many segments to keep, how small a group can be and how often to rebuild them. Each answer ties a number to a decision that can be documented and reproduced safely. These answers are operational guidance, not market-specific legal advice.
How many segments should a team keep?
Only as many as support distinct customer decisions with enough evidence, volume, control and ownership. A smaller governed library is often more useful than hundreds of filters nobody can explain. Start from the decision each group changes, as the field guide to email segmentation does.
Agree the question before counting groups. The GAO guide to designing evaluations says an evaluator should gain agreement on the evaluation questions before completing the design. That is federal program guidance, so it does not make a local marketing result causal or transferable, but the habit travels: write down what the group is meant to change.
Retire a segment when:
- the decision it served ends;
- the rule cannot be explained;
- the data or permission changes;
- the group becomes unstable;
- evidence no longer justifies the cost and risk.
Unused or overlapping rules go first.
Overlap changes what the count means
One person can enter several segments, so group sizes do not add up to an audience. The program defines overlap, priority, duplicate removal, total contact limits and incompatible offers. Central suppressions override every promotional rule, and the intersections need testing before anyone trusts a count.
Suppression and consent duties differ by market. The CAN-SPAM duties cover commercial email to US recipients, and the CASL consent rules cover Canadian ones. The privacy owner confirms which apply and records the date it was checked.
How small is too small?
Not necessarily more relevant. Small groups can be noisy, untestable or identifiable. Set a context-appropriate minimum size before anyone builds the report, and combine groups when the same purpose can be met more safely.
| Risk | What it looks like | Safer handling |
|---|---|---|
| Noisy | Results swing on a few records | Combine groups with the same purpose |
| Untestable | Too few records for the test cases | Raise the floor or merge |
| Identifiable | A row points to one person | Restrict row-level access, aggregate reporting |
Where California subscribers are in scope, the entry should point to the California privacy rules that apply to those fields. The NIST Privacy Framework says an organization seeking to establish a privacy program can use the Core's categories and subcategories as a reference, which suits the access and retention rules for small groups.
How often should segments refresh?
Match refresh to how quickly the underlying state and the decision change. Record the data cutoff, time zone, processing delay, evaluation time and expiry. Recheck high-consequence eligibility close to sending.
Do not assume a vendor's cadence. Google's audience management documentation says its product reevaluates audience membership as new data arrives, and documents editing, archiving, conditions, sequences, exclusions and product limits. That describes one product. Measure the actual source-to-send delay and removal behavior in your own stack.
Segments that trigger or gate a journey raise the same timing questions as the automation questions, so write the refresh rule once and reference it from both.
Test the floor and the clock
Sizing and refresh rules are only as good as their tests. Use positive, negative, boundary, null, stale, overlap, suppression, identity, localization and late-event cases. Reconcile counts, sample authorized records and dry-run destinations before release.
Segment test case checklist
- Positive and negative cases
- Boundary and null cases
- Stale and late-event cases
- Overlap and suppression cases
- Identity and localization cases
- Reconcile counts and sample records
- Dry-run destinations and monitor
Preserve the tested version and monitor after activation. A documented test plan also belongs in the email campaign planning checklist before any segment goes live.
A sizing card
| Question | Evidence needed | What to record |
|---|---|---|
| How many? | Distinct decisions and owners | Ceiling and retirement rule |
| How small? | Noise, testability, identifiability | Minimum size and access limits |
| How fresh? | Latency and decision window | Refresh rule and expiry |
| How tested? | Edge records and comparison | Release or repair |
Common questions
Can one customer belong to several segments?
Yes. Define precedence, exclusions, message pressure and conflict resolution so overlapping membership does not create contradictory or excessive communication.
Is a small segment more relevant?
Not necessarily. It can be noisy, untestable or identifiable, so set a minimum size and combine groups when the same purpose can be met more safely.
When should a segment be retired?
Retire it when the decision ends, the rule cannot be explained, the data or permission changes, the group becomes unstable, or evidence no longer justifies the cost and risk.
