Quick Summary
To segment email lists by behavior, build your segments from tracked events like opens, clicks, site visits and purchases, then give each rule an event, a count and a recency window. Start with one event and one window, and add a second condition only if the segment stays large enough to mail.
- Name every tracked event in snake_case, lowercase, past tense, with one shared definition.
- Size recency windows at roughly two to three times your typical deal or repurchase cycle.
- Require at least 100 contacts before a segment goes live and 200 before it gets targeted content.
- Hold back 10 percent of every targeted send as a control group.
- Retire any segment that underperforms the parent list on three of four KPIs for two months.
What Behavioral Segmentation Actually Changes
Behavioral segmentation groups subscribers by what they did, rather than by whatever they typed into a signup form eight months ago.
Most teams start with demographic buckets. Then they wonder why a careful newsletter and a hard pitch both get the same shrug from the same people. Sorting by action fixes more of that than another round of persona work will, which is an annoying thing to discover after you have already built the personas.
A behavior segment changes who gets a message and when they get it, and usually it changes what the message asks for as well. Get those lined up and unsubscribe rates fall.
The Behavioral Data You Need Before You Build a Segment
The events feeding a segment set its ceiling. For most teams, opens, clicks, site visits and purchase or reply history are enough to work with.
Build an event taxonomy before you build segments
An event taxonomy is a fixed list of tracked actions, each with one name, one definition, and one owner. Skip it and the same action shows up as email_opened from one tool and opened_email from another, and no rule can join them.
Something like this is enough to start:
| Event name | What it records | Source | Key property |
|---|---|---|---|
email_opened | A tracked open on a platform send | Email platform | campaign_id |
email_clicked | A click on any tracked link | Email platform | link_url, campaign_id |
email_replied | A reply detected on a sequence | Email platform | sequence_id |
page_viewed | A page load on your site | Site analytics or pixel | page_path |
pricing_viewed | A visit to a pricing page | Site analytics or pixel | page_path |
purchase_completed | A completed order | Store or billing system | order_value |
cart_abandoned | A cart started and not completed | Store | cart_value |
Name every event in snake_case, lowercase, past tense, and write the definition down somewhere shared, so two people cannot quietly disagree about what counts as a visit.
Where each event actually comes from
Email opens and clicks come from your sending tool. Platform sends in SEMAOS track both by default.
Site events come from a pixel or from UTM-tagged links. UTM tags are cheaper to set up: tag every link with utm_source, utm_medium, and utm_campaign, and your analytics can attribute the visit back to the send that caused it.
Purchase and reply events come from your store or billing system and from reply detection.
Rules, thresholds, and recency windows
A rule needs an event, a count, and a time window. "Clicked a link in the last 30 days" qualifies. "Clicked a link" does not, because it will happily match someone who poked at a footer link in 2023. Size the windows off your sales cycle, somewhere around two to three times the length of a typical deal or repurchase cycle:
| Cycle length | Suggested recency window | Example rule |
|---|---|---|
| Under 30 days | 14 days | email_clicked at least once in 14 days |
| 30 to 60 days | 30 days | pricing_viewed at least twice in 30 days |
| 60 to 120 days | 90 days | email_opened at least once in 90 days |
| Over 120 days | 180 days | purchase_completed at least once in 180 days |
Counts matter as much as windows. One click is a signal of mild curiosity. Three clicks in a week is a person with a problem they want solved this month. Start with a count of one and raise it only if the segment stays big enough to mail.
Segments that stack too many conditions shrink to nothing. Start with one event and one window, then add a second condition only if the first segment stays large enough to mail. A segment of 40 contacts is a manual list wearing a costume.
Connect the data before you trust the rule
A segment rule breaks the moment the join between your sources breaks, and it breaks silently, which is the worst kind. The email address is the join key, so every event has to carry the same normalized address: lowercase, trimmed, no plus-addressing surprises. If your store records Jane+Shop@Example.com and your platform records jane@example.com, the purchase event never reaches the segment and Jane keeps getting the first-time-buyer discount. Before you trust anything, pick ten contacts, pull every event attached to them, and read the timeline end to end. It takes an afternoon and it is the only part of this process I have never regretted doing.
Step 1: Map Your Segments to the Customer Journey
Journey mapping comes first because it tells you which segments are worth the maintenance. Write out the stages a subscriber moves through, then attach one behavior to each stage.
Something along these lines:
| Journey stage | Behavior signal | Segment purpose |
|---|---|---|
| New subscriber | Joined in last 14 days | Welcome and orientation |
| Engaged | Opened or clicked in last 30 days | Regular sends |
| Interested | Visited pricing or product page | Nurture with proof |
| Ready | Replied or requested a demo | Direct follow-up |
| Dormant | No opens in 90 days | Re-engagement or removal |
Each row turns into a segment with its own rules. Once the stages are settled, the next job is building the follow-up sends that act on them.
Step 2: Build the Segment Rules in Your Email Platform
With a journey map in hand, this part is mechanical. Open your platform's segment builder and create one segment per stage.
For each segment, set:
- The trigger event, such as a click or a page view
- The count, such as one or more
- The recency window, such as the last 30 days
- The exclusion, such as anyone who already replied
The exclusion is the one people skip, usually because the builder makes it optional. Excluding recent repliers is what stops a nurture sequence from pitching someone who already said yes last Tuesday.
Branching logic splits a sequence by opens, clicks, replies, or engagement score.
Email Segmentation Examples You Can Copy Today
Four behavior segments most teams could ship by Friday:
- Clicked a link in the last 14 days and never replied. Send a direct question.
- Viewed the pricing page twice in 30 days without booking a demo. Send a case study.
- Bought more than once. Send the advanced offer instead of the beginner pitch.
- Opened four of the last five sends and clicked nothing. Send something with a different ask, or stop sending for a month.
Not every sending tool can hold compound conditions or refresh them on a schedule, and it is worth finding that out before you design around it.
Behind each of those is an event, a count and a window. Keep the structure, swap in whatever your own taxonomy calls things.
Email Engagement Segmentation: Scoring Contacts 0 to 100
An engagement score compresses a lot of small behaviors into one number, so a team can tell who is warm without reading event logs all morning. On paid plans and the trial, SEMAOS recalculates a score from 0 to 100 per contact every night and sorts contacts into five heat tiers. For turning that number into a follow-up order, see how to use email engagement scores to prioritize leads.
How the email engagement score turns behavior into tiers
The top three tiers:
- Hot: 80 and up
- Warm: 60 to 79
- Cool: 40 to 59
Replies do not feed the score, which is worth remembering before you treat it as a full picture of intent. Use the tiers to decide what gets sent first. The score and the heat tiers are part of the full SEMAOS feature set, which shows how scoring sits alongside sequences and broadcasts.
Email Segmentation Best Practices for Small Teams
A small team needs segments it can maintain without hiring an ops person for them, which mostly means fewer segments and rules simple enough to explain out loud.
Set a minimum audience size before you build
Below a certain size, a segment is just a manual list with extra configuration. A workable floor is 100 contacts for going live and 200 before a segment gets its own content. Those numbers are rules of thumb rather than statistics, and having any floor at all is most of the benefit. Under them, merge segments or mail the parent list.
| Segment size | What to do |
|---|---|
| Under 100 | Do not build. Merge into the parent segment. |
| 100 to 199 | Build, but send the same message as the parent. Use it for reporting only. |
| 200 and up | Build and send targeted content. |
| About 3,000 and up | Big enough to A/B test two subject lines inside the segment. |
Testing is a much higher bar than targeting. You need about 1,500 recipients per variant before a 5-point difference in open rate means anything, so most small-team segments are better tested on the parent list.
Write fallback rules for sparse data
Sparse data is the normal case, not the edge case. New subscribers have no click history. Long-cycle buyers have no recent purchase. A contact who only ever gets mailbox sends may have no tracked opens at all. Without a fallback, every one of those people quietly falls out of your sending.
A chain that works:
- If the contact matches the primary rule, send the targeted message.
- If the contact has no events in the window, send the parent-list message.
- If the contact has no events in twice the window, move them to the re-engagement segment.
- If the contact has no events in three times the window, suppress.
Write it down. A fallback chain that lives in one person's head stops existing the week that person is on holiday.
Test at the segment level, with a control group
Test one variable at a time. A/B testing a broadcast without wrecking your sample covers how to split on subject or body and how big a test slice has to be before the result means anything.
A plan small enough to actually follow:
- Hold back 10 percent of the segment as a control.
- Send the targeted message to the other 90 percent.
- After seven days, compare open rate, click rate, reply rate and unsubscribe rate across the two groups.
On a segment of a few hundred, the holdout is a few dozen people, so only a large gap tells you anything. Pool several sends to the same segment before you call the targeting a win or a loss.
SEMAOS broadcast A/B tests support up to three variants of subject or body. By default they split the whole list. As an opt-in, they go to a test group first (20 percent by default), and after a wait (4 hours by default) the winner goes to everyone else. If no variant wins clearly, the platform sends variant A.
Track segment-level KPIs, not just list-level ones
List-level open and click rates will happily hide a segment that is quietly annoying people. Track four numbers per segment, monthly:
| KPI | What it tells you |
|---|---|
| Open rate | Whether the subject lands with this group |
| Click rate | Whether the content matches the behavior |
| Reply rate | Whether the segment is warm enough for a direct ask |
| Unsubscribe rate | Whether the segment is being over-mailed |
If a segment loses to the parent list on three of those four for two months running, retire it or rebuild the rule. The more interesting case is a segment that beats the parent on clicks and replies while its unsubscribe rate climbs. That is usually over-mailing rather than bad targeting, so cut the frequency before you cut the segment.
Keep the maintenance load small
Three habits that keep this from turning into a second job:
- Cap live segments at what one person can audit in a monthly sitting. For most small teams that lands around five to eight.
- Name segments in plain language. "Clicked pricing, 30 days" beats
seg_pricing_30d_v2, especially six months later. - Retire any segment that has not sent in 60 days.
Privacy, Consent, and Keeping Segments Accurate
A behavior segment built on stale or unconsented data is a legal problem and a deliverability problem at the same time. Every send needs an unsubscribe link and a postal address, and suppression checks have to run before the send goes out, not after someone complains.
Three habits keep segments honest:
- Honor opt-outs quickly and pull those contacts out of every segment, not just the one that mailed them
- Purge contacts with no activity after a window you have decided on in advance
- Re-read your segment rules every quarter, because the product changes and the rules do not
For teams sending outbound, the rules that actually apply are covered in CAN-SPAM compliance for cold outbound.
If you only take one thing from this: put the quarterly rule review and the monthly KPI check on an actual calendar, with a name attached. Segment rot is slow and nobody notices it until a campaign underperforms for reasons that look mysterious and are not.
FAQ
What is behavioral email segmentation?
It groups subscribers by what they actually did (opens, clicks, page views, purchases, replies) rather than by demographic details they typed into a signup form. Each segment is defined by an event, a count, and a recency window.
How big should a recency window be?
Size it at roughly two to three times your typical deal or repurchase cycle. Under a 30-day cycle, use a 14-day window; 30 to 60 days, use 30; 60 to 120 days, use 90; over 120 days, use 180.
How small is too small for an email segment?
Under 100 contacts, do not build it; merge it into the parent segment. Between 100 and 199, build it for reporting but send the parent message. Send targeted content from 200 up. A/B testing needs far more: about 1,500 recipients per variant to trust a 5-point difference in open rate.
What should I do about contacts with no tracked events?
Write a fallback chain: match the primary rule and get the targeted message; no events in the window and get the parent-list message; no events in twice the window and move to re-engagement; no events in three times the window and suppress.