What Is Ecommerce Data?
Ecommerce data is structured information describing products and market activity across digital commerce environments. Depending on the context, the term can include first-party information such as orders and customer transactions as well as external market information such as product listings, prices, merchants and availability.
Ecommerce data can describe many types of information across digital commerce, including first-party data such as orders, transactions and customer activity. kwery focuses on a more specific category: marketplace data. It describes observable conditions on marketplaces and shopping platforms, what a product costs, which sellers offer it, whether it is available, how offers are positioned and when those conditions were observed.
That distinction matters. Customer, checkout and order data tells you what happened inside your own commerce operation; marketplace data tells you what is happening in the market around it. For pricing systems, market intelligence applications and commerce platforms, both can matter, but they come from fundamentally different data pipelines.
What Does Marketplace Data Contain?
There is no single universal commerce-data schema; fields vary by marketplace, geography, product category and use case. Most marketplace datasets can nevertheless be understood through a few common groups, and those groups are a good checklist when evaluating any provider's output.
kwery covers 12 marketplaces: Amazon, Google Shopping, eBay, Walmart, Idealo, Otto, AliExpress, Rakuten, Kaufland, Lidl, guenstiger.de, billiger.de.
Product identity
Identifiers connect an observation to the correct product. Depending on the source, these can include GTIN, EAN, UPC, ASIN, marketplace IDs, MPNs, URLs, brand and product name. The identifier is critical because comparing values is meaningless when two records do not represent the same product or variant.
Example fields
- gtin
- product_id
- brand_name
- name
- url
Price
Price data describes what shoppers can currently see or what a merchant is offering. Useful price records preserve context such as currency, shipping and observation time rather than storing a number in isolation.
Example fields
- price
- currency
- shipping
- total
- observed_at
Offers and sellers
A single marketplace product can have many competing offers. Seller-level data makes it possible to understand the offer landscape instead of treating one displayed price as the entire market.
Example fields
- seller_name
- seller_type
- offer_position
- price
- shipping
Availability
A price without availability context can produce bad decisions. Availability signals indicate whether an offer is currently purchasable and, where exposed by the source, may include stock or delivery context.
Example fields
- is_available
- availability_code
Marketplace signals
Some platforms expose additional signals such as Buy Box ownership, offer position, ratings, review counts, promotional prices or marketplace-specific status fields. These signals differ between sources and should not be forced into false equivalence.
Provenance and quality metadata
Production systems need to know more than the observed value. They need to know when and where it was observed and whether there are reasons to treat the record cautiously. Useful metadata can include timestamps, source, geography, request status, schema version and quality or confidence indicators.
Marketplace Data Is Not the Same as a Product Feed
The terms are sometimes used interchangeably, but they describe opposite data directions. A product feed distributes information from your own catalog outward to destinations such as marketplaces, advertising platforms or shopping channels, where you control what is published. Marketplace data flows the other way: it observes external commerce environments and brings structured market information back into your systems.
Product feed
Marketplace data
- 01
Primary direction
Your catalog → external channel
Marketplace → your systems
- 02
Typical owner
Merchant / brand
Market observer / data provider
- 03
Examples
Your title, price, images, stock
Competitor prices, offers, sellers
- 04
Main purpose
Publish products
Understand market conditions
- 05
Typical destinations
Google Merchant Center, marketplaces
Pricing engine, warehouse, BI
| Product feed | Marketplace data | |
|---|---|---|
| Primary direction | Your catalog → external channel | Marketplace → your systems |
| Typical owner | Merchant / brand | Market observer / data provider |
| Examples | Your title, price, images, stock | Competitor prices, offers, sellers |
| Main purpose | Publish products | Understand market conditions |
| Typical destinations | Google Merchant Center, marketplaces | Pricing engine, warehouse, BI |
Companies often use both. One controls how their own products are published; the other helps them understand the environment in which those products compete.
Where Does Marketplace
Data Come From?
Marketplaces are not one homogeneous database. Amazon marketplace data, eBay, Google Shopping data, Walmart marketplace data, Idealo and regional retailers expose different page structures, identifiers, seller models, localization rules and marketplace-specific fields.
Data can come from official interfaces where suitable access exists, authorized feeds, public marketplace surfaces and other technically permissible collection mechanisms depending on the source and use case. The collection mechanism is only the first part of a production data system, raw retrieval still has to become usable data.
Acquisition Pipeline
Source
Marketplace or shopping platform
Collection
Obtain current observable values
Matching
Resolve product identity
Normalization
Map source-specific fields
Validation
Check completeness and consistency
Delivery
API / webhook / pipeline
Customer System
Pricing, BI, analytics, applications
Source
Marketplace or shopping platform
Collection
Obtain current observable values
Matching
Resolve product identity
Normalization
Map source-specific fields
Validation
Check completeness and consistency
Delivery
API / webhook / pipeline
Customer System
Pricing, BI, analytics, applications
Raw Data vs Decision-Ready Data
Retrieving a page and producing a reliable production input are different engineering problems. Raw marketplace output can contain missing fields, different currencies, changing page structures, multiple sellers, variants, promotions and values observed at different times, all of it technically correct, none of it ready to act on.
Before downstream systems can use it, teams normally need to answer questions such as:
- Does this observation belong to the correct SKU?
- Is the seller offer actually available?
- Does the price include shipping?
- Which geography was queried?
- When was the value observed?
- Can values from two marketplaces be compared?
- Has the source changed?
- Can the record be traced when a decision is questioned?
Answering them consistently, across every source and every day, is what turns collected output into decision-ready data. That processing layer is where marketplace data stops being a script and becomes infrastructure.
Four Properties of Production-Grade Marketplace Data
Identity
The system must resolve the right product before comparing anything else. Incorrect matching can create errors that look perfectly valid downstream.
Freshness
Every observation should have a meaningful timestamp. How fresh the data needs to be depends on the decision it supports; a quarterly assortment study and an automated pricing engine have very different requirements.
Consistency
Downstream applications should not have to understand a completely different data model for every marketplace. Normalization creates a stable interface while preserving marketplace-specific fields where necessary.
Traceability
When a system reacts to an external price or offer, teams should be able to determine what was observed, where it came from and when it was collected.
Related
Marketplace Data QualityWhat Is Marketplace Data Used For?
The value of market data comes from the decision it supports, not from the number of records collected. A few thousand well-matched observations behind a working pricing rule are worth more than millions of rows nobody trusts.
Competitive pricing
Compare your prices with current competing offers and feed the observations into your own pricing rules or repricing engine.
Price monitoring
Observe how market prices change by SKU, seller, source or geography over time.
Marketplace intelligence
Understand offer distributions, merchants, availability and competitive conditions across marketplaces.
Commerce software
Embed normalized marketplace information inside repricing platforms, multichannel applications, analytics products and internal tools.
Data warehouses and BI
Land structured marketplace observations alongside internal sales, inventory and margin data for analysis.
AI and automated systems
Give models or agents structured observations rather than forcing each downstream application to interpret marketplace pages independently.
Marketplace data should normally be treated as input, not as the decision itself. An external price observation does not know your margin floor, stock position, brand policy or pricing strategy, those rules belong in your systems.
Managed Marketplace Data vs Web Scraping
Web scraping is a collection method. Managed marketplace data is the structured output a business consumes. The practical difference is which team operates the layers between source pages and production-ready records.
Your Team Operates
Web Scraping
The collection method is flexible, but your team owns the operating layer between source pages and usable records.
- 01
Access and collection
Collection infrastructure, retries and localization
- 02
Extraction and change handling
Source-specific parsers and schema changes
- 03
Product structure
Product matching and normalization
- 04
Quality operations
Validation and monitoring
- 05
Delivery operations
Scheduling and storage
Provider Operates
Managed Marketplace Data
The provider operates the collection and data layer, exposing structured marketplace records through a stable interface.
- 01
Access and collection
Source access and collection are operated for you
- 02
Extraction and change handling
Source changes are absorbed behind a stable interface
- 03
Product structure
Products, offers and sellers arrive in a consistent model
- 04
Quality operations
Quality checks and operational monitoring stay upstream
- 05
Delivery operations
Structured records are delivered to your systems
The Boundary
Collection stays on the provider side. Application logic and commercial decisions remain in your systems.
Real-Time and Historical Marketplace Data Solve Different Problems
Fresh observations answer what is happening now; historical observations answer how the market changed. Neither is universally better, automated pricing may require highly current observations, while strategic analysis cares more about a consistent time series. Many mature systems combine the two: ingest current observations, act when required and retain the relevant records in their own warehouse for later analysis.
kwery is designed primarily as the live marketplace data layer, so customers that need durable long-term history persist the observations they receive in their own storage environment.
Where kwery Fits in the Commerce Data Stack
kwery provides the marketplace data layer between external commerce sources and the systems that make decisions. Instead of maintaining source-specific collection pipelines for every marketplace, teams query a normalized marketplace data API and receive structured observations their existing stack can consume directly.
Delivery is API-first because the job is to supply data to systems rather than replace them, with webhook and batch delivery where a workflow needs them. The trade-offs between those patterns are compared in API, webhook or batch.
Marketplaces
- Amazon
- eBay
- Google Shopping
- Walmart
- Idealo
- Otto
- Kaufland
- AliExpress
- etc.
kwery
- Collection
- Product resolution
- Normalization
- Validation
- Quality signals
- Delivery
Your stack
- Pricing logic
- Snowflake
- BigQuery
- BI
- ERP
- Repricing engine
- Application
Scope
kwery delivers data, not pricing opinions
Your margin logic, algorithms, thresholds and commercial decisions remain yours.
How to Evaluate Marketplace Data
Before choosing a provider, or building the infrastructure internally, evaluate the data in the context of the system that will consume it.
Source coverage
Does the provider support the marketplaces, countries and page or offer types relevant to your catalog?
Product matching
Can records reliably map to the identifiers your systems already use?
Freshness controls
Can you determine when information was observed and request data at a cadence appropriate to your decision?
Schema stability
Will adding another marketplace require rewriting downstream systems?
Data quality
How are missing, uncertain or inconsistent values represented?
Traceability
Can your team investigate the input behind a downstream pricing or analytics result?
Delivery model
Can results flow directly into the stack you already operate?
Operational ownership
Which parts of acquisition, parsing, validation, storage and monitoring remain your responsibility?