Audience segmentation: deciding who should not receive this

Audience segmentation is dividing a subscriber list into groups defined by shared characteristics or behaviour, so that a message can be targeted at the group most likely to want it. A segment is a query over your subscriber data, not a folder you drag people into.

That distinction has a practical consequence. A static list is a snapshot that decays from the moment it is created; a dynamic segment is a definition that re-evaluates, so someone joins or leaves automatically as they meet or stop meeting the criteria. Almost every segmentation problem in practice comes from a static list being used where a dynamic segment was meant.

Behavioural segments outperform demographic ones consistently, because what someone did predicts what they will do far better than what they are. 'Bought twice in the last ninety days' is a stronger signal than any attribute you could collect on a signup form.

The most valuable segment for most senders is also the least glamorous: the engaged segment. Restricting sends to people who have interacted recently protects sender reputation, which protects placement for everything else you send. It is the segment that makes the other segments work.

Suppression is the mechanism that stops you sending to people who have told you, directly or by behaviour, that they do not want it. It matters more than targeting because the cost of getting it wrong is asymmetric: a poorly targeted email underperforms, while a message to someone who unsubscribed can be both a spam complaint and a regulatory breach.

A suppression list must operate globally and take precedence over every segment. The common failure is per-list suppression, where unsubscribing from one list leaves someone eligible for another — technically a different list, but from the recipient's point of view the same sender ignoring them.

Suppression also has to survive imports. Re-uploading an old spreadsheet that reintroduces previously unsubscribed addresses is one of the most reliable ways to damage a sending reputation, and it usually happens by accident.

Custom fields store values; tags record facts. A field answers 'what is this person's plan tier' and holds one value at a time. A tag answers 'did this happen' and accumulates. Using one where the other belongs is the origin of most unmaintainable subscriber schemas.

The specific anti-pattern to avoid is encoding state in tag names — `plan-free`, `plan-pro`, `plan-enterprise` as three separate tags. Nothing prevents a subscriber holding all three simultaneously, and eventually someone will, because tag removal is easy to forget in one code path out of five. A single `plan` field cannot enter that state by construction.

Collect fewer fields than you think you need. Every field is something that can be wrong, and stale personalisation is more damaging than none — a message addressed to a role someone left two years ago demonstrates that the sender's data is unreliable.

Consent is granted for a purpose, and a segment cannot widen that purpose. Someone who subscribed to a product changelog has not consented to promotional campaigns simply because a segment can identify them as a good prospect for one.

Under both the GDPR and India's DPDP Act, the lawful basis attaches to the individual and the purpose, not to the list they happen to be in. In practice this means recording why each subscriber joined, and keeping that as a queryable property rather than an assumption about the list.

Where subscribers can choose topics, honour those preferences at send time rather than at signup only. A preference centre that records choices but does not enforce them is worse than not offering one, because it creates a documented expectation you are then visibly failing to meet.