Capturing UK Grocery Loyalty Pricing (Clubcard, Nectar & More Card) Across Tesco, Sainsbury's & Morrisons

The Client

A pricing-intelligence business building a product around UK grocery — the market where, more than almost anywhere, the loyalty price has quietly become the real price. When the majority of a supermarket's promotional volume moves at Clubcard Price, Nectar Price, or More Card Price, a dataset that captures only the standard shelf price is describing a market that increasingly doesn't exist at the till. The client understood this precisely, which is why their engagement with Actowiz Solutions began not with a full production order but with a sample — a verification step before commercial scoping, targeting the exact field that makes or breaks UK grocery data: member pricing, captured correctly.

This case study is worth documenting for two reasons: it's a clinic in what UK grocery pricing data actually requires, and it shows how a sophisticated buyer de-risks a data engagement — by testing the hardest field first, and asking the one technical question most buyers forget to ask.

The Challenge

The client's sample brief was specific, and every specification pointed at a genuine difficulty:

• Loyalty pricing is a distinct field, not a discount. The core requirement: capture standard price, member/loyalty price, and promotional price as three separate fields — member price null where none exists, promotional price distinguished from both. This sounds simple and is the crux of the entire problem. On a UK grocery product page, these prices appear in different components, with different labels (Clubcard Price, Nectar Price, More Card Price), sometimes layered (a promotional price and a member price on the same product), and a pipeline that collapses them into one "price" field destroys exactly the signal the client needed. Getting the three-way distinction right, per chain's different presentation, is the engagement.
• Three chains, three loyalty schemes, three page structures. Tesco's Clubcard Price, Sainsbury's Nectar Price, and Morrisons' More Card Price each present differently, on differently-built sites. A unified schema had to capture the same logical fields from three distinct presentations without losing each scheme's specifics.
• Price-per-unit is mandatory for grocery comparison. As in any grocery data, price-per-unit (per litre, per kg, per 100g, per wash) is essential — and it must be captured or computed consistently, and ideally captured for each price type so member-price-per-unit is comparable across chains.
• Search-driven scope with completeness. The brief specified running defined search terms per chain and returning all matching products per term — plus a targeted set of products currently on loyalty price across any category. This is a search-completeness requirement: return everything matching, not a first-page sample.
• And the question that revealed a serious buyer: ID stability. The client asked, explicitly, whether the product identifiers returned would be stable across refreshes — would the same product carry the same ID in next week's data? This is the single most important and most overlooked question in recurring price data. An ID that changes between crawls makes time-series analysis impossible: you cannot track a product's price over time if you can't reliably say "this is the same product as last week." That the client asked it upfront signalled they were scoping a real production time series, not a one-off snapshot — and it deserved a real, honest answer, not reassurance.

The Actowiz Solution

1. The three-way price model, per chain.

The heart of the engagement: extraction logic tuned per chain to correctly identify and separate standard price, loyalty price (Clubcard/Nectar/More Card, captured with its scheme label), and promotional price — as three distinct fields, with member and promotional prices null where genuinely absent, and layered cases (member + promo on one product) represented correctly rather than flattened. This three-way model, validated against each chain's specific presentation, was exactly the field the client's sample existed to verify.

2. Full required-field schema.

Every record delivered with the client's specified fields: product identifier, chain, product title, brand, pack size, standard price, member/loyalty price (separate, null where none), promotional price (distinguished from both), price-per-unit, direct product-page URL, stock availability, category, and capture timestamp — in the client's preferred JSON (CSV available), the complete record as specified.

3. Search-completeness execution.

The defined search terms run per chain with all matching products returned per term (not a first-page sample), plus the targeted loyalty-priced product set per chain across categories — delivered with the completeness the brief required, so the sample genuinely represented the chains' matching assortment.

4. Price-per-unit rigour.

Price-per-unit captured/computed consistently and, where the client needed comparison, aligned to the member price too — so loyalty-price-per-unit was comparable across the three chains, the genuinely useful comparison in a loyalty-driven market.

5. The honest ID-stability answer.

Rather than a marketing reassurance, we gave the client the real engineering answer their question deserved: which identifier we return (the retailer's own stable product identifier where exposed, resolved from the product URL/page), why that ID is stable across refreshes (it's the retailer's persistent product key, not a position- or session-derived value), the specific cases where it can change (product relisting, catalogue restructures) and how those are handled, and — crucially — that our recurring feeds are built to maintain a consistent internal product key that survives retailer-side changes, so the client's time series stays joinable even when a retailer reshuffles. This answer, more than the data itself, was what the sample was really testing.

6. Crawl-transparency metadata.

Per the brief's request, the sample stated, per chain, exactly when it was crawled — capture timestamps per record and a per-chain crawl-window summary — so the client knew the data's vintage and freshness precisely, and could judge it as the point-in-time snapshot it was.

7. Compliance.

Public catalogue and pricing data only; no personal or loyalty-account data (the loyalty price is public on the product page; no member accounts, no personal data involved); GDPR-conscious posture per our compliance framework; per-record lineage.

The Outcome

The client got exactly what a well-designed sample delivers: verification of the hard thing. The three-way price model — standard, loyalty, and promotional as distinct, correctly-populated fields across three different loyalty schemes and three different site structures — was proven on their own specified search terms and loyalty-priced set. This was the field their entire product depended on, and the sample demonstrated it worked, per chain, with the null-handling and layered-case correctness that separates a usable loyalty-price dataset from a misleading one.

The ID-stability answer was, by the client's own framing, the deciding factor. Because we answered it honestly and specifically — which ID, why it's stable, when it can change, and how our consistent-key approach protects their time series through retailer-side changes — the client could scope their production time series with confidence rather than discovering an ID-drift problem three months into a longitudinal dataset. That honesty, delivered at the sample stage, is what earns the production engagement: a buyer scoping recurring price data is really buying reliability over time, and the sample proved it.

The crawl-transparency metadata closed the loop: the client knew precisely when each chain was captured and could judge the sample as the point-in-time reference it was. The sample did its job — it verified the pipeline on the client's terms — and set up the commercial scoping for the full production programme (more UK chains, Aldi/Lidl coverage, with and without member pricing) on a foundation of demonstrated capability rather than promised capability.

Why This Pattern Repeats

UK grocery — and increasingly grocery markets everywhere with loyalty-tiered pricing — cannot be understood without capturing member pricing correctly, as a field distinct from standard and promotional price. And any recurring price dataset lives or dies on identifier stability. The transferable design: a rigorous multi-way price model tuned per retailer's presentation, complete search-driven collection, price-per-unit across price types, an honest and engineered answer to ID stability, and crawl-transparency metadata — proven on a sample before production. The loyalty price is the real price now; capturing it correctly, with joinable IDs over time, is the whole game.

Frequently Asked Questions

Why capture loyalty price as a separate field from standard and promotional price?

Because in UK grocery the loyalty price (Clubcard, Nectar, More Card) is increasingly the price most volume actually transacts at — and collapsing it into a single "price" field destroys the exact signal that matters. Standard, loyalty, and promotional must be three distinct, correctly-populated fields.

Are the product IDs stable across refreshes?

We return the retailer's persistent product key (resolved from the product page/URL) and maintain a consistent internal key across refreshes, so the same product carries the same ID week to week — the prerequisite for any price time series. Cases where retailer IDs can change (relisting, restructures) are handled to preserve joinability.

Is loyalty-account or personal data involved?

No — the loyalty price is displayed publicly on the product page. No member accounts, no personal data; public catalogue and pricing data only, handled per our compliance framework.

Can this scale beyond three chains?

Yes — the same model extends across UK chains including Aldi and Lidl, with and without member pricing. This sample is the verification step before that production scope. Contact Actowiz Solutions to scope UK grocery price coverage.