Segmentation strategy: beyond RFM

RFM — Recency, Frequency, Monetary — slots users into a grid based on how recently they engaged, how often, and how valuable. It works because the three dimensions are genuinely predictive of future behaviour, and because you can explain the model to a CMO in under two minutes without diagrams.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 runs out. 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 RFM can't tell them apart. Lifecycle decisions need the direction of travel, not just the current position.

The second problem is non-transactional products. Monetary value is a weak signal on a content platform and literally nonexistent on a free product. Programs that 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.

Layer 1 — Lifecycle stage.Every user sits in exactly one stage: new, activated, engaged, at-risk, lapsed, churned. Mutually exclusive, collectively exhaustive. Stage is the single most consequential filter in almost every lifecycle program — it decides whether someone gets an onboarding email or a winback email. 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.

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 are short-lived — 24 to 72 hours — and always additive on top of stage and tier. They trigger campaigns; they don't re-categorise the user.

Three layers, three different jobs. 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.

The most common segmentation disaster is stage ambiguity. "Activated" means one thing to product, something different to growth, something different again to finance. 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, and every stakeholder quietly losing faith in the numbers.

Fix it by defining stage as a derived attribute in your CDP or Braze, computed from raw event data 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.

Braze gives you three tools: segments (saved audience definitions), custom attributes (per-user fields), and derived values (usually populated from your CDP or API). The common mistake is creating a segment for every combination. Six lifecycle stages multiplied by four engagement tiers equals twenty-four segments before you've added a single product filter. That list is unmaintainable inside a quarter.

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- or webhook-triggered campaigns than as persistent segments.

One user has one lifecycle stage at any moment; 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.

Predictive tiers — churn risk, likelihood to purchase, propensity scores — are the most ambitious layer and the one most commonly overbuilt. A score is worth the investment 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 18 months later.