Why Behaviour-Based Loyalty Is Hard to Build In-House

Building a behaviour-based loyalty program in-house is much harder than building a points-per-purchase one, and the difficulties are mostly not the ones in the business case. 

You choose which behaviours to reward before you know which ones matter: marketing needs to change the rules without waiting for a developer; every point you award is a promise the business still owes, so mistakes reach the accounts; streaks and challenges need a program that remembers, not one that only knows today's balance; and nobody verifies behaviour that isn't a purchase.

Rewarding a purchase means one connection to one system, and that system already tells you reliably what happened, keeps a record, and knows who the customer is. 

Rewarding a behaviour means a dozen connections to systems that do none of that. Almost everything below follows from that difference. If you want the architectural comparison first, we've covered points-based against event-driven programs separately.

Key takeaways

• You choose which behaviours to reward before the program has told you which ones matter, and changing that choice later is expensive.
• Marketing needs to change earn rules faster than engineering can ship them, so somebody has to build the tools that make rule changes safe.
• Under ASC 606 and IFRS 15, loyalty points are a promise the business still owes, so an accidental double award overstates a figure that reaches the accounts.
• Behavioural data arrives from systems you don't control, rarely labelled with a customer, and every new market adds its own consent rules and reward catalogue.
• Nobody verifies behaviour that isn't a purchase, so fraud control is a permanent job rather than a launch feature.

Behaviour-based loyalty is a different problem

A points program tracks one thing: someone buys something, the till or the website says so, and points get added. You can build that in a sprint, and plenty of teams have.

A behaviour-based program has no fixed list: profile completion, app visits, referrals, reviews, store visits, support calls, subscription renewals. Each one comes from somewhere different, at a different moment, and often doesn't say clearly who it belongs to.

SKB Bank shows why brands want this anyway. One of Slovenia's largest banks, part of the OTP Group, it had struggled to encourage the two things it wanted most: customers recommending the bank to friends, and customers updating their marketing consent. Neither is a purchase, and neither fits a points-per-purchase model. 

The three-month BONUS pilot we built turned both into a game with tiers and challenges. Nearly a third of the consent updates SKB received in that period came from program participants, alongside a 188.2% rise in Flik instant payment transactions.

So the commercial case is settled. It's the building that goes wrong.

1. You have to guess which behaviours matter before you have any data

The program is the thing that tells you which behaviours predict loyalty. But you have to decide what to track before you launch it, which means making the important decision at the moment you know the least.

That would be fine if changing your mind were cheap, but it usually isn't. Sooner or later you have to change what information you record about each event, and there is no easy way to do it. 

Biscuit is what the alternative looks like. The pet wellbeing app rewards dog owners for things with no obvious template: breed-specific exercise targets, walking challenges, quizzes, badges. 

Its Quests feature awards XP, and hitting 100 XP in a skill area unlocks a new level. None of that existed at launch: because the earn logic lives in a configurable engine rather than buried in the app's code, Biscuit could add it without a development cycle. 

Users have since walked more than 950,000 miles and finished over 60,000 weekly challenges, and the app reached 50,000 registered users in nine months with a 4.6-star rating.

The difference is whether changing your mind costs an afternoon or a quarter.

2. Marketing will need to change the rules faster than engineering can ship them

Earn logic starts life in code, and for the first three rules that is genuinely fine. Then marketing wants double points for one market this weekend, then a bonus that only applies to members below silver, then the weekend promotion pulled early because finance saw Saturday's numbers. Every one of those is a ticket, a sprint, a release.

What the business actually needs is somewhere a program manager can change a rule without asking anyone, and that is more demanding than it sounds. Someone without technical training has to be able to set the conditions. New rules need trying out on real member data before they go live, because a mispriced offer found by members is expensive to unwind. And every change needs a record and an undo, because "what were the rules on 14 March" becomes an urgent question the first time a member disputes a balance.

Built in-house, that is a second product sitting alongside the first one. Nobody scopes it as a product, which is why it usually arrives late, half-finished, and only usable by the engineer who wrote it.

The SKB pilot is a small illustration of what the alternative buys. New members completed a set of tasks to move from the entry tier to the next one, which unlocked further rewards. 

That logic was configured rather than coded, which is the only reason a three-month pilot was viable. A hard-coded version would have taken longer to build than the pilot was scheduled to run. 

We've written separately about what happens when loyalty sits behind the dev backlog.

3. Every point you award is a promise you still owe

Finance and the project team tend to discover this one at different times, and neither discovery is comfortable.

Loyalty points aren't simply a marketing cost. Loyalty points aren't simply a marketing cost. Under ASC 606 in the US and IFRS 15 internationally, points that let a customer get something later at a discount count as a promise the business has yet to fulfil.

PwC's revenue recognition guide puts the point that matters most here plainly: the obligations created by a loyalty program can be significant even where each individual reward is insignificant. IFRS 15 sets out equivalent requirements for the same arrangements. A fraction of a penny per transaction, accumulating across millions of them, becomes a real number in the accounts.

There's a detail in that guidance worth knowing, because it catches people out. The amount set aside is based on what the points are worth to the customer, not on what the reward costs you to provide. Brands that assume their exposure equals the wholesale cost of the vouchers they hand out are working from the wrong figure.

Exactly how the calculation runs depends on how your program is structured, and it's a question for your accountants rather than for a blog post. What matters for anyone choosing how to build a program is the consequence: the loyalty system has to produce a number your finance function can rely on, every reporting period, and it has to be right.

Which makes accidental double awards a bigger problem than they look. If the same 500 points get credited twice because a message arrived twice, that isn't just a cosmetic glitch in someone's app: the business has overstated what it owes, in a figure that reaches the accounts.

Payment providers solved this years ago, and a repeated message now gets recognised as a repeat rather than paid out twice. Behaviour-based programs need that protection more than card-only ones, because every new behaviour you reward is another place a duplicate can get in. A walk logged by a phone on a patchy connection arrives whenever it can, sometimes twice.

4. The data lives in systems you don't control, in every market you operate in

More systems are involved than the earn mechanic suggests. Things come in from your website, app, tills and partners; things go out to your CRM, email tool, analytics and finance reporting, because marketing needs segments, finance needs the liability figure, and support needs balances.

That's the part teams plan for. The part they don't plan for is working out who the customer is. A purchase comes with a card, a store visit comes with a phone, a review comes with an email address, a support call comes with a phone number. 

None of them arrives labelled with a customer, so joining them into one member is the actual project, and it never really finishes, because every new behaviour you reward brings another loose end. This is why data capture tends to be the piece brands buy even when they build the rest.

Operating across borders multiplies all of it. Different countries mean different consent rules governing which behaviours you may track and reward at all, different card networks feeding the purchase data, different reward catalogues, and points worth different amounts where currencies diverge. 

Tickit, the program we built for Dubai Holding, awards points automatically when members shop with a linked Visa or Mastercard across a network covering roughly 3,500 locations in the UAE. That works because the card network side was built once and each market's rules are set up rather than rebuilt. A brand doing this in-house builds it per market, then maintains every version.

5. Behaviour that isn't a purchase is easy to fake

A payment is verified by a bank with money at stake. A review, a check-in, a referral and a logged walk are verified by nobody. The mechanics that drive the most engagement usually have the weakest proof, which isn't a coincidence.

The volumes involved aren't trivial. Our receipt validation flagged more than 5,000 fraudulent receipts across PepsiCo's promotional campaigns, and a receipt has a firmer paper trail than most of the behaviours a program like this rewards.

Catching it is a solved problem, and we've covered how AI and machine learning detect loyalty fraud in detail elsewhere. What matters for a build decision is that the work never finishes. 

Rules need retuning as people find new angles, someone has to review the cases that look odd, and you need a way to take an award back without wrecking the figure finance just reported. In-house builds ship the earn mechanic and leave all three until the first incident.