Native Retention Stack (Overview)
The umbrella framing for apps/native retention — four return-drivers (money, memory, habit, identity), how every other idea maps to them, how they compound, and the order to build them in. No new mechanics; the connective tissue.
Status: Accepted (framing); individual features tracked in their own decisions
Date: June 2026
Decision: Frame apps/native retention around four return-drivers — money, memory, habit, identity — and map each idea to the driver it serves. This is the umbrella that explains why the feature set hangs together and exposes gaps. No new mechanics; it’s the connective tissue for the ideas on receipts, stamps, points, funding, birthday, and nearby (plus Spend Insights & Tiers).
TL;DR
People return to an app for four reasons: money, memory, habit, identity. Map each feature to a driver: points = money, receipts = memory, nearby = habit, birthday = identity. The stack covers all four, the features compound (nearby aggregates them, push delivers them), and they ship in dependency order: points → receipts → nearby → birthday → insights/tiers.
Context
The other ideas each add a retention feature, but a feature list isn’t a strategy. People return to an app for one of four reasons:
| Driver | The user’s reason to open |
|---|---|
| Money | “I can save or earn something.” |
| Memory | “It holds a record I need.” |
| Habit | “It’s part of a routine / decision I make often.” |
| Identity | “It feels like mine / it celebrates me.” |
A durable app covers all four. A wallet-only app (money only) gets checked occasionally and churns. The goal is a stack where, on any given day, some driver is pulling the user back.
The stack mapped to drivers
| Feature | Idea | Primary driver | Secondary | Frequency |
|---|---|---|---|---|
| Points currency | 04 | Money | Habit | Per purchase + balance checks |
| Receipt wallet | 02 | Memory | Money (insights) | Per purchase + when needed |
| Nearby / “use now” | 07 | Habit | Money | Multiple/week (decisions) |
| Birthday engine | 06 | Identity | Money | Once/yr (guaranteed + push) |
| Referral | 03 | Growth (not retention per se) | Identity | One-off-ish |
| Insights + tiers | 09 | Identity | Memory/Money | Monthly + passive status |
Coverage check
- Money ✅ — points currency is the spine; nearby + insights reinforce it.
- Memory ✅ — receipt wallet (the stickiest: people don’t delete apps holding their records).
- Habit ✅ — nearby “what can I use now” is the high-frequency decision tool.
- Identity ✅ — birthday engine (emotion) + tiers/status (belonging); the most ownable.
No driver is empty. The stack is balanced.
How they reinforce each other
The features aren’t independent — they compound:
Points (04) ── earned per spend ──┐
├─→ Nearby (07) surfaces "points usable here"
Receipts (02) ── spend data ──────┤
├─→ Insights (09) makes receipts/points *mean* something
Birthday (06) ── grant ───────────┤
├─→ Nearby (07) ranks birthday perks #1
└─→ shareable moment ─→ Referral (03) growth loop
Tiers (09) ── lifetime points ────→ status feeds back into points earn rate- Nearby is the aggregator — it renders the actionable state of points, perks, stamps, and birthday grants in one place. It’s where the other features become visible.
- Receipts feed insights — the receipt wallet is dormant memory until insights (09) turn it into “you spent RM240 across 6 cafés.”
- Birthday feeds referral — the celebratory moment is the most shareable thing in the app.
- Push is the delivery layer for all of them — expiring points, birthday perks, new nearby perks, return windows.
Sequencing (retention-feature order)
Not all at once. Suggested order by leverage and dependency:
- Points currency (04, constrained per 05) — the spine; everything annotates against it.
- Receipt wallet (02) — independent, sticky, low-risk; can run in parallel.
- Nearby (07) — needs points/perks to annotate, so after 04.
- Birthday engine (06) — needs voucher rails; the flagship, but once-a-year so pair with 07 first.
- Insights + tiers (09) — needs accumulated data (receipts/points history) to be meaningful.
Referral (03) is growth, not retention; sequence it whenever the loop is ready, ideally after the birthday moment exists to share.
Push notifications — the shared delivery layer
Every feature gives a reason to return; push delivers it. The high-value triggers across the stack:
| Trigger | Feature |
|---|---|
| Points expiring soon | 04 |
| Birthday perk unlocked / window | 06 |
| New perk at a place you visit | 07 |
| Return/warranty window closing | 02 |
| Tier almost reached / achieved | 09 |
The birthday engine is the best opt-in justification — request push permission framed as “get notified when your birthday gifts are ready,” then leverage the granted permission for the rest.
Consequences
| Type | Consequence |
|---|---|
| Pro | Gives a single lens (four drivers) to evaluate any future feature — “which driver does this serve, and is that driver under-served?” |
| Pro | Exposes compounding — features reinforce rather than fragment. |
| Pro | Provides a defensible build order tied to dependencies. |
| Con | It’s framing, not a feature — value depends on the underlying decisions actually shipping. |
| Con | Several features share a cold-start weakness (birthday, nearby) — coverage/seed strategy must be solved or the stack feels empty early. |
Open Questions
- Cold-start coverage: birthday and nearby both feel empty with sparse merchants — what’s the seed/platform-funded strategy across the stack? (See Cold-Start & Coverage.)
- Push fatigue: with five trigger sources, how is frequency capped so the user isn’t over-notified?
- Measurement: what’s the north-star retention metric (D7/D30, monthly actives, opens/week) and per-feature attribution?
- Driver gaps over time: as the app grows, which driver weakens first and needs reinforcement?