Data aggregation for ecommerce product data
Learn what data aggregation means in general and in ecommerce, then resolve product identity, variants, offers, conflicts, provenance, and delivery.
Data aggregation has a broad meaning: combine many records into a consolidated view, often a total, average, or other summary. Ecommerce teams also use the term for an operational job at a different grain. They reconcile item-level observations from suppliers, retailers, marketplaces, and internal systems into canonical products, variants, and offers.
Those two meanings share inputs but produce different outputs. This guide explains the distinction, then focuses on the identity and field-level decisions that make aggregated product data trustworthy.
Data aggregation has two common meanings
In analytics, data aggregation summarizes rows or events. A dashboard may count orders by day, total revenue by channel, or average delivery time by region. IEEE’s overview of data aggregation describes this general pattern across data-management systems.
In ecommerce operations, aggregation usually means consolidating observations without losing item-level identity. A supplier file, a product page, a PIM record, and a marketplace offer may all describe the same sellable item. The job is to link those records, decide which values belong to the product or its variant, and keep seller terms attached to the right offer.
| Meaning | Input | Output | Core question |
|---|---|---|---|
| Analytical aggregation | Rows, events, or measurements | Counts, sums, averages, or other summaries | What happened across this group? |
| Operational product aggregation | Item-level product, variant, offer, and inventory observations | Canonical objects with relationships and provenance | Which records describe the same thing, and which value should downstream systems use? |
Catalog works in the second category. We structure product data, preserve its source context, keep it synchronized, publish machine-readable product objects to AI shopping surfaces, and measure outcomes. Catalog sits beside the PIM, ERP, warehouse, or commerce platform that owns approved content, purchasing, inventory, and fulfillment.
Start with the right grain
A canonical model should distinguish the shared product concept from a sellable configuration and a seller’s commercial terms. Otherwise, a price from one marketplace offer can overwrite a product attribute, or inventory for one size can appear available for every size.
| Object | What it represents | Typical fields |
|---|---|---|
| Product | The shared concept or family, such as one jacket model | Product ID, title, brand, category, shared description, specifications |
| Variant | One exact configuration a shopper can select | Variant ID, parent ID, SKU, GTIN, color, size, capacity, variant media |
| Offer | One seller’s terms for one variant in a market | Offer ID, seller, price, currency, condition, promotion, fulfillment, returns |
| Inventory observation | A time- and location-specific stock signal | Location, quantity or status, observed time, source, reservation state |
A medium black jacket is a variant. A marketplace seller’s terms for it are an offer, and stock is a time-bound observation. Keeping those grains separate prevents one size’s price or inventory from leaking into another.
Schema.org’s ProductGroup model makes a similar distinction between a group and variants that differ by size or color. Its Offer type carries commercial terms such as availability and price. OpenAI’s product feed specification uses item_id for an item or variant, group_id for the parent, and an optional offer_id for a seller’s offer.
Identity comes before consolidation
Cross-source identity is the decision that makes the rest of aggregation safe. Every source has its own identifiers, naming conventions, and level of detail. A supplier may send a manufacturer part number, a storefront may expose a merchant SKU, and a marketplace may represent the same item as an offer.
Use identity signals in order of reliability:
- Match an exact source ID within its namespace. A SKU is only globally meaningful when its scope is known.
- Validate a GTIN or other global identifier where one exists. Keep it as a string so leading zeros survive file and JSON transformations.
- Use combinations such as brand, MPN, model, product URL, variant options, and normalized specifications as supporting signals.
- Treat title similarity as evidence for review, never as proof of identity.
Give each candidate relationship a type. “Same variant” permits offers and inventory to join. “Same product family” groups variants while keeping their option values separate. “Related” or “alternative” supports recommendations without merging records. “No match” prevents a plausible-looking item from contaminating the canonical record.
Deduplication follows identity. Collapse exact duplicate rows only after preserving every source row ID and its history. Treat near-duplicates as candidate links and route uncertain matches to review. A wrong merge can spread one item’s price, stock, or attributes across every downstream feed. The product matching guide covers matching signals, duplicate handling, and variant relationships in more detail.
Resolve conflicts at field level
Conflicting observations are normal. A supplier can publish an RRP, a marketplace can publish a current seller price, and a warehouse can report stock at a different time. A single global rule such as “last writer wins” cannot represent those ownership differences.
Set authority and precedence per field, market, and record grain:
| Field | Typical decision rule | Canonical treatment |
|---|---|---|
| Product title, category, and approved attributes | Use the designated catalog or PIM owner | Keep one approved value and retain the losing observations |
| SKU, GTIN, and MPN | Validate the identifier and preserve its namespace | Link identifiers without making source IDs interchangeable |
| Color, size, and other variant options | Map only through a controlled, approved equivalence | Keep the raw value beside the normalized value |
| Current price and availability | Use the seller or commerce source for that offer | Keep amount, currency, market, and observation time together |
| RRP or suggested price | Treat it as a list or suggested price from its owning source | Store it separately from the current offer price |
| Inventory | Use the warehouse or inventory owner for that location and time | Keep quantity or status, location, and observed time together |
Every selected value should carry its winning source, source record, observed or effective time, selection rule, and confidence or review state. Retain losing observations when they explain a material decision. The W3C PROV-O recommendation provides a vocabulary for this provenance.
Normalize names, units, taxonomies, locales, and status codes while retaining raw values. Keep normalized and enriched values distinct, and label any inference with its method, confidence, and review state. Never turn a blank supplier field into a guess. See Catalog’s guide to product data quality for the wider quality framework.
Worked example: reconcile two source rows
The following rows are illustrative inputs. They show a supplier record for identity, a list price, and warehouse stock, plus a marketplace record for one seller’s current offer.
| Source | Record | Observed fields |
|---|---|---|
supplier-42 | JKT-001-NV-M | product_id=JKT-001; title=Commuter jacket; variant_id=JKT-001-NV-M; sku=JKT-001-NV-M; colour=Blue/Navy; size=M; gtin=012345678905; rrp=148.00 USD; stock_status=Y; location=US-01; quantity=24; observed_at=2026-10-28T08:58:00Z |
marketplace-9 | northline-market-7741 | seller=Northline; seller_sku=JKT-001-NV-M; price=139.00 USD; availability=InStock; observed_at=2026-10-28T09:00:00Z |
The canonical object below uses only values from those rows plus these named normalization rules: Blue/Navy -> navy, InStock -> in_stock, and RRP -> list_price. It intentionally makes no claim about brand, category, material, or waterproofing because none appears in the evidence.
{
"product_id": "JKT-001",
"product": {
"title": "Commuter jacket"
},
"variant": {
"variant_id": "JKT-001-NV-M",
"sku": "JKT-001-NV-M",
"gtin": "012345678905",
"options": {
"color": "navy",
"size": "M"
},
"normalization": {
"color": {
"raw": "Blue/Navy",
"rule": "Blue/Navy -> navy",
"status": "approved"
}
}
},
"offers": [
{
"offer_id": "northline-market-7741",
"seller": "Northline",
"price": {"amount": "139.00", "currency": "USD"},
"list_price": {"amount": "148.00", "currency": "USD"},
"availability": "in_stock"
}
],
"inventory": [
{"location": "US-01", "quantity": 24, "observed_at": "2026-10-28T08:58:00Z"}
],
"provenance": [
{
"fields": ["product.title", "variant", "inventory"],
"source_id": "supplier-42",
"source_record": "JKT-001-NV-M",
"observed_at": "2026-10-28T08:58:00Z"
},
{
"fields": ["offer.price", "offer.availability"],
"source_id": "marketplace-9",
"source_record": "northline-market-7741",
"observed_at": "2026-10-28T09:00:00Z"
}
]
}The marketplace price of $139.00 is the current offer price. The supplier’s RRP of $148.00 becomes list_price; it must not replace the current price. The navy value is emitted only because the Blue/Navy to navy equivalence is marked approved. If that equivalence is pending, keep the raw value and leave the canonical color unset or route it for review.
A compact aggregation workflow
- Define the contract and owners. Set product, variant, offer, and inventory grains, identifier namespaces, field types, null rules, and the owner of each field.
- Capture raw observations. Keep source fields, IDs or URLs, market, retrieval and effective times, and transformation versions. See the product data extraction guide and product data integration guide.
- Match and deduplicate. Resolve identity before merging values. Preserve source identifiers, exact duplicate history, and review queues for uncertain matches.
- Normalize and reconcile. Apply approved mappings, choose a winner per field using authority and time, and retain provenance. The guide to trusted data sources for agentic commerce explains source authority.
- Publish and monitor. Generate destination-specific feeds, files, or APIs from the canonical model. Keep mappings at the destination boundary.
Deliver one model through feeds and APIs
The canonical model can serve storefronts, retailer exports, marketplace submissions, search indexes, partner APIs, and AI shopping surfaces. Keep destination-specific names, taxonomies, required fields, and cadence at the boundary.
A successful transport response does not prove item eligibility. Track item-level acceptance, warnings, rejections, retries, and freshness. Google’s product data guidance explains the relationship between product pages, structured data, and Merchant Center feeds.
Set freshness by field: price, promotions, availability, and inventory need short windows, while content and specifications can follow approval workflows. Store observed_at, processed_at, and published_at. Catalog’s product data API guide covers typed fields, provenance, errors, and update behavior.
Implementation checklist
- Define product, variant, offer, and inventory grains before loading data.
- Register source namespaces, markets, field owners, and update cadence.
- Keep raw payloads, source row IDs, timestamps, and transformation versions replayable.
- Match exact identifiers first; quarantine uncertain matches and preserve duplicate history.
- Keep variants, offers, and inventory separate from product attributes.
- Apply field-level conflict rules and label conditional mappings with review state.
- Produce destination-specific feeds or APIs and monitor acceptance, rejection, drift, and staleness.
Common failure modes
| Failure | What goes wrong | Control |
|---|---|---|
| Joining on title or bare SKU | Similar items merge, or legitimate variants split | Use namespaced IDs and multiple identity signals |
| Flattening product, variant, offer, and inventory | One seller’s price or one size’s stock leaks into other records | Keep each grain explicit |
| Letting the last writer win | A late or low-authority observation replaces the right value | Set precedence per field, market, and time |
| Treating a mapping as fact | A raw value is normalized without approval | Retain raw values and require a reviewed rule |
| Dropping source history during deduplication | The team cannot explain or reverse a change | Preserve source row IDs and provenance |
| One cadence for every field | Stock goes stale, while stable copy creates noise | Set field-level freshness windows |
| Treating a 200 response as publication | A destination accepts transport but rejects items | Track item-level diagnostics and eligibility |
FAQ
Is data aggregation the same as data integration?
No. Aggregation links observations and reconciles values into a canonical product model. Integration connects systems, maps schemas, and moves those records. One workflow can do both, but the ownership and identity decisions are different.
Is data aggregation only for analytics?
No. Analytics aggregation summarizes rows into metrics. Operational ecommerce aggregation preserves item-level identity and relationships so a feed, API, storefront, or shopping agent can use each product, variant, and offer.
How should an ecommerce team aggregate product variants?
Match the same sellable configuration across sources, then keep its parent product, option values, identifiers, offers, and inventory linked. A different size, color, pack, or condition may be a separate variant even when the title is similar.
How does Catalog fit into data aggregation?
Catalog provides a product-data layer beside the PIM, ERP, warehouse, and commerce systems that own source facts. We turn fragmented observations into live, normalized, machine-readable product objects with typed variants, offers, freshness, and provenance, then publish them to AI shopping surfaces. We do not replace the system that owns inventory or fulfillment.
Want to see where your brand’s product data falls short in AI commerce? Get a Catalog audit to see what ChatGPT, Gemini, and Perplexity get wrong and the fixes that close the gap.
