Debugging Price Discrepancies

You check a product on Amazon, see $29.99. PriceFetch returns $34.99. Both are correct — you're just seeing different versions of the page. Here's why:

**Geo-targeting** — retailers show different prices based on the visitor's location. PriceFetch's scraping infrastructure runs from specific data center locations. The price it sees might differ from the price shown to a user in a different city or country.

**Logged-in vs. anonymous** — Amazon shows Prime-exclusive prices to Prime members. PriceFetch accesses pages as a non-logged-in visitor, so it sees the non-Prime price.

**Dynamic pricing / A/B testing** — some retailers run pricing experiments, showing different prices to different visitors at the same time. This is especially common on Amazon.

**Coupon and promo pricing** — if you've clipped a coupon or have a promo applied to your account, you see a lower price. PriceFetch sees the base price without account-specific discounts.

**Cache timing** — you might be seeing a cached page in your browser while PriceFetch fetched a live version with a recent price change, or vice versa.

First, understand that PriceFetch returns the publicly visible price — the price a typical non-logged-in visitor sees. This is the most universal and comparable data point.

To reduce discrepancies:

- **Compare in incognito mode** — open the URL in a private browsing window without logging in. This approximates what PriceFetch sees.

- **Account for Prime pricing** — if you know a product has Prime-exclusive pricing, note that PriceFetch returns the non-Prime price. You can add a flag in your system indicating Prime-eligible products.

- **Use the same country domain** — if you're checking amazon.co.uk, make sure you're comparing against the UK price, not the US price.

- **Check multiple times** — if you suspect A/B testing, fetch the price 2-3 times over an hour. Consistent results suggest the price is stable. Varying results confirm dynamic pricing.