A customer is a ticket with a name on it, repeated
Every CRM measure comes from the same place: a ticket that could be attributed to a person. Recency is the date of the last one, frequency the count, monetary the sum, loyalty the points those tickets earned, and a campaign's lift the tickets that happened after the offer versus the tickets that would have happened anyway. If the ticket cannot be attributed, none of it exists. So the first fact in this dataset is not the customer; it is the capture.
The Cybex CRM & Loyalty dataset is five facts on one customer identity. One resolves who the customer is and what they have consented to; one holds every attributable ticket; one scores and segments; one keeps the loyalty programme as a ledger; one records lists, campaigns and the response to them. Nothing here is specific to one retailer or one loyalty provider: member ids, tier names, consent channels and points rules are mapped to generic values at load time, and the provider behind the ledger can change without the model changing.
Capture
At the till and online
The share of tickets carrying a customer is a first-class measure. A segment built on 5% capture describes 5% of the business.
Identity
One person, many keys
Member id, loyalty id, email, phone and web account resolve to one customer key with consent per channel.
Scores
Recomputed, dated
RFM, segment, lifetime value and churn risk are computed per period from the transaction fact and kept with their as-of date.
Lift
Against a control
A campaign's sales are attributed inside a window and compared with a held-out group, so the number is a lift, not a total.
Five facts, one customer identity
| Fact | Grain | Question it answers | Loaded from |
|---|---|---|---|
| Customer identity | One row per resolved customer; one row per source key beneath it | Who is this, how do we reach them, and may we? | Member master, loyalty provider profile, web accounts, POS customer fields, consent records |
| Customer transaction | One row per ticket with a customer; lines beneath it | What did they buy, where, when, from whom, and at what margin? | Ticket fact and lines, product master, store master, seller, tender, campaign code |
| Scores and segments | One row per customer and scoring period | How recent, frequent and valuable, which segment, what next? | Customer transaction fact, scoring rules, model outputs |
| Loyalty ledger | One row per customer and points event | What was earned, redeemed, adjusted and expired, and what is the balance? | Loyalty provider events and the POS points calls, tier rules |
| Lists and campaigns | One row per list or campaign and customer; response events beneath | Who was targeted, who was held out, who responded, and what did it earn? | List builder output, campaign and event definitions, response and attributed tickets |
Figure: the five facts share the customer key; ticket, points event and campaign membership sit beneath it, so a list, a score and a response all point at the same person.
Generic dataset attributes
Attributes are grouped by role. BI marks the ones the list builder, CRM matrix and profile reports aggregate; AI marks the ones the scoring, prediction and recommendation models consume. Most are both.
Customer identity
| Group | Attributes | Notes | Used by |
|---|---|---|---|
| Keys | Customer key, Member id (site + number), Loyalty provider id, Web account id, Email hash, Phone hash, Source system, Match method, Match confidence | One customer key per person; every source key kept beneath it with how it was matched. A merge is a new mapping row, never a delete. | BIAI |
| Profile | Name, Postal code, Region, Home store, Join date, Join channel, Birth month, Gender (if given), Language, Preferred store, Staff flag | Staff customers are flagged so staff discounts and programme measures can exclude them. | BIAI |
| Consent | Email consent, SMS consent, Mail consent, Consent date and source per channel, Do-not-contact, Data-deletion request date | Consent is per channel and dated; every list and campaign is filtered by it at build time, not at send time. | BIAI |
| Status | Active flag, Last activity date, Lifetime first purchase date, Lifetime tickets, Lifetime sales, Current tier, Current segment, Current LTV band | Denormalised from the other facts nightly for the list builder; the facts remain the source. | BI |
| Privacy | PII masked flag, Retention class, Purpose codes | Analytical roles see hashes and bands; contact detail is exposed only to the campaign execution role. | BI |
Customer transaction
| Group | Attributes | Notes | Used by |
|---|---|---|---|
| Identity | Customer key, Ticket number, Store, Channel (store, web, marketplace), Date, Time, Retail week, Cashier, Primary seller, Tender type, Campaign code, Coupon code | Same ticket identity as the sales and audit facts, so a CRM finding drills to the same row an auditor or a store manager sees. | BIAI |
| Basket | Lines, Units, Net sales, Discount, Gross margin, Returns, Average unit retail, Departments in basket, Classes in basket, Private-label share, Programme item flag | Basket composition is stored at line grain beneath the ticket so market-basket and cross-sell measures need no re-join. | BIAI |
| Capture | Captured flag, Capture method (loyalty scan, phone lookup, email, web login), Captured by employee | Capture rate by store, employee and channel is the health measure of the whole dataset. | BI |
| Sequence | Ticket number in customer's history, Days since previous ticket, First-purchase flag, Store of first purchase | Derived once per load; inter-purchase interval is the backbone of recency and churn scoring. | AI |
Scores and segments
| Group | Attributes | Notes | Used by |
|---|---|---|---|
| Identity | Customer key, Scoring date, Scoring window (start, end), Scope (chain, region, banner) | Scores are dated. A segment without an as-of date cannot be compared with last quarter's. | BIAI |
| RFM | Recency days, Frequency (distinct tickets), Monetary (net sales), R score, F score, M score, RFM sum, Quintile bounds used | Scores by quintile within the scope, so a regional segment is relative to its region. Bounds are stored with the scores so they can be reproduced. | BIAI |
| Segment | Segment (champions, loyal, potential loyalist, new, promising, need attention, about to sleep, at risk, cannot lose, hibernating, lost), Previous segment, Segment change, Months in segment | The eleven-segment scheme from the RFM essay, with movement between periods kept so migration can be reported. | BIAI |
| Value | Gross margin contribution, Margin rate, Discount dependency, Return rate, Average order value, Units per ticket, Lifetime value (observed), Predicted 12-month value, LTV band | Margin beside sales: a high-monetary customer bought entirely on markdown is a different segment in practice. | BIAI |
| Risk and propensity | Churn probability, Expected next purchase date, Days overdue, Next best category, Next best product, Cross-sell affinity scores, Channel propensity | Model outputs with the model version, so a change in scoring is visible in the trend. | AI |
| Behaviour | Preferred store, Preferred day-part, Preferred category, Private-label affinity, Seasonal pattern, Full-price share | Behavioural clustering inputs, derived from the transaction fact. | AI |
Loyalty ledger
| Group | Attributes | Notes | Used by |
|---|---|---|---|
| Identity | Customer key, Provider customer id, Event id, Event date and time, Event type (earn, redeem, adjust, expire, bonus, tier change), Source (POS, web, provider, manual), Store, Ticket number | A ledger, not a balance: the balance is the sum of events, and a provider change replays cleanly. | BIAI |
| Points | Points earned, Points redeemed, Points adjusted, Points expired, Running balance, Points value at redemption | Earned minus balance gives redeemed where the provider reports no redemption field. | BIAI |
| Tier | Tier at event, Tier rule (spend or points threshold), Tier start date, Tier expiry date, Progress to next tier | Tier names are provider-specific; the level number is generic. | BIAI |
| Programme measures | Programme tickets, Eligible tickets, Attach rate, Redemption rate, Breakage (points expired ÷ points earned), Liability (outstanding points × value), Cost of programme, Incremental margin | Attach and redemption use eligible denominators; liability is a finance number and reconciles to the provider statement. | BI |
Lists and campaigns
| Group | Attributes | Notes | Used by |
|---|---|---|---|
| Definition | List id, List name, Criteria (saved query), Built date, Sample size, Random sample flag, Campaign id, Campaign name, Event, Channel, Offer, Start date, End date, Attribution window (days), Cost | The criteria are stored with the list so the selection is reproducible; a sample is a list with a random flag. | BI |
| Membership | Customer key, Group (target, control), Included date, Consent state at inclusion, Suppressed reason | Every campaign holds out a control group at build time; suppressed customers keep the reason. | BIAI |
| Delivery and response | Sent, Delivered, Opened, Clicked, Redeemed, Responded (purchased in window), Response date, Response ticket, Response store, Response channel | Response is a ticket in the attribution window, linked by ticket number to the transaction fact. | BIAI |
| Result | Target response rate, Control response rate, Lift (percentage points), Attributed sales, Attributed margin, Incremental sales (target − control × target size), Cost per incremental sale, ROI | Incremental, not attributed, is the number that decides whether the campaign is repeated. | BIAI |
Lift = ResponseRate(target) − ResponseRate(control)
IncrementalSales = (SalesPerCustomer(target) − SalesPerCustomer(control)) × TargetCustomers
Recency = days since last ticket · Frequency = distinct tickets in window · Monetary = net sales in window
IncrementalSales = (SalesPerCustomer(target) − SalesPerCustomer(control)) × TargetCustomers
Recency = days since last ticket · Frequency = distinct tickets in window · Monetary = net sales in window
Functional areas and what each reads
| Functional area | Reads | Deciding attributes | BI output | AI output |
|---|---|---|---|---|
| Identity and capture | Identity, Transaction | Match confidence, capture flag and method, consent per channel | Capture rate by store, employee and channel; duplicate and merge queue; consent coverage | Probabilistic matching across keys; capture-lift targets per store |
| Segmentation | Scores, Transaction | R, F, M scores, segment, margin rate, discount dependency | Segment counts and value by period; migration matrix; segment by store and region | Behavioural clusters beyond RFM; segment-specific value forecasts |
| Lifetime value and churn | Scores | Inter-purchase interval, expected next purchase, churn probability, predicted value | At-risk and overdue lists; LTV bands by cohort; retention curves by join month | Churn prediction with drivers; predicted 12-month value; intervention timing |
| Loyalty programme | Loyalty ledger, Transaction | Points events, tier, attach, redemption, breakage, liability | Programme dashboard: members, active members, attach, redemption, liability, breakage; tier movement | Redemption propensity; points-offer sizing to move a customer up a tier or back into activity |
| List building and targeting | Identity, Scores, Transaction | Saved criteria, purchase history joins, consent, sample | Visual list builder: member lists, random samples, attribute write-back, event assignment | Look-alike expansion; propensity-ranked lists sized to budget |
| Campaigns and events | Lists and campaigns, Transaction | Target and control, attribution window, response tickets, cost | Campaign results: response, lift, incremental sales and margin, ROI; event attendance and spend | Offer selection per segment; send-time and channel choice; expected lift before send |
| Market basket and cross-sell | Transaction (lines) | Departments and classes per basket, affinity scores, private-label share | Basket composition by segment; what sells with what; category penetration per customer | Next best category and product; bundle and cross-sell recommendations |
| Clienteling | Identity, Scores, Transaction | Preferred store and seller, next best action, last purchase, tier | Customer profile card for the store: history, preferences, points, open offers | Next best action per customer for the associate; outreach prioritisation |
Rules the dataset carries
Identity and consent
- One key, many sources. Source ids map to one customer key with the method and confidence recorded; merges add mappings and never delete history, so a mistaken merge can be undone.
- Consent is checked at build time, per channel. A list carries each member's consent state as of inclusion; a campaign cannot target a channel the customer has not agreed to.
- PII stays with execution. Analytical facts carry hashes, bands and keys; names and contact detail are exposed only where a campaign is executed.
- Capture is measured before anything is inferred. Every customer measure is reported with the capture rate it rests on, so a "no customer" flag reads as a capture gap where capture is low.
Scoring and programme
- Scores are dated and scoped. RFM quintiles are computed within the scope and window, the bounds are stored, and segment movement between periods is kept.
- Margin beside monetary. Value scores carry gross margin and discount dependency so a markdown-only customer is not mistaken for a champion.
- The programme is a ledger. Balance, redeemed and breakage are derived from events; a provider change replays the ledger rather than restating a balance.
- Eligible denominators. Attach and redemption rates divide by customers or tickets that could have attached or redeemed, not by everything.
Attribution
- Every campaign holds out a control. Lift and incremental sales are differences against the control group; attributed totals are reported but never presented as the result.
- A response is a ticket. It is linked by ticket number inside the attribution window, so campaign results reconcile to the sales fact and can be drilled to the line.
- Staff and returns are excluded from lift. Staff customers and returned tickets are flagged out of response rates.
Process workflow
The customer cycle runs on two clocks: nightly for capture, identity and scoring, and per campaign for targeting and measurement. The Hub runs the nightly loop unattended; marketing and the stores run the middle; the AI layer scores ahead of the list and measures behind the campaign.
01
Capture
Loyalty scans, lookups, web logins and sign-ups put a customer on the ticket; the provider posts points events.
02
Resolve
Nightly: source keys matched to one customer key; consent refreshed; capture rate and match queue reported.
03
Score
RFM, segment, value, churn and next-best scores computed for the period and dated; migration recorded.
04
Target
Lists built from criteria and scores with consent applied; a control group held out; the list saved with its definition.
05
Offer
Offer, channel and timing chosen per segment; expected lift estimated before the send.
06
Execute
Campaign or event runs; deliveries, opens, redemptions and response tickets land against the membership rows.
07
Measure and learn
Lift and incremental margin versus control; results feed the next offer selection and the scoring models.
Cadence
| When | Step | Output | Owner |
|---|---|---|---|
| Continuous | Capture | Customer on ticket; points events from the provider | POS, web, loyalty provider |
| Nightly | Resolve, score | Identity mappings, consent, capture rate, dated scores and segments, ledger balances | AI Data Hub |
| Per campaign | Target, offer, execute | List with control, offer plan, deliveries and responses | Marketing |
| Weekly | Programme and capture review | Attach, redemption, liability; capture by store and employee | Marketing, store operations |
| Campaign close plus window | Measure | Lift, incremental sales and margin, ROI | Marketing, finance |
| Quarterly | Learn and tune | Segment migration review, model refresh, offer library update | Marketing, data science |
Where BI ends and AI begins
BI on the customer dataset
QuestionWho bought, how often, what did the campaign return
UnitCustomers, tickets, points, lift
SurfaceList builder, CRM matrix, profile card, programme dashboard
RulesConsent, control groups, eligible denominators
OutputA list and a result
AI on the same dataset
QuestionWho will lapse, what to offer, what it will earn
UnitProbabilities, predicted value, recommendations
SurfaceScored lists, next-best-action cards, insight pages
RulesLearned from response and margin
OutputA ranked list with an expected lift
Both read the same five facts. The segment a marketer selects in the list builder is the segment the churn model scored, and the response the campaign report shows is the ticket the sales fact already holds.
What a conforming dataset delivers
Target outcomes from a CRM & Loyalty dataset deployment
Customer measures that state their coverage. Every segment, LTV and programme number is reported with the capture rate beneath it, so the business knows what share of trade it describes.
Campaigns measured as lift. Control groups are built in, responses reconcile to tickets, and the result is incremental margin rather than attributed sales.
A programme you can change. The loyalty ledger is provider-independent, so a switch of provider replays history rather than losing it.
5
Facts on one customer identity
11
RFM segments, dated and scoped
Control
Held out on every campaign
Deployment approach
01
Map identity and consent · Week 1
Inventory every customer key (member, loyalty, web, POS fields), define the match rules and confidence levels, and map consent channels and the loyalty provider's event types to the ledger.
02
Load transactions and ledger · Weeks 2–3
Build the identity and customer-transaction facts from the ticket fact, replay the loyalty ledger, and publish capture rate, programme dashboard and the list builder over the resolved keys.
03
Score and segment · Week 4
Compute dated RFM scores and the eleven segments, add margin and discount dependency, and publish segment counts, migration and the at-risk list. Train the first churn and value models on the history.
04
Close the loop · Weeks 5–6
Run the first campaign with a control group, measure lift against the transaction fact, connect next-best-action to the profile card, and start the quarterly model and offer review.