Proxies for Geo-Pricing Audits: Seeing the Price Each Region Sees

• Country-level exits are enough for nearly every pricing audit. City targeting matters only for local services, delivery zones and a few marketplaces.
• Run at least three exits per country at the same time, so you can tell a regional price from ordinary variation.
• Change one signal at a time. IP country, browser language, store cookie and account country each move prices on different sites. Knowing which one did it is the finding.
• Compare net of tax, in one currency, at a dated exchange rate. Otherwise VAT alone creates a fake 20% "difference".
• Keep a screenshot, the HTML and the verified exit IP for every flagged price.
• Check that the site believes your location. Some sites treat hosting IPs as VPN traffic and serve a default region, which hides real differences.

The same technique answers quite different questions. Decide which one you are asking, because it sets the targets, the sample and the evidence standard.

The rest of this guide applies to all five. The difference is how much evidence you keep: a pricing analyst needs a clean table, a journalist needs something a lawyer will read.

Retail price collection at scale is covered in how ecommerce companies use proxies for competitive intelligence. This page is about the audit question specifically: is the price different because of where the buyer is?

Before any difference counts, rule these out.

The last one is the sneaky one because it produces false negatives. You run twelve countries, see identical prices, and conclude the site does not geo-price, when in fact it served you its default store twelve times.

Every audit should start with a control run. Pick one country, fetch the same product from several different exit IPs within a few minutes, and look at the spread.

If five UK exits return five identical prices, any cross-country gap is easy to interpret. If they return two different prices, the site is testing or personalising, and a single-IP check in each country would have produced nonsense.

The Scraping API takes a country_code per request, so a control run is a short loop. Each request gets its own rotating exit:

import re
import statistics
import requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "YOUR_API_KEY"
PRODUCT = "https://store.example/product/sku-123"

def fetch_price(country):
    r = requests.get(API, headers={"X-API-Key": KEY}, timeout=90, params={
        "url": PRODUCT,
        "render_js": "true",
        "country_code": country,
    })
    r.raise_for_status()
    # Site-specific: adapt the pattern to the target's price markup.
    m = re.search(r'itemprop="price"\s+content="([\d.]+)"', r.text)
    cur = re.search(r'itemprop="priceCurrency"\s+content="([A-Z]{3})"', r.text)
    return (float(m.group(1)) if m else None, cur.group(1) if cur else None)

samples = [fetch_price("GB") for _ in range(5)]
prices = [p for p, _ in samples if p is not None]
print("currencies seen:", {c for _, c in samples})
print("min", min(prices), "max", max(prices), "median", statistics.median(prices))

A practical decision rule: only flag a regional difference when the gap between two countries' medians is larger than the widest within-country spread you observed in the control run. It is not a formal significance test, but it stops the most common false alarm cold.

Sites decide "where is this buyer" from several inputs, and they do not all use the same ones. Change one at a time and record which change moved the price.

The rung that moves the price is often more important than the size of the gap. A price that follows IP alone means a buyer cannot easily see the other market's price. A price that follows a URL path any buyer can type is a different story, especially in the EU.

Rung 6 has a hard boundary. Logged-out audits cannot see prices that are set by billing country at checkout, and creating accounts or entering payment details to find them moves you from audit into terms of service and fraud-control territory. Note it as a limitation rather than working around it.

Headers for rung 2 can be passed through the API's forward_headers parameter. Device type for rung 5 is the device parameter.

Raw scraped prices are not comparable. Normalise in this order, and store every intermediate value so anyone can check the arithmetic.

1. Split the price. Product price, shipping, other fees, and whether tax is included as displayed.
2. Remove tax. Divide tax-inclusive prices by one plus the standard rate for that market. Note reduced rates where a product category qualifies.
3. Convert currency at a single reference rate for the whole run. The European Central Bank publishes euro reference rates each working day, which gives you a dated, citable source.
4. Index against a base market. Express every country as a percentage of your base, so 112 means 12% more expensive net of tax.

FX_TO_EUR = {"EUR": 1.0, "GBP": 1.17, "USD": 0.92}   # example rates, date them
VAT = {"DE": 0.19, "FR": 0.20, "GB": 0.20, "US": 0.0}   # US shown pre-sales-tax

def net_eur(price, currency, country, tax_included=True):
    net = price / (1 + VAT[country]) if tax_included else price
    return round(net * FX_TO_EUR[currency], 2)

base = net_eur(99.00, "EUR", "DE")
for country, price, cur in [("FR", 99.00, "EUR"), ("GB", 89.00, "GBP"), ("US", 99.00, "USD")]:
    idx = net_eur(price, cur, country, tax_included=(country != "US")) / base * 100
    print(country, round(idx))

The exchange rates in that snippet are example values, not current rates. Look them up for the date of your run.

Look at what the normalisation does to a headline. €99 in Germany and $99 in the US look identical. Net of German VAT and converted, the German price is about €83 and the US one about €91 before sales tax, so the US is roughly 10% more expensive on these example rates, the opposite of what the raw numbers suggested.

For internal pricing work, a normalised table is enough. For anything that might end up in a negotiation, a complaint or an article, keep a record per flagged observation:

• A full-page screenshot showing the price, currency and any region indicator.
• The raw HTML of the same response, so the price can be found in the source.
• The exit IP and its geolocation, checked in the same session against a geolocation service.
• A UTC timestamp and the request parameters: country, language, device, cookies.
• A SHA-256 hash of the screenshot and HTML, written to your log when captured.

Screenshots come from the same API call with format=screenshot, which the docs price as a +5 credit add-on. Take them only for flagged observations, not the whole run.

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://store.example/product/sku-123" \
  --data-urlencode "country_code=FR" \
  --data-urlencode "format=screenshot" \
  -o fr-sku-123.png && sha256sum fr-sku-123.png

Reproduce before you report

One capture is an observation. A finding is something that shows up again. Before a flagged gap leaves the analytics team, re-run just those products at least 24 hours later, from fresh exits, in the same countries, and at a similar time of day. Prices that reappear go in the report. Prices that do not were probably a test cell, a flash sale or a stock change, and belong in a footnote rather than a headline.

Write the method down alongside the results: countries, exits per country, the signals held constant, the tax rates and exchange rate date used, and the decision rule for flagging. If the company you are auditing disputes the finding, a reproducible method is what settles the argument, not the size of the gap.

Our IP geolocation accuracy guide explains why you verify the exit's location rather than trusting the label on the proxy.

Geo pricing audits need correct country geolocation more than they need a particular IP type. Commercial geolocation databases generally place datacenter IPs in the right country, and a lot of retail, SaaS and travel sites price on that alone. The catch is the default-region fallback from the confounder table.

Some sites, especially streaming, digital goods and some travel sellers, flag hosting and VPN ranges and respond by serving their home region or blocking the page. For those, a datacenter exit gives you a wrong answer, not an error. Detect it on every run: if the page's currency or region indicator does not match the exit country, treat the observation as invalid, not as "no difference".

SparkProxy is datacenter-first. Its proxy plans provide a USA pool and a worldwide rotating pool across 1M+ IPs in 80+ countries, which suits collection where you log the exit country per request. For choosing a specific country on each request, the Scraping API's country_code parameter is the direct route. SparkProxy does not sell residential proxy plans, so for targets that reject hosting IPs, buy residential exits elsewhere. For scraping jobs, the SparkProxy Scraping API does offer residential exits through its premium_proxy option, which routes a request through a residential pool for 10 credits, or 25 with JavaScript rendering. More on the difference in what geo-targeting means in proxies and residential vs datacenter proxies.

Whichever you use, never audit through a consumer VPN. A handful of shared exit IPs per country are exactly the ranges pricing and anti-fraud systems know best. See proxy vs VPN for the broader comparison.

An audit round is countries × products × exits per country. Here is an illustrative sizing, not a quote for any specific target.

Assumptions: 12 countries, 50 products, 3 exits per country, weekly rounds, pages need JavaScript rendering, screenshots for the 10% of observations that get flagged.

• Price fetches per round: 12 × 50 × 3 = 1,800.
• Credits per fetch per the API docs: 5 for rendering plus 5 for country_code = 10, so 18,000 credits.
• Screenshots: 180 flagged, as separate calls at 15 credits each (rendering, country and screenshot) = 2,700 credits.
• Per round: 20,700 credits. Four rounds a month: 82,800 credits.

That sits comfortably inside the Starter plan's 250,000 credits for $49/mo, with 50 concurrent requests, which leaves room for a control run and the signal-ladder tests. The 1,000 free credits cover a first control run on a few products before you pay anything.

The number that grows fastest is exits per country. Going from 3 to 10 improves your noise estimate but more than triples the bill, so run the heavier baseline once per target, then drop back to 3 for routine rounds unless the target shows within-country variation.

Geographic price differences are not illegal in general, and this is not legal advice. Two EU rules shape what an audit should look for.

The EU Geo-blocking Regulation (EU) 2018/302, applying since December 2018, does not require the same price in every member state. It stops traders from blocking or automatically redirecting customers from other member states without consent, and in defined situations requires that they can buy on the same general conditions as local customers. For an EU audit, "can a buyer in France reach the German store and buy at its terms?" is often the more useful question than "is the German price lower?". That is exactly what rung 3 of the signal ladder tests.

The Omnibus Directive (EU) 2019/2161 requires traders to tell consumers when a price has been personalised on the basis of automated decision-making, applying since May 2022. Personalised prices without that notice are a different finding from regional pricing, and your noise baseline is what separates them.

Outside the EU, rules vary by country and sector. Keep collection to public, logged-out pages, at polite request rates, and take advice before publishing findings that name companies.