Email Audience Snapshots: Decide Whether Membership Is Frozen or Live
Choose frozen or live campaign audiences deliberately, while rechecking current eligibility so an old membership snapshot cannot override a later opt-out.
TL;DR
- Decide whether audience membership is a frozen snapshot or a live evaluation based on the campaign's purpose and approval expectations, so the preview count does not imply a different guarantee.
- Specify how newly qualifying contacts are treated and validate behavior at the send boundary by creating test fixtures that exercise joins, leaves, field changes and batch processing.
- Keep membership distinct from current eligibility, record the policy with the campaign, and report original candidates, new qualifiers, suppressions and handed-off messages so count changes are explainable.
Decide what the audience count promises
When a campaign preview says it will reach a certain audience, the operator needs to know whether that membership is frozen or will be recalculated later. A stored list and a live segment answer different questions.
A snapshot records who matched at a particular time. A live evaluation asks who matches when the rule is executed. Neither is universally correct. The choice should reflect the campaign's purpose, approval process and the kinds of changes that can occur before sending.
Write the policy beside the audience definition so a preview count does not imply a guarantee the system never intended to make.
Separate membership from eligibility
Even a frozen audience should not be treated as permanent permission to send. A contact can unsubscribe, become suppressed or lose the relationship that made the message appropriate after the snapshot was taken.
Keep the original membership decision and the current eligibility decision distinct. The snapshot can explain why the contact was considered, while a final check can explain why the message was not authorized later.
The SendDart consent-record guide is relevant to preserving preference history. A campaign approval should not erase a recipient's newer choice simply because the address appeared in an earlier list.
Work through a customer-announcement example
Imagine a company announces a change affecting customers on a particular plan. The team reviews the audience on Monday and schedules delivery for Thursday. Some customers change plans between those dates.
A frozen audience may be appropriate if the announcement concerns everyone affected by Monday's contractual state. A live audience may be appropriate if the message describes only the current plan experience. The correct interpretation depends on the actual business event.
Write that reason in the brief. Otherwise the engineering implementation may choose one behavior for convenience while the campaign owner assumes the other.
Define how new members are handled
For a live segment, decide whether contacts who qualify after approval can enter the campaign. That can change the audience materially, especially when an import or product event adds many records.
For a snapshot, explain that newly qualifying contacts are not automatically included and identify any separate follow-up workflow if one is needed. Avoid quietly mixing snapshot and live behavior in different batches of the same campaign.
If the audience can expand, the approval record should describe the rule and any boundaries, not merely the count observed during review. The reviewer must understand what future membership changes are being authorized.
Keep personalized facts consistent with the policy
Membership timing and content timing can differ. A frozen audience does not necessarily mean every personalized field should remain frozen, but that distinction must be intentional.
In the plan-change example, using a current plan name inside a message explaining an earlier plan state can create a contradiction. Decide which facts describe the historical event and which should reflect current information, then render them consistently.
Record the relevant version or event reference with the campaign. This allows support staff to explain why a recipient received a particular statement even if their account looks different today.
Show count changes with reasons
A useful sending summary distinguishes original candidates, newly qualified members where allowed, current suppressions and messages actually handed off. Do not force all counts to match the preview when the policy intentionally permits changes.
For an illustrative snapshot of 1,000 contacts, a later summary could show fewer authorized recipients because some opted out or became ineligible. That is a correct result when the current checks are working, not evidence that the system lost contacts.
Use mutually understandable categories and state whether they are exclusive. A contact can satisfy several exclusion reasons, so naive addition can overstate the number removed.
Test the evaluation boundary
Create fixtures where a contact joins, leaves, changes a relevant field or unsubscribes between preview, approval and worker execution. Include a campaign processed in several batches while membership continues changing.
If the application uses database transactions to capture a consistent set, understand the chosen isolation and scope. The PostgreSQL transaction-isolation documentation is a useful reference for the general issue, but a database snapshot alone does not establish the campaign's business policy.
Test the actual behavior at the send boundary rather than only checking the preview query.
Preserve the policy with the campaign record
Store the segment definition or snapshot reference, evaluation time, approval scope and current-eligibility rules. Make these available to the people responsible for explaining the campaign.
When using SendDart, verify which audience behavior the actual sending workflow implements and add application controls where needed. Do not assume a segment resource name tells you whether membership is frozen at approval or evaluated at delivery. A clear policy makes the count, content and recipient choice understandable throughout the campaign's lifecycle.
Related reading: Scheduled Email Delivery: Store the Time, Content and Cancellation State.