Segmentation strategy: beyond RFM

Back to the marketer at the spreadsheet. Two million users, one inbox each, and a single decision to make: who hears what this week. Segmentation — the act of cutting a user list into groups that should be talked to differently — is the tool that makes that decision tractable instead of paralysing.

The cut almost everyone reaches for first is RFM — Recency, Frequency, Monetary. Score every user on how recently they engaged, how often they buy, and how much they spend, then drop them into a grid. It became the default for two reasons. The three dimensions are independently predictive of future behaviour, and you can explain the model to a CMO in under two minutes without diagrams. Both still true.Source · Harvard Business ReviewIdentifying and Evaluating the Best Customers in a Direct Marketing FrameworkRFM was formalised in direct-response marketing literature in the 1990s — the approach has proven durable because it maps to three independent behavioural dimensions.hbr.org

Here's where it falls over. RFM describes past behaviour, full stop. Two users with identical scores can be on completely different trajectories — one accelerating into power-user territory, one quietly decelerating toward churn — and the model can't tell them apart. Lifecycle decisions need the direction of travel, not just the current position.

The second crack: non-transactional products. Monetary value is a weak signal on a content platform and literally nonexistent on a free product. Programs that try to patch this by bolting "session count" or "content views" onto the M end up with a fragile Frankenstein that pretends to be RFM and behaves like a homegrown activity score nobody can defend in a quarterly review. The honest move is to stop calling it RFM and build the layers that actually answer the question.

Forget frameworks for a second. Picture one user. To decide what to send them tomorrow, you need three answers — and they're different questions, even though most teams squash them into one segment. Where are they in their relationship with the product? How intensely do they use it? What did they just do that's worth reacting to? Three layers, three different jobs.

Layer 1 — Lifecycle stage.Every user sits in exactly one stage: new, activated, engaged, at-risk, lapsed, churned. Mutually exclusive (you're only ever in one), collectively exhaustive (every user is in some stage). Stage is the single most consequential filter in almost every lifecycle program — it decides whether someone gets an onboarding email or a winback. Misclassify a user here and the whole program miscommunicates with them. It's the most expensive segmentation error you can make, and the one most programs make quietly for years.

Layer 2 — Engagement tier. Within a stage, users vary by intensity. Power, regular, light, inactive. Tier is where RFM finally earns its keep — recency, frequency and value are the right inputs when you're ranking intensity within a stage, rather than using them as the whole model. Two activated users behave differently if one logs in daily and one logs in monthly; tier is what catches that.

Layer 3 — Behavioural intent. Recent actions that signal what the user is about to do. Added an item to cart. Viewed pricing twice this week. Invited a teammate. Opened a feature for the first time. Intent segments— short-lived audience cuts based on a recent action — last 24 to 72 hours and always sit on top of stage and tier. They trigger campaigns; they don't re-categorise the user.

Stage decides which program family the user is in. Tier decides how intensely you talk to them. Intent decides what's worth triggering right now. Keeping those jobs separate is what keeps the segment count manageable instead of exploding into the hundreds.

The most common segmentation disaster isn't a sophisticated modelling failure. It's stage ambiguity. "Activated" means one thing to product, something different to growth, something different again to finance. Picture the meeting: three teams, three definitions, all confident, all going to ship campaigns this quarter against different versions of the same word. Unless the definition is written down and operationalised, users flicker between stages based on whichever team's definition got applied last. The downstream mess is severe — onboarding emails firing at activated users, winbacks firing at engaged ones, every stakeholder quietly losing faith in the numbers.

Fix it by defining stage as a derived attribute — a user field that's computed from raw events rather than typed in by hand — in your CDP or Braze, with a single canonical rule. New = signed up within the last N days OR hasn't yet taken the activation event. Activated = took the activation event AND hasn't crossed the lapsed threshold. At-risk = between engagement threshold and lapsed threshold. Lapsed = past the lapsed threshold. Churned = cancelled or deleted. Each threshold is a number you tune for your product. For infrequent-usage products the thresholds change shape entirely — the lifecycle for flat products guide covers that case.

How often should you recompute stage? Daily for most programs. Event-driven where transitions need to be immediate — onboarding flows that should move a user to "activated" the moment the activation event fires, for example. A nightly batch is fine for everything downstream of that.

The non-negotiables: one canonical definition, enforced in code. No team overrides. The Orbit CRM Data Model skill covers the data architecture this requires — the derived attributes, the event taxonomy, and the rules that keep stages consistent when three different teams all want to tweak the definition.

The trap is so common it's almost a rite of passage. A lifecycle lead opens Braze — an enterprise messaging platform covering email, push, in-app, the lot — sees how easy segments are to make, and starts making one for every combination. Six lifecycle stages multiplied by four engagement tiers equals twenty-four segments before a single product filter has been added. Add three intent flags and you're past a hundred. That list is unmaintainable inside a quarter and unreadable inside two.

Braze gives you three tools that look interchangeable and aren't. Segments are saved audience definitions you target campaigns at. Custom attributes are per-user fields stored on the profile (e.g. lifecycle_stage = "activated"). Derived values are usually populated from your CDP or via API. The pattern that scales: store lifecycle stage and engagement tier as custom attributes on the user profile, not as segments. Create segments only for the combinations your campaigns actually target — usually 10 to 15 named segments, built from those attributes plus any additional filters.

Intent segments are almost always better as Currents- (Braze's real-time event-streaming product) or webhook-triggered campaigns than as persistent segments. The difference matters: a persistent segment is a list that gets recomputed on a schedule; a triggered campaign fires off the event itself, in seconds, and doesn't accumulate as a segment to maintain.

The mental model: one user has one lifecycle stage at any moment, but that same user belongs to many segments at the same time. The stage is a filter inside nearly every segment, not a segment itself. Once you internalise that distinction the segment list stops growing on its own.

The Orbit Namer generates segment names from a consistent convention so the list stays scannable six months in. The Braze Segment Analysis skill audits existing segments for overlap, redundancy, and the long tail of segments nobody uses but nobody wants to delete either.

The most ambitious layer, and the one most commonly overbuilt. Predictive scores — a model's estimate of a future outcome, like churn risk, likelihood to purchase, or propensity to upgrade — sound like the obvious next step once basic segmentation is humming. They're sometimes worth it. Often they're not, and the people building them rarely admit which is which.

A predictive score earns its keep only if three conditions all hold: you have enough data volume for a meaningful model (100K+ users, longer for low-traffic products), you can act on the score inside the lifecycle program in a way you couldn't with a rule, and the prediction is meaningfully more accurate than the simple rule-based proxy you'd use otherwise.

If any of those three is missing, skip it. A rule-based "at-risk" segment — users whose session cadence dropped more than 50% over the last 30 days, for example — usually outperforms a half-trained ML model at a tiny fraction of the operational cost. The people building half-trained ML models rarely admit this, which is part of why the problem persists.

When predictive scoring does pay off, integrate it as an attribute on the Braze profile rather than a native Braze segment. Keeps model ownership in the CDP or warehouse where it belongs. Decouples the model's update cadence from Braze's segment refresh cycle. Lets you version and roll back without rebuilding segments. Starting here instead of inside Braze saves you from a messy migration eighteen months later.