A shared schema does not mean shared data. When we ran identical smoke tests across eight retailer trackers that all return the same 55-field row, the retailers filled between 28 and 33 of those fields — and disagreed about which ones. That gap is the actual design problem in multi-retailer price monitoring. The collection is easy; building analysis that survives per-retailer blind spots is the work.
What does one price row contain?
Every tracker in this family returns the same normalized shape: product identity (title, brand, product ID, canonical URL), money (price, currency, price text, was-price and discount where the retailer shows one), social proof (rating, review count), seller and availability signals, and imagery. Fifty-five fields in total, with a source URL on every row.
The point of the shared shape is comparison: a Walmart row and a Flipkart row drop into the same table, the same dashboard, the same join. What the shared shape cannot do is force every retailer to say everything.
Which fields does each retailer actually fill?
Numbers from live runs of eight products per retailer, counting fields populated on every returned row:
- Amazon (US) — 28 of 55: price, currency, rating and review count on nearly every row; brand on almost none. Amazon search results simply do not carry brand consistently.
- Walmart (US) — 33 of 55, the fullest source: price, rating, review count and the seller behind every listing, which is what lets you separate first-party retail from marketplace offers.
- eBay (US) — 29 of 55: price, seller, item condition and shipping text on every row — and no ratings at all. Marketplace listings are not products with review histories; treating them as such produces empty joins.
- Flipkart (India) — 32 of 55: INR prices with rating, review count, condition and brand nearly complete.
- Argos (UK) — 28 of 55: GBP prices with ratings and brand, a clean high-street retail view.
- Target (US) — deal badges and delivery text on every row, the promotional layer other retailers mostly omit.
- Myntra (India, fashion) — discount text and percentage on almost every row, because discounting is the category’s native language.
The lesson is not that some retailers are worse. Each fills the fields its marketplace actually runs on: eBay’s condition, Walmart’s seller, Myntra’s discount. The schema is shared; the semantics are local.
How should analysis handle the gaps?
Never average across retailers on a field only some of them fill. A “mean rating” over a set that includes eBay is a mean over the retailers that happen to have ratings, presented as if it covered the set.
Three rules keep cross-retailer numbers honest:
- Per-field denominators. Every aggregate carries the count of rows that actually had the field, not the count of rows.
- Compare within retailer, then across. Price movement is retailer-local; a cross-retailer price gap is a separate, explicit comparison with currency conversion stated.
- Missing is a value. An empty seller field on Amazon means “Amazon does not say”, not “no seller”. Write it as unknown, never as absent-therefore-first-party.
What about currency and country?
Each tracker accepts a country from a shared 33-country list, but the retailers do not operate in 33 countries — Argos is British, Flipkart is Indian, Walmart’s depth is North American. Passing a technically-valid country a retailer does not serve returns an empty or irrelevant set that looks like a data problem and is actually a scoping error.
Practical rule: pin each retailer to its home market unless you have verified the specific country works, and keep the currency field on every row rather than assuming it from the retailer — cross-border listings do appear, and a GBP price parsed as USD is a silent 25% error.
When is one aggregated tracker better than eight?
Use the single multi-platform tracker when the question is market-shaped: “what does a robot vacuum cost this week across the market”. One input, one deduplicated result set, 23 platforms.
Use per-retailer trackers when the question is retailer-shaped: monitoring your own listings on a marketplace, watching a competitor’s assortment at one chain, or feeding a repricing rule that must react to one retailer’s moves. Per-retailer runs are also cheaper to schedule frequently, because you only pay for the sources you actually watch.
The wrong choice is running the aggregate and then filtering to one retailer after the fact — you paid for 22 sources you discarded.
What does a production monitoring loop look like?
A weekly loop that has held up in practice: a scheduled run per retailer with a fixed keyword set, results appended to one table keyed on product ID + retailer + collected date. A small validation step checks each batch the way we smoke-test the trackers themselves — row count above zero, price populated on every row, currency matching the retailer’s home market — before anything reaches the dashboard.
The validation step is not optional decoration. A blocked or half-rendered result usually arrives as a successful run with fewer fields filled, and the field-coverage numbers above are the baseline that makes that drift detectable: when Walmart rows stop carrying seller, something changed at the source, and the alert should fire before anyone reads a chart built on it.
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.