Read the price each market is actually shown, then land it in one currency
Currency, tax treatment, promotion, shipping threshold, seller and variant all change with the storefront a request lands on — so a shelf price read from your own office is not comparable to anything. LUDAX loads the public product page from inside each market, on a held session, so your tooling can normalise what that market was shown into one landed price per offer.
Illustrative sample data. Every SKU, retailer host, price, rate and figure on this page is an example of what a public product page can return — not a measured result, not a real retailer, and not a promise about any market.
The residential network path into the country or city you are pricing, the pinned browser TLS profile, and a sticky session that stays one visitor across the product page, the postcode step and the delivery estimate.
Extraction, screenshots, diffing, scheduling, storage and alerts. Variant matching, currency and tax normalisation, promotion fields and the landed-price maths all live in your monitoring stack.
A price feed, a repricing engine, a scraper or an alerting product. No proxy network can promise a challenge-free product page, and no setup can prove a price was never displayed.
Five stages between a rendered page and a comparable price
Normalisation is a pipeline, and every stage can invalidate the number that came out of the last one. Run it on the SKU and market you selected above and watch what each stage carries forward — the value only becomes comparable at the end, and only for one offer.
Every stage above happens in your own tooling. LUDAX supplies the residential path into the market and city, the pinned browser profile, and the sticky session that keeps the product page and the delivery estimate on one exit — without which stages 04 and 05 belong to two different shoppers.
Six weeks of one shelf price, event by event
A sweep tells you where a market sits today. The history tells you whether it moved, and what the move actually was: a dated promotion, a seller change, or a stock-out with a stale number still rendered on the page. Promotion windows are shaded, stock gaps are hatched and break the line, and every point is focusable — tab into the series and read the check behind it.
Illustrative sample series. The three-checks-a-day cadence, the promotion/base split and the decision to break the line rather than carry the last known number are conventions your tooling implements. LUDAX supplies the network path each of those checks was made through.
One row per offer, expandable to the whole observation
The comparison table is where a pricing decision is actually made: shown price beside normalised price, what it lands at once tax and shipping are applied, and the delta against each SKU's own reference row. Filter by market or SKU, sort the normalised columns, and expand any row for the host, offer id, tax basis, FX rate and the reason a row is not comparable.
SAMPLE DATA · SWEEP PM-2026-0412 · 3 CHECKS PER ROW · Δ MEASURED AGAINST EACH SKU'S OWN REFERENCE ROW · EXPAND A ROW FOR SELLER, PROMOTION, SHIPPING, TAX, HOST AND FX
No rows match these filters — re-enable a market chip or clear the comparable-only filter.
Sorting is on the normalised figures only; a shelf price in PLN and one in JPY cannot be ordered against each other. Rows more than 8% from their reference are marked; rows whose seller, variant or availability does not match the reference are dimmed rather than counted.
Every flagged change opens as a before-vs-now receipt
When a change is raised the useful artefact is small: which fields moved, what they read before, and the capture metadata that lets somebody re-read the number a week later. Four receipts from the same sweep; the flagged one is open, the rest are one click away.
Read this before you schedule a sweep
Public product pages only. No accounts, no carts, no buying.
Monitoring means reading what any shopper in that market can load: public product, category and delivery-estimate pages. Not pricing behind a login you are not authorised to use, not partner or wholesale portals, not internal APIs, and nothing behind an access control. Credential sharing and unauthorised access breach the acceptable use policy.
Do not use the network to complete purchases, hold inventory, place or cancel orders, or run checkout automation against a marketplace's terms — and keep request rates well below anything that could affect a storefront's availability. Accounts are terminated for it.
01Normalise the offer before you compare the numberVariant, condition, pack size and seller type decide whether two prices describe the same product at all.
Variant, condition, pack size, seller type and bundle state decide whether two prices are the same product at all. A 1P listing, a third-party offer and a multipack belong in three separate rows with three separate offer ids.
DO key every observation on offer_id, not on SKU alone · SO a buy-box change cannot look like a price cut
02Store currency, tax and shipping as separate fieldsA tax-exclusive US price and a tax-inclusive German price are not comparable until each part is its own field.
A tax-exclusive US price and a tax-inclusive German price are not comparable, and free delivery over a threshold is part of the offer. Keep the shown string, the parsed number, the currency, the tax flag, the shipping rule and the FX rate you used, each in its own field.
DO record the conversion rate and its date with the row · never overwrite the shown price with a normalised one
03Treat redirects, challenges and empty offer blocks as dataA challenge page is not a price of zero, and a redirect is the observation rather than something to follow.
A redirect to another regional store tells you the storefront rejected your geography; log it as the observation rather than following it into the wrong catalogue. A challenge page is not a price of zero, and an out-of-stock line still renders a number — mark the check and retry on a fresh session token.
DO assert html_lang, currency and the resolved host before you parse a single price
04Match cadence to the category, and hold the sessionBaskets, postcodes and delivery estimates all need one exit held across the whole flow.
Most catalogues do not move more than daily; fast-moving marketplaces justify several checks a day. Anything with a basket, a postcode or a delivery estimate needs one exit held across the whole flow — two to eight minutes. Vary session tokens between sweeps so you are not repeatedly served one edge cache.
DO -session-px-gb-time-8 · three checks per window before a change is raised · size the month with the estimator above
import requests
USER, PASS = "YOUR_USERNAME", "YOUR_PASSWORD"
def proxy(country, city=None, session=None, profile="chrome145"):
pw = f"{PASS}-country-{country}"
if city: pw += f"-city-{city}"
if session: pw += f"-session-{session}-time-8"
pw += f"-profile-{profile}"
url = f"http://{USER}:{pw}@gw.ludaxproxy.com:9999"
return {"http": url, "https": url}
# one sticky exit for the product page AND the delivery step
p = proxy("gb", city="manchester", session="px-gb")
page = requests.get("https://example-electro.co.uk/p/aurex-ax90-black",
proxies=p, timeout=30, allow_redirects=True)
# the resolved host is the observation — never parse before you check it
hops = [(r.status_code, r.headers.get("location")) for r in page.history]
# delivery estimate on the SAME exit, or it belongs to another shopper
ship = requests.post("https://example-electro.co.uk/api/delivery",
json={"postcode": "M1", "sku": "AX90-BLK"},
proxies=p, timeout=30)
# store the exit region with the row, or the price has no market
region = requests.get("https://api.ludaxproxy.com/whoami", proxies=p, timeout=15).json()Full parameter reference in the documentation.
Price monitoring FAQ
01Why not check prices straight from your own servers?
Many storefronts serve hosting ranges a different experience or block them outright, and one address cannot read more than one market. Residential exits with country and city targeting are what let you read the page a shopper in that market is shown.
02How often should I sample?
Match the category. Fast-moving marketplaces justify several checks a day; most catalogues do not change more than daily. Whatever the cadence, take more than one check per window — a single deviating read is usually a cache or a test, not a price change.
03Do I need sticky sessions?
For anything involving a basket, a postcode or a delivery estimate, yes — two to eight minutes so the whole flow is one visitor. For flat product pages, rotation is cheaper and simpler.
04Can I monitor prices behind a login?
Only on accounts you are authorized to use and where the terms permit automated access. Credential sharing and unauthorized access are prohibited, and so is any use of the network to buy, hold or cancel inventory.
05Do you extract prices or send alerts?
No. LUDAX supplies the residential network path, the country or city geography, the browser TLS profile and the sticky session. Extraction, screenshots, diffing, scheduling, storage and alerting stay in your own monitoring or crawling tool.
06Residential TLS or standard Residential?
Residential TLS is the product priced on this page: $1.49 for 1 GB, down to $0.74 per GB at 1 TB. Standard Residential is a separate product from $0.49 per GB, without pinned browser handshakes. Neither can promise a challenge-free product page.
Price one market. Then all of them.
Buy the smallest amount of traffic, read one catalogue's product pages from inside the market you bought, and compare what was shown with the baseline you keep.
$1.49/ 1 GB · $0.74 / GB at 1 TB