Loyalty Program Architecture: 5 Decisions for Enterprise Scale

Loyalty program architecture is a set of decisions behind how a program identifies members, records what they do, stores their points, exchanges data with other systems and lets staff change the rules. 

Five of those decisions determine how far an enterprise program can grow, and one of them is expensive to change once members have joined.

Problems with these decisions usually surface in the second year: a brand opens in a country with a different currency, signs a partner who wants to fund their own rewards, or gets a request from finance for the year-end points liability, and finds the system was never set up for it.

Our earlier post on why behaviour-based loyalty is hard to build in-house covers the problems themselves: this one is about the choices.

What is loyalty program architecture?

Loyalty program architecture is the structure underneath a loyalty program: the data model, the rules engine, the integrations and the admin controls. Members never see it, though it limits what the app and the rewards catalogue can offer them.

A points-per-purchase program has very little of it: the till reports a sale and points go on the account. An event-based loyalty program rewards things like reviews, referrals, app visits and subscription renewals, and each of those comes from a different system with its own data format. (We compare the two models in points-based vs event-driven loyalty programs.)

Our Loyalty Engine has three building blocks. 

• Events record what a member did. 
• Reactors are the rules that respond, for example by adding points, issuing a voucher, awarding a badge or calling a webhook. 
• Audiences are groups of members that rules and rewards can be aimed at. 

Most of the decisions below come down to how those three are set up for your business.

1. How should a loyalty program identify customers?

Start by deciding who the member is: a person, a household, a business account or a hierarchy of accounts. Balances, tiers, rewards and reports all attach to that unit, so changing it after launch means migrating every member's history.

Two related questions are worth settling at the same time. 

1. First, what happens to activity that arrives without a recognisable member? A store visit might come with a phone number, a review with an email address and a purchase with a card number, and someone has to decide whether those are held and matched later or dropped. 
2. Second, which identifier does the loyalty program trust? Most enterprises already have a customer ID in their CRM or ecommerce platform, and using that one keeps loyalty in line with everything else.

In White Label Loyalty, member profiles have core fields, custom attributes and user ID properties, so a program can key off the customer ID your systems already use. Profiles also support GDPR restricted processing.

2. What should a loyalty event contain?

An event should have a type, the member it belongs to, the time it happened and a payload that follows an agreed schema. If every system reports activity in that shape, the marketing team can write rules without asking engineering what each field means.

In practice that gives five fields to agree on:

1. The event type.
2. The subject, meaning the member the event belongs to.
3. The time of the event, which can be earlier than the time it was reported (a walk logged offline, say).
4. The payload, with whatever details a rule might need, such as basket value, product category or store.
5. The schema the payload has to follow, so malformed data is rejected when it arrives.

Keep events as a permanent record, separate from the points they generated: with the raw events stored, you can check a proposed rule against last quarter's activity before switching it on, and you can explain any member's balance one event at a time.

That setup is how Biscuit, a pet wellbeing app, rewards breed-specific exercise targets, walking challenges and quizzes, none of which involves a purchase.

3. Which system should own which loyalty data?

Pick one system of record for each type of loyalty data, then decide which flows have to be real time and which can run in batches. Most integration trouble starts when two systems both think they own the member profile or the points balance.

Real time is needed wherever a member is waiting, such as a balance check in the app, a redemption at checkout or a voucher shown to a cashier. Finance reports and segment syncs to marketing tools can run overnight.

Some markets have no usable transaction feed at all. Card linking and receipt scanning can supply one, as long as validation rules are in place to catch fake submissions.

White Label Loyalty is API-first, so the Loyalty Engine plugs into the systems a brand already runs. It connects to CRM, point-of-sale and ecommerce platforms through more than 250 integrations, with pre-built connectors for tools such as Klaviyo, Shopify and Awin and webhooks for anything else. 

Where no transaction feed exists, our data capture tools provide one through card linking and AI receipt scanning. In PepsiCo's promotional campaigns, receipt validation flagged more than 5,000 fraudulent receipts.

4. How should a program be structured across markets and brands?

Most enterprise programs use one of three structures; which one fits depends on how different your markets are and who pays for the rewards. It's worth deciding before the second market launches, since moving members between structures later is a migration project.

Each market will also need its own settings for currency and points value, the reward catalogue (vouchers and partners rarely work across borders), language, time zone and consent. Consent rules vary by country and can limit which behaviours you're allowed to track or reward.

Tickit, which we built for Dubai Holding, gives members points automatically when they pay with a linked card at more than 3,500 outlets in the UAE. Wotzon Rewards in Thailand runs on our multi-tenanted platform: more than 250 merchants manage their own rewards from a self-service console, and the program went from proof of concept to launch in weeks.

5. Who should be able to change loyalty rules, and how?

Before launch, agree who owns the program, who can change each part of it, how changes get tested and how they're recorded. In the first year a handful of people edit the program. 

Three years in, it might be the CRM team, several market teams, finance, customer support and partners, and every extra editor adds some risk of an expensive mistake.

One way to split ownership:

The model needs a few controls behind it: permissions by area let a market manager edit local rewards without access to global earn rules, a test environment lets new rules run on realistic data before members see them, and an audit trail means that when a member disputes a balance, someone can find out who changed what, and when.

In what order should you make these decisions?

Start with the decisions that are hardest to undo, because the early ones shape the data the later ones rely on.

1. The event contract is first, since changing it later breaks existing rules and historic reports.
2. Then the points ledger. Mistakes here tend to be found by auditors.
3. System ownership can be rewired later, though each change involves several teams.
4. Market structure has to be settled before the second market launches.
5. Governance is the easiest to adjust, and it will keep changing as more people work on the program.

If you're replacing an existing program, the same list works as an audit. Problems with the first two usually explain why the current program is slow to change.