An ecommerce monitor should record what a public product page displayed at a specific time, market, and URL. It should not assume that a displayed price includes shipping, tax, membership discounts, coupons, or every seller offer unless those components are explicitly returned and verified.
All Shopping Scraper is the AgentX multi-source route for standardized marketplace collection. Dedicated tools such as AliExpress Product Scraper and Rakuten Product Scraper are useful when source-specific fields matter.
What should the monitoring contract define?
Specify:
- products, queries, categories, or seller pages in scope;
- country, language, currency, and delivery destination;
- whether the target is a product, offer, seller, or search result;
- collection frequency and acceptable delay;
- price components required;
- availability states;
- identifiers used to match the same product over time.
“Track competitor prices” is too broad to implement reliably.
What is the difference between a product and an offer?
A product is the underlying item. An offer is one seller’s purchasable presentation of that item at a time. A marketplace page can contain several offers with different sellers, prices, shipping, condition, and availability.
Use separate keys:
| Entity | Example fields |
|---|---|
| Product | title, brand, model, GTIN/MPN, variant attributes |
| Offer | seller, condition, base price, shipping, currency, availability |
| Observation | source URL, collected time, market, query, displayed promotion |
Flattening these into one row can hide seller changes and produce false price movements.
How should prices be normalized?
Retain the original displayed text. Parse numeric price and currency into separate fields. Keep shipping, taxes, coupons, struck-through prices, and subscription prices separate unless the source clearly combines them.
Do not convert currencies without storing the exchange-rate source and timestamp. Do not infer a missing currency only from the symbol when several currencies use the same symbol.
How are identical products matched across sources?
Prefer stable identifiers such as GTIN, UPC, EAN, MPN, or a verified source product ID. When those are missing, use a confidence model based on brand, model, variant, size, color, and title—not title similarity alone.
Keep ambiguous candidates unmerged. A false match creates convincing but incorrect price comparisons.
Which changes deserve an alert?
Useful alerts require persistence and materiality controls:
- price change beyond a defined percentage or amount;
- availability changing for consecutive observations;
- a new verified seller offer;
- assortment appearance or disappearance across several runs;
- promotion text beginning or ending;
- product identifier or variant changing unexpectedly.
Suppress one-off anomalies until a second observation where the use case permits. Keep the raw page observation for review.
What quality checks should run?
- working source URL rate;
- parsed currency and numeric price coverage;
- negative, zero, or extreme price detection;
- product-match confidence distribution;
- duplicate offer rate;
- availability value vocabulary;
- source and country distribution;
- unexpected row-count change.
Review a sample against the public pages from the same market and collection window.
Multi-source or dedicated Actor?
Use All Shopping Scraper when one schema and broad marketplace coverage matter. Use a dedicated marketplace Actor when seller structure, local fields, filters, or debugging depth matter more. The BestCrawler commerce and property topic hub organizes both routes.
For a durable production process, combine this guide with How to Validate Scraped Data Quality and verify current Actor behavior on the live Apify page.
Continue in the directory
Turn the guide into a real sample run.
Open the current AgentX contract, check pricing and fields, then validate a narrow output.