Stop Sending Everyone the Same Message: User Segmentation for Vibe Projects

First, a fictional teaching example

Ayuan built a workout check-in app called "Seven-Day Ring". Three months after launch it had 8,000 users, and he wanted to promote a new feature: check in seven days in a row and get an advanced training plan. He wrote one broadcast message in the backend — "You're one step away from levelling up" — and sent it to all 8,000 people. That same day more than 300 unsubscribed, and the comments filled with complaints. What went wrong? Among those 8,000 people were newcomers who had registered a day earlier, people who had stopped checking in two months ago, and long-time users who had already bought the advanced plan. To a newcomer, "one step away" was nonsense; to someone who had stopped, the message felt like mockery; to an existing customer, it was repeat sales pressure. One sentence sent to 8,000 people in completely different situations was bound to offend most of them.

This example is fictional: the name, the product, the numbers, and the events are all made up to make a point. But the lesson behind it is real: users are not one crowd, they are a crowd of people in completely different situations. Segmentation exists to solve exactly this — "stop sending the same message to everyone". This guide covers how to do segmentation, how far to take it, and where to stop.

Scope first: what this guide covers, and what it does not

"Segmentation" is a wide word, so let us draw the boundaries first, or you will end up building a huge "user profiling system" that takes three months and still cannot ship.

First, analytics metrics are not segmentation. Daily active users, retention, and conversion tell you whether the product as a whole is healthy; segmentation tells you which groups of people are healthy and which are in trouble. The first is a dashboard, the second is a scalpel — do not build them as one feature.

Second, lifecycle email sequences are not segmentation. A sequence is about "what to send on day N of a user's journey"; segmentation is about "who this message should go to". A sequence needs segmentation to pick its recipients, but the sequence's copy rhythm and send intervals are another topic — this guide only covers how people get divided up.

Third, winning back churned users is not segmentation. Win-back is one application of segmentation: first separate out "the group that is drifting away", then act on them. But segmentation has far more uses than win-back — new-user onboarding, paid conversion, and feature promotion all use the same capability. This guide covers that shared capability, not any single scenario.

Fourth, cold start in recommendation systems is not segmentation either. Recommendation solves "what content to show this person"; segmentation solves "which people belong in one group". Recommendations can use segmentation results as an input, but the recommendation algorithm itself — collaborative filtering, content similarity — is outside this guide's scope.

With the boundaries drawn, this guide is about one thing only: how to divide users into meaningful groups, and how to make sure each group receives something appropriate for them.

Segmentation is not labelling: start from behaviour

Many teams take the wrong first step in segmentation: they start sticking labels on people. Male, female, twenty, thirty, from Beijing, from Shanghai. A pile of labels later, they still do not know who to send a message to — because demographic attributes answer "who is this person", while operations really needs to answer "what situation is this person in right now".

Situations are visible in behaviour. When was the last session, how many days in a row have they checked in, have they used the core feature, have they ever paid, are they still active after paying? Put those behaviours together and you have a person's current situation. Someone who registered three days ago and opens the app daily is in a completely different situation from someone who registered three months ago and has not opened it in two weeks — even if they are the same age, the same gender, and from the same city.

Behavioural segmentation has a classic starting point: recency, frequency, and monetary value — the RFM idea. When was the last activity, how frequent is the activity, how much money has been spent? Cross those three dimensions and you get the most basic groups: active paying users, active free users, dormant paying users, dormant free users, and newly registered users who have not started yet. Those five groups cover almost every distinction you need for any operations action. Split those five first, and only then consider going finer.

When you do go finer, judge by one test: "can I take a different action for this group?" Splitting "seven-day streak" from "thirty-day streak" is worth it if you plan to do completely different things for each; if you plan to do exactly the same thing for both, the split is pointless — it only makes the rules more complex and harder to maintain. Finer is not better. The right granularity is "every group maps to a different action", no more.

There is another common mistake: treating segmentation as a one-time job. Users move. Today's newcomer is next month's veteran; today's active user may be dormant next month. Segmentation rules must be recalculated regularly, at least once a day. Static lists are only for one-off campaigns — "send a survey to users who registered last month" — while ongoing operations need dynamic rules that let users flow naturally between groups.

Four ways to segment, and the trade-offs

There are four ways to implement segmentation, from simple to complex, with cost and capability rising together. Which one you pick depends on your user count and team size; pick wrong and you either cannot do enough or you overbuild.

The first is a static list. An operator hand-picks people, exports a list, and sends one message to that list. The advantage is zero development cost — you can be working in half an hour. The disadvantage is that the list is out of date the moment it is exported; when users' situations change, the list does not follow. It fits one-off campaigns, beta invitations, and small rollouts — not ongoing operations.

The second is static rules. Rules live in code or configuration, for example "registered more than seven days ago and active in the last three days". The rules never change, but the population is recalculated against them every day. The advantage is simplicity and predictable results; the disadvantage is that as rules multiply they become hard to manage, and changing a rule means changing code and redeploying. It fits the stage where user numbers are modest and segmentation needs are still simple.

The third is dynamic rules. Rules can be configured and changed by operators in the backend themselves, without waiting for developers. The population is recalculated against the rules in real time or daily, and when a rule changes, the population follows. The advantage is flexibility — operators can experiment on their own. The disadvantage is that a misconfigured rule affects real users immediately, so preview and testing features are mandatory. It fits the stage where user numbers are in the tens of thousands and operations actions are frequent.

The fourth is model scoring. An algorithm gives every user a score — churn risk, willingness to pay — and groups are formed by score. The advantage is finding patterns people cannot see; the disadvantage is the highest cost, needing data accumulation, model training, and effect evaluation, and the meaning of a score is hard to explain to operators. It fits the stage where user numbers are large and data is rich — not a product that has just started.

My judgement: the vast majority of vibe projects are fine starting with the second approach. Write a few static rules, split out the basic five groups, run them for a month or two, and see whether operations really needs more flexible rules before deciding to upgrade to dynamic rules. Jumping straight to model scoring is the most common form of overbuilding — the model is still being trained long after operations has run out of patience.

How to write rules that do not fight each other

Once rules multiply, they start fighting. One person matches both the "newcomer" rule and the "active user" rule — should they get the newcomer onboarding or the active-user content? Someone sits in both the "dormant" group and the "paying user" group — should they get a win-back message or a paying-user perk? If these questions are not settled when the rules are designed, they turn into user complaints after launch.

The first fix is priority. Give every rule and every send a priority; the highest priority runs first and the lower ones wait. When a person matches several rules at once, only the highest-priority one executes. For example, "paying-user perks" should outrank "dormant win-back", because sending a win-back message to a paying user is offensive, while sending a perk to a dormant user is merely wasteful. Priorities are not guessed — rank them by "the cost of getting it wrong": things that offend people if sent wrong go first, things that are merely wasted go last.

The second fix is mutual exclusion. Some groups are naturally exclusive: a person cannot be both a "newcomer" and a "veteran", or both "paid" and "unpaid". Write the exclusion into the rules engine so that entering group A automatically removes someone from group B — do not rely on operators maintaining it by hand. Manually maintained exclusions will leak sooner or later.

The third fix is rule versioning. Every change to a rule leaves a record: who changed it, when, what it was before, what it is now. If a rule change goes wrong, you must be able to roll back to the previous version with one click. In a system without versioning, when something breaks you cannot even find out when it went bad.

The fourth fix is preview before publish. Once a rule is configured, first compute how many people it will hit, and pull a few sample users to check whether they are really the group you want. A hit count ten times higher than expected, or samples that include people who clearly should not be there, are both signals that the rule is written wrong. Do not skip the preview step — it is your last chance to catch a mistake before launch.

Channels and frequency caps: sending right also means sending with restraint

Getting the groups right is only half the job. The other half is: which channel, how many times, and when. Sent wrong, even perfectly segmented messages are wasted.

Pick the channel by the weight of the message. Light messages go through in-app notifications or banners — users see them naturally when they open the product, without being interrupted. Heavy messages go by email, which reaches users even when they are offline, at the cost of low open rates. Only the heaviest messages deserve SMS or phone calls, and those are used a handful of times a year. Many products get this backwards: light messages blasted by SMS, heavy messages left sitting in-app waiting for users to find them.

Frequency caps are the part of a segmentation system most easily overlooked and most likely to cause trouble. Without a cap, one person can receive five messages in a single day: a newcomer guide, a feature promotion, an event notice, a win-back message, and a payment reminder. Each one looks reasonable on its own; together they are harassment. My suggestion: at most two operations messages per person per day, at most five per week, with anything over the cap automatically deferred to the next day or dropped. Transactional messages do not count — order confirmations and password resets are triggered by the user, so they are outside the limit.

Quiet hours must be set too. No operations messages between 10 p.m. and 8 a.m. — that is the floor. Better still, let users set their own quiet hours, or automatically avoid the night in each user's timezone. Send times must be computed in the user's local time, not server time: a user who gets a promotion at 3 a.m. will unsubscribe first thing in the morning.

Unsubscribe and preference settings are the safety valve of a segmentation system. Users must be able to unsubscribe from one category of message with one click, instead of only being able to unsubscribe from everything or uninstall the app. Unsubscribing must take effect immediately — do not send "one last confirmation email" to harass someone who has already unsubscribed. The finer the preferences, the less likely a user is to unsubscribe from everything at once: they can turn off event notices and keep product updates, which is better for both of you.

How to measure results: without a control group, do not talk about results

Once segmentation is live, the most common question is: how do you know whether it works? Operators will say by feel that "this campaign did well", when it may only have coincided with a weekend, a payday, or a competitor's outage. Without a control group, every "it worked well" is just a guess.

The right approach is to hold back a control group for every send: randomly pick 5% to 10% of the same group and do not message them, then compare them with the people who did receive the message. Look at four metrics together: open rate, click rate, conversion rate, and retention rate. Open rate alone will fool you — clickbait can win opens but not conversions. Conversion rate alone is not enough either: a campaign can bring conversions while damaging retention, which loses money in the long run.

The control group's size should follow the group's size. In a group of 100,000, a 5% control group is plenty; in a group of only 500, 10% is just fifty people, which is statistically meaningless. For small groups, measure trends over a longer period instead of staring at one campaign's numbers. Small groups deserve more attention to qualitative feedback: did recipients complain, reply, or say in the community that the message was exactly what they needed?

There is also an attribution trap to avoid: do not credit all growth to segmentation. Users naturally return and naturally pay; segmentation's credit is only "the extra part beyond what would have happened without it". That is what the control group is for — separating "what would have happened anyway" from "what segmentation caused". Without a control group you will keep calculating more and more optimistically, until you reach conclusions like "segmentation caused 100% of the growth" that even you do not believe.

Results must feed back into the rules. If a group's open rate runs below average three times in a row, the split may be wrong, or the messages that group receives may be wrong. If a group's unsubscribe rate suddenly rises, something is off with the frequency or the content. Segmentation is not something you build and abandon — review it monthly: which groups are still in use, which are dead, which should merge, which should split.

The privacy and compliance floor: segmentation is not surveillance

Take segmentation far enough and you will hit privacy questions, because segmentation is, at its core, "sorting people by their behaviour" — and being sorted can itself make users uncomfortable. Set the floor in advance; do not wait for complaints or regulators to remind you.

The first floor is minimum collection. Collect only the data segmentation actually needs; do not collect everything "because it might be useful later". City-level location is enough — not street-level. Recording "which feature was used" is enough — not the coordinates of every click. The less data you collect, the smaller the blast radius when something goes wrong.

The second floor is: do not touch sensitive attributes. Race, religion, political views, health status, sexual orientation — do not use these to segment, even when it is technically easy. Not because of what any particular law says, but because once users discover you are grouping them by these attributes, trust is gone for good. Some lines are not uncrossable; they are un-returnable once crossed.

The third floor is transparency. Users should be able to see which group they are in, why they are in it, and change it. At a minimum, they should be able to see in settings an explanation like "you received this message because you have not opened the app in the last seven days". Segmentation you cannot explain is a black box, and black boxes get treated as surveillance sooner or later.

The fourth floor is that deletion must be complete. When a user deletes their account or requests data deletion, the segmentation results, the behaviour records, and the inputs to any scoring model must all go together — not just the account while the profile lives on. The scope of deletion belongs in the privacy policy, and the process must leave a record.

Advice for vibe coding: how to build this feature without it blowing up

Segmentation suits vibe coding well: the rules are clear, acceptance is easy to define, and an AI is unlikely to wander off track. But there are a few places where AI will happily dig a hole for you, and you need to guard those yourself.

The first hole is that AI loves turning segmentation into a "user profile dashboard". Tell it to "build user segmentation" and it may produce a pile of labels, charts, and a flashy profile page — while messages can still only be sent to everyone at once. Write it into the requirements in stone: the acceptance test for segmentation is "can send a message to one group", not "can see a profile". Build the sending capability first, the display second.

The second hole is that AI-written rules often have no mutual exclusion or priority. Each rule looks right on its own; together they fight. The requirements must state that rules have priorities, exclusions live in the engine, and when a person matches several rules only the highest-priority one executes. When testing, deliberately create test users who match several rules at once and check which message the system actually sent.

The third hole is that AI easily forgets the frequency cap. The rules engine is done, the sending logic is done, but nowhere limits how many messages one person can receive in a day. You only discover it when users complain, and fixing it then means changing several places. Put the frequency cap at the top of the requirements: two a day, five a week, automatic deferral when exceeded.

My suggestion is to split segmentation into three acceptance milestones. Milestone one is "can split out the five basic groups by rules, and can send a message to one group" — get the main flow working first. Milestone two is "rules have priorities and exclusions, with preview and version history" — make the rules engine solid. Milestone three is the full operations loop: control groups, result measurement, frequency caps, and preference settings. Do not try to do it all at once. Ship milestone one, run it for a month, see whether operations is really using it, and then move on.

Launch checklist

Finally, a checklist you can tick off directly. Confirm each item before launch; fill whatever is missing, and do not launch on a feeling.

One, groups are split by behaviour, not by demographic labels, and the five basic groups are already separated. Two, every group maps to a different operations action — there is no group that was split "without knowing what to do with it". Three, segmentation rules are recalculated daily, and users flow naturally between groups. Four, rules have priorities, exclusions live in the engine, and when a person matches several rules only the highest-priority one executes. Five, rule changes have version history and can be rolled back with one click. Six, before a rule ships you can preview the hit count and samples, with a warning when the hit count looks abnormal. Seven, each person receives at most two operations messages a day and five a week, with excess automatically deferred, and transactional messages do not count. Eight, no operations messages between 10 p.m. and 8 a.m., with send times computed in each user's local timezone. Nine, users can unsubscribe from one category of message with one click, and it takes effect immediately. Ten, every send holds back a 5% to 10% control group, and open rate, click rate, conversion rate, and retention rate are read together. Eleven, sensitive attributes are never used for segmentation, and only the data segmentation truly needs is collected. Twelve, users can see why they received a given message, and when an account is deleted the segmentation results and behaviour records are deleted with it. Thirteen, segmentation is reviewed monthly: which groups are still in use, which should merge, which should split.

Thirteen items looks like a lot, but every one of them maps to at least one real incident. Most of the time, users never notice segmentation at all — they only feel it when a message arrives that is "exactly what I needed", and think the product understands them. Build segmentation solid, and it understands the user one step before they even speak.