Mobile Proxy Retail Data

Retail Data Beyond the Website

Retail data is the part of commerce that never moved online. It describes physical stores: what is on the shelf in a particular branch, at what price, today. The unit of analysis is the store rather than the catalogue, and almost everything interesting is gated behind a location.

That produces a specific access shape. Availability endpoints, click-and-collect slots and local pricing are all functions of a branch, so the retailer asks where you are before it will tell you anything. Supplying a postcode from a foreign address frequently returns a partial answer or a rejection, which is why a local exit and a local postcode go together — either alone tends to produce data that looks fine and is not.

Finding Store Identifiers First

Every store-level endpoint expects a store_id, and the retailer's own store locator is usually the only place that maps a postcode to one. A locator query typically takes a postcode or a latitude and longitude pair plus a radius, and returns the branches inside it along with their internal identifiers. That call has to run once, from inside the same market, before any stock or price collection starts, because branches are added, closed and renumbered over time — a stale store_id reads back as store not found rather than out of stock, a failure mode that is easy to mistake for the product itself disappearing.

Store-Level Stock and Availability

The most valuable field in retail data is one no retailer publishes: how long a product was actually unavailable at a given branch. Availability snapshots are commonplace and fairly uninformative. Out-of-stock duration is what tells you about supply reliability, distribution failures and demand spikes — and like time on market in property, it exists only if you were collecting continuously.

store_id          …
postcode_area     …
product_id        …
in_stock          true | false | limited
observed_at       2026-08-24T09:14:02Z
market            GB
price             …          # per store, not per chain
promotion         …          # regional campaigns show up here

Cadence should be daily. Availability and promotions turn over on that rhythm, and faster collection adds noise rather than signal — a product going out of stock at eleven and back in at three is not something anybody can act on. Store-level endpoints are also comparatively fragile and were never designed for constant polling, which is a second reason patience pays here.

Fake Stock Instead of a Block

Store endpoints that detect a bot do not always answer with a 403. Some quietly serve a cached or default response instead, usually in stock at every branch, because that is the answer least likely to prompt a support ticket. This is worse than a hard block, because the collection keeps running and looks healthy while the numbers underneath it are meaningless. The tell is variance: a feed where every store in a region turns permanently in stock, with no branch ever showing limited or out of stock, is more likely a detection response than genuine retail performance. Spot-checking a handful of branches against what a person actually sees in the app is the only reliable way to catch this early.

Website vs App Endpoints

Some chains run stock lookup and click-and-collect slot availability exclusively through the mobile app's API rather than the public website. The app endpoint is often less hardened, since the assumption is that only the retailer's own app calls it, but it expects mobile-shaped signals in return: a mobile user agent, an app version header, and traffic that originates from a carrier IP rather than a data-centre range. Treating the app API as a separate, parallel source rather than a fallback for the website is usually the more productive framing, since the two do not always agree even for the same store on the same day.

Local Pricing and Promotions

In many markets, prices genuinely differ between stores in the same chain, and it is one of the more interesting things retail collection reveals. Convenience and forecourt formats frequently price well above the same chain’s supermarkets, and that is deliberate strategy rather than error. None of it is visible from the national website.

Regional promotions behave the same way. A chain may run a campaign in one part of a country to answer a local competitor, and the national site will show no sign of it. Collecting per region rather than per chain is what surfaces this, and it is usually the finding that justifies the programme to whoever is paying for it.

MAP Monitoring

A related but distinct use of the same data is minimum advertised price monitoring, run by the brand rather than by a retailer's competitor. Manufacturers who set a minimum advertised price for their products need evidence of what price is actually showing at the shelf edge or in the app, store by store, because a national recommended price tells them nothing about whether an individual franchise or discount format is undercutting the agreement. The record required is identical to competitor price tracking — store, product, price, timestamp — but the audience and the enforcement action that follows are different, which is worth deciding before the collection design rather than after.

Scaling Retail Collection

The temptation is to cover every store. It is almost always wrong. A well-chosen sample — a handful of branches per region, spanning the formats the chain operates — captures the variation that matters at a fraction of the volume, and a smaller footprint is also considerably less likely to attract attention from endpoints that were never built for this.

• Sample stores, do not enumerate them — Variation comes from region and format, not from store count.
• Hold the store as part of the key — Chain-level aggregation destroys exactly the differences you collected for.
• Pair a local exit with a local postcode — Either on its own produces answers that look complete and are not.
• Watch the app surface too — Some chains expose stock and offers in their app that the website never shows.
• Alert on collection health — A store endpoint that starts returning empty looks identical to a store with nothing in stock.

Request Budget Per Store

A sensible cadence limits collection to a handful of requests per store per day — one pass for stock, one for price, perhaps a spot-check for promotions — rather than polling continuously. Store-level endpoints were built to serve a locator widget or a single shopper's session, not a script checking the same branch every few minutes, and unusually regular timing is itself a signal separate from the postcode or the exit IP. Spacing requests unevenly through the day, and varying the exact minute of each pull, removes a pattern that is otherwise trivial to notice.

For the online half of the same question see ecommerce data, and for continuous price watching, price monitoring.

Query Stores the Way Local Shoppers Do

Live PXM2 locations — pick the countries whose chains you track and collect store-level data from inside each:

Frequently Asked Questions

Related Mobile Proxy Guides

Retail is the physical half of commerce; the online half and the pricing half sit next door.

Business use cases

Core mobile proxy guides