The five parts of a price monitor
A price monitor is five small jobs wired together: pick targets, fetch the page, parse the price, store the reading, and schedule plus alert.
1. Pick targets. Keep a list of product URLs (or marketplace identifiers) you care about. Tag each as hot (fast-moving, competitive SKUs) or long tail.
2. Fetch reliably. This is where DIY trackers break. A plain request from a datacenter IP gets blocked, gets the wrong country price, or misses a price that loads via JavaScript. Route each request through a residential proxy in the buyer geography and render the page. A scraping API does all of this in one call.
3. Parse the price. Pull the current price, not the struck-through original. Many stores expose a clean price in embedded JSON (schema.org Product/Offer markup) which is more stable than scraping a styled price element; auto-parse output or that JSON block is your friend.
4. Store history. Append a timestamped row per reading - never overwrite. History is what lets you draw trends and detect drops.
5. Schedule and alert. Re-run on a cadence and compare to the last stored value to fire alerts. See the next two sections.
Fetch and parse: residential proxies, geo, and the right number
The fetch step decides whether your monitor works at all, because retailers challenge automated traffic and localize prices.
Geo and currency. A product page served to a US IP and a German IP can show different prices, currency, and availability. Set the proxy country to match the market you sell in - if you track US pricing, fetch from a US residential IP. Getting this wrong silently poisons your data.
Reliability at scale. Price pages on large retailers sit behind verification challenges and rate limits, so a naive monitor returns errors instead of prices. A managed fetch layer that handles residential IP routing, browser rendering, and per-site request pacing keeps the monitor stable and the data complete. Holding a consistent session per target keeps each product's readings on one coherent connection, which makes the collected price series cleaner.
Grabbing the correct number. Prefer structured data: most stores embed an application/ld+json Product object with a clean offers.price and priceCurrency. That survives layout redesigns far better than a CSS selector aimed at a price element. With autoparse set to true, Scrappey returns parsed fields for many product pages; otherwise parse the embedded JSON yourself. Normalize to a number and store the currency alongside it.
Schedule, store history, and alert
Re-check on a cadence, append every reading to durable storage, and compare each new price to the last one to decide when to alert.
Cadence. Tier your SKUs. Hot, competitive items justify hourly checks; the long tail is fine daily or weekly. Polite, tiered cadence costs less and is far gentler on the target site than hammering every URL every minute - see throttling and polite crawling. Run the loop from cron, a scheduler, or a queue worker with 200 concurrent requests available on every Scrappey plan.
Store history. Each run writes one row per SKU: url, price, currency, timestamp. A timestamped table (SQLite, Postgres, or even CSV to start) gives you trend charts and an audit trail. You can later export to CSV/JSON or push to Google Sheets for the business team.
Alert. After storing, compare the new price to the previous stored value. Fire a webhook, email, or Slack message when it crosses a threshold (drops more than X percent, or undercuts your own price). That diff-on-write is the entire alerting engine. For a survey of off-the-shelf options, see the price-monitoring tools roundup.