Purchase History Segmentation: Targeting Buyers and Browsers
Splitting on what someone bought, how recently, and how often — plus the one-purchase group most senders mishandle.
On this page
The short version
- Three splits do most of the work: what they bought, how recently, and how often. Everything more elaborate is usually a variation on those.
- The single-purchase group is the largest and the most mishandled — treated either as a customer who will buy again or as a prospect who has not bought, when it is neither.
- Suppression matters more here than segmentation. Selling someone what they already own is the fastest way to look like nobody is paying attention.
Purchase data is the strongest segmentation input available, because it is behaviour that cost money. It is also the one most often stuck in a system that does not talk to the email platform, which is why so many programmes have it and do not use it.
Three splits carry most of the value, and they are the same three that underpin RFM scoring — which is worth knowing, because it means you can get most of the benefit without building the full model.
The three splits and what each is for
| Split | Answers | Changes |
|---|---|---|
| What they bought | What are they interested in? | Which products you mention |
| How recently | Are they still active? | Whether to sell or to re-engage |
| How often | Are they a repeat customer? | Tone, offers, whether to ask for a referral |
| How much | What can they justify? | Which tier you present |
| What they viewed and did not buy | What did they consider? | What to answer |
The single-purchase group
On most lists this is the largest customer segment, and it gets handled badly in one of two ways.
Treated as a customer, they receive loyalty messaging and repeat-purchase offers appropriate to someone with an established habit. They do not have one — they bought once and have no particular attachment.
Treated as a prospect, they receive acquisition messaging for a product they already own, which reads as the sender having no idea who they are.
The correct handling is its own sequence: confirm the purchase was a good decision, help them get value from it, and only then suggest what comes next. The second purchase is a different decision from the first and the first was not evidence that it will happen.
Recency needs a scale, not a threshold
"Bought in the last ninety days" is meaningless without knowing how often people normally buy. For a consumable ordered monthly, ninety days is a lapsed customer; for something bought annually, it is a recent one.
Set the bands from your own repurchase interval. Take the median gap between first and second purchase and build the recency bands around it — active is within one interval, cooling is one to two, lapsed is beyond that.
That one calculation makes every recency segment meaningful and it is available from data you already have.
Joining purchase data to email
The join is on the email address, and it is where this usually breaks. Someone who ordered as a guest with a different address, or with a plus-tagged variant, or with a typo, will not match — and they will receive the wrong email as a result.
Normalise on both sides before joining: lowercase, trim, and decide deliberately whether to strip plus-tags. Then measure the match rate, because an unmeasured join quietly failing on a fifth of customers is the sort of thing that persists for years.
Where a customer genuinely has two addresses, the honest answer is that you have two records and should suppress both from acquisition messaging rather than trying to merge them automatically.
Purchase segmentation check
- Recent buyers are suppressed from acquisition messaging
- Nobody is sold what they already bought
- Cart reminders stop when the order completes
- Recency bands are derived from your own repurchase interval
- Single-purchase customers have their own sequence
- The email join is normalised on both sides
- The match rate between orders and subscribers is measured
Frequently asked questions
How long should a purchase suppress promotional email?
At least through the delivery and any return window. Beyond that it depends on the product — for something repurchased monthly a fortnight is right, for a durable good it is far longer.
What about people who browsed but never bought?
That is behavioural rather than purchase data, and it is worth treating separately. What they viewed tells you what to answer; the absence of a purchase tells you the objection was not resolved.
Do I need an integration to do this?
A regular export of purchases keyed by email address is enough to start, even a daily file. Real-time integration matters for suppression timing, which is the case worth building it for.