Review a Suggested Email Audience Before It Becomes a Send
A focused starting set is useful for discovery. Eligibility, suppression, deduplication, and approval still define the send population.
- Written by
- Marketing Wiki Research Automation
- Review status
- Not independently reviewed
- Published
- Updated
- Evidence checked
- Sources
- 4
Turn a tool-suggested starting audience into an auditable campaign population with permission, exclusions, counts, and freeze-time evidence.
A suggested campaign audience is a starting query, not an approved send list. Rebuild it as an explicit set, prove permission for the message class, subtract every exclusion, reconcile counts, and freeze the result immediately before scheduling.
Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 4, 2026.
Prezly’s September 1 changelog says its experimental Build audience flow begins from a focused recipient set instead of an entire contact database. That can reduce accidental breadth. It does not transfer accountability from the sender to the suggestion.
Define the campaign contract first#
Record the message class, purpose, jurisdictional scope, sender identity, and expected relationship before selecting people. Then express the candidate population:
sendable = seed
INTERSECT purpose_eligible
INTERSECT permission_eligible
INTERSECT current_contact_state
MINUS global_suppressions
MINUS campaign_exclusions
MINUS frequency_cap_exclusions
MINUS duplicates
Do not let the tool infer permission from a job title, CRM stage, company, lookalike score, or past meeting. Migma’s sending rules explicitly distinguish clear permission from merely being present in a CRM, attending a call, resembling an audience, or appearing on a public network.
Record how the seed was produced#
| Field | Example |
|---|---|
| Seed type | saved list, natural-language suggestion, lookalike, imported IDs |
| Seed query/version | exact filter or immutable query ID |
| Source systems | CRM, product database, preference center |
| Evaluation timestamp | when dynamic conditions were resolved |
| Seed count | before permission and exclusions |
| Missing-data policy | exclude, hold for review, or approved fallback |
| Suggested rationale | why the tool included each class of contact |
| Owner | person accountable for the population |
If the product cannot expose its suggestion logic, export the selected identifiers and classify the set as opaque. Opaque does not automatically mean unusable, but it requires stronger sampling and a conservative exclusion policy.
Keep lists and segments distinct#
A list is usually a named membership set. A segment is a query whose membership can change. Migma’s lists and segments documentation describes those structures separately. Record which one produced the seed.
For a dynamic segment, freeze the query and capture the evaluated member IDs at approval time. Otherwise the population can change between review and send as contacts update, events arrive, or time-window criteria move.
For a static list, verify source date and consent provenance. Static membership prevents query drift; it does not keep permission current.
Apply permission before relevance scoring#
Relevance cannot repair missing permission. Use this order:
- establish whether the message is marketing, transactional, or another governed class;
- confirm the recipient’s permission or expected relationship for that class;
- apply global suppression and contact-state restrictions;
- evaluate relevance and campaign-specific eligibility;
- apply frequency caps and fatigue rules;
- deduplicate by the identifier used at delivery.
Migma’s suppression-list documentation describes blocking addresses because of unsubscribe, bounce, complaint, or manual suppression. Treat the most restrictive current state as authoritative even if the same person appears in another system as subscribed.
Reconcile counts at every boundary#
Create a count ledger:
| Stage | Input | Removed | Output | Evidence |
|---|---|---|---|---|
| Suggested seed | — | — | 12,480 | query ID and timestamp |
| Purpose eligibility | 12,480 | 1,210 | 11,270 | rule version |
| Permission | 11,270 | 890 | 10,380 | consent-source report |
| Suppressions | 10,380 | 142 | 10,238 | suppression snapshot |
| Frequency caps | 10,238 | 503 | 9,735 | send-history window |
| Deduplication | 9,735 | 37 | 9,698 | canonical identity rule |
Counts alone do not prove correctness, but an unexplained count change is a stop signal. Preserve removal reason per contact or in aggregated buckets that can be reproduced without exposing unnecessary personal data.
Sample the edges, not only random rows#
Review contacts most likely to reveal a rule defect:
- newest and oldest consent timestamps;
- missing locale, time zone, or subscription source;
- people at a score threshold;
- contacts included by multiple criteria;
- recent unsubscribe, bounce, complaint, or preference change;
- people near a frequency cap;
- records whose identity merged across systems;
- seed members the suggestion cannot explain.
A random sample can miss systematic boundary failures. Pair it with targeted fixtures for every inclusion and exclusion rule.
Freeze and approve the send population#
At final approval, store the campaign contract, query versions, evaluated timestamp, final identifier set or digest, count ledger, suppression snapshot ID, sampled exceptions, and approver. Recompute immediately before send. If membership or counts change beyond the approved tolerance, return to review.
Do not silently refresh a suggested audience after creative approval. The copy, offer, sender, and audience define one release object.
Evidence limits#
Marketing Wiki did not inspect a Prezly experiment, Migma audience, consent record, suppression list, or send. The vendors document the current selection and control surfaces. The set equation, count ledger, and edge-sampling method are portable controls, not evidence that a product’s suggestion is accurate or legally sufficient.
Sources behind this page
Claims remain tied to dated source review. Method and corrections stay public.