What ShoppingScraper Is Known For
ShoppingScraper focuses on Google Shopping and comparison-shopping data. kwery covers Google Shopping as one of 12 marketplaces, returning merchants, offers, shipping and availability in the same schema as Amazon, idealo, eBay and the rest, with provenance and trust signals on every record.
A Google Shopping-centred pricing-data and monitoring platform with product, merchant and price-tracking capabilities built around the Google Shopping ecosystem.
Google Shopping Focus
Product, offer and merchant data organized around the Google Shopping ecosystem across multiple countries.
Price Monitoring
Tracking and monitoring workflows aimed at following competitor prices over time.
Merchant View
Visibility into which merchants appear for a product within the shopping surface.
Practical Onboarding
A focused product surface that is quick to evaluate when Google Shopping is the primary market view.
Where the Products Overlap
A fair comparison starts with the shared ground. Both products are used for the following, which is why they appear in the same evaluation at all. Below the shared band, the ledger shows where the two designs diverge.
Where they overlap
Where they diverge
Google Shopping
Yes, the main focus of the product
Yes, one source among several
Amazon read directly
No, Amazon is seen through the Google Shopping surface
Yes, read from Amazon itself
Idealo read directly
No
Yes
Walmart read directly
No, seen through the Google Shopping surface
Yes, read from Walmart itself
Otto and Kaufland read directly
No
Yes
Google Shopping
ShoppingScraper
Yes, the main focus of the product
kwery
Yes, one source among several
Amazon read directly
ShoppingScraper
No, Amazon is seen through the Google Shopping surface
kwery
Yes, read from Amazon itself
Idealo read directly
ShoppingScraper
No
kwery
Yes
Walmart read directly
ShoppingScraper
No, seen through the Google Shopping surface
kwery
Yes, read from Walmart itself
Otto and Kaufland read directly
ShoppingScraper
No
kwery
Yes
Google Shopping View or Direct Marketplace Data?
Google Shopping is an aggregation layer. It provides an excellent cross-merchant market view, and for many categories it is the fastest way to understand where a product sits in the market. What it exposes, however, is constrained by what the aggregator currently shows.
Observing a marketplace directly answers a different question. Marketplace-specific seller structure, fulfilment, availability and Buy Box behaviour exist in the marketplace, not in the aggregated view, and pricing systems that act on marketplace-specific behaviour need them.
kwery treats Google Shopping as one source among several and collects marketplaces such as Amazon, Otto, Kaufland and Idealo directly, returning all of them in the same response format. The trade-off is that kwery supports a defined library rather than every shopping surface variation.
The point is not which sources a provider lists but how they are reached. A source observed through Google Shopping and that same source observed directly are not the same dataset: the aggregated record shows the merchant offers Google currently surfaces, while the direct record carries the marketplace's own seller structure, Buy Box behaviour, fulfilment and availability. A provider covering several sources via Google Shopping is therefore not equivalent to those sources being listed directly.
Architecture
Aggregated view ←→ Direct observation
ShoppingScraper
Google Shopping ecosystem, merchant-centred
kwery
Marketplaces read directly, one response format
Both paths deliver marketplace data. They differ in what your application receives and what it still has to model.
If the underlying layers are still unclear, the marketplace data infrastructure guide describes what sits between a marketplace and a production record.
How ShoppingScraper and kwery Compare
Each row is either a shared capability, a genuine strength of the other product, or a kwery capability the other product does not document. Verify every row against current documentation during evaluation.
- 01
Google Shopping
ShoppingScraper
Yes, the main focus of the product
kwery
Yes, one source among several
- 02
Amazon read directly
ShoppingScraper
No, Amazon is seen through the Google Shopping surface
kwery
Yes, read from Amazon itself
- 03
Idealo read directly
ShoppingScraper
No
kwery
Yes
- 04
Walmart read directly
ShoppingScraper
No, seen through the Google Shopping surface
kwery
Yes, read from Walmart itself
- 05
Otto and Kaufland read directly
ShoppingScraper
No
kwery
Yes
- 06
Start from a barcode
ShoppingScraper
Yes, a separate /match call; the reliable path is DeepSearch at 4 credits
kwery
Yes, part of the same call, no extra credits
- 07
Can you trust the data?
ShoppingScraper
A match verdict on the match call; no confidence signal on the price data
kwery
A match confidence and data-health flags come back with every record
- 08
Price history you can read on day one
ShoppingScraper
Yes, up to 12 months of Google Shopping history
kwery
No, history builds up from your own readings
- 09
No-code monitoring
ShoppingScraper
Yes
kwery
No, API-first
- 10
Google Sheets workflows
ShoppingScraper
Yes
kwery
No
- 11
Repricing
ShoppingScraper
Yes, built into the platform
kwery
No, kwery delivers the data, your system sets the price
- 12
Where the data came from
ShoppingScraper
Not offered, no source, method or timestamp details documented
kwery
Every record says which source, which country, how it was collected and when
- 13
What changed since last time
ShoppingScraper
Alerts inside the platform, not a change record in the API
kwery
A structured change record when the next reading differs from the previous one
- 14
Same fields across sources
ShoppingScraper
Fields follow the Google Shopping surface
kwery
Every source returns the same fields
- 15
Pricing model
ShoppingScraper
Request credits; matching and real-time requests can consume differently
kwery
One credit per complete SKU dataset, per source
| Dimension | ShoppingScraper | kwery |
|---|---|---|
| Google Shopping | Yes, the main focus of the product | Yes, one source among several |
| Amazon read directly | No, Amazon is seen through the Google Shopping surface | Yes, read from Amazon itself |
| Idealo read directly | No | Yes |
| Walmart read directly | No, seen through the Google Shopping surface | Yes, read from Walmart itself |
| Otto and Kaufland read directly | No | Yes |
| Start from a barcode | Yes, a separate /match call; the reliable path is DeepSearch at 4 credits | Yes, part of the same call, no extra credits |
| Can you trust the data? | A match verdict on the match call; no confidence signal on the price data | A match confidence and data-health flags come back with every record |
| Price history you can read on day one | Yes, up to 12 months of Google Shopping history | No, history builds up from your own readings |
| No-code monitoring | Yes | No, API-first |
| Google Sheets workflows | Yes | No |
| Repricing | Yes, built into the platform | No, kwery delivers the data, your system sets the price |
| Where the data came from | Not offered, no source, method or timestamp details documented | Every record says which source, which country, how it was collected and when |
| What changed since last time | Alerts inside the platform, not a change record in the API | A structured change record when the next reading differs from the previous one |
| Same fields across sources | Fields follow the Google Shopping surface | Every source returns the same fields |
| Pricing model | Request credits; matching and real-time requests can consume differently | One credit per complete SKU dataset, per source |
Verify each row against current documentation during evaluation. Last verified: September 2026.
What Comes Back With Each Record
Both products return prices and offers. The rows below show what else is attached to a record when it reaches your system, and which side provides it.
Coverage
Which marketplaces can I read?
BothShoppingScraper
Merchants and marketplaces as they appear on Google Shopping
kwery
Amazon, Google Shopping, Idealo, eBay, Walmart, Otto, Kaufland and further supported sources
Merchants and marketplaces as they appear on Google Shopping
Amazon, Google Shopping, Idealo, eBay, Walmart, Otto, Kaufland and further supported sources
Collection
Who runs the retrieval?
BothShoppingScraper
Managed retrieval from the Google Shopping surface
kwery
Managed retrieval from the requested marketplace
Managed retrieval from the Google Shopping surface
Managed retrieval from the requested marketplace
Product matching
Is this the right product?
BothShoppingScraper
Separate /match endpoint; standard match relies on Google Shopping's sparse barcode index, DeepSearch (4 credits) is the documented reliable path
kwery
Give a barcode (GTIN/EAN), ASIN or marketplace ID and get the matching product on that marketplace, with a match confidence, included in the same call
Separate /match endpoint; standard match relies on Google Shopping's sparse barcode index, DeepSearch (4 credits) is the documented reliable path
Give a barcode (GTIN/EAN), ASIN or marketplace ID and get the matching product on that marketplace, with a match confidence, included in the same call
How the data reaches your system
How do results reach my system at scale?
BothShoppingScraper
Synchronous per-request API; at catalog scale the Channel API requires a submit → poll → collect → ack loop, and results expire after 6 hours
kwery
Single lookups return synchronously with wait (usually no polling); batches run as jobs with optional webhook push, no ack loop, no drain window
Synchronous per-request API; at catalog scale the Channel API requires a submit → poll → collect → ack loop, and results expire after 6 hours
Single lookups return synchronously with wait (usually no polling); batches run as jobs with optional webhook push, no ack loop, no drain window
Response format
Does one integration read every source?
kwery onlyShoppingScraper
Fields follow the Google Shopping surface
kwery
The same response format for every source
Fields follow the Google Shopping surface
The same response format for every source
Can you trust the data?
Should my system act on this price?
kwery onlyShoppingScraper
Not offered, the response carries the data, not a confidence signal
kwery
A trust score and data-health flags come back with every record
Not offered, the response carries the data, not a confidence signal
A trust score and data-health flags come back with every record
Where the data came from
Can I see where and when this was collected?
kwery onlyShoppingScraper
Not offered, no source, method or timestamp details documented
kwery
Every record says which source, which country, how it was collected and when
Not offered, no source, method or timestamp details documented
Every record says which source, which country, how it was collected and when
What changed since last time
What changed since the last reading?
BothShoppingScraper
In-platform monitoring and alerting
kwery
A structured change record when the next reading differs from the previous one
In-platform monitoring and alerting
A structured change record when the next reading differs from the previous one
Application layer
Where does the pricing logic live?
ShoppingScraper onlyShoppingScraper
Dashboards, scheduling, Google Sheets workflows and repricing
kwery
None, the pricing logic stays in your systems
Dashboards, scheduling, Google Sheets workflows and repricing
None, the pricing logic stays in your systems
Source path
Where is the value actually read from?
kwery onlyShoppingScraper
Sources reached through the Google Shopping surface
kwery
Supported marketplaces observed directly
Sources reached through the Google Shopping surface
Supported marketplaces observed directly
Price history
Can I read the past without collecting it first?
ShoppingScraper onlyShoppingScraper
Pre-populated Google Shopping price history, up to 12 months
kwery
No pre-populated history; history builds up from your own readings
Pre-populated Google Shopping price history, up to 12 months
No pre-populated history; history builds up from your own readings
Design emphasis, not quality ranking
How Price and Offer Changes Are Detected
kwery discovers a change when the next reading differs from the previous one and sends a structured change record through the configured delivery workflow, a real difference between two readings, not a platform alert.
ShoppingScraper offers historical price data as a separate product and a Channel API that must be polled and acknowledged; deciding which of the collected values changed materially remains work on your side.
Detected Change Event
- Observation T1€129,90
- Marketplace changesunknown
- Observation T2€119,90
kwery detects
€129,90 → €119,90
kwery discovers a change when the next marketplace observation differs from the previous one. It does not know the exact instant the marketplace changed. The structured delta is then emitted through the configured delivery workflow.
Compare Cost per Usable Dataset, Not Cost per Credit
The comparable figure is what each side charges for one complete SKU dataset.
How we compare cost per datasetShoppingScraper’s unit
Variable6
credits per complete SKU dataset (reliable match path)
- Deep match4 credits, the reliable barcode path
- Product data1 credit, /info
- Offers1 credit, /offers
- DeliveryChannel API is asynchronous
kwery’s unit
Fixed1
credit per complete SKU dataset, everything included
- 1 creditper SKU × source × fresh fetch
- Includedmatching, product data and offers
- Cache hitsno additional credit
- Rolloverunused paid credits while active
Billing unit
- ShoppingScraper
- The billing unit is one API request per endpoint. Matching is a separate /match call, product data is a separate /info call, and offers are a separate /offers call, a complete SKU dataset is never one request.
- kwery
- One credit per complete SKU dataset: one SKU, one source, fetched fresh. Matching the product, the product data and the offers are all included.
The comparable figure is the cost of one complete SKU dataset per source, including identity and the offers your logic reads.
kwery charges one unit for one complete SKU dataset: no separate matching step, no separate lookup, no per-endpoint stacking, so the cost of an integration can be calculated before it is built.
What One Complete Dataset Costs
The steps below are drawn from publicly available documentation and should be verified against current documentation during evaluation.
GTIN → product match (reliable path)
ShoppingScraper
/match?deepsearch=true, 4 credits
kwery
Included
GTIN → product match (reliable path)
/match?deepsearch=true, 4 credits
Included
Product metadata
ShoppingScraper
/info, 1 credit
kwery
Included
Product metadata
/info, 1 credit
Included
Seller offers
ShoppingScraper
/offers, 1 credit
kwery
Included
Seller offers
/offers, 1 credit
Included
One complete SKU dataset
ShoppingScraper
6 credits
kwery
1 credit
One complete SKU dataset
6 credits
1 credit
Standard /match (1 credit) relies on Google Shopping's barcode index, which ShoppingScraper's own documentation describes as sparse and inconsistent; DeepSearch is the documented reliable path for hard cases and the correct comparison to kwery's GTIN matching. Variants (/variants, 6 credits), reviews (1 credit) and historical price data are separate endpoints and are not part of one complete SKU dataset. Credit charges and endpoint scope should be verified against current documentation during evaluation.
When ShoppingScraper or kwery Is the Better Fit
Neither option is the general answer. The requirement decides, and the requirement is usually clearer than the feature comparison.
ShoppingScraper may fit better when
- a finished monitoring and repricing application is preferred over a data layer
- non-technical users need dashboards, scheduling and Google Sheets workflows
- a pre-populated Google Shopping price history is needed on day one
- built-in variants and reviews are needed as application features
kwery may fit better when
- Google Shopping is one input among several
- Amazon, Idealo, eBay, Walmart, Otto or Kaufland must arrive in the same fields
- the data must come from the marketplace itself, not through Google Shopping
- a match confidence, data-health flags and full source-and-timestamp details must come back with each record
- catalog-scale collection should not require a submit → poll → collect → ack loop with a drain window
- pricing logic already exists internally and needs data, not another application
Before You Switch
A provider migration is not only an API-key change. These considerations are specific to moving between ShoppingScraper and kwery:
Aggregated to Direct Fields
Merchant-level fields from the shopping surface do not map one-to-one onto marketplace seller and fulfilment fields. Map the concepts before mapping the keys.
Monitoring to Deltas
In-platform tracking becomes change records delivered to your system, which moves alert logic into your own rules engine.
Coverage Check
List the shopping countries and marketplaces you rely on and confirm both sides support them before committing.
General migration checklist
- Identifier Compatibility
- Can existing GTINs, EANs, UPCs, ASINs or source URLs be reused as request inputs?
- Schema Migration
- Which fields change name, type or meaning, and which consumers read them today?
- Source Parity
- Are all required marketplaces and countries available on both sides of the move?
- Freshness Semantics
- Does "fresh" mean the same thing in both systems, and does every record carry a collection timestamp?
- Offer Modeling
- Are seller, shipping and availability represented in equivalent ways?
- History
- Will historical records need to remain in the existing system, and for how long?
- Failure Handling
- How should the application interpret unresolved products and partial results?
- Billing Unit
- Are you paying by request, credit, record, product/source lookup or another unit?