Pruning the segments nobody uses
Most programmes carry hundreds of saved segments and use a dozen. How to audit the list, delete safely, and rebuild the survivors on definitions people agree with.
Open the audience list in almost any mature marketing platform and you will find several hundred saved segments. Scroll down and the names tell the story: "VIP_test_FINAL", "Xmas high value copy 2", "Segment - Anna", "do not use - broken".
Nobody made that mess deliberately. Each one was a reasonable five-minute decision by somebody under deadline, and the platform made creating a new audience easier than finding the right existing one. Repeat that weekly for three years and this is what you get.
The cost is not storage. It is that two campaigns aimed at the same people now use different definitions of those people, so their results cannot be compared and neither can be trusted. It is also that every new starter inherits a list they are afraid to touch.
Start by counting, not by judging
Before anyone argues about which segments matter, get the facts out of the platform. Most tools can export the audience list with metadata; where they cannot, the API usually can.
For each segment, pull:
- Name, creation date, and who created it.
- Date it was last edited and date it was last used in a send or journey.
- Current membership count, and the count six months ago if history exists.
- Whether it is referenced by any live journey, template or integration.
- Whether it is static or rule-based, and if rule-based, the rule in full.
Sort by last used. In most programmes we audit, a small handful of segments account for nearly all sending, and the long tail has not been used in a year or more. That distribution is the argument. You are not proposing to delete work, you are proposing to delete things that have already stopped existing in practice.
The four ways a segment goes stale
Not everything in the tail is dead weight, and knowing why something went stale tells you whether to delete it or fix it.
The one-off that never got cleaned up. Built for a single campaign, used once, never deleted. This is most of the tail. Delete without ceremony.
The one whose underlying field changed. The rule still references a field that stopped being populated, or a value the source system renamed. It runs without error and returns a smaller audience every month. These are dangerous, because they look alive.
The one nobody can reproduce. A static list uploaded from a spreadsheet two years ago, with no record of how it was built. It may still be commercially useful, and it can never be refreshed, which makes it a liability dressed as an asset.
The one that was overtaken. A behavioural segment built on signals that no longer arrive the same way. We wrote about signal decay in the piece on cookies staying put. The practical effect is that segments built on cross-site behaviour age faster than those built on your own first-party events.
Tag each row in the export with one of those four, plus "keep". The tagging is the audit.
A deletion protocol that nobody can block
The reason these lists never get pruned is that deletion feels irreversible and somebody always says "wait, I might need that". Remove both objections with a process.
- Export the full definition of every segment before touching anything. Rules, counts, creator, the lot. Keep the file in the client's own storage.
- Rename rather than delete first. Prefix the candidates with an archive marker and a date. They drop to the bottom of every picker and stop being chosen by accident.
- Wait one full campaign cycle, usually a month. Anything somebody genuinely needed will surface, loudly, in that window.
- Disable rather than delete at the end of the wait, if the platform allows it.
- Delete in one batch, on a scheduled date, announced in advance.
Two exclusions apply throughout. Never archive anything referenced by a live journey until the journey has been rewritten, and never archive a suppression list. Suppression is the one category where a mistake reaches customers, and consent-derived lists in particular should be treated as untouchable infrastructure.
Rebuild the survivors on definitions people agree with
Pruning without rebuilding just delays the regrowth. The survivors need to become a small set of shared, named definitions that everybody uses instead of rolling their own.
Three layers cover most programmes. Lifecycle state, which says where someone is in their relationship with you. Value, usually an RFM or spend-band cut. And declared preference, which comes from what people have told you rather than what you inferred, and which your preference centre should already be writing back to the profile.
Each definition gets written down away from the platform: a plain-English sentence, the fields it depends on, the owner of those fields, and the refresh frequency. That is a data contract in its simplest useful form, and it is what stops "active customer" meaning three different things in three different reports.
Where the same customer exists in several systems, the definitions belong at the single customer view layer rather than inside the sending tool. A segment defined once upstream and pushed to every channel stays consistent. A segment rebuilt in each platform will drift within a quarter, because someone will fix a rule in one place and not the others.
Keep the count low on purpose
The list grows back unless the conditions that produced it change. Four habits do most of the work.
- Give every new saved segment an owner and an expiry date at creation. A field for "review by" is enough; anything past its date without a recent use goes into the next archive batch.
- Enforce a naming convention with a prefix that says what kind of thing it is. Campaign one-offs get a prefix that marks them as disposable from the moment they are created.
- Build campaign audiences as a saved core segment plus a campaign-specific filter, rather than as a new standalone rule. The core segment stays maintained, the filter is throwaway.
- Put the audit on the calendar quarterly. It takes an afternoon once the export exists, and it never again takes the two weeks that the first one does.
The measure of success is not the count itself. It is being able to ask "who is in our active file" in a meeting and getting one answer rather than a discussion.
What to do this week
- Export the full segment list with last-used dates and membership counts, and sort it by last used.
- Tag every row as one-off, broken field, unreproducible, overtaken or keep, and count how much of the list falls outside "keep".
- Rename the first batch with an archive prefix and a date, then agree the deletion date with whoever owns the platform.
- A preference centre people actually fill in · 28 July 2024
- Chrome keeps third-party cookies: what changes for CRM · 24 July 2024