UK Supermarket Price & Product Data: The Complete Guide (2026)

Introduction

UK grocery is the most mechanically complex retail market in Europe to collect data from, and the reason is that no two of the major retailers price the same way. Tesco and Sainsbury's run loyalty price layers. ASDA runs a cashpot that is not a discount at all. Morrisons sells a large share of its range by weight. Aldi and Lidl are almost entirely own-label with no shared barcodes, and much of Lidl's promotional activity sits behind an app. A schema built for one of them will silently produce wrong numbers on the others. This guide maps the landscape, compares the pricing mechanics side by side, sets out the matching methodology that cross-retailer comparison actually requires, and covers UK compliance.

Who the players are and why this data is valuable

The UK grocery market is dominated by four large supermarket groups — Tesco, Sainsbury's, ASDA and Morrisons — alongside two discounters, Aldi and Lidl, which have taken substantial share over the past decade — in the 12 weeks to 9 August 2026, Worldpanel by Numerator (formerly Kantar Worldpanel) put the six at Tesco 27.8%, Sainsbury's 15.2%, Asda 11.5%, Aldi 10.7%, Lidl 8.8% and Morrisons 8.5%, with Aldi and Lidl together now accounting for close to 19.5% of the market. Beyond them sit Waitrose, Co-op, Iceland, M&S Food and Ocado, each serving distinct positions.

The commercial demand for this data comes from five directions.

• CPG and FMCG brands need to know whether the price and promotion they agreed with a retailer is actually live, on the agreed dates, at the agreed depth. Promotional non-compliance is a real and recoverable cost, and it is invisible without daily data.
• The retailers themselves benchmark each other. Price-matching schemes in particular require continuous, auditable competitor pricing to administer credibly — you cannot run a price match programme on data you check weekly.
• Price comparison and cashback platforms need broad catalogue coverage refreshed frequently enough that displayed prices are not stale.
• Analysts, researchers and journalists track food inflation at SKU level, study shrinkflation, and examine loyalty pricing structures — work that has drawn regulatory attention, with the Competition and Markets Authority's Review of Loyalty Pricing in the Groceries Sector, published in November 2024, examining Clubcard, Nectar and other member pricing at Tesco, Sainsbury's, Morrisons, Co-op and Waitrose and finding that loyalty prices delivered genuine savings — typically 17–25% — in the large majority of cases checked, while flagging a small number of pricing patterns that warranted closer scrutiny.
• Retail media and agency teams measure on-site search ranking and share of shelf for client products.

What unites them is that they all need the same thing: accurate, comparable, timestamped price data across multiple retailers. And that turns out to be much harder than it sounds.

The core problem: every retailer prices differently

This is the section that matters most, and it is the thing most guides skip.

There is no such thing as "a UK supermarket price schema". Each retailer runs a different promotional architecture, and those differences are not cosmetic — they change what a price field means. Here is the landscape in one view.

Retailer Pricing Mechanics Comparison

Read down the third column. Three of the six run a headline mechanic that is not a price reduction at all, and each fails differently if you model it as one.

• ASDA Rewards credits pounds into a cashpot for later redemption. The shopper pays the shelf price today. Model a £2 cashpot as a £2 discount and your ASDA basket reads materially cheaper than it is.
• Morrisons Price Lock is a commitment to hold a price for an extended period. It may not lower today's price at all. Its value is as a stability signal, not a discount — and collapsing it into a promo field loses exactly the information that makes it interesting.
• Lidl Plus offers are delivered through an authenticated app and are frequently personalised to the individual shopper. They are not public data and should not be collected at all.

A single "effective price" column applied across all six retailers will be wrong on at least three of them, in different directions, by different amounts. That is why cross-retailer grocery datasets so often fail quietly: nothing errors, the file validates, and the numbers are simply not comparable.

The five problems that apply across UK grocery

Beyond the per-retailer mechanics, five issues recur across the whole market. Every one of them is a source of silently wrong data.

1. Prices resolve against a location

UK online grocery pricing and availability resolve in the context of a delivery postcode or a selected store. Change the context and you can change availability, offers and — at retailers operating convenience formats — the price itself. ASDA Express and Morrisons Daily generally price above their large-store equivalents.

A capture without a controlled, recorded location context is not reproducible. You cannot compare Tuesday's file to Wednesday's and trust the delta, because you do not know whether the price moved or the context did.

The rule: every capture is pinned to an explicit location and store format, and both ship as fields on every row, stamped at collection time rather than reconstructed later. For national benchmarking, fix one reference context and hold it constant for the life of the dataset. For regional work, run a defined panel in parallel. Never blend formats into one price series.

2. Loyalty layers are not one thing

Clubcard Prices, Nectar Prices and More Card prices are genuine price reductions available to members. ASDA Rewards is not. Lidl Plus is not public. Treating "loyalty" as a single concept across retailers produces a dataset where the same column means four different things.

The rule: model pricing as an array of typed offer objects rather than a fixed set of columns, then flatten to columns at output. A new promotional mechanic next year becomes a new entry, not a schema migration and a broken downstream report.

3. Not everything is priced per item

Morrisons in particular sells a large share of its range by weight — Market Street counter lines, loose produce, variable-weight packs. A whole chicken at £6.50 per kilogram recorded into a price column that also holds a £1.20 tin of beans corrupts every category average by a factor that varies per product.

The rule: pricing_basis is a required field with no default. If it cannot be resolved for a row, that row fails validation rather than defaulting to per-item. Normalise everything to a comparable unit price at ingestion — that is the only field that compares across fixed and variable weight lines, and across retailers.

4. Some ranges are ephemeral

Aldi Specialbuys and Middle of Lidl are time-limited non-food ranges that drop on a schedule, sell out, and disappear. A product that appears and sells out between two daily captures never existed as far as your dataset is concerned — and there is no archive to backfill from.

The rule: capture cadence follows the drop schedule, not the clock. Sell-out timing is often more commercially valuable than price, and it exists only if you sampled densely enough to observe both ends of the transition. Ship the observation gap alongside any derived duration as an uncertainty band.

5. Own-label breaks barcode matching

This is the problem that defines cross-retailer work, and it gets its own section below.

Cross-retailer matching: the hard part

Comparing prices across UK grocers sounds like a lookup problem. It is not. It is a matching problem, and the difficulty scales with own-label share.

Branded lines match cleanly. A branded product carries the same EAN at Tesco, Sainsbury's, ASDA and Morrisons. Match on identifier, compare prices, done. This is the easy 30-40% of a typical basket.

Own-label lines do not match at all. A Tesco own-label bean has no equivalent EAN at Sainsbury's. There is no identical item — there are three different products serving the same need at three different quality positions.

Discounter comparison is hardest, because both sides are almost entirely own-label. An Aldi-versus-Lidl comparison has no shared identifier anywhere. Every single matched pair is an attribute-based judgement.

The matching methodology that holds up

• Match on normalised unit basis, never headline price. Price per 100g or per litre. Pack sizes differ deliberately between retailers, and discounters in particular use non-standard pack sizes that make headline comparison meaningless
• Match tier to tier. A retailer's value line pairs with another's value line, not with its premium line. Every major UK grocer runs a three-tier own-label architecture — value, core, premium — and tier mismatch is the single largest source of misleading comparison. An Aldi Everyday Essentials product compared against a Tesco Finest product produces a number that is arithmetically correct and analytically worthless
• Match on published attributes — variety, cut, fat content, format, key ingredients
• Score every pair and expose the score. Exact-format, same-tier, comparable-pack matches score high. Loose category-level pairings score low. A basket comparison built on low-confidence matches presented as fact is how data vendors lose clients
• Accept partial coverage. Not every line has a defensible counterpart. A comparison covering 60% of a basket with high-confidence matches is far more useful than one covering 100% with a third of the pairs invented

Why this matters legally, not just analytically

If your output supports public "cheaper than" claims, the matching methodology carries legal weight. Misleading comparative advertising is regulated in the UK. A comparison whose methodology is unstated and whose confidence is unexposed is not defensible when a competitor's legal team challenges it — and in UK grocery, they do.

Any serious comparison dataset ships its matching logic alongside its prices. If a vendor will not show you theirs, that is the answer to your question.

A schema that works across all six retailers

The practical approach is a common core plus retailer-specific extensions. Every row carries the core; retailer-specific fields populate where they apply.

Core identity: product_id, product_url, product_name, brand, is_own_label, own_label_tier, pack_size, gtin_ean, category_path, image_urls, retailer.

Core pricing: price, currency, pricing_basis, unit_price, unit_of_measure, was_price, offers[] (typed array), effective_price (derived, till-price only).

Core context: availability_status, delivery_postcode, store_id, store_format, fulfilment_type, price_source, captured_at.

Retailer extensions: clubcard_price (Tesco); nectar_price, aldi_price_match (Sainsbury's); is_rollback, rewards_offer, rewards_conditions (ASDA); more_card_price, is_price_lock, price_lock_until, price_per_kg, estimated_weight_kg (Morrisons); is_specialbuy, sold_out_at, availability_duration_hours (Aldi); is_middle_of_lidl, observation_gap_minutes (Lidl).

Three design rules make this work.

• effective_price reflects only what is paid at the till. Rewards cashpot value and Price Lock status never enter it. They live in their own fields where a user can combine them deliberately if they want to.
• Derived fields never replace raw fields. Store the inputs. An analyst who cannot reconstruct how a number was produced cannot defend it.
• Required fields fail loudly. pricing_basis, store_format and price_source have no defaults. A null is a validation failure, not a warning. Failing on 200 rows is far cheaper than silently mispricing them.

Refresh strategy by category

Uniform daily capture across everything is the most common configuration and usually the wrong one — it overspends on stable categories and underspends where it matters.

Recommended Cadence by Category

The asymmetry worth internalising: some fields cannot be created later. Rollback duration, Specialbuy sell-out speed, promotional window length — these are derived from observed state transitions. A client who starts with weekly capture and later wants duration analysis cannot backfill it. The data was never collected.

That makes the cost of starting late genuinely irrecoverable, which is not true of most data projects.

Validation: catching silent failures

Front ends change. Parsers break. The dangerous failures are the ones that do not throw errors.

Boolean fields are the most dangerous fields in a retail scraper, because a broken parser and a real "no" look identical. When ASDA's Rollback selector stops matching, is_rollback writes false across the catalogue. Nothing errors. Three weeks later someone asks why ASDA appears to have stopped running promotions, and you have three weeks of corrupt history that cannot be recovered.

A validation layer that runs on every batch:

• Rate monitoring on every boolean and optional field. If clubcard_price populates on 18% of rows Monday and 0.2% Tuesday, that is a parser break, not a market event
• Cross-field logic. Loyalty price above standard price. Rollback flagged with no was-price. Sold-out timestamp before first-seen
• Required-field completeness. Zero nulls permitted in pricing_basis, store_format, price_source
• Unit price sanity bounds by category — how a per-kg value written into a per-item field surfaces
• Volume checks per category. 1,600 SKUs yesterday, 80 today is a discovery failure
• Historical continuity. Match rate against the previous run; a sharp drop means keys are breaking
• Capture continuity alerting on drop days — a missed ephemeral window is permanent loss and should alert immediately, not appear in a weekly report

UK legal and compliance

UK enterprise buyers raise this during procurement. It is the main commercial risk in the category.

Public data only. Collect what any visitor can see without authenticating. No logged-in areas, no account data, no basket data. This boundary does real work at Lidl, where a substantial share of promotional activity sits behind an authenticated app — that data is out of scope regardless of technical feasibility.

No personal data. Prices are not personal data. Customer reviews may contain reviewer names or identifiable content — if you collect reviews, UK GDPR applies and you need a lawful basis, retention policy and minimisation. For most price monitoring, collect review counts and averages only, never review text or author identity. Personalised offers are a different category again, because they are derived from an identified individual's behaviour.

Database rights. The UK retains a sui generis database right, separate from copyright, protecting substantial investment in obtaining, verifying or presenting database contents. Extracting a substantial part can infringe it. The defensible position is factual price monitoring for analysis and comparison — not republishing a retailer's catalogue as your own product.

Comparative claims. Misleading comparative advertising is regulated. Where output supports public price comparisons, matching methodology and confidence scores are part of the compliance posture, not just the analytics.

Rate limiting as a legal posture. Conduct that impairs a service is where scraping disputes escalate. Conservative volumes are a risk control — with particular care around high-traffic moments like discounter drop mornings.

Terms of service. Site terms are contractual and enforceability against non-account-holders varies. Note that this variability is precisely why account-gated content sits on a different and much less favourable footing.

Not legal advice. Take advice from a qualified UK solicitor for your specific programme.

Build in-house or buy?

The honest dividing lines, by scope.

Build is reasonable when: you need one or two ambient categories, from one or two retailers, refreshed weekly, and can tolerate gaps when a site changes. The first version of a UK grocery scraper is genuinely not hard.

Buy makes sense when: your scope includes any of the following — multi-retailer comparison requiring a matching layer; fresh and variable-weight categories; ephemeral ranges with drop-aligned capture; multi-format or regional panels; or an SLA someone else is accountable for.

The calculation that usually decides it is not the build cost. It is the three-year maintenance cost, and the cost of decisions made on wrong data before anyone noticed a break. Model both.

There is also a governance dimension. An in-house team under pressure to "just get the Lidl Plus data" faces a temptation that an external partner with a contractual scope boundary does not. Having the boundary written into a contract and into the validation layer is worth something on its own.

Twelve questions to ask any UK grocery data vendor

Use these in evaluation. The answers separate operators from resellers.

• How do you handle Clubcard, Nectar and More Card prices — as separate fields or folded into one price?
• Where does ASDA Rewards cashpot value appear in your schema?
• Is Morrisons Price Lock captured as a discount or as a duration?
• Do you carry pricing_basis on every row, and what happens when it cannot be resolved?
• What location and store format context is stamped on each row, and how is it held constant?
• How do you capture Aldi Specialbuys and Middle of Lidl, and at what cadence?
• What is your position on Lidl Plus data?
• What is your cross-retailer matching methodology, and do you expose confidence scores?
• What validation runs before a file ships, and what specifically catches a silent boolean failure?
• What is your historical depth, and can you backfill?
• What is the SLA on delivery, accuracy and time-to-fix when a site changes?
• Can you show a real sample from a category we choose, this week?

Question 7 is the fastest filter. A vendor who claims complete Lidl Plus coverage is either describing something narrower than it sounds or doing something that creates exposure for you. Either way, you have learned what you needed to know.

Frequently asked questions

Which UK supermarkets can be covered?

Tesco, Sainsbury's, ASDA, Morrisons, Aldi and Lidl are the core six. Waitrose, Co-op, Iceland, M&S Food and Ocado extend coverage. Each needs retailer-specific handling — a schema built for one will produce wrong numbers on the others.

How often should UK grocery prices be refreshed?

Daily covers most promotional monitoring, since UK promo cycles typically turn over weekly. Fresh and availability tracking benefit from twice-daily. Ephemeral ranges need drop-aligned intraday capture. Inflation research is fine weekly, because depth of history matters more than frequency.

Can prices be captured for specific UK regions?

Yes, by running a defined postcode panel in parallel with the location and store format stamped on every row. Because UK grocery pricing resolves against a delivery location, this is the only reliable way to produce regional comparisons.

Can loyalty prices be captured without a loyalty account?

For Tesco Clubcard, Sainsbury's Nectar and Morrisons More Card, yes — these are displayed publicly on product pages so shoppers see the saving before signing in. Lidl Plus is different: it is app-gated and frequently personalised, which places it outside public data.

How do you compare own-label products across retailers?

Through attribute-based matching on normalised unit price, own-label tier equivalence, pack size and published attributes, with a confidence score on every pair. Barcode matching does not work, because own-label products are exclusive to each retailer by definition.

Is scraping UK supermarket websites legal?

Collecting publicly displayed factual pricing for analysis is a widely practised commercial activity. The risk areas are personal data under UK GDPR, database rights, contractual site terms, conduct that impairs a service, and — where output supports public comparison claims — comparative advertising rules. Take legal advice for your specific programme.

What is the biggest mistake teams make with UK grocery data?

Applying one schema across all six retailers. It produces files that validate cleanly and are wrong in different directions on different retailers, which is far more damaging than an obvious failure because nobody catches it until a decision has already been made.

Retailer-specific guides

Each of these goes deep on one retailer's mechanics, schema and failure modes:

• How to Scrape Tesco Product, Price & Clubcard Price Data — dual price structure and loyalty capture
• How to Scrape Sainsbury's Grocery Data (incl. Nectar Prices) — three overlapping price layers and Aldi Price Match
• How to Scrape ASDA Product & Rollback Price Data — why Rewards is not a discount, and store-format pricing
• How to Scrape Morrisons Product Catalogue & Offers — variable-weight fresh and pricing basis
• How to Scrape Aldi UK Product & Specialbuys Data — ephemeral ranges that cannot be backfilled
• How to Scrape Lidl UK Product Data — the public versus app-gated boundary

Get a sample dataset

Actowiz Solutions delivers UK grocery datasets across all six major retailers, with retailer-specific mechanics modelled correctly, location and store-format context on every row, attribute-based cross-retailer matching with exposed confidence scores, validated schemas and scheduled delivery to S3, SFTP, BigQuery or API.

Conclusion

You can also reach us for all your mobile app scraping, data collection, web scraping , and instant data scraper service requirements!