E-commerce Proxies

Prices are geo-personalised

The same product URL returns different prices, currencies, shipping estimates and availability by postcode. Any price intelligence dataset without pinned city-level geo targeting is measuring noise.

Two very different workloads

Catalogue and price scraping is stateless and wants huge rotating residential pools. Running a seller or buyer account is stateful and wants one dedicated ISP IP held for months. Never mix the two.

MAP enforcement and brand protection

Minimum advertised price monitoring requires collecting evidence from the exact consumer viewpoint — country, region and device — that the violation targets, which is why residential IPs matter more than raw throughput.

Handling the hard targets

Amazon and Walmart run in-house bot defences that read TLS and HTTP/2 fingerprints, not just IPs. Pair residential proxies with a real browser engine or a managed unlocker API for consistent success rates.

Price intelligence that survives personalisation

Retail prices are a function of postcode, currency, device, loyalty state and session history. Collecting from a national IP with a clean session yields a price no customer actually sees. Pin the postcode, set the currency and point of sale explicitly, and record all of it alongside every observation so an anomaly can be traced to a collection artefact rather than a genuine market move.

Sample continuously. Flash discounts, coupon-gated prices and inventory-driven repricing routinely last hours; a nightly snapshot misses the behaviour you are paying to measure.

Marketplace defences and how to pass them

Amazon, Walmart and the large European marketplaces run in-house detection that reads TLS and HTTP/2 fingerprints, behavioural timing and account-level history. Residential IPs alone are not sufficient — the request has to look like a browser all the way down.

The two workable stacks are a real browser engine behind rotating residential, or a managed unlocker API billed per successful request. For catalogue-scale work, structured scraper APIs that return parsed JSON usually beat both on total cost, because you stop paying engineers to maintain parsers through layout changes.

Seller accounts are the opposite workload

Selling on a marketplace is stateful: one dedicated static residential IP per account, in the marketplace's country, held for months. Rotation here is not an optimisation — it is an account-takeover signal that triggers verification holds and, on repeat, suspension.

Keep seller traffic on entirely separate credentials from research crawling. Sharing a pool between the two is how a scraping block turns into a suspended storefront.

Limited drops and high-demand retail

Sneaker and console drops are latency contests. An ISP proxy in the same metro as the retailer's CDN edge beats a residential IP on another continent by hundreds of milliseconds — the whole queue. Buy fresh, site-specific subnets, use one proxy per task, and retire addresses that start queueing rather than trying to nurse them back.

How to choose a provider for e-commerce

Start from the workload, not the price list. For e-commerce the recommended class is rotating residential for data · isp static for seller accounts, with a high bandwidth traffic profile — that pair alone eliminates most of the market. Then score the shortlist on four things: measured success rate against your own targets, geographic and ASN granularity, session control, and the billing model.

Every credible provider offers a trial or a small pay-as-you-go tranche. Run the same hundred requests through each candidate, from the same client, against your real targets, and compare success rate and median latency. Vendor benchmarks are run on empty pools at favourable hours; yours will not be.

Finally, read the refund and expiry terms. Non-expiring traffic, prorated refunds and the ability to pause a plan are worth more than a 10% discount when workloads are seasonal.

Pricing and budgeting for e-commerce

Three billing models dominate. Per-gigabyte pricing suits residential and mobile pools and rewards efficient clients that block images and analytics. Per-port or per-IP pricing suits static ISP, dedicated datacenter and mobile ports, and is the only sane model when one identity must hold one address. Per-request pricing, used by unlockers and scraper APIs, transfers the block risk to the vendor and is the cheapest option on genuinely hard targets.

Model the total, not the headline. Add failed-request overhead, the bandwidth your client wastes on assets you never parse, and the engineering time spent maintaining parsers. Efficiency work — response compression, asset blocking, conditional requests, aggressive caching — routinely halves a bill without changing provider.

Commit annually only after a full month of production traffic. Volume discounts are real, but so is the cost of being locked into a pool that turns out to be weak on your key geos.

Rotation, sessions and geo targeting in practice

Rotation policy should follow state. Stateless requests can take a new exit every time; anything with a login, a cart or a multi-step form needs a sticky session that outlives the flow. Most gateways support both concurrently, selected by port or by a session token in the username.

Geo targeting granularity matters more than pool size for most buyers. Country-level is table stakes; city, region, ZIP and ASN or carrier targeting are what let you reproduce a specific user's experience. Verify the targeting actually works by resolving the exit IP's geolocation against two independent databases — advertised coverage and delivered coverage diverge more often than vendors admit.

Common mistakes in e-commerce setups

Buying on pool size alone. Headline IP counts are unaudited and include long-inactive peers; a smaller, well-maintained pool with good ASN diversity outperforms a bigger stale one on every hard target.

Rotating when you should be sticky, and sticky when you should be rotating. Both fail loudly — one as account-takeover challenges, the other as rate-limit blocks.

Ignoring the client fingerprint. A default HTTP library behind a premium residential IP is still detectable in the first packet.

No observability. Without per-target success rates, per-IP error codes and a cost-per-record metric, you cannot tell a provider problem from a code problem, and you will keep switching vendors instead of fixing the crawler.

Measuring success and knowing when to switch

Instrument four metrics from day one: success rate per target domain, median and p95 latency per exit country, cost per successful record, and ban half-life — how long a fresh IP survives on a given target. Together they tell you whether a degradation is the pool, the target's new defences, or your own code.

Set a review cadence. Re-benchmark the top three providers quarterly with the same script; pools shift as peers churn and vendors buy or lose supply. A provider that led a year ago is not automatically the right answer today, and switching is cheap when your crawler treats the gateway as configuration rather than architecture.