Email Operations5 min read

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
Direct answer

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#

Scroll table →
FieldExample
Seed typesaved list, natural-language suggestion, lookalike, imported IDs
Seed query/versionexact filter or immutable query ID
Source systemsCRM, product database, preference center
Evaluation timestampwhen dynamic conditions were resolved
Seed countbefore permission and exclusions
Missing-data policyexclude, hold for review, or approved fallback
Suggested rationalewhy the tool included each class of contact
Ownerperson 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:

  1. establish whether the message is marketing, transactional, or another governed class;
  2. confirm the recipient’s permission or expected relationship for that class;
  3. apply global suppression and contact-state restrictions;
  4. evaluate relevance and campaign-specific eligibility;
  5. apply frequency caps and fatigue rules;
  6. 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:

Scroll table →
StageInputRemovedOutputEvidence
Suggested seed——12,480query ID and timestamp
Purpose eligibility12,4801,21011,270rule version
Permission11,27089010,380consent-source report
Suppressions10,38014210,238suppression snapshot
Frequency caps10,2385039,735send-history window
Deduplication9,735379,698canonical 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.