RFM & CLM Engine
Reactivating a 3.9M-User Base

A super-app with millions of food users, and no systematic way to keep them.

Pathao is Bangladesh's leading super-app - rides, deliveries, and food ordering under one roof. Pathao Food, the food delivery vertical, had built up a user base in the millions over several years of acquisition pushes, seasonal campaigns, and organic growth riding on the rest of the super-app.

What it hadn't built was a systematic way to manage that base over time. Retention activity existed, but it was campaign-shaped: a promo push around a holiday, a blanket "we miss you" notification, a discount code blasted to everyone regardless of whether they needed the nudge. There was no persistent model of who a user was in their lifecycle - newly acquired, loyal and active, drifting, or already gone - and no infrastructure that let the growth team target spend at the users who actually needed it.

I proposed and built the RFM-based Customer Lifecycle Management (CLM) engine to close that gap: a persistent segmentation model that scores every user on Recency, Frequency, and Monetary value, and a treatment framework built directly on top of it - so retention spend goes where it changes behaviour, not where it's easiest to send a push notification.

Blanket campaigns were burning budget on the wrong users - and missing the real one.

When I pulled the full active-user base and looked at it through a recency and value lens for the first time, three problems became impossible to ignore.

Five decisions that turned a spreadsheet exercise into lifecycle infrastructure.

Two axes, 28 cells, and a user base that looked nothing like I expected.

RFM segmentation scores every user on three independent dimensions and combines them into an addressable structure. I defined how each axis would be measured for Pathao Food specifically, then combined them into the matrix that drove every downstream decision.

The 28-segment matrix

Every one of the 3.9M+ users falls into exactly one of 28 cells - one of 7 value tiers crossed with one of 4 recency bands. Each cell shows its population and whether it received a promotional treatment or was deliberately held out as a control.

Bottom-right cell - Rust tier, 200+ days dormant - is the single largest segment in the base at 2,656,530 users, 68% of the entire addressable population on its own.

Seven tiers, one value ladder, an extreme long tail.

I named the tiers after a familiar loyalty-ladder convention - Diamond at the top, Rust at the bottom - specifically so non-technical stakeholders could reason about segment value at a glance. Underneath the names, each tier is a composite Frequency + Monetary score band, computed against the full active base.

The distribution isn't a gentle pyramid - it's a cliff. Diamond through Bronze together hold less than 4% of the base. Iron and Rust alone account for over 96% of all users. That shape told me something a flatter distribution wouldn't have: this program couldn't be designed primarily around rewarding the top of the ladder. The real product problem, and the real budget, needed to live at the bottom of it.

Different offer, different target, different reason - for every cell in the matrix.

I didn't design one promo and apply it everywhere. Each of the 28 segments has its own combination of: whether it's treated at all, the discount depth and minimum order value, the usage cap, whether curated collections accompany the push, and which RFM dimension the treatment is designed to move - recency alone, or recency and frequency together.

Freshly active users (0–30 days): spend only where it's needed

Within the most recent recency band, I split treatment on food-usage category, not just tier. Users who were already ordering food as their primary app behaviour got no promo at all, regardless of value tier - they were already converting organically, and spending budget on them would have been pure margin loss. Users who were active on Pathao but not yet primary food users got treated, specifically to cross-sell them into the food vertical.

Dormant users (200+ days): the largest, most expensive-to-move segment

At the other end of the recency axis, every tier gets treated - the priority flips entirely to just getting one order placed again. Discounts here are the deepest in the entire matrix, minimum order values are lowered to reduce friction, and usage caps are raised so a single reactivation can turn into a short habit-forming streak.

Modelling the worst case before asking anyone to approve the average case.

A 28-segment matrix with differentiated discount depths is only useful if finance will actually fund it. Before this went to sign-off, I built a burn model across every segment - projecting cost under three redemption scenarios and two different discount-cap structures, so the conversation with finance started from numbers, not intuition.

Two discount-cap structures, modelled side by side

I also stress-tested two different discount-cap ceilings - a higher-cap structure (Tk80–100 max discount per order) and a lower-cap structure (Tk50–70 max discount per order) - across every tier and cohort, so the eventual budget decision could weigh reactivation strength against cost efficiency directly, rather than guessing at the trade-off.

A 12-week comms sequence, not a single blast.

Segmentation and offers only work if the delivery cadence gives users more than one reason to come back. I designed a 12-week rolling sequence that alternates between direct promo pushes, curated content collections, and cuisine-specific moments - so the same dormant user sees several different reasons to open the app, not the same discount code on repeat.

Twenty metrics across eight categories - because redemption rate alone lies.

What could go wrong - and how I designed against it.

What building a lifecycle engine taught me that a single feature never would.