This page teaches how to decide which customer data a loyalty programme genuinely needs, for an export retail buyer, a brand-side contact, or a domestic buyer setting up a scheme for the first time. This lesson mainly teaches the information flow: it separates the small set of data fields a loyalty programme actually uses from the much longer list a system can technically collect. A retailer often assumes that more customer data is always better, since it feels like more insight for later use. Without this skill, a retailer builds a customer database full of fields nobody ever reads, pays to store and protect data it does not need, and risks a customer's trust over information the programme was never going to use.
You need: no previous lesson. A basic understanding of what a loyalty programme is, a scheme that rewards a customer for repeat purchases, is useful, though not required.
By the end of this lesson you can:
Not covered here: grouping customers by their own purchase behaviour once the data exists (Lesson 2), calculating the value of a repeat customer (Lesson 3), deciding whether a specific reward actually changes behaviour (Lesson 4), and building a complete customer data and loyalty worksheet (Lesson 5).
| Term | Meaning |
|---|---|
| Customer record | A single stored entry of information about one identified customer, built from that customer's own purchases and contact details. |
| Purchase history | The list of what a specific customer has actually bought over time, kept as fact rather than as a guess about that customer. |
| Loyalty programme | A scheme that rewards a customer for repeat purchases, usually in exchange for the retailer holding that customer's own purchase data. |
| Consent-based data collection | Collecting a customer's own data only after that customer has agreed to it, and only for the stated purpose the customer agreed to. |
| Aggregated data | Customer information combined across many customers, so no single customer can be identified from the combined figure. |
| Programme running cost | The yearly cost of operating a loyalty programme, including its data system, staff time and any reward paid out. |
A loyalty programme exists to reward repeat purchases and to use real purchase data to decide who earns that reward. Purchase history, a way to identify the same customer across visits, and basic contact details for reaching that customer are the small set of fields the programme actually reads. Any field beyond that set, a customer's exact address, a customer's browsing habits, a customer's age beyond a broad band the programme never uses, is a field the retailer now has to store, protect and justify holding, without the programme ever reading it to decide anything.
| What can differ | The shapes you meet | Why it matters |
|---|---|---|
| Export MTO retailer vs. domestic MTS/hybrid retailer | An export retailer such as Fairway Stores runs one confirmed seasonal buy per style with no reorder inside the season; a domestic retailer such as Cedar & Co. reorders mid-season based on its own forecast | A domestic retailer's loyalty data can influence a reorder decision within the same season; an export retailer's loyalty data mostly informs the next season's own buy |
| Wholesale customer data vs. shop customer data | A brand selling wholesale through Fairway Stores may never see the final shop customer's own data at all, since Fairway Stores runs its own till and its own loyalty scheme | A brand that does not own the till has to agree with its retail partner what customer data, if any, is shared back, rather than assuming it already has it |
| A programme built for a broad customer base | A retailer with many shops and a wide range of styles needs purchase history broad enough to see a customer's overall pattern, not just one category | A programme reading only one category's data can wrongly treat a broad repeat customer as a one-time buyer |
| A programme built for a narrow, single-category range | A smaller domestic retailer selling one product family can run a simpler loyalty scheme, since a customer's whole purchase history sits inside one category already | A narrow-range retailer risks over-collecting data it copied from a broader retailer's own scheme design, without needing that much |
| Product families | The same rule, collect only the data the programme actually uses, applies whether the retailer sells apparel, socks and hosiery, knit-to-garment, terry and towels, or home textiles and bedding | A retailer new to loyalty data collection should not assume a different product family needs a different, longer list of fields |
Fairway Stores, an export department-store chain that buys Order A's own T-shirt style wholesale from Northline Apparel at USD 8.00 per piece and sells it at its own USD 19.90 shop price, is designing its first loyalty programme. Fairway Stores' own systems team has proposed a customer sign-up form asking for purchase history, a loyalty card number, an email address, a home address, a date of birth, and the shop customer's own browsing history on Fairway Stores' website.
Before approving the form, Fairway Stores' own loyalty programme lead needs to decide which of these fields the programme will actually use to decide who earns a reward, and which fields only add cost and risk without ever being read.
The worked numberFairway Stores' own loyalty programme lead reads this figure directly against the sign-up form: the programme's own value comes from purchase history alone, since that is the field driving the extra 2 pieces per member per year. None of the other fields on the proposed form, the home address, the date of birth, or the browsing history, appear anywhere in this calculation, because the programme was never going to read them to decide who earns a reward.
A common mistake is assuming that collecting more customer data now is automatically useful later, without checking whether the programme has any actual use for each field at launch. If Fairway Stores had approved its systems team's full sign-up form without this check, it would be storing and protecting a home address, a date of birth and a browsing history for every one of its loyalty members, none of which the worked number above needed, while carrying the cost and the customer-trust risk of holding that unused data indefinitely.
A loyalty programme only needs to know what a customer has actually bought, some way to recognise that same customer again, and how to reach them to give the reward. Anything beyond that is a field the retailer has to store and protect without ever using it to decide anything. On Fairway Stores' own T-shirt style, the whole programme's value comes from purchase history driving 2 extra pieces bought per member per year, worth USD 23.80 in profit; the programme needs 2,000 members to cover its own USD 47,600 running cost, and that figure never depends on a home address, a date of birth or browsing history.
Fairway Stores' own loyalty programme lead has received the sign-up form its systems team designed, ready to launch across all shops next month. The facts in front of the loyalty programme lead:
The note attached to the systems team's own form:
Should the loyalty programme lead approve the six-field form as submitted? Decide before you open the decision.
No. The loyalty programme lead should approve only the fields the programme actually uses, and remove the rest before launch.
Two facts decide this. First, this lesson's own rule states that a loyalty programme only needs the data it actually uses to decide who earns a reward, and the worked number shows the entire breakeven calculation depends on purchase history alone. Second, this lesson's own trap warns exactly against collecting a field with no stated use; the home address, the date of birth and the browsing history each carry storage cost and customer-trust risk without appearing anywhere in the programme's own decision.
Approving the six-field form as submitted would commit Fairway Stores to protecting three unused fields for every one of its 2,000-plus loyalty members, a real ongoing cost and a real trust risk taken on for no stated benefit.
None of these 6,000 unused field entries contribute to the USD 23,800 or USD 47,600 figures in the worked number; they exist only as stored data the programme must protect, with no stated decision reading them. The cost is not one fixed figure the way a markdown or a shipping charge is, but it is real: every unused field is a field Fairway Stores must secure, and a field a customer may reasonably ask why it was collected at all.
Use the T23-C04 Customer data and loyalty worksheet. For Fairway Stores' own sign-up form, list every proposed field and the exact decision it serves, and the sheet flags any field with no stated decision attached, so an unused field is visible before the programme launches rather than after.
[Download the Customer data and loyalty worksheet](../../templates/T23-C04-customer-data-and-loyalty-worksheet.xlsx)
1. Why does a loyalty programme only need a small set of customer data fields, rather than every field a sign-up form could ask for?
2. Fairway Stores' loyalty programme needs 2,000 enrolled members to cover its own USD 47,600 running cost. Which single field's own data actually drives that calculation?
3. A domestic retailer proposes collecting a customer's browsing history for a new loyalty programme, with no stated use for it in the programme's own reward decisions. What should the retailer do?
| EN | AR | FR | TR | Meaning |
|---|---|---|---|---|
| Customer record | سجل العميل | Fiche client | Müşteri kaydı | A single stored entry of information about one identified customer, built from that customer's own purchases and contact details. |
| Purchase history | سجل المشتريات | Historique d'achats | Satın alma geçmişi | The list of what a specific customer has actually bought over time, kept as fact rather than as a guess about that customer. |
| Loyalty programme | برنامج الولاء | Programme de fidélité | Sadakat programı | A scheme that rewards a customer for repeat purchases, usually in exchange for the retailer holding that customer's own purchase data. |
| Consent-based data collection | جمع البيانات القائم على الموافقة | Collecte de données fondée sur le consentement | Onaya dayalı veri toplama | Collecting a customer's own data only after that customer has agreed to it, and only for the stated purpose the customer agreed to. |
| Aggregated data | بيانات مُجمَّعة | Données agrégées | Toplulaştırılmış veri | Customer information combined across many customers, so no single customer can be identified from the combined figure. |
| Programme running cost | تكلفة تشغيل البرنامج | Coût de fonctionnement du programme | Program işletme maliyeti | The yearly cost of operating a loyalty programme, including its data system, staff time and any reward paid out. |
You now know which customer data fields a loyalty programme actually needs before it launches. The next lesson shows what to do with that data once it exists: grouping customers into segments based on what they have actually bought, not on an assumption about who they are. Back to the course map