Key takeaway
Email segmentation splits one list into groups defined by a rule, so a send goes to the people the message is for. The version that works isn't a folder people get sorted into, it's a query that re-evaluates every time it runs. Build three before anything else: engaged in the last 90 days, lapsed, and new in the first 30. A 90-day window that was right at 5,000 contacts is usually wrong at 50,000, so I re-cut mine whenever the list doubles.
What email segmentation actually is.
Email segmentation is splitting one list of contacts into groups defined by a rule, so that a send goes to the people the message is actually for. A list is who you have. A segment is a rule over them. Personalization is a third thing, because it changes what the message says rather than who receives it. The distinction that decides everything downstream is the one almost nobody follows through on: a segment is a query, not a folder. It's a definition that gets re-evaluated every time it's used. A segment built by exporting a CSV and filtering it in a spreadsheet is a photograph, and it was true on the day it was taken. Everything below assumes the rule runs at send time, and a stack that can't do that is doing something else.
A rule in practice is plain. Opened something in the last 90 days. Bought twice. Joined this week. Sits in this country, on this plan. Each one is a condition over fields you already hold, and the segment is the standing answer to it.
Which is why a contact belongs to several segments at once and is never moved into any of them. Somebody who joined last week, opened twice, and bought once is in three groups simultaneously, and no operation put them there. That's where the folder metaphor stops being useful, and it's worth killing early: most segmentation mistakes come from treating a segment as a place people are kept. I've watched more segmentation projects stall on that one idea than on any rule anybody wrote.
The data a segment can be built from.
A segment is only as good as the fields underneath it, and most segmentation plans fail at the data step rather than at the rule step. So the first useful exercise isn't designing a taxonomy. It's listing what you already record, honestly, including the custom field that's populated on a handful of contacts and can't carry a rule.
What you hold falls into four kinds:
- Declared data: what the contact told you. Signup fields, preference-centre choices, and custom fields on the contact record.
- Behavioural data: what they did with the email. Opens, clicks, and how recently, which is the input the next section leans on hardest.
- Transactional data: what they bought or did in the product, arriving over an API or an integration rather than from the email itself.
- Contextual data: where they came from and where they sit in the lifecycle. Source, signup date, plan, and country.
Declared data ages badly and behavioural data doesn't. A stated interest from a signup form two years ago is a claim about a person who has since changed, while a click last Tuesday is an observation. A segment that mixes the two should lean on the behavioural half and keep the declared half as a tiebreak.
There's a limit sitting over all four, and it isn't technical. What you may segment on is a narrower set than what you happen to store: data collected for one purpose doesn't automatically become a targeting dimension, and the rules that govern that vary by where the contact sits. It's a question worth asking before the rule is built rather than after it has been running for a quarter.
Grouping customers by manual labels scales poorly. Our own recommendation engine ignores them completely. The architecture we detailed on QA Selling Online avoids static lists entirely. The system "doesn't run on tags" at all. We build segments by finding similar products and similar people instead.
Three segments to build before any others.
The honest answer to "how many segments" is fewer than the ideas-list posts suggest. Those posts run to eleven or fifteen because enumeration is what makes a page long, not because a programme that size is one anybody maintains. Three is enough to beat a single unsegmented send, and if you never build a fourth you'll still have taken most of the available win.
- Engaged in the last 90 days. Anyone who opened or clicked inside the window. This is the segment that protects every other one, and it's where a send goes whenever anything about it is uncertain.
- Lapsed. On the list, no engagement in the window, and not yet suppressed. These people need a different message at a lower frequency, not the same campaign a fourth time.
- New in the first 30 days. They know the least about you and they're the most likely to act, which is a combination you never get back. Their sequence is the one worth writing separately.
Those three answer different questions, which is what earns them the effort: one protects the sending reputation, one contains a risk, and one converts. The first does the most work, because a new template, a bigger volume than usual, or a domain that's still warming all go there before they go anywhere else. A fourth is a decision about how much content you can write, not about what the tooling allows, and it's worth taking on those terms.
A basic product recommendation campaign requires almost no setup. It also generates the best returns. The platform metrics we reviewed on QA Selling Online prove the point. The "revenue per email sent is the highest" across all accounts using these simple targeted sends.
Segmentation is a deliverability control, not just a relevance trick.
Mailbox providers judge you on how recipients react, and they measure that reaction across everything you send rather than campaign by campaign. So who is in the send is a reputation decision before it's a marketing one, which is the half of segmentation the guides file under benefits and never return to. I'd treat the engaged segment as a deliverability control first and a relevance one second.
The thresholds are published. Google's sender guidelines tell bulk senders to keep the Postmaster Tools spam rate below 0.10%, and never to let it reach 0.30%. Yahoo's sender best practices carry the same 0.30% ceiling and add two rules that are segmentation rules in everything but name: honour the frequency the list opted into, and monitor inactive recipients rather than keep mailing them.
The cheapest way to sit under those numbers is to stop sending to people who stopped reading, and that's a segment. The most common version of this we see is a programme that has never separated the two groups: one audience, one frequency, and a complaint rate that averages a healthy population against a hostile one. Splitting them doesn't improve anybody's opinion of you. It stops you asking the people who already dislike you for another vote. Put more bluntly: engagement is a primary signal now, and a chronically unengaged list out-loses a smaller engaged one every time, which is the case for auto-suppression over a manual quarterly clean.
There's a mechanism under it, worth knowing rather than taking on faith. Abandoned mailboxes get recycled into spamtraps, so an address quiet for a year isn't neutral, it's a risk that grows. Spamhaus calls the remedy a sunset policy: segment on engagement, suppress on it, and expect an address unengaged for anywhere from three to twelve months to be treated as fair game.
None of it makes an unengaged contact worth more than they were. Re-engagement often causes the damage it was meant to prevent, because a campaign fired at the whole lapsed group at once is the largest low-quality send you'll ever make. Stagger it, and watch the complaint rate between batches.
How to build a segment, end to end.
The order matters, because four of these five steps are about the rule and only one is about the send. Most advice inverts that and starts in the builder, which is how a workspace ends up with thirty segments nobody can state the purpose of.
- Write the question first, in a sentence. "Who bought once and hasn't opened in 60 days" is a specification you can build. "Loyal customers" is a mood.
- Check the field exists before you design the rule. If nothing records the signup source, no segment can use it, and the fix is a change to what you collect rather than a cleverer rule.
- Write the rule so it re-evaluates. A membership computed at send time is a segment. A static import of contact IDs is a list wearing a segment's name.
- Send against it and keep something to compare with. A holdout, or the last unsegmented send. Otherwise the result is a number with nothing to read it against.
- Put a review date on the rule. A 90-day window that was right at 5,000 contacts is usually wrong at 50,000, and nothing tells you except looking.
The review step is the one that gets dropped, because it's the only step with no immediate output. That's also how stale rules happen: a segment nobody has reread since the product changed underneath it.
What segmentation can't do for you.
Content capacity is the real ceiling and it arrives sooner than anybody plans for. Twelve segments means twelve messages somebody has to write, and a segment that gets served the same email as everybody else is overhead with no upside attached. Most programmes run out of writing long before they run out of rules.
Small lists hit a different wall. Split a few thousand contacts eight ways and the per-segment results stop being readable: you get a difference between two groups and no way to tell whether it's a difference. The arithmetic doesn't care how good the rule was.
Stale rules are the dangerous ones, because they fail silently. A segment written against a product that has since changed keeps returning people and keeps looking healthy, and the only symptom is a slow drift in who receives what. Nothing flags a rule that's still valid syntax and no longer valid logic.
Then there's the segment that's really a data problem. A group full of addresses that never engage is usually telling you something about how they were collected rather than something about the audience, and Spamhaus on spamtraps puts it plainly: chasing the symptom isn't the fix. Segmenting those contacts into a bucket of their own organizes the problem without touching it.
None of that is a tooling problem. The one thing tooling genuinely decides is whether the rule is an object you can inspect, change, and rerun, or a state saved inside a screen.
Retail segmentation tactics fail completely on a content newsletter. We learned this early on and decided to ignore blogs entirely. The product roadmap we discussed on Developer Podcast reflects this hard boundary. We ensured "we built SmartrMail to be purely for ecommerce" from day one. Narrowing the focus is the only way to build a functional recommendation engine.
Running segments from one agent command.
Nitrosend is MCP-first: every capability is an API endpoint and an MCP tool before it's a screen. Segments are among them, alongside contacts, lists, campaigns, flows, suppression, and events. A segment is an addressable object rather than a state saved in a builder, so the same command that defines it can send against it. Every other platform grew its agent on top of a builder that still owns the segment's state. The agent drives the screen and never holds the object, which is a different thing from a segment an agent can define, read, and rewrite directly.
That changes which of the five steps needs a person. Writing the question is judgement and stays yours. Checking that a field exists, rebuilding a rule when the window has drifted, and holding the review date are all things an agent can do on a schedule, which is the difference between a review step that happens and one that sits on a list. Contacts are unlimited on every plan, including Free, so the usual reason a segmentation plan gets trimmed doesn't apply. Transactional segments run on the events you send us, and there's no product-feed sync with an ecommerce storefront. Nitrosend specializes in email, and this is the part of email it's built to run.
You now have three segments worth building and a review step nobody keeps up with. The free tier covers both: 8,000 emails to start, then 500 a month, unlimited contacts, and full MCP, API, and CLI access, with no credit card. Build the engaged, lapsed, and new segments, point your agent at them, and let it hold the review date you'd otherwise forget.
Go deeper
Sources
- Google, Email sender guidelines: the instruction to keep the spam rate reported in Postmaster Tools below 0.10%, and never to reach 0.30%.
- Yahoo, Sender best practices: the 0.30% complaint ceiling, honouring the frequency the list opted into, and monitoring inactive recipients.
- Spamhaus, sunset policies: engagement segmentation plus engagement-based suppression, recycled spamtraps, and the three to twelve month window providers work to.
- Spamhaus, spamtraps and the symptom: a list full of non-engagers is a collection problem, and chasing the trap treats the symptom.
Common questions
A list is a set of contacts you hold. A segment is a saved question asked of that set, and it's answered again every time you send, so nobody is ever added to one or taken out of one. The practical difference is maintenance: a list has to be kept, while a segment only has to still be the right question, and one contact can match several of those questions at once.
No. Segmentation decides who receives the message. Personalization decides what the message says once it's been sent to them. They work well together, and a lot of programmes reach for personalization tokens when the real problem is that the wrong people are on the send.
Whatever your next message actually is. The first three (engaged, lapsed, and new) are all defined by engagement, so a fourth usually has to come from somewhere else: something a contact bought, the plan they're on, or the country you send different terms to. Build it when the message exists rather than when the rule occurs to you, and retire it once nobody is writing for it.
Less than most guides suggest. Engagement recency alone supports the three segments above, and it's data your sending platform records without anyone configuring it. Declared fields, transactional history, and lifecycle context widen what you can build, but the first exercise is listing what you already record rather than designing a taxonomy you can't populate.
Yes, and the thresholds are published. <a href="https://support.google.com/a/answer/81126" rel="nofollow noopener">Google's sender guidelines</a> tell bulk senders to keep the Postmaster Tools spam rate below 0.10% and never to let it reach 0.30%, and Yahoo publishes the same 0.30% ceiling. Those rates are read across everything you send rather than campaign by campaign, so one send aimed at people who stopped reading is charged against the mail your best customers get. Leaving that group out is a segment, and it's the cheapest control on the list.
A well-built segment updates itself, because the rule re-evaluates every time it runs. What needs a schedule is the review of the rule: whether the window is still right, whether the field it reads still means what it meant, and whether anyone still sends to it. Put a date on that when you create the segment.
Easily, and the limit is arithmetic rather than taste. Divide a small list far enough and each group returns too few opens for the gap between two of them to mean anything, so you end up acting on noise. Writing is the second limit, because every segment worth having needs its own message. On a small list the better move is fewer rules held for longer, which gives each one enough sends to be judged on.
With Nitrosend, yes. Every capability is an API endpoint and an MCP tool before it's a screen, and segments sit alongside contacts, lists, campaigns, flows, suppression, and events. That means a segment is an addressable object rather than a state saved in a builder, so an agent can define one, send against it, and revisit the rule on a schedule.