A segmentation framework your team can actually maintain

Every programme we inherit has a segmentation deck somewhere. It has personas with names like Ambitious Amir, a colourful grid, and no connection at all to the audience definitions running in the platform.

The gap exists because the deck was written by strategists and the segments are built by whoever is closest to the send button. Under deadline, people build what the tool makes easy, and the framework quietly stops being used.

So we build segmentation the other way round. Start from what the data can support, keep the number of definitions small, and give every segment a named owner and a refresh rule.

Separate the three layers before you name anything

Confusion comes from treating three different things as one. Pull them apart and most segmentation arguments resolve themselves.

The first layer is state: facts about where someone is right now. Subscribed, active, lapsed, churned, trialling, high value. State is mutually exclusive, so every contact sits in exactly one bucket, and it drives which programme they belong to.

The second layer is attribute: durable descriptive facts such as market, language, product held, acquisition channel and lifecycle start date. Attributes stack freely and drive content selection within a programme.

The third layer is behaviour: what somebody did recently, expressed as a time-bounded event. Viewed a category twice in seven days, abandoned a basket, opened four of the last five sends. Behaviour is volatile and drives triggers, not list membership.

Write each layer on a separate page. If a proposed segment mixes all three, it usually belongs in the triggers rather than the audience structure.

Keep the base set small and countable

We aim for six to ten state segments covering the whole file, with no gaps and no overlaps. Every contact must resolve into one, including the awkward ones such as unsubscribed purchasers and staff accounts.

For each state segment, record four things in a single document:

• The definition in plain English, in one sentence, with no conditionals.
• The technical definition, as the actual query or platform filter, copied verbatim.
• The current count, with the date it was counted.
• The named person who approves changes to the definition.

Count them all and add the numbers up. If the total does not match your total addressable file, the definitions have gaps or overlaps, and that is a genuinely useful thing to find before a campaign goes out.

Resist the request for a special segment for a single campaign. Those definitions live forever, drift from the base set, and are the main reason programmes end up with four hundred audiences nobody understands.

Give every segment a refresh rule and an owner

A segment without a refresh rule is a snapshot pretending to be a definition. Write down how often each one recalculates, and where the calculation happens.

Decide deliberately between warehouse and platform. Complex state logic belongs in the warehouse where it can be tested and versioned, then synced into the platform as a simple attribute. Fast behavioural logic belongs in the platform, close to the trigger.

We put the state layer in the warehouse, refreshed nightly, and let the platform own behaviour in real time. That split keeps the expensive logic in one testable place and the fast logic where latency matters.

Ownership is the part teams skip. Each segment needs one person who approves definition changes, and a changelog entry every time a definition moves. Without that, two people optimise the same audience in opposite directions and nobody can explain the drop in performance.

Decide what personalisation each segment earns

Not every segment deserves bespoke content. Personalisation costs production time, and a variant that nobody measures is pure overhead.

We grade each segment into three tiers.

Tier one gets a dedicated creative treatment and its own reporting. Tier two gets modular blocks swapped inside a shared template. Tier three gets the default, with only the greeting and the product feed varying.

Sizing decides the tier. A segment below roughly two per cent of your addressable file rarely justifies bespoke creative unless its value per customer is exceptional. Be honest about that, and put the saved time into the segments that move revenue.

Review the tiers quarterly against performance. Segments graduate and segments get demoted, and both are normal. The framework exists to be edited, not admired.

Test the framework against your existing programmes

Before you roll anything out, run the new structure against what you already send. Take the message inventory from your audit and map each message to a state segment, an attribute filter and a behavioural trigger.

Anything that will not map is telling you something. Either the framework has a gap, or the message is targeting an audience nobody can defend. Both findings are worth having before launch.

We usually find two or three messages with no home, and they are almost always legacy sends that should have been retired at the audit stage. Fixing the segmentation becomes a good excuse to switch them off. Helping teams get to that structure is a large part of what we do in CRM strategy.

What to do this week

• Write your state, attribute and behaviour layers on three separate pages, and move any mixed definitions into the layer where they belong.
• Document the six to ten state segments with plain English definitions, technical definitions, current counts and named owners.
• Add up the segment counts and reconcile the total against your addressable file, then investigate every gap and overlap you find.