Spend Insights & Tiers
Two low-cost, data-leverage retention surfaces — spend insights that turn receipt/order/points data into a personal summary, and Bronze→Gold tiers derived from lifetime points for passive, identity-driven belonging. Both reuse existing data.
Status: Accepted (direction); implementation deferred
Date: June 2026
Decision: Add two low-cost, data-leverage retention surfaces to apps/native: (1) spend insights — turn the receipt/order/points data the app already holds into a personal summary (“you spent RM240 across 6 cafés this month”) — and (2) tiers — a Bronze→Gold status derived from lifetime_earned points, for passive, identity-driven belonging. Both reuse existing data; neither needs new transactional flows.
TL;DR
Two cheap, read-mostly surfaces that reinterpret existing data. Insights turn receipt/order/points data into a monthly + annual personal summary (makes the receipt wallet active). Tiers turn lifetime_earned points into Bronze→Gold status (loss aversion = passive retention). No new schema beyond an optional rollup cache + tier config. Add after points + receipts have accumulated history.
Context
The retention stack covers money (points), memory (receipts), habit (nearby), and identity (birthday). Two cheap additions deepen identity and make the memory layer do something:
- The receipt wallet and orders accumulate spend data that currently just sits there. Insights make it valuable to the user (and reinforce the scan/log habit).
- The points wallet already tracks
lifetime_earned. Tiers turn that into status — a proven, passive retention driver.
Both are read-mostly: they reinterpret existing data rather than add mechanics. High leverage, low build cost.
Decision
Part 1 — Spend insights
A personal, periodic summary built from receipts + orders + points:
| Insight | Source |
|---|---|
| Total spend (period) | orders + receipts (receipt management) |
| Spend by merchant / category | order_items, receipt line items |
| Visits / frequency | orders, store_customers.visit_count |
| Points earned / redeemed | befday_point_events (points currency) |
| “Top merchant this month” | aggregation |
| Trend vs last period | period-over-period comparison |
- Cadence: a monthly “your month with befday” summary (push-delivered) + an always-available insights tab.
- Year-in-review: an annual recap (high-engagement, shareable — feeds referral).
- Privacy: purely the user’s own data, shown only to them; no new sharing surface.
Insights make the receipt wallet active: a reason to keep scanning (“the more I log, the better my picture”), closing the loop on receipt management.
Part 2 — Tiers (status)
A status ladder derived from lifetime_earned (or rolling 12-month earned points):
| Tier | Threshold (example) | Possible benefit |
|---|---|---|
| Bronze | 0 | baseline |
| Silver | e.g. 5,000 pts | small earn multiplier / early perks |
| Gold | e.g. 20,000 pts | higher multiplier / exclusive catalog |
- Derived, not stored as truth — tier is computed from points history;
lifetime_earnedis the ground truth (per points currency). Avoids drift. - Benefit options: earn-rate multiplier, exclusive catalog items, early/extended birthday perks, priority. Keep benefits points-native so they reuse existing rails.
- Rolling vs lifetime: rolling-12-month thresholds keep tiers earned, not permanent — a stronger retention pull (“don’t drop to Silver”) — but lifetime is simpler. Open question.
- Loss aversion is the mechanism — showing “1,200 pts to keep Gold” is a recurring, passive return reason.
Why these two together
Both are the same kind of move: reinterpret existing data into an identity/value surface at low cost.
| Spend insights | Tiers | |
|---|---|---|
| Driver | Memory → Money | Identity |
| Build cost | Low (aggregation) | Low (derived threshold) |
| New schema | None (reads) | None (derived from points) |
| Frequency | Monthly + annual | Passive + threshold nudges |
| Risk | Low | Low–med (benefit cost) |
Neither is a flagship (that’s the birthday engine) — they’re force-multipliers on data you already collect. Add after points + receipts have accumulated meaningful history.
Data Model Impact (sketch)
Almost entirely reads. Insights aggregate existing tables; tiers derive from points.
Optional: cached aggregates (performance)
Computing insights live across all orders/receipts per open is wasteful. Optionally cache per-user monthly rollups:
| Table / column | Notes |
|---|---|
consumer_spend_rollups |
optional — (user_id, period, merchant_id, total_cents, visits, points) precomputed monthly |
Start by computing live; add the rollup table only if performance demands it (avoid premature optimization).
Tiers: config, not a table
| Config | Notes |
|---|---|
befday_program_settings.tier_thresholds |
jsonb — tier names + point thresholds (tunable) |
befday_program_settings.tier_basis |
enum lifetime | rolling_12m |
Tier is computed from befday_wallets.lifetime_earned (or a rolling sum of befday_point_events) against thresholds — no stored tier column to drift.
API Impact (sketch)
| Procedure | Status | Notes |
|---|---|---|
consumer.insights.summary |
New | Period summary (spend, merchants, visits, points) |
consumer.insights.yearReview |
New | Annual recap (shareable) |
consumer.tier.get |
New | Current tier, progress to next, points-to-keep (if rolling) |
(job) monthlyInsightsPush |
New | Enqueues “your month with befday” notification |
Aggregation is server-side; the client renders. Build an index of the user’s orders/points once and aggregate in a single pass (avoid N queries per merchant) — same pattern as nearby.
Consequences
| Type | Consequence |
|---|---|
| Pro | High leverage, low cost — reinterprets data already collected. |
| Pro | Insights make the receipt wallet active, reinforcing the scan habit (receipt management). |
| Pro | Tiers add passive, loss-aversion-driven retention with no new mechanic. |
| Pro | Year-in-review is highly shareable → growth loop. |
| Con | Neither is a flagship — they assume the spine (points/receipts) exists and has data. |
| Con | Tier benefits have a real cost (multipliers, exclusive perks) — must be costed like any reward. |
| Con | Live aggregation can be slow at scale — may need the rollup cache. |
| Con | Insights are only as good as data coverage — sparse receipts/orders = thin insights. |
Resolved Decisions
| Question | Decision |
|---|---|
| Add insights? | Yes — monthly summary + annual year-in-review |
| Add tiers? | Yes — derived from lifetime_earned points |
| Tier storage | Derived, not stored (config thresholds; points are truth) |
| New schema | Minimal — optional rollup cache; tier config in program settings |
| Sequencing | After points + receipts accumulate meaningful history |
Open Questions
- Tier basis: lifetime (simple) vs rolling-12-month (stronger loss aversion) — pick one.
- Tier benefits: which benefits, and their cost — earn multiplier vs exclusive catalog vs birthday boost?
- Insight cadence: monthly only, or also weekly nudges? (Balance value vs push fatigue per Native Retention Stack.)
- Rollup cache: compute live or precompute — decide based on measured performance, not upfront.
- Category taxonomy: do receipts/orders have enough structure for “spend by category,” or is that merchant-only at first?
- Shareability: how much of year-in-review is shareable without leaking private spend amounts?