E-Commerce Tips
Mobile App + Loyalty CRM: Why They Should Be Built Together
Bolt loyalty onto a separate app and website and two things break: customer identity stops matching, and the channel that doesn't reward loses sales.
Danny Khow, Co-Founder & Managing Director5 min read
The usual sequence goes like this: a retailer builds an e-commerce store, then later commissions a mobile app, then later still adds a loyalty programme, often through a third vendor entirely. Each project solves its own problem well enough on its own. The trouble shows up at the seams: a customer's points balance lags between app and website, redemption rules get implemented twice and drift apart, and every new loyalty feature needs to be built once for the storefront and again for the app. None of that is any single vendor's fault. It's what happens when three systems that were never designed to share a backend get wired together after the fact.
Guardian Malaysia didn't take that path, and it's worth walking through why.
One backend, not three
Guardian has been our Adobe Commerce partner for more than 8 years. When the mobile app and the MyGuardian Rewards loyalty programme came into the picture, they weren't scoped as separate initiatives bolted onto the existing store. The app was built on Adobe Commerce's headless architecture, meaning the storefront, the app, and the loyalty layer all sit on top of the same backend and the same customer data, rather than three systems that have to be kept in sync after the fact.
Bolted on afterwards
Kept in sync after the fact
Built together
The same number on every channel
Practically, that means a member's points balance, tier status, and available rewards are the same number whether they're looking at the app or the website, because there's only one number, not two systems each keeping their own copy and reconciling periodically. It also means a new loyalty feature gets built once against the shared backend and is immediately available everywhere, instead of being built for the app, then rebuilt for the web, on whatever timeline each team gets to it.
| Where it shows | Three systems wired together | One shared backend |
|---|---|---|
| Points balance and tier status | Each system keeps a copy, reconciled later | One number, the same on the app and the website |
| A new loyalty feature | Built for the app, then rebuilt for the web | Built once, available everywhere |
| Redemption rules | Implemented twice, and drift apart | Implemented once |
| Customer account | A separate record on each channel | One account, in-store, on the website, and in-app |
What that unification looks like in the results
Since launching the integrated loyalty app, MyGuardian Rewards membership grew by nearly 90% within the first 47 days alone, and by more than 250% over the following year. Growth at that pace isn't just a function of the loyalty mechanics being appealing. It's also a function of friction being low: a customer signing up in-store, on the website, or in the app is joining the same programme through the same account, not choosing between two loyalty systems or discovering that their in-store enrolment doesn't carry over to the app.
| Guardian Malaysia | Result |
|---|---|
| Bridzia as Adobe Commerce partner | More than 8 years |
| MyGuardian Rewards membership, first 47 days | Grew nearly 90% |
| MyGuardian Rewards membership, over the following year | Grew more than 250% |
The failure mode this avoids
We've built the bolted-on version too, for clients who added a loyalty programme to an existing separate app and website after the fact, and two problems show up almost every time.
Matching customer identity across systems is a genuine headache, not a minor detail. Mobile apps typically use phone number as the account identifier, since OTP-based signup is the path of least friction on a phone. Websites more often use email. When the app and the website were built as separate systems, those two identifiers were never designed to reconcile, so the same human being ends up as two different customer records with no reliable key linking them. Fixing this after the fact usually means asking the customer to manually merge their web and app accounts themselves, an extra step that adds friction exactly at the point where you want enrolment to be effortless, and a step a meaningful share of customers simply won't bother completing. The alternative, trying to auto-match records by fuzzy-matching name and other details, risks merging the wrong two people or failing to merge the right two, which is worse.
Channel-specific rewards quietly cannibalize the channel that doesn't reward. If the app awards points and the website doesn't (or vice versa, which happens just as often when the loyalty programme was originally an app-only initiative), customers respond rationally: they shift their purchasing toward whichever channel actually rewards them. That's not a hypothetical risk, it's a predictable outcome of giving customers a financial reason to prefer one channel over another that has nothing to do with which channel actually serves them better. A retailer can end up having accidentally trained its customers to abandon the website in favour of the app, or the other way round, without ever deciding that's what they wanted.
Beyond these two, the same bolted-on setup also tends to produce sync delay (points earned on one channel taking time to appear on another), redemption rules implemented twice and drifting apart, and slower feature rollout across two separate codebases instead of one. But the identity-matching problem and the cannibalization risk are the two that actually change customer behaviour and revenue, not just backend tidiness.
What to check before you commission either project
If you're planning a mobile app and a loyalty programme, even if not at exactly the same time, a few questions are worth asking before committing to vendors or architecture:
Will the loyalty programme's data live in the same backend as the storefront and app, or in a separate system that needs to be synced?
Does the mobile app pull customer and order data from the same API the website uses, or a separate integration layer?
What's the actual account identifier on each channel, and will it match?
If the app is going to use phone number and the website uses email, decide how those reconcile before launch, not after customers start complaining that their points don't show up.
Will every channel earn rewards at the same rate?
If one channel doesn't reward and another does, that's a deliberate business decision to make, not something to discover after customers have already started shifting their behaviour around it.
If you build the app first and the loyalty programme later (or vice versa), does the architecture you're choosing now make combining them later straightforward, or does it lock you into stitching two systems together afterward?
If you're planning either a mobile app or a loyalty programme, and especially if you're planning both, talk to us about Mobile Application Development or Loyalty CRM.
Keep reading
Related articles
More on platforms, integration, and how buyers find brands.
E-Commerce Tips
Gamification in Loyalty Programmes: What Actually Increases Engagement
Only 5% of eligible users registered for one gamified campaign we ran, but 99.7% of those who did played, most more than once. What that funnel reveals.
Read the article
E-Commerce Tips
Why Friends & Family Loyalty Mechanics Drive Referral Growth
60% of one loyalty app's signups came directly through a Friends & Family invite. Here's how that mechanic out-paced an established, multi-year programme.
Read the article
E-Commerce Tips
AI Discovery Starts on Your Own Site, Not ChatGPT
74% of Malaysian shoppers already use AI while shopping. What Adobe Commerce Live Search and AI recommendations delivered across 4 real implementations.
Read the article