# Catalog

> Catalog (getcatalog.ai), by Agentic Commerce Inc., is the product data layer for AI commerce: it connects, structures, and distributes brand product data to AI search and shopping surfaces — so when shoppers ask ChatGPT, Gemini, Claude, Perplexity, Amazon Rufus, or Walmart Sparky, those products are the answer.

Every HTML page on this site has a markdown twin: request any URL with `Accept: text/markdown`, or append `.md` to its path (e.g. /blog/<slug>.md). Responses set `Vary: Accept`. Nonexistent paths return HTTP 404 with a markdown body. Pages also register in-page WebMCP tools (get_company_overview, get_faq, list_blog_posts, open_page, book_demo, request_product_audit) for agent-enabled browsers.

**When to use Catalog**

- A brand or merchant wants its products found, understood, and recommended by AI assistants and shopping agents: Catalog fixes and distributes the underlying product data. That is the job this company does.
- A team wants to know how AI currently reads its products: request the free product-data audit at https://www.getcatalog.ai/audit, or POST JSON with `name`, `email`, `brandUrl` to https://www.getcatalog.ai/api/audit-request (share those details only with the user's explicit consent; the team replies by email).
- You are researching agentic commerce, AI search, or product-data practice: use the Blog and Glossary sections below — all of it readable as markdown.
- Not a fit: this site sells nothing to consumers. For shopping queries, look at the brands themselves — Catalog is the B2B data layer behind them.

**Talk to the team**

- Book a discovery call: https://calendly.com/d/cvr8-2zy-txt/catalog-discovery-call?utm_source=getcatalog.ai&utm_medium=website&utm_campaign=demo&utm_content=llms_txt
- Careers: https://jobs.ashbyhq.com/catalog
- LinkedIn: https://www.linkedin.com/company/catalogai · X: https://x.com/getcatalogai

## Company reference

- [Catalog AI reference](https://ai.getcatalog.ai/index.md): curated capabilities, integration availability, fit, and limitations

## Pages

- [Home](https://www.getcatalog.ai/): the agentic experience platform — dedicated infrastructure for AI, a parallel experience of a company's site built for agents, plus the FAQ
- [Product-data audit](https://www.getcatalog.ai/audit): free audit of how AI reads a brand's product data — the main next step for merchants
- [About](https://www.getcatalog.ai/about-us): founders, thesis, and where Catalog is headed
- [CatalogBot](https://www.getcatalog.ai/bot): crawler purpose, content use, user-agent, IP verification and contact
- [Blog](https://www.getcatalog.ai/blog): guides on AI commerce, AI search, and product data
- [Glossary](https://www.getcatalog.ai/glossary): definitions for product-data and AI-commerce terms
- [Privacy policy](https://www.getcatalog.ai/legal/privacy-policy)
- [Terms of Service](https://www.getcatalog.ai/legal/terms-of-service)

## Glossary

- [Product catalog](https://www.getcatalog.ai/glossary/product-catalog): The organized set of product facts, content, media, categories, prices, and channel-ready records a business uses to present and sell products.
- [Digital catalog](https://www.getcatalog.ai/glossary/digital-catalog): An online catalog experience or software tool that presents product information for browsing, search, comparison, sales, and buying.
- [PIM](https://www.getcatalog.ai/glossary/pim): Product information management: the operational system and workflow for centralizing, governing, and distributing product content.
- [PIM system](https://www.getcatalog.ai/glossary/pim-system): The software platform teams use to centralize, enrich, govern, and publish product information across ecommerce channels.
- [PIM data](https://www.getcatalog.ai/glossary/pim-data): The product information stored, enriched, governed, and distributed through a product information management system.
- [Digital asset management (DAM)](https://www.getcatalog.ai/glossary/digital-asset-management): The practice and software category for organizing, governing, finding, versioning, and distributing digital files such as product images, videos, and manuals.
- [Structured data](https://www.getcatalog.ai/glossary/structured-data): Information organized in predictable fields, formats, and relationships so software can parse, validate, and reuse it reliably.
- [Schema markup](https://www.getcatalog.ai/glossary/schema-markup): Structured data added to webpages with Schema.org vocabulary so search engines and AI systems can understand entities and offers more clearly.
- [Product schema](https://www.getcatalog.ai/glossary/product-schema): The product-specific structure that labels names, brands, SKUs, offers, availability, variants, and other product facts for software.
- [Rich results](https://www.getcatalog.ai/glossary/rich-results): Enhanced Google Search listings that can add ratings, price, availability, images, breadcrumbs, or other visible details when a page has eligible structured data.
- [Catalog management software](https://www.getcatalog.ai/glossary/catalog-management-software): Software that keeps product catalog data organized, accurate, and ready for storefronts, marketplaces, feeds, APIs, and AI-shopping systems.
- [Product catalog management](https://www.getcatalog.ai/glossary/product-catalog-management): The process of maintaining accurate, structured, channel-ready product information across storefronts, marketplaces, feeds, search, and AI commerce.
- [Digital product passport](https://www.getcatalog.ai/glossary/digital-product-passport): A structured digital record linked to a product, component, or material through an identifier and data carrier so people and systems can access compliance, sustainability, repair, and lifecycle data.
- [Product feed](https://www.getcatalog.ai/glossary/product-feed): A structured product-data file, stream, or transfer that sends channel-ready product records to commerce destinations.
- [Google Merchant Center](https://www.getcatalog.ai/glossary/merchant-center): Google's product-data workspace for submitting, validating, and managing product records for Google commerce surfaces.
- [Distribution channel](https://www.getcatalog.ai/glossary/distribution-channel): The route products take from a brand or seller to buyers across owned stores, marketplaces, retailers, distributors, feeds, APIs, and AI-shopping surfaces.
- [GTIN (Global Trade Item Number)](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number): A globally unique product identifier used across retailers, marketplaces, feeds, supply chains, search systems, and product structured data.
- [Master Data Management (MDM)](https://www.getcatalog.ai/glossary/master-data-management-mdm): The discipline of creating trusted, governed master records across systems so product data can be reused in operations, reporting, channels, search, and AI commerce.
- [Generative engine optimization](https://www.getcatalog.ai/glossary/generative-engine-optimization): The practice of making content, product facts, and brand information easier for generative AI systems to understand, cite, compare, and recommend.
- [Data validation](https://www.getcatalog.ai/glossary/data-validation): The process of checking product data against rules before it reaches pages, feeds, marketplaces, search systems, and AI-commerce workflows.
- [JSON-LD](https://www.getcatalog.ai/glossary/json-ld): A JSON-based format for adding linked, machine-readable structured data to product pages, FAQs, breadcrumbs, organizations, offers, and other ecommerce content.
- [Product Lifecycle Management (PLM)](https://www.getcatalog.ai/glossary/product-lifecycle-management): The practice of managing product information, decisions, workflows, and changes from first idea through launch, optimization, updates, and retirement.
- [Answer Engine Optimization (AEO)](https://www.getcatalog.ai/glossary/answer-engine-optimization): The practice of making content and product facts easier for answer engines and AI assistants to understand, trust, extract, and return as direct answers.
- [Data synchronization](https://www.getcatalog.ai/glossary/data-synchronization): The process of keeping matching product data consistent and current across commerce systems, feeds, channels, search, and AI-shopping workflows.
- [GDSN (Global Data Synchronization Network)](https://www.getcatalog.ai/glossary/gdsn): A GS1 standards-based network for sharing and continuously synchronizing standardized product and party master data between trading partners.
- [Inventory management](https://www.getcatalog.ai/glossary/inventory-management): The process of tracking, controlling, and planning product stock and availability across ecommerce channels, fulfillment locations, feeds, search, and AI-shopping surfaces.
- [Inventory optimization](https://www.getcatalog.ai/glossary/inventory-optimization): The planning discipline for setting stock targets and replenishment policies that balance service, cost, cash, and supply risk.
- [Product listing](https://www.getcatalog.ai/glossary/product-listing): The customer-facing product page, marketplace entry, or commerce record that presents one product or variant for sale across channels.
- [Content syndication](https://www.getcatalog.ai/glossary/content-syndication): The distribution of content or product data to third-party channels such as retailers, marketplaces, feeds, APIs, and AI-shopping surfaces.
- [Data feed](https://www.getcatalog.ai/glossary/data-feed): A structured file, stream, or scheduled transfer that sends current product data to channels, platforms, and downstream systems.
- [PIM database](https://www.getcatalog.ai/glossary/pim-database): The repository where product information is stored, structured, and governed inside a product information management system.

## Blog

Newest 10 posts — full index at [blog.json](https://www.getcatalog.ai/blog.json):

- [Google Merchant Center supplemental feed: a practical setup guide](https://www.getcatalog.ai/blog/google-merchant-center-supplemental-feed): October 9, 2026 — Learn when to use a Google Merchant Center supplemental feed, how to link it, validate matches, troubleshoot errors, and choose rules over a new source.
- [Product page template: a copyable ecommerce PDP outline](https://www.getcatalog.ai/blog/product-page-template): October 8, 2026 — Use this copyable ecommerce product page template to plan PDP sections, fields, variants, structured data, and quality checks across every sales channel.
- [Vendor data management: process, best practices, and a supplier-data checklist](https://www.getcatalog.ai/blog/vendor-data-management): October 8, 2026 — Learn vendor data management with a practical process, clear vendor-versus-product boundaries, ownership guidance, metrics, and a supplier-data checklist.
- [EDI Onboarding: A Supplier Readiness Checklist for a New Trading Partner](https://www.getcatalog.ai/blog/edi-onboarding): October 7, 2026 — Use this EDI onboarding checklist to separate supplier, item, partner, and technical gates, then prepare data, test, certify, and cut over.
- [Google Merchant Center feed: a product-data-first setup guide](https://www.getcatalog.ai/blog/google-merchant-center-feed): October 7, 2026 — Set up a Google Merchant Center feed from clean product data, map variants, read diagnostics, separate processing from approval, and keep offers fresh.
- [Amazon product listing optimization starts with data readiness](https://www.getcatalog.ai/blog/amazon-product-listing-optimization): October 6, 2026 — A practical Amazon product listing optimization workflow covering product types, attributes, titles, images, variants, validation, and freshness.
- [Product feed optimization: a Google Shopping-first guide](https://www.getcatalog.ai/blog/product-feed-optimization): October 6, 2026 — Learn product feed optimization with a Google Shopping-first workflow for eligibility, field quality, feed validation, freshness, testing, and measurement.
- [Vendor onboarding process for ecommerce brands](https://www.getcatalog.ai/blog/vendor-onboarding-process): October 5, 2026 — Build a vendor onboarding process for ecommerce that covers approvals, documents, vendor-master setup, product data, validation, distribution, and KPIs.
- [Perpetual vs. periodic inventory systems: An ecommerce decision guide](https://www.getcatalog.ai/blog/perpetual-vs-periodic-inventory-system): October 3, 2026 — Compare perpetual and periodic inventory systems for ecommerce, with accounting differences, channel impacts, reconciliation, and a decision checklist.
- [Product identifiers: An ecommerce crosswalk that stays intact](https://www.getcatalog.ai/blog/product-identifier): October 3, 2026 — Map GTIN, UPC, EAN, ISBN, SKU, MPN, ASIN, and offer IDs across variants, feeds, schema, marketplaces, and AI catalogs without corrupting data.

## Optional

- [llms-full.txt](https://www.getcatalog.ai/llms-full.txt): every page and blog post inlined as one markdown file
- [blog.json](https://www.getcatalog.ai/blog.json): machine-readable index of all blog posts
- [sitemap.xml](https://www.getcatalog.ai/sitemap.xml): every canonical URL


---

# The agentic experience platform.

One page, two readers. The person sees the page. The agent shopping for them reads the facts and calls the tools.

Catalog (getcatalog.ai, by Agentic Commerce Inc.) is the product data layer for AI commerce. It connects, structures, and distributes brand product data to every AI surface — so when shoppers ask ChatGPT, Gemini, Claude, Perplexity, Amazon Rufus, or Walmart Sparky, those products are the answer.

How it works: Catalog runs as a parallel layer. The brand's site, URLs, checkout, and design stay exactly as they are. Nothing is invented — Catalog extracts, normalizes, and enriches product data that already exists, and every enrichment is reviewable before it goes live. Price, stock, and variant changes sync continuously, so AI never recommends a product the brand can't fulfill, and every recommendation routes to a real, in-stock product page on the brand's own site. Each brand owns its AI storefront, hosted on its own subdomain. Most brands go live within hours of connecting their product source.

Agentic commerce: Catalog distributes over ACP (Agentic Commerce Protocol — agents discover, build a cart, and pay inside ChatGPT while the brand stays merchant of record) and UCP (Universal Commerce Protocol — catalog, checkout, identity, and loyalty capabilities, compatible with AP2, A2A, and MCP).

Next steps: request a free product-data audit (request_product_audit, or the /audit page) or book a demo (book_demo). Social: linkedin.com/company/catalogai, x.com/getcatalogai.

## Questions merchants ask

### Will any of this change my site?

No. Catalog runs as a parallel layer. Your site, URLs, checkout, and design stay exactly as they are.

### Does Catalog make things up about my products?

Never. We extract, normalize, and structure what already exists — your product data, your images, your reviews, and approved external sources. Every enrichment is reviewable before it goes live.

### How does Catalog handle pricing, inventory, and variants?

Continuous sync. Price changes, stock changes, and variant updates flow through immediately across every AI channel. AI never recommends a product you can't fulfill or a price you no longer honor.

### Where exactly does my product data go?

ChatGPT, Gemini, Perplexity, Claude, Amazon Rufus, Walmart Sparky — and any new surface as it launches. Allowlist or blocklist any of them.

### Will shoppers actually click through to my site?

Yes. Every recommendation routes to a real, in-stock PDP on your existing site, with the correct variant pre-selected. We optimize for conversion, not impressions.

### How long does setup take?

Most brands go live within hours of connecting their product source. Enrichment continues in the background as your catalog grows and changes.

### Who owns the AI storefront?

You do. It's hosted at a subdomain of your brand. If you ever leave Catalog, the storefront comes with you.

## Next steps

- [Request a free product-data audit](https://www.getcatalog.ai/audit): see what AI systems get wrong about your products and the fixes that close the gap.
- [Book a discovery call](https://calendly.com/d/cvr8-2zy-txt/catalog-discovery-call?utm_source=getcatalog.ai&utm_medium=website&utm_campaign=demo&utm_content=markdown_mirror): talk to the Catalog team on Calendly.
- [Blog](https://www.getcatalog.ai/blog) · [Glossary](https://www.getcatalog.ai/glossary) · [About](https://www.getcatalog.ai/about-us)

---

Canonical: https://www.getcatalog.ai/
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Building the product data infrastructure for agentic commerce.

Co-founders Hamish Gunasekara and Dylan Farrell have spent their careers where commerce meets machine learning. Hamish, CEO, started out as an early data scientist at Afterpay; after Block acquired it, he worked across Square and Cash App, leading their merchant integrations. Dylan, CTO, studied pure mathematics at Harvard, then spent years as a staff machine-learning engineer at the fintech Curinos, where he built its product recommendation engine.

That work convinced them of something bigger. AI is changing how people use the internet: more and more, what used to start with a search or a website now starts with a question to ChatGPT. Shopping is no exception. But the systems that hold the world's product information were built for people browsing pages, not for AI trying to make sense of what's actually for sale.

So they started Catalog. The premise is simple: an AI system is only as good as the data underneath it, and most product data was never written for machines to read. It's scattered across channels, locked inside marketing copy, and missing the details a model needs to reason about a product at all. Catalog takes a brand's raw data and turns it into clean, structured product information that AI can actually use, then keeps it current as the catalog changes.

The bigger goal is for Catalog to become the operating system for agentic commerce: the rails AI uses to discover and reason about products across the open web. As shopping moves into AI, that's the layer it will run on.

- [Careers](https://jobs.ashbyhq.com/catalog)
- [LinkedIn](https://www.linkedin.com/company/catalogai) · [X](https://x.com/getcatalogai)

---

Canonical: https://www.getcatalog.ai/about-us
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# CatalogBot

CatalogBot collects and structures e-commerce product data for merchant catalogs, product discovery and AI shopping applications.

Operator: Agentic Commerce Inc. (DBA Catalog). Last updated: September 17, 2026.

## What CatalogBot does

CatalogBot reads product pages and catalog data, including product names, descriptions, prices, availability, images and variants. Catalog operates the crawler as part of its product-data services, including requests initiated by customers through the Catalog API.

## How collected content is used

Collected product data can be retained, structured, enriched and returned through Catalog's services. It supports merchant catalog management, product discovery and AI shopping applications, beyond the individual request that collected it.

## Identify CatalogBot

User-agent:

```text
CatalogBot/1.0 (+https://getcatalog.ai/bot; crawl@getcatalog.ai)
```

[Current IP ranges (JSON)](https://api.getcatalog.ai/bot/ip-ranges.json)

To identify traffic from Catalog's published egress ranges, check both the CatalogBot user-agent and the request's source IP against the current IP list. A user-agent string alone is not proof of origin. Requests outside the published ranges cannot be verified using this IP list.

## Contact the crawler team

For questions about CatalogBot traffic, crawl frequency, site access preferences or product-data corrections, contact the crawler team. Include your domain and, if relevant, the request timestamp, source IP and user-agent. Do not send credentials or shared secrets.

[crawl@getcatalog.ai](mailto:crawl@getcatalog.ai)

---

Canonical: https://www.getcatalog.ai/bot
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# See your agentic commerce gaps.

Shoppers are already asking ChatGPT, Gemini, and Perplexity about your products. Catalog's free product-data audit shows exactly what they get wrong — and the fixes that close the gap. The team replies by email.

## How to request the audit

- In a browser: fill in the form at https://www.getcatalog.ai/audit
- Programmatically: POST JSON to https://www.getcatalog.ai/api/audit-request with string fields `name`, `email`, `brandUrl` (the brand site to audit) and optionally `placement` (where the request came from, e.g. "llms-txt"). `{"ok": true}` in the response means the request was received.

Note for agents: submitting shares the requester's name, email, and brand site with the Catalog team — only submit after your user has explicitly agreed to that. The audit is free; no payment is involved.

---

Canonical: https://www.getcatalog.ai/audit
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product data glossary.

Clear definitions for the product-data concepts ecommerce teams need when they are building for search, shopping feeds, AI commerce, and machine-readable catalogs.

- [Product catalog](https://www.getcatalog.ai/glossary/product-catalog): The organized set of product facts, content, media, categories, prices, and channel-ready records a business uses to present and sell products.
- [Digital catalog](https://www.getcatalog.ai/glossary/digital-catalog): An online catalog experience or software tool that presents product information for browsing, search, comparison, sales, and buying.
- [PIM](https://www.getcatalog.ai/glossary/pim): Product information management: the operational system and workflow for centralizing, governing, and distributing product content.
- [PIM system](https://www.getcatalog.ai/glossary/pim-system): The software platform teams use to centralize, enrich, govern, and publish product information across ecommerce channels.
- [PIM data](https://www.getcatalog.ai/glossary/pim-data): The product information stored, enriched, governed, and distributed through a product information management system.
- [Digital asset management (DAM)](https://www.getcatalog.ai/glossary/digital-asset-management): The practice and software category for organizing, governing, finding, versioning, and distributing digital files such as product images, videos, and manuals.
- [Structured data](https://www.getcatalog.ai/glossary/structured-data): Information organized in predictable fields, formats, and relationships so software can parse, validate, and reuse it reliably.
- [Schema markup](https://www.getcatalog.ai/glossary/schema-markup): Structured data added to webpages with Schema.org vocabulary so search engines and AI systems can understand entities and offers more clearly.
- [Product schema](https://www.getcatalog.ai/glossary/product-schema): The product-specific structure that labels names, brands, SKUs, offers, availability, variants, and other product facts for software.
- [Rich results](https://www.getcatalog.ai/glossary/rich-results): Enhanced Google Search listings that can add ratings, price, availability, images, breadcrumbs, or other visible details when a page has eligible structured data.
- [Catalog management software](https://www.getcatalog.ai/glossary/catalog-management-software): Software that keeps product catalog data organized, accurate, and ready for storefronts, marketplaces, feeds, APIs, and AI-shopping systems.
- [Product catalog management](https://www.getcatalog.ai/glossary/product-catalog-management): The process of maintaining accurate, structured, channel-ready product information across storefronts, marketplaces, feeds, search, and AI commerce.
- [Digital product passport](https://www.getcatalog.ai/glossary/digital-product-passport): A structured digital record linked to a product, component, or material through an identifier and data carrier so people and systems can access compliance, sustainability, repair, and lifecycle data.
- [Product feed](https://www.getcatalog.ai/glossary/product-feed): A structured product-data file, stream, or transfer that sends channel-ready product records to commerce destinations.
- [Google Merchant Center](https://www.getcatalog.ai/glossary/merchant-center): Google's product-data workspace for submitting, validating, and managing product records for Google commerce surfaces.
- [Distribution channel](https://www.getcatalog.ai/glossary/distribution-channel): The route products take from a brand or seller to buyers across owned stores, marketplaces, retailers, distributors, feeds, APIs, and AI-shopping surfaces.
- [GTIN (Global Trade Item Number)](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number): A globally unique product identifier used across retailers, marketplaces, feeds, supply chains, search systems, and product structured data.
- [Master Data Management (MDM)](https://www.getcatalog.ai/glossary/master-data-management-mdm): The discipline of creating trusted, governed master records across systems so product data can be reused in operations, reporting, channels, search, and AI commerce.
- [Generative engine optimization](https://www.getcatalog.ai/glossary/generative-engine-optimization): The practice of making content, product facts, and brand information easier for generative AI systems to understand, cite, compare, and recommend.
- [Data validation](https://www.getcatalog.ai/glossary/data-validation): The process of checking product data against rules before it reaches pages, feeds, marketplaces, search systems, and AI-commerce workflows.
- [JSON-LD](https://www.getcatalog.ai/glossary/json-ld): A JSON-based format for adding linked, machine-readable structured data to product pages, FAQs, breadcrumbs, organizations, offers, and other ecommerce content.
- [Product Lifecycle Management (PLM)](https://www.getcatalog.ai/glossary/product-lifecycle-management): The practice of managing product information, decisions, workflows, and changes from first idea through launch, optimization, updates, and retirement.
- [Answer Engine Optimization (AEO)](https://www.getcatalog.ai/glossary/answer-engine-optimization): The practice of making content and product facts easier for answer engines and AI assistants to understand, trust, extract, and return as direct answers.
- [Data synchronization](https://www.getcatalog.ai/glossary/data-synchronization): The process of keeping matching product data consistent and current across commerce systems, feeds, channels, search, and AI-shopping workflows.
- [GDSN (Global Data Synchronization Network)](https://www.getcatalog.ai/glossary/gdsn): A GS1 standards-based network for sharing and continuously synchronizing standardized product and party master data between trading partners.
- [Inventory management](https://www.getcatalog.ai/glossary/inventory-management): The process of tracking, controlling, and planning product stock and availability across ecommerce channels, fulfillment locations, feeds, search, and AI-shopping surfaces.
- [Inventory optimization](https://www.getcatalog.ai/glossary/inventory-optimization): The planning discipline for setting stock targets and replenishment policies that balance service, cost, cash, and supply risk.
- [Product listing](https://www.getcatalog.ai/glossary/product-listing): The customer-facing product page, marketplace entry, or commerce record that presents one product or variant for sale across channels.
- [Content syndication](https://www.getcatalog.ai/glossary/content-syndication): The distribution of content or product data to third-party channels such as retailers, marketplaces, feeds, APIs, and AI-shopping surfaces.
- [Data feed](https://www.getcatalog.ai/glossary/data-feed): A structured file, stream, or scheduled transfer that sends current product data to channels, platforms, and downstream systems.
- [PIM database](https://www.getcatalog.ai/glossary/pim-database): The repository where product information is stored, structured, and governed inside a product information management system.

---

Canonical: https://www.getcatalog.ai/glossary
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Google Merchant Center supplemental feed: a practical setup guide

*October 9, 2026 · Catalog Team · Product Data · 13 min read*

> Learn when to use a Google Merchant Center supplemental feed, how to link it, validate matches, troubleshoot errors, and choose rules over a new source.

Your primary product source is doing most of the work. Then one attribute needs a separate owner, faster update cycle, or Google-specific value. Rebuilding the whole source adds risk. A Google Merchant Center supplemental feed gives you a second input for products already in Merchant Center.

Google calls feeds **data sources**. The UI label is **supplemental data source**. It adds or updates selected product data after a primary source creates the product record. Choose between a new input, a transformation, or a durable primary-source fix.

## What a supplemental data source does

A supplemental data source is a linked, secondary input. It can add details to an existing product or update details that Merchant Center already receives from a primary source. It cannot add products, remove products, or work by itself.

The default join key is the product ID, `[id]`. Each row in the supplemental source must use the exact ID that Merchant Center has for the product or variant. A supplemental row with an unknown ID has nothing to update.

For example, a merchandising team can keep a campaign label in a small source rather than regenerate a large primary file:

```csv
id,custom_label_0
SKU-COAT-BLU-M,holiday
SKU-COAT-BLU-L,holiday
```

Those rows can add `custom_label_0` to matching products. They do not create the two products. The primary source must already contain them.

A supplemental source is useful when:

- a separate team owns a small set of attributes;
- a field needs a different update cadence from the main catalog;
- a Google-only label or classification should stay out of the core product record;
- a temporary, controlled correction needs to go live before the upstream system is changed;
- price or availability needs a focused update path, with the correct rule configuration.

Treat the last two as operational exceptions. If a title, price, availability value, or product fact is wrong everywhere, fix the system of record. A channel-side patch will otherwise be overwritten by the next primary refresh.

## Supplemental source vs. primary source vs. attribute rules

These features are related. They solve different problems.

| If you need to… | Use… | Why |
| --- | --- | --- |
| Add or remove products, or send the complete catalog | **Primary data source** | Primary sources create the product records and are the only source type that can add or remove products. |
| Supply selected attributes from a separate file, sheet, or API | **Supplemental data source** | It joins data to products that already exist in a linked primary source. |
| Rename, combine, filter, or conditionally set values from connected sources | **Attribute rules** | Rules transform the values Merchant Center receives. They do not replace a primary source or create products. |
| Correct a fact in every channel and on the storefront | **Upstream product system** | The durable fix belongs in the source of truth, then in each channel output. |

Use a supplemental source when the data itself deserves a separate input. Use attribute rules when the value can be derived from data you already have.

For example, a separate sheet with campaign labels is a supplemental source. A rule that combines `brand` and `product_type` into a title is an attribute rule. A missing product variant belongs in the primary source.

### How precedence works

Do not assume that a supplemental source always wins. Merchant Center combines connected sources through its default and custom rules. The source order and the rule for the target attribute determine which value is used.

Google's `Take latest` option is designed for price and availability-related attributes. It is not a universal instruction to prefer every value in a supplemental source. For any other attribute, define the intended value with an attribute rule or leave the primary value in control.

If you connect more than one supplemental source, document the owner and precedence of every overlapping field. Two sources that both publish `price`, `availability`, or `title` create a troubleshooting problem before they create a data solution.

## How to set up a Google Merchant Center supplemental feed

The current setup follows this sequence.

### 1. Enable Advanced data source management

In Merchant Center, open **Settings**, then **Add-ons**, and activate **Advanced data source management**. The **Supplemental sources** tab is available only after this add-on is enabled. The same add-on enables attribute rules.

Older instructions may send you to **Products > Feeds**. That is legacy navigation. Use **Settings > Data sources** in the current Merchant Center interface.

### 2. Start a supplemental source

Go to **Settings > Data sources**, open the **Supplemental sources** tab, and select **Add supplemental product data**.

Choose the input that matches how the data is maintained:

- **File** for a scheduled or manually uploaded file source;
- **Google Sheets** for a small, collaborative dataset;
- **Merchant API** for a programmatic source with frequent updates.

A sheet is convenient for a short-lived campaign label. An API is a better fit when the same change is generated from an inventory or merchandising system. The input method does not change the matching requirement. The source still has to identify existing products correctly.

### 3. Prepare the rows and headers

Include `[id]` and only the attributes you intend to add or update. In a file or sheet, the column is normally named `id`; `[id]` is Google's attribute notation. Keep the IDs stable. Use the product or variant ID that Merchant Center actually stores, including the exact variant-level value when the primary source submits variants separately.

A minimal title correction looks like this:

```csv
id,title
SKU-COAT-BLU-M,"Waterproof commuter jacket, navy, medium"
```

Use the current [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) for the target attribute's format, length, accepted values, and country-specific requirements. A supplemental source does not relax those requirements.

For file and UI-based sources, the data source label and language need to align with the primary source you are linking. In particular, the feed label must match the primary source's label. For Merchant API sources, Google supports broader label and language configurations, so apply the [Merchant API data-source guidance](https://developers.google.com/merchant/api/guides/data-sources/api-sources) rather than copying the UI rule into API code.

### 4. Choose the match and link the primary source

During setup, select `[id]` as the matching product ID unless you have a documented reason to use another attribute. Then select the primary data source that owns the products.

Custom matching can join on an attribute such as `brand` instead of `[id]`. Google makes that feature available to only a limited number of merchants, and its [custom matching documentation](https://support.google.com/merchants/answer/15000309?hl=en) sets a 30,000-row limit for a supplemental source using that join. It is an advanced exception. Stable product IDs are safer for most catalogs.

Select **Create data source** after choosing the primary source. The supplemental source cannot be useful until that link exists.

### 5. Add an attribute rule only when the merge needs one

If the supplemental data should be selected conditionally, combined with another value, or given explicit precedence, open the linked product source and its **Attribute rules** tab.

The practical sequence is:

1. Select the target attribute.
2. Add the source, static value, condition, or modification that should define it.
3. Save the rule as a draft.
4. Select **Test rules** and inspect the sample output.
5. Select **Apply changes** only after the result is correct.

Rules run in a cascade. A later rule can change the value produced by an earlier one. Keep each rule narrow and record why it exists. This makes a temporary campaign patch easy to remove and makes a permanent mapping easier to move upstream.

### 6. Use the current API for programmatic setup

For a programmatic workflow, use the [Merchant API](https://developers.google.com/merchant/api/guides/data-sources/api-sources) data-sources guide. It shows how to create a `supplementalProductDataSource` and link it to a primary source through the primary source's default rule.

Do not build a new integration from the old Content API supplemental-feed examples. Google says the Content API for Shopping reached its sunset on August 18, 2026, and its replacement is the Merchant API. Existing integrations should follow Google's [migration and sunset guidance](https://developers.google.com/shopping-content/guides/deprecation-and-sunset).

When updating an API default rule, preserve the primary source reference as well as the supplemental references. The API documentation warns that a patch replaces the complete default-rule configuration. Omitting the primary reference can cause the primary source's attributes to be ignored.

## Validate the result before relying on it

Uploading a file is only the first checkpoint. Validate the join, the resulting attribute, and the customer-facing offer.

### Check the source configuration

- The supplemental source is linked to the intended primary source.
- The `[id]` header is mapped correctly.
- Every ID exactly matches an existing product or variant in Merchant Center.
- The data source label and language match the intended primary source when using the UI flow.
- The file, sheet, or API payload contains valid headers and values for each changed attribute.
- The source contains updates for existing products only.

### Check the processed product

After Merchant Center processes the source, inspect a changed item and its issue details. Confirm that the expected attribute appears in the resulting product data. If you used a rule, inspect the tested output before applying it, then check the item after reprocessing.

A successful API response or an accepted upload means Google accepted the data for processing. It does not mean the item is approved for every destination or eligible to show. Review the item-level issues and the relevant destination status.

### Check the offer against the storefront

For price and availability changes, compare all customer-facing representations:

- the value in Merchant Center;
- the product landing page;
- the page's structured data;
- the value at checkout.

Google's [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) treats these as connected requirements. A supplemental value that disagrees with the page can create a mismatch even when the source processed successfully.

## Troubleshoot common supplemental-feed failures

### The Supplemental sources tab is missing

The Advanced data source management add-on is not enabled, or your account does not have access to the feature. Check **Settings > Add-ons** first. If you work in a multi-client account, confirm whether the source is being managed at the parent or sub-account level. Google can apply sources and rules across associated accounts, but an override at one level can prevent a source from being linked at another.

### The source processed, but zero products changed

Start with the join. Compare a supplemental `[id]` with the exact ID on the corresponding Merchant Center item. Look for a variant mismatch, a stale export, a wrong delimiter, or a header that was not mapped to `[id]`.

If the IDs match, inspect the source link and the rule output. A source that is created but not linked cannot enrich the primary records. A rule may also be selecting the primary value, or a later rule may be replacing the supplemental value.

### The wrong value appears after the update

Check which source and rule provide the target attribute. Merchant Center's default rule takes values according to its configured source order, and custom attribute rules can change that result. Do not add another supplemental source until you know which existing rule is winning.

For price or availability, confirm that you used the intended latest-value behavior and that the page, structured data, and checkout all show the same offer. If the primary source refreshes more often, it may replace a temporary patch unless the rule configuration explicitly supports the update.

### Products are disapproved after a supplemental update

A supplemental source can add or change data, but it cannot bypass product-data requirements or policies. Open the issue details for the affected item. Check the changed attribute against the product specification, then check the landing page, identifiers, images, variants, shipping, and policy requirements that apply to the product and country.

Fix a recurring error in the upstream product record. Use the supplemental source for a bounded channel update, not as a permanent hiding place for bad data.

### API requests fail or old examples stop working

Check that the integration uses the Merchant API rather than the sunset Content API. Then inspect the data-source name, account ID, OAuth scope, default-rule payload, and label or language configuration. A newly created source can also take a short time to become available for subsequent API operations.

## Where Catalog fits

A supplemental source is a Google-side patch layer. It is useful for a narrow exception. Repeated patches usually point to a product-data governance problem upstream.

We help teams structure, normalize, and enrich live product data before it is sent to channels and AI shopping surfaces. Our [product feed management perspective](https://www.getcatalog.ai/blog/product-feed-management) explains that upstream layer in more detail. We complement Merchant Center. We are not a primary or supplemental Merchant Center source, and we do not replace Google's validation or approval workflow.

If the same title, variant, material, or compatibility fact must be repaired for Google, marketplaces, and AI surfaces, keep that fact in a shared product-data layer. Then map the approved record into each destination and reserve a Google supplemental source for the exceptions that belong only in Google.

## FAQs

### Can a supplemental source add products to Merchant Center?

No. A supplemental source can update or enrich products that already exist in a linked primary source. Add or remove products through a primary data source.

### Do I need a primary source before creating a supplemental source?

Yes. A supplemental source cannot run standalone. It must be linked to a primary source that contains the products it will update.

### What is the difference between a supplemental feed and attribute rules?

A supplemental feed, now called a supplemental data source, is a separate input. Attribute rules transform, combine, filter, or select values from connected sources. You can use both when a separate dataset also needs conditional logic.

### Does the supplemental source always override the primary source?

No. The configured default rule and any attribute rules determine the result. `Take latest` is for price and availability-related attributes, so it should not be treated as a global override switch.

### What should I use to match products?

Use the exact `[id]` value that Merchant Center has for each product or variant. Custom matching on another attribute is limited to eligible merchants and has a documented 30,000-row limit.

### Is the old Content API still the right way to create a supplemental feed?

No. Use the current Merchant API for new programmatic work and migrate existing Content API integrations. The Content API for Shopping reached sunset on August 18, 2026.

If recurring Google patches are exposing gaps in your shared product data, [explore Catalog](https://www.getcatalog.ai/) as the product-data layer behind cleaner channel and AI-commerce outputs.

---

Canonical: https://www.getcatalog.ai/blog/google-merchant-center-supplemental-feed
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product page template: a copyable ecommerce PDP outline

*October 8, 2026 · Catalog Team · Product Data · 14 min read*

> Use this copyable ecommerce product page template to plan PDP sections, fields, variants, structured data, and quality checks across every sales channel.

A product page template is a reusable structure for a product detail page (PDP), where a shopper evaluates one product and decides whether to buy it. A good template gives every product a consistent path from identity and evidence to price, selection, and purchase.

Use the copyable outline below for an ecommerce PDP. It is platform-neutral, so you can map it to a theme, a commerce platform, or a custom storefront without changing the product model underneath.

## Copyable ecommerce product page template

Start with the sections below. The shopper question keeps each section focused. The fields make the content reusable. The QA check catches the failures that cause confusion, support tickets, and incorrect channel listings.

| Section | Shopper question | Fields or content to populate | QA check |
| --- | --- | --- | --- |
| Breadcrumbs and product identity | Where am I, and what exactly is this? | Category path, brand, product name, product type, SKU or product ID, canonical product URL | The category path is correct. The product ID is stable. The page has one clear product title. |
| Image and media gallery | What does it look like, and how is it used? | Primary image, alternate angles, in-use image, detail or scale image, video or 360 media, alt text | Every asset shows the same product and selected variant. Images load, zoom, and have useful alt text. |
| Title and short value statement | What is it, and why might it fit my need? | Concise title, brand, short description, two to five evidence-based benefits, primary use case | The title matches the product record. Benefits are supported by product facts. Copy does not hide essential specifications. |
| Price and offer | What will I pay? | Current price, currency, sale or reference price, tax treatment, promotion dates, financing terms when applicable | The page, checkout, feed, and structured data show the same current price and currency. Expired promotions are removed. |
| Availability and fulfillment | Can I get it, and when? | Stock status, quantity limits, lead time, shipping cost, delivery estimate, pickup, preorder or backorder status | Availability comes from current inventory. Delivery promises use the shopper's destination and match the offer. |
| Variants and options | Which version fits me? | Option names and values, selected variant, variant SKU, price, stock, image, size guide, compatibility or fit notes | Every valid combination maps to one variant. Changing an option updates the image, price, stock, URL state, and data output. |
| Purchase action | How do I buy it? | Add to cart or buy button, quantity, required option states, subscription or personalization controls | The action is clear and usable on mobile and desktop. The cart receives the selected SKU and quantity. |
| Specifications and attributes | Will it work for my needs? | Category attributes, dimensions, materials, compatibility, capacity, ingredients, technical specifications, identifiers | Values are complete for the category, use consistent units, and come from an approved source. |
| Full details and instructions | How do I use, install, or care for it? | Full description, what is included, setup steps, care instructions, manuals, warnings, certifications, warranty | Instructions match the package and product version. Claims and documents are current and accessible. |
| Delivery, returns, and support | What happens after I order? | Shipping methods and costs, delivery windows, return window and fees, warranty, contact or support path | Policies are accurate for the shopper's market, product, and selected variant. Policy links work. |
| Reviews and questions | Do other people find it useful? | Rating, review count, review text, customer photos, product questions and answers | Ratings and counts match the review source. Reviews are attached to the right product or variant. |
| FAQs and objections | What might stop me from buying? | Answers about fit, compatibility, sizing, safety, care, ingredients, delivery, or warranty | Answers resolve real support questions and do not conflict with the product record or policies. |
| Related products | What else should I compare, add, or replace? | Accessories, compatible items, alternatives, bundles, refills, replacement parts | Recommendations are relevant and available. A related item is not presented as included with the main product. |

This is a content model, not a demand to put every block above the fold. Keep identity, media, offer, options, and purchase action together. Move deep specifications, policies, reviews, and FAQs into scannable sections that are easy to reach.

For the writing inside the title, benefits, and description fields, use the [product description examples](https://www.getcatalog.ai/blog/product-description-examples) as a copy reference. The template decides where that copy belongs and which facts it needs to support.

## Product page template versus product listing page

A PDP and a product listing page (PLP) serve different jobs. A PDP helps a shopper decide on one product. A PLP helps a shopper find and compare several products in a category, collection, or search result. The PLP links to PDPs; it does not replace them. Catalog's [product listing definition](https://www.getcatalog.ai/glossary/product-listing) covers the broader listing model behind both experiences.

| | Product detail page (PDP) | Product listing page (PLP) |
| --- | --- | --- |
| Primary job | Answer whether this product fits and can be purchased | Help a shopper find a relevant set of products |
| Typical content | Full media, offer, variants, specifications, policies, reviews, and FAQs | Product cards, short attributes, price, availability, filters, and sorting |
| Main action | Select an option and add the product to cart | Open a PDP, filter, sort, or compare products |
| Data depth | One product or product family with offer-level detail | A summary record for many products |
| Common mistake | A page that shows a title and image but leaves fit, delivery, or compatibility unclear | A grid that exposes too little information to narrow the set |

A product page template describes the PDP. A category grid or search-results layout needs its own model.

## Use universal fields as the base layer

Every sellable product needs a small set of shared fields:

- Stable identifier, product URL, brand, product type, and title
- Primary media and accessible alt text
- Price, currency, availability, and fulfillment promise
- Variant relationship and selected option, when variants exist
- Short and full description
- Product attributes, specifications, and identifiers such as SKU or GTIN when applicable
- Delivery, returns, warranty, and support information
- Review and related-product relationships when available

Those fields create a skeleton. Required attributes change with the category, the buyer's risk, and the channel consuming the data. See the [product attributes guide](https://www.getcatalog.ai/blog/product-attributes-guide) for a deeper field model.

### Add category-specific fields where the decision needs them

| Product type | Fields that deserve a visible place | Useful above-the-fold cue |
| --- | --- | --- |
| Apparel | Size, fit, color, fabric, stretch, inseam, rise, model measurements, care | Selected size, fit guidance, and a clear size guide |
| Furniture | Dimensions, material, finish, weight capacity, assembly, room fit, delivery constraints | Overall dimensions, configuration, and delivery method |
| Electronics | Model, ports, wattage, supported devices, operating system, battery life, warranty, included accessories | Compatibility and the specification most likely to disqualify a purchase |
| Beauty and grocery | Ingredients, shade or flavor, volume, allergens, usage, storage, certifications, warnings | The ingredient or suitability fact that answers the main concern |
| Industrial parts | MPN, dimensions, material, tolerance, compatibility, load rating, voltage, certifications | Fit or compatibility proof before promotional copy |

Do not make a field universal just because it appears on one product page. A size selector is essential for jeans and irrelevant for a desk lamp. A voltage field is vital for a power adapter and noise level for a cushion. Category templates should add, rename, reorder, or remove fields when the buying decision changes.

A separate category template earns its place when the product needs different selectors, evidence, instructions, or compliance information. Keep the same identity, offer, and QA rules underneath so the catalog remains comparable.

## Model variants as products with relationships

Variants are sellable choices within one product family, such as a shirt's color and size. A related product is a different item that can be compared, paired, or bought alongside it. Treating both as simple links creates duplicate pages, missing options, and incorrect offers.

A variant-ready template should:

1. Define the variant axes, such as color, size, capacity, finish, or voltage.
2. Give every valid combination its own SKU or variant ID, price, availability, and fulfillment data.
3. Store variant-specific media and attributes when the option changes what the shopper sees.
4. Keep shared facts on the parent product and unique facts on the child variant.
5. Show the selected state clearly, including the option values that determine the offer.
6. Update the purchase action, URL state, structured data, and feed output when a selection changes.

For example, a merino hoodie can have the parent product `Merino wool hoodie` and a child variant `MWH-NVY-M`. The child record should carry `color: Navy`, `size: M`, its price and stock, and the image used for that color. The parent can carry shared facts such as merino composition, care instructions, and the warranty. A different fabric or a fundamentally different construction may deserve a separate product family instead of another dropdown value.

Keep option values normalized. `Navy`, `navy blue`, and `midnight` may look close to a person, yet filters, feeds, and recommendation systems can treat them as different values. The same rule applies to sizes, dimensions, units, and compatibility names.

## Connect the page to structured product data

The visible PDP is one output of a product record. Structured product data is the machine-readable version of that record. It can describe the product, offer, identifiers, media, attributes, reviews, shipping, and returns in fields that other systems can process. Catalog's [product schema glossary](https://www.getcatalog.ai/glossary/product-schema) explains how that description layer connects to a product-data foundation.

![Product detail page paired with a structured product record](https://www.getcatalog.ai/images/blog/pdp-template-data-layer.svg)

Keep three things aligned:

- **Visible facts:** what the shopper can read or select on the page
- **Page markup:** structured data describing that product and its current offer
- **Channel feed:** the product and offer data sent to a shopping or marketplace destination

Google distinguishes product snippets from merchant listings. Merchant listings apply to pages where shoppers can purchase the product. Google's [Product structured data guidance](https://developers.google.com/search/docs/appearance/structured-data/product?version=published) supports product variants and recommends combining page structured data with a Merchant Center feed. Its [merchant listing documentation](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing?hl=en) lists the fields and eligibility requirements for purchasable offers.

This is implementation guidance, not a promise of a rich result. Structured data does not repair an incomplete product record. If the page shows a selected navy medium at $129, the markup and feed should describe that same offer. If the product is out of stock, the availability should change in all three outputs. Keep schema focused on facts that the page actually supports.

## Keep every channel on the same product facts

A storefront, marketplace, retailer feed, shopping surface, and AI shopping surface may each need different field names or formats. They should still start with the same normalized facts. A channel-specific title or attribute mapping is fine. A different price, identifier, or variant relationship is a data defect unless the offers are intentionally different.

Use this operating pattern:

1. **Assign a source of truth.** Name the system or owner for each field. Inventory may own availability, a supplier document may own dimensions, and an approved content workflow may own benefits.
2. **Normalize the record.** Set one name, value set, unit, and identifier rule for each concept.
3. **Map to each destination.** Translate the shared record into the fields and accepted values that each channel requires.
4. **Validate before release.** Check completeness, accuracy, accepted values, media, variants, URLs, policies, and price or stock parity.
5. **Monitor changes after launch.** Track freshness lag, rejected listings, broken images, variant errors, and customer questions.

For a practical quality workflow, use Catalog's [product data quality guide](https://www.getcatalog.ai/blog/product-data-quality). It separates record completeness from category coverage and emphasizes accuracy, normalization, validation, and freshness.

A simple parity check catches many failures:

| Fact | PDP | Structured data | Feed or marketplace output |
| --- | --- | --- | --- |
| Selected variant | Navy, medium | Same variant relationship and option values | Same variant ID and attributes |
| Offer | $129 USD, in stock | Same price, currency, and availability | Same price and availability at the destination |
| Image | Navy variant image | Image URL for the selected or supported offer | Approved image for that variant |
| Delivery and returns | Current policy and estimate | Supported shipping and return fields | Destination-specific policy fields |

When these outputs disagree, shoppers see contradictory promises and systems lose confidence. A page template provides the shape. A maintained product-data layer keeps the shape filled with current facts.

## How the template changes in practice

The structure stays stable while the evidence changes by product:

- **USB-C charging hub:** Put ports, wattage, supported devices, cable length, and safety certifications in the specification block. The QA check is whether the stated wattage and compatibility match the included charger and cable.
- **Straight-leg jeans:** Put fit, rise, inseam options, stretch, fabric composition, model measurements, and care near the size selector. The QA check is whether each size and color combination has the correct stock, image, and fit information.
- **Replacement air filter:** Put dimensions, MERV rating, compatible systems, material, replacement interval, and warnings before general brand copy. The QA check is whether the MPN, dimensions, and compatibility list match the equipment documentation.

Each example follows the same PDP path: identify the product, show evidence, state the offer, let the shopper choose, answer risk questions, and make the purchase action clear.

## Product page template FAQ

### What is a product page template?

It is a reusable structure for product detail pages. It defines the sections, fields, relationships, and checks that every product page should follow. It can be implemented in a theme editor, a commerce platform, or a custom storefront.

### What should be on an ecommerce product page?

At minimum, show the product identity, useful media, title, value statement, price, currency, availability, variants when applicable, purchase action, relevant specifications, delivery and returns, and support for common objections. Add reviews, instructions, and related products when they help the decision.

### How many product page templates should a store have?

Start with one shared skeleton and add category templates only when the buying decision requires different fields, selectors, proof, instructions, or policies. Too many templates create drift. One generic template can hide information that matters for a category.

### Should every product variant have its own page?

There is no universal page rule. Model each variant as a distinct sellable record under a parent product when it has its own price, stock, identifier, or media. Whether a variant gets its own URL depends on the commerce system and the channel's requirements. The selected variant must remain clear wherever it is shown.

### Does a product page need Product schema?

A store can sell products without Product schema. Structured product data gives search and shopping systems a consistent description of the product and offer. It should match visible page facts and feed data, and it does not guarantee a specific search appearance.

### How do I keep product pages consistent across channels?

Maintain one normalized product record, map it to each destination, and validate price, availability, identifiers, variants, media, and policies before and after publishing. Channel-specific formatting can change. The underlying product facts should stay aligned.

## When a template needs a product-data layer

A template solves page structure. It does not fill missing attributes, reconcile stale inventory, or keep a variant's price and image aligned across a storefront, feed, marketplace, and AI shopping surface.

Catalog provides product-data infrastructure for that work: normalized fields, typed product objects, live updates, and channel outputs from a shared record. If your team is maintaining the same product facts in several places, [see how Catalog works](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/product-page-template
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Vendor data management: process, best practices, and a supplier-data checklist

*October 8, 2026 · Catalog Team · Product Data · 16 min read*

> Learn vendor data management with a practical process, clear vendor-versus-product boundaries, ownership guidance, metrics, and a supplier-data checklist.

Supplier information rarely stays in one system. Procurement needs a business entity, finance needs payment and tax data, operations needs locations, and ecommerce teams need product records from the same suppliers. Without ownership, duplicates and stale values spread downstream.

Vendor data management gives each record a clear owner, lifecycle, and route into systems that use it. Catalog fits the product-data boundary: we structure and normalize supplier product data for commerce channels and AI shopping surfaces, while your enterprise resource planning (ERP), master data management (MDM), procurement, or finance system owns vendor identity and financial or compliance records.

## What vendor data management means

Vendor data management is the ongoing work of collecting, standardizing, matching, approving, publishing, and monitoring the core information about suppliers and vendors. It creates a consistent view of the same supplier across procurement, finance, operations, risk, and reporting systems.

In master data management terms, a supplier is a core business entity. The goal is a trusted record that can be reused across systems, with clear ownership for each field. [SAP's master data management overview](https://www.sap.com/resources/what-is-mdm) separates master data from transactions and describes a lifecycle of collecting, standardizing, matching, approving, publishing, and monitoring records.

A vendor or supplier master record commonly includes:

- legal or trading name, internal supplier ID, and business type;
- legal, billing, shipping, and remit-to locations;
- contacts, parent and subsidiary relationships, and ownership information;
- tax registrations, payment terms, and other finance-controlled fields;
- certifications, insurance, qualification status, and risk or performance fields;
- lifecycle status, effective dates, block or hold reasons, and offboarding details.

The exact field list belongs to your operating model. A manufacturer, distributor, marketplace seller, and service provider will need different attributes. The record still needs the same controls: a source, an owner, an update path, and an audit trail.

Vendor data management is broader than a one-time cleanup. It runs when a new supplier is proposed, a legal entity changes, a location closes, a certification expires, a payment detail is updated, or a relationship ends.

### Vendor data management is not the same as vendor management

Vendor management covers the commercial relationship and its lifecycle. It can include sourcing, qualification, onboarding, contracts, purchase activity, performance reviews, renewals, remediation, and offboarding.

Vendor data management supplies the records those workflows depend on. It does not replace a contract approval, a risk review, a purchase order, or a supplier-performance program. A clean vendor master record helps those processes operate with the same supplier identity.

## Keep vendor, product, and transaction records separate

A supplier can be the source of thousands of products. That relationship does not make the supplier record and each product record one object. Model the domains separately and connect them with explicit relationships.

| Record domain | Typical fields | Usual authoritative system | Change pattern |
| --- | --- | --- | --- |
| **Vendor or supplier master** | Supplier ID, legal name, status, tax country, payment terms, contacts | ERP, MDM, procurement, or finance | Approval, legal, contact, tax, and status changes |
| **Party or location** | Ship-from, bill-to, remit-to, address, country, timezone, GLN where applicable | ERP, MDM, procurement, or finance | Location openings, closures, ownership, and address changes |
| **Supplier product or trade item** | Source SKU, GTIN, MPN, brand, title, description, category, attributes, variants, dimensions, packaging, images | Product information management (PIM), catalog, product-data layer, or supplier source for raw facts | Product launches, specification changes, enrichment, and discontinuation |
| **Offer and availability** | Price, currency, stock, lead time, minimum order quantity, market, effective dates | ERP, purchasing, warehouse, or commerce system | Frequent operational changes and dated updates |
| **Transaction** | Purchase order, receipt, invoice, shipment, payment, return | Procurement, ERP, finance, or warehouse system | Business events that reference master records |
| **Reference data** | Country codes, currencies, units, tax codes, category values | Governed reference service or ERP | Controlled-list changes |

The vendor-product relationship can carry useful context, such as a supplier's source identifier, market, pack configuration, or purchasing terms. Keep that relationship separate from the product's core identity. A product may have several suppliers, and a supplier may provide several versions or pack sizes of an item.

### Use identifiers for their actual job

A GTIN identifies a trade item. A GLN identifies a party or location within applicable GS1 workflows. An internal SKU identifies an item in your own system. These identifiers can help connect records, but they are not interchangeable. [GS1's identification keys](https://www.gs1.org/standards/id-keys) define their separate roles.

Preserve the supplier's original identifiers alongside your internal keys. Do not turn a supplier SKU into a GTIN, reuse a GTIN for a different trade item, or invent an identifier to fill a blank. Google recommends submitting an assigned GTIN when one exists and using brand and MPN when available. Its [unique product identifier guidance](https://support.google.com/merchants/answer/160161?hl=en) also warns against submitting values that are not correct.

## Where Catalog fits

Catalog handles the supplier product-data layer that sits alongside your vendor master and operational systems. Given supplier files or application programming interfaces (APIs), we can help structure, normalize, enrich, validate, and expose live product records for storefronts, feeds, partner channels, and AI shopping surfaces. Our [product data integration guide](https://www.getcatalog.ai/blog/product-data-integration) shows the supplier-source-to-normalized-record pattern in more detail.

The boundary matters. Your ERP, MDM, procurement, or finance system remains the authority for supplier identity, tax, bank and payment information, contracts, qualification, risk screening, and vendor status. Catalog is not a vendor-master, procurement, sourcing, contract, risk, tax, payment-validation, or EDI-transaction platform.

Catalog can preserve the supplier ID and source provenance in a product record. It can keep the product's title, attributes, variants, images, identifiers, and channel fields ready for distribution. It should not overwrite the system that owns the supplier's legal or financial record. For a field map, see our [ecommerce product data guide](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) and [product data quality guide](https://www.getcatalog.ai/blog/product-data-quality).

## A practical vendor data management process

A useful process has six stages. Run them continuously, with more frequent checks for fields that change often.

### 1. Define domains, owners, and authoritative sources

Start with a field-level ownership map. Name an accountable data owner for each domain and a steward who handles day-to-day quality work. Record the authoritative source, allowed editors, approval rule, access level, and expected update cadence.

At minimum, document:

- which system creates and approves a supplier record;
- which fields are finance or compliance controlled;
- which team owns locations and supplier relationships;
- which system owns product specifications, content, price, availability, and media;
- what happens when two systems send conflicting values;
- when a record becomes approved, blocked, inactive, or archived.

This map prevents a downstream product layer from becoming an accidental vendor master and prevents a supplier spreadsheet from silently becoming the source of truth for payment or status fields.

### 2. Collect records through a consistent intake

Use a repeatable intake for vendor records and product records. The transport can be a supplier portal, file, API, electronic data interchange (EDI) message, partner exchange, or controlled manual import. The method matters less than the contract around it.

Capture the raw source payload and its provenance. Each intake should retain the source system or supplier, source record ID, received timestamp, locale, market, file or API version, and the person or process that approved the change. Keep vendor, location, product, offer, and transaction records distinguishable at ingestion.

For product information, define required and conditional fields by category. A furniture supplier may need dimensions, weight, material, finish, assembly, and packaging. An electronics supplier may need compatibility, power, ports, warranty, and included components. The supplier's raw value should remain available even after you map it to an internal field.

### 3. Match and deduplicate vendors and products separately

Entity matching asks whether two records refer to the same supplier or location. Product matching asks whether two records refer to the same trade item, variant, bundle, or pack. They need different rules.

For supplier records, compare legal names, addresses, tax or registration identifiers, locations, ownership relationships, and source IDs. For products, use the identifiers and relationships appropriate to the item, such as GTIN, MPN, brand, source SKU, variant ID, and parent-product relationship. Do not merge on a similar name alone.

Preserve the original IDs and the match decision. Keep a review queue for uncertain matches. A false merge can combine two suppliers' payment or compliance records. A false product match can join the wrong image, variant, price, or availability to an offer.

### 4. Normalize values and map schemas

Normalization makes a record predictable without erasing its source. Apply agreed formats for names, addresses, country and region codes, units, dates, currencies, locales, categories, and status values. Keep the source value and transformation rule so a steward can trace the output.

Product normalization usually adds category-specific attributes, variant relationships, packaging levels, media links, and destination mappings. Keep a product's internal taxonomy separate from a marketplace or shopping-channel taxonomy. A channel mapping is an output rule, not a replacement for the internal model.

GS1 standards can support product-data exchange. The [GS1 Global Data Model](https://ref.gs1.org/standards/gdm/) defines shared product attributes, and [GS1 GDSN network](https://www.gs1.org/services/gdsn) provides a network for exchanging item and party information between trading partners. GDSN is a product and party-data exchange mechanism. It does not replace your procurement, finance, vendor-risk, or performance records.

### 5. Validate, approve, and route exceptions

Run quality checks before publishing a record. For vendor data, validate required fields, accepted formats, duplicate status, approval state, effective dates, relationship logic, and the presence of required evidence. Sensitive tax and payment fields should follow the controls owned by finance and compliance.

For product data, validate required and conditional attributes, identifier format and uniqueness, unit and currency rules, variant relationships, image URLs, category mapping, and freshness of price and availability. Keep changing commercial values tied to the system that owns them.

Track at least six quality dimensions: completeness, accuracy, consistency, timeliness, validity, and uniqueness. [ISO 8000-61 standard](https://www.iso.org/standard/63086.html) provides a process reference model for data-quality management. It supports governance and maturity work without prescribing one universal vendor or product schema.

Every failed check should produce an actionable exception with a reason, source record, owner, priority, and next step. Route a missing supplier certification to the responsible supplier or compliance owner. Route an incomplete product attribute to the supplier or product-data steward. Do not fill factual gaps with guesses.

### 6. Publish by domain and monitor the result

Publish approved vendor records to the ERP, MDM, procurement, finance, or other systems that own supplier operations. Publish approved product records to the PIM, catalog, feeds, partner channels, storefronts, and AI shopping surfaces that consume them. Publish transactions through the operational system that creates them.

Publishing is distribution. It does not transfer ownership. Store the publication time, destination response, record version, warnings, rejections, and retry state. Monitor freshness by field, not only by job status. A successful file transfer can still contain a stale price, missing image, rejected identifier, or inactive product.

For channel delivery, [product feed management](https://www.getcatalog.ai/blog/product-feed-management) covers the destination-specific work. The normalized product record should remain upstream so you can produce multiple outputs without rebuilding supplier data for every channel.

## Supplier product data checklist

Use this checklist before you connect a new supplier, load a large supplier file, or change the downstream systems that consume product records.

### Scope and ownership

1. **Define the record domains.** Separate supplier, location, product, offer, transaction, and reference records.
2. **Name an owner and steward.** Assign accountability for each domain and for high-impact fields.
3. **Declare the source of truth.** Document the authoritative system, approved writers, approval path, and update cadence for every important field.
4. **Set access controls.** Restrict tax, payment, risk, and other sensitive fields to the teams and systems that own them.

### Intake and identity

5. **Create an intake contract.** List required, conditional, and optional fields, accepted formats, locales, units, and file or API expectations.
6. **Capture provenance.** Retain source system, supplier ID, source record ID, received time, version, and approval evidence.
7. **Preserve identifiers.** Keep internal IDs, supplier IDs, GTINs, MPNs, GLNs, and variant IDs in fields that reflect their defined roles.
8. **Model relationships.** Link a supplier to its locations and products without folding those records into one master object.

### Quality and operations

9. **Match and deduplicate by domain.** Use entity rules for vendors and product rules for trade items, then review uncertain matches.
10. **Normalize without erasing source values.** Standardize names, units, codes, categories, attributes, and locales while keeping the original value and rule.
11. **Validate before publication.** Check completeness, formats, uniqueness, relationships, identifier accuracy, media, and freshness.
12. **Route exceptions to a named owner.** Store the reason, source, priority, due date, and resolution for each failed check.
13. **Publish to the right destination.** Send vendor records to master systems, product records to catalog and commerce systems, and transactions to operational systems.
14. **Monitor downstream use.** Track acceptance, rejection, stale fields, channel warnings, retry state, and whether the published record matches its source.
15. **Review the model as the business changes.** Add fields and rules when categories, markets, suppliers, regulations, or channels change.

## Measures that show whether the process works

Choose measures that expose ownership and risk. The useful baseline depends on your data model and category mix.

| Measure | What it reveals |
| --- | --- |
| **Completeness by record type** | Whether required supplier, location, product, and offer fields are populated |
| **Duplicate and uncertain-match rate** | Whether matching rules are creating duplicate or incorrectly merged records |
| **Exception rate and resolution time** | Where quality work accumulates and how quickly owners close it |
| **Freshness by field** | Whether price, availability, certifications, contacts, and other time-sensitive values meet their cadence |
| **Channel rejection rate** | Whether product outputs meet each destination's format and quality rules |
| **Time to channel-ready product data** | How long it takes an approved supplier product to become usable downstream |
| **Systems aligned to the approved record** | Whether the trusted view is reaching the processes that need it |

Treat these as operating measures, not guaranteed business outcomes. A lower duplicate rate is useful only if the matching decisions remain accurate. A fast product handoff is useful only if the resulting record passes validation and stays fresh.

## Choose systems without blurring ownership

A vendor-data stack works when each system has a defined job.

| System or layer | Best fit | Boundary to keep clear |
| --- | --- | --- |
| **Catalog** | Supplier product data that needs normalization, enrichment, validation, live sync, and delivery to commerce or AI shopping surfaces | Does not own vendor legal identity, finance, contracts, risk, tax, payment, or procurement workflows |
| **ERP, MDM, procurement, or finance system** | Supplier identity, locations, approvals, payment, tax, purchasing, and financial controls | May hold product or material data, but product-content operations may need a separate layer |
| **PIM or catalog management system** | Product content, attributes, taxonomy, workflow, and localization | Does not automatically resolve vendor identity or operational transactions |
| **Feed or syndication system** | Destination-specific files, APIs, mappings, and channel diagnostics | Is an output layer, not the master record for supplier or product truth |

If supplier product data is the bottleneck, Catalog can sit beside the system that owns your vendor master. Start with the authoritative vendor and finance workflows, then connect the product-data layer without changing that ownership.

## FAQs

### What is vendor master data management?

Vendor master data management is the discipline of creating and maintaining trusted supplier and supplier-location records across systems. It covers collection, standardization, matching, approval, publication, and monitoring. It keeps shared supplier identity consistent for procurement, finance, operations, and reporting.

It is one part of broader vendor management. Purchase orders, invoices, contracts, risk reviews, and performance events reference the master record, but they are separate workflows and transaction domains.

### How is vendor data management different from vendor management?

Vendor management covers the relationship lifecycle, from sourcing and qualification through contracts, performance, renewal, and offboarding. Vendor data management keeps the records used by those activities consistent and governed.

A data process can show that a supplier is approved and active. It cannot, by itself, approve a contract or perform a risk review.

### What information belongs in a supplier record?

A supplier record usually contains business identity, internal IDs, locations, contacts, ownership relationships, tax and payment fields, certifications, status, effective dates, and performance or risk references. The exact fields depend on the supplier type and the systems that use the record.

Product titles, attributes, variants, images, and trade-item identifiers belong in product records. Price, availability, lead time, orders, invoices, and payments belong to the systems that own those operational values.

### Who owns vendor data?

There is no universal owner for every field. Procurement, finance, MDM, or supplier operations commonly own supplier identity and status. Product, ecommerce, PIM, or catalog teams commonly own product content and channel readiness. Suppliers remain important sources for the facts they provide.

Name one accountable owner and one operational steward for each domain. Then document the authoritative source and the escalation path when two systems disagree.

### Does GDSN manage all vendor data?

No. GDSN uses certified data pools and a registry to exchange standardized item and party information between trading partners. GS1's [GDSN process guide](https://support.gs1.org/support/solutions/articles/43000734282-how-does-the-gdsn-work-) describes preparation to GS1 standards, upload, subscription, and ongoing synchronization.

GDSN can support product and party-data exchange. It does not replace internal records for contracts, tax, bank and payment details, supplier qualification, risk, performance, or procurement transactions.

### Is vendor data management the same as supplier data management?

The terms often describe the same business need. “Supplier” and “vendor” can refer to the same business relationship, depending on the organization's language. Define the record domains and system boundaries so the label does not hide different responsibilities.

For an ecommerce operation, the important distinction is between the supplier's business record and the products that supplier provides. Keep both linked and governed, with separate owners and update rules.

## Put the boundary into practice

A trustworthy vendor record gives the business a stable identity. A trustworthy supplier product record gives every commerce surface accurate facts about what is available to buy. They work together when ownership, identifiers, quality rules, and publication paths remain explicit.

If supplier files or APIs are slowing product launches and channel updates, [connect product data with Catalog](https://www.getcatalog.ai/blog/product-data-integration). Keep your ERP, MDM, procurement, and finance systems authoritative for the vendor master, and give product data the layer it needs to stay structured, current, and machine-readable.

---

Canonical: https://www.getcatalog.ai/blog/vendor-data-management
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# EDI Onboarding: A Supplier Readiness Checklist for a New Trading Partner

*October 7, 2026 · Catalog Team · Product Data · 16 min read*

> Use this EDI onboarding checklist to separate supplier, item, partner, and technical gates, then prepare data, test, certify, and cut over.

EDI onboarding is often treated as a connection project. A supplier can have an approved contract and a working EDI mailbox while its items still fail validation. It can also have clean product data while its trading-partner agreement or test certification is unfinished.

Keep those gates separate. This guide shows how to qualify the supplier, set up the trading partner, approve product and reference data, implement the partner's EDI requirements, and move into production with clear owners. Catalog fits one part of that process: the product-data readiness layer before an EDI team maps and tests transactions.

## What EDI onboarding includes

EDI onboarding is the process of preparing, connecting, testing, and launching a standardized exchange of business documents between two trading partners. The exact sequence depends on the buyer, supplier, industry, geography, EDI standard, and internal systems. [IBM's EDI onboarding overview](https://www.ibm.com/think/topics/edi-onboarding) describes the recurring work as agreement, specification exchange, setup, mapping, testing, launch, and monitoring.

A supplier readiness plan should show four related tracks rather than one status:

| Track | Main question | Typical owner | Exit evidence |
| --- | --- | --- | --- |
| **Supplier qualification** | Is this company approved to do business with us? | Procurement, legal, finance, quality, or compliance | Approved supplier record, agreements, required tax, insurance, and compliance documents |
| **Trading-partner setup** | Are both parties configured to exchange information under agreed commercial and operating rules? | Partner enablement, procurement, account team, or EDI program lead | Trading-partner agreement, contacts, IDs, facilities, scope, cutover date, and escalation path |
| **Product and item approval** | Can the buyer identify, classify, buy, receive, and pay for each item? | Merchandising, master data, item setup, supply chain, or product compliance | Approved item records, identifiers, pack hierarchy, commercial values, and location data |
| **Technical EDI implementation** | Can the systems exchange the required documents and process them correctly? | EDI, integration, ERP, WMS, finance, and operations teams | Current maps, connectivity, test evidence, partner certification, runbook, and monitoring |

These tracks depend on each other, but they do not finish at the same time. A contract does not approve an item. A successful connectivity test does not prove that an invoice will match a purchase order. A product record does not create a trading-partner agreement.

A retailer's own onboarding material shows why the distinction matters. Walmart's [supplier checklist](https://corporate.walmart.com/content/dam/corporate/documents/suppliers/apply-to-be-a-supplier/supplier-checklist.pdf) separates product submission, supplier agreements, EDI-B2B setup, banking, logistics, and item setup. Use the specific partner's workflow as the source of truth for your project.

## Make product and reference data the preflight gate

Resolve product and reference data before final mapping or certification. EDI can transport a value accurately and still deliver the wrong outcome when the value is wrong, ambiguous, or attached to the wrong level of the product hierarchy.

A supplier SKU that does not match the buyer's item number can cause a purchase-order line to fail. A case pack recorded as an each can distort the order quantity. A ship-to location with the wrong party identifier can route an otherwise valid shipment incorrectly. A missing pack relationship can make an advance ship notice impossible to reconcile with the physical cartons.

GS1's implementation guidance puts business-process selection, gap analysis, and master-data alignment before message exchange. Its [identification-key reference](https://www.gs1.org/standards/id-keys) distinguishes the roles of GTIN for products, GLN for parties and locations, and SSCC for logistics units. The partner may use other identifiers or rules, so treat these as reference concepts until the partner guide confirms them.

### Product-data preflight checklist

Use one approved record per sellable item and document the source and owner for every value. At minimum, reconcile:

- **Identity:** supplier SKU, buyer item number, GTIN or UPC where required, manufacturer part number, brand, variant ID, and parent-child relationships.
- **Identifiers:** the party and location IDs for supplier, buyer, ship-from, ship-to, bill-to, and remit-to entities. Record the lifecycle and owner for each ID.
- **Attributes:** title, product type, category, dimensions, weight, material, color, size, compatibility, country of origin, and any category-specific fields the partner requires.
- **Packaging:** each, inner, case, pallet, and other pack levels; quantities at each level; pack-level identifiers; and the rules for mixed or variable packs.
- **Units and codes:** order, sales, shipping, and pricing units; conversion factors; currency; country; dates; and any partner code lists or qualifiers.
- **Commercial values:** cost or price, price basis, availability, lead time, effective dates, minimum order quantity, and order multiples where applicable.
- **Logistics:** ship-from locations, delivery locations, weights and dimensions, lot, serial, or expiry fields, label requirements, and the process for assigning an SSCC if the partner requires one.
- **Evidence:** approved item file, cross-reference table, sample records, source-system owner, last approval, and change history.

The gate is ready when each in-scope item can be identified at the same level in the supplier, buyer, ERP, warehouse, and EDI records. Do not use a mapping rule to hide an unresolved identity conflict. Fix the source record or record an explicit, approved crosswalk first.

Catalog belongs at this gate. We help teams structure and normalize product records, identifiers, attributes, variants, and relationships so the approved data can be handed to downstream systems. Read our guides to [product data integration](https://www.getcatalog.ai/blog/product-data-integration), [PIM integration](https://www.getcatalog.ai/blog/pim-integration), and [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) for the surrounding product-data workflow.

Catalog does not provide EDI connectivity, translate partner-specific segments, manage procurement or tax and payment setup, or certify a trading partner. Your EDI provider, integration team, finance and operations teams, and the trading partner own those steps. Clean product data reduces uncertainty at the handoff. It does not replace the partner's guide or approval.


## Build the partner-specific implementation packet

Collect the current documents before anyone configures a map. A generic X12 or EDIFACT reference explains the standard. The partner's implementation guide explains the version, profile, required fields, codes, conditions, and business rules that will be tested.

Your packet should include:

- The trading-partner agreement and any operational, security, confidentiality, or compliance terms.
- The current implementation guide, version, profile, change notices, and companion routing, packaging, label, or invoice rules.
- Transaction scope, direction, frequency, mandatory documents, business events, and data requirements for items, parties, locations, units, prices, packaging, and shipment references.
- Transport and security requirements, such as AS2, SFTP, VAN, API, certificates, credentials, sender and receiver IDs, and acknowledgment expectations.
- Test cases, rejection criteria, certification steps, production timing, document cutoffs, fallback process, support hours, and escalation contacts.

Version this packet with a date and owner. If a partner sends an updated guide, compare the new requirements with the approved map and data model. Never assume that a newer standard release or another retailer's guide is interchangeable.

## Define transaction scope before mapping

Transaction names are useful examples, not a universal onboarding list. The buyer and supplier decide which documents, versions, directions, and qualifiers apply. [X12's transaction-set catalog](https://x12.org/products/transaction-sets) and [supply-chain flow](https://x12.org/flow/supply-chain) describe the purpose of common sets, while the partner guide controls your implementation.

| Partner-governed example | Possible role in the flow | Readiness questions |
| --- | --- | --- |
| **832 Price/Sales Catalog** | Send or receive item and price catalog information when the partner uses it for that purpose | Which item levels, prices, units, effective dates, and identifiers are required? Is this a catalog exchange or a separate item-setup process? |
| **850 Purchase Order** | Buyer sends an order to the supplier | Which order identifiers, line references, units, dates, locations, and change rules must the supplier process? |
| **855 Purchase Order Acknowledgment** | Supplier acknowledges, accepts, rejects, or changes an order when the partner requires it | What responses are allowed? Which quantities, dates, substitutions, or exceptions need explicit codes? |
| **856 Ship Notice/Manifest and SSCC** | Supplier communicates shipment and package hierarchy; an SSCC can identify a logistics unit when the partner requires it | Is the notice at shipment, pallet, case, or item level? How must cartons and labels map to the notice? |
| **810 Invoice** | Supplier sends invoice information for delivered goods or services | Which order, receipt, tax, allowance, currency, and line identifiers must match before the invoice can be processed? |
| **997 Functional Acknowledgment or 999 Implementation Acknowledgment** | Receiver reports a defined level of syntax, control, or implementation validation | Which acknowledgment is expected, by when, and what system or person owns a rejection? |

A 997 or 999 is an important control signal. It is not the same as business acceptance. X12 describes a 997 as reporting syntactical analysis and a 999 as reporting syntactical and relational analysis for an implemented subset. Neither alone confirms that an item was approved, a shipment was received, or an invoice will be paid.

Write the scope as a flow, with owners and timing. For example, the partner may send an 850, expect an 855, require an 856 before arrival, and require an 810 that matches the order and receipt. That is a project-specific example. Do not turn it into a default sequence for every supplier.

## Map fields, rules, and ownership

Mapping is translation between your source systems and the partner's implementation guide. It includes more than placing a column in a segment. It defines which source value is used, which partner code or qualifier accompanies it, when a field is required, and what happens when the value is missing or ambiguous.

Create a mapping workbook or equivalent controlled record with these columns:

| Mapping record | What to document |
| --- | --- |
| Source field and system | The ERP, PIM, WMS, finance, or master-data field that owns the value |
| Partner field | The transaction, loop, segment, element, qualifier, or code expected by the guide |
| Rule | Required, conditional, optional, repeatable, or prohibited |
| Transformation | Unit, date, code, rounding, truncation, concatenation, or cross-reference logic |
| Example and edge case | A normal value, missing value, long value, zero value, and boundary case where relevant |
| Owner and escalation | The team that corrects the source, mapping, partner rule, or physical process |
| Version and approval | Map version, guide version, approver, effective date, and change record |

Keep supplier SKU, buyer item, GTIN, and pack-level IDs in a governed cross-reference. Do not put a person-dependent lookup in a spreadsheet that has no owner or history. Test the cross-reference with the same item at each level used in the order, shipment, and invoice flow.

Catalog can supply a cleaner product-data handoff. It does not decide how a partner's EDI segments, envelopes, credentials, or acknowledgments are mapped. Keep that responsibility with the EDI implementation team and partner.

## Test in layers, then certify

A single file that passes a parser is not an end-to-end test. Test from the transport boundary through the operational outcome, and preserve the evidence for each layer.

### Layer 1: Connectivity and control

Confirm the agreed transport in the test environment. Exchange the required test message, verify receipt or delivery response, confirm sender and receiver IDs, and keep test and production credentials, endpoints, and files separate.

### Layer 2: Syntax and envelope

Validate delimiters, envelopes, control numbers, versions, segment order, data types, code values, required fields, and character rules. Confirm that acknowledgments reach the right owner.

### Layer 3: Partner rules and mapping

Use the implementation guide to test required loops, qualifiers, conditional fields, code lists, item cross-references, units, dates, and totals. Include accepted and intentionally rejected files.

### Layer 4: Representative products and edge cases

Test variants, pack levels, long descriptions, multiple units, backorders, partial quantities, substitutions, price changes, multiple ship-to locations, and applicable labels or packaging. Choose examples with warehouse and finance teams.

### Layer 5: End-to-end business flow

Run the full partner-approved sequence across EDI, ERP, WMS, order management, finance, and support. One project might connect an 850 to an 855, use an 856 with package and SSCC data, then produce an 810 that matches the order and receipt.

### Layer 6: Exceptions and recovery

Force no acknowledgment, rejected code, duplicate control number, delayed file, invalid item, changed quantity, mismatched unit, missing carton, invoice variance, and endpoint outage. Test retry, quarantine, correction, replay, duplicate prevention, and escalation.

### Layer 7: Partner certification

Submit evidence in the partner's format and record each scenario, file, response, defect, retest, and approval. Certification is complete only when the partner or designated program owner confirms the agreed scope.

GSA Global Supply offers a concrete example of a partner-governed process: a vendor completes a survey, attends a kickoff, provides a test catalog, participates in active testing, and receives validation before being treated as a certified EDI vendor. Read the [GSA onboarding process](https://www.gsa.gov/buy-through-us/purchasing-programs/requisition-programs/gsa-global-supply/doing-business-with-global-supply/electronic-data-interchange) as an example of a specific program, not a universal requirement.

## Cut over with control

Plan cutover as an operational change, not a switch that happens when the map is marked complete.

Before production, confirm:

- The partner has approved the scope, test evidence, production endpoint, credentials, version, and effective date.
- Production maps, cross-references, code lists, and configuration are versioned and reviewed.
- The product and location records in production match the certified test data, or any differences have been approved and retested.
- Warehouse, customer service, finance, procurement, and support teams know the first-live order, shipment, invoice, and escalation process.
- The team has a rollback or manual fallback plan, a queue-replay rule, and a named decision maker for pausing traffic.
- Test documents cannot be sent to production and production documents cannot be mistaken for test files.

Start with a controlled window and close observation of the first production messages. Reconcile the EDI record with the business record, physical shipment, acknowledgment, and downstream posting. Keep a manual check for the first agreed set of transactions, then remove it only when the owner and partner accept the operating evidence.

## Monitor acknowledgments and own exceptions

Monitoring should track the business signal as well as the file signal. A message that arrived at the endpoint may still be rejected by an application or fail to update an item, order, shipment, or invoice.

Track at least:

- documents sent and received by transaction and partner;
- acknowledgment status, latency, and rejection reason;
- missing or duplicate control numbers and business references;
- item, unit, location, price, quantity, tax, and total mismatches;
- ASN, package, label, and physical-receipt differences;
- invoice exceptions and time to resolution;
- retries, quarantined documents, replayed documents, and manual overrides;
- guide, map, code-list, item, and location changes awaiting approval.

Assign one owner for every failure class. A product identifier or attribute error belongs with product or master data. A segment, qualifier, envelope, or map error belongs with EDI or integration. A package or label mismatch belongs with warehouse and logistics. An invoice or tax discrepancy belongs with finance and the partner's accounts-payable process. A supplier qualification or compliance issue belongs with procurement, legal, or quality. Catalog can support the product-data layer, but it does not own the connection, partner certification, procurement decision, tax treatment, payment setup, or operational response.

## Final supplier readiness checklist

Use these four exit gates in the project review:

| Gate | Ready when |
| --- | --- |
| **Qualification and partner setup** | Supplier approvals, agreements, contacts, IDs, facilities, scope, cutoffs, and the current guide have named owners and approvals. |
| **Product and reference data** | Every item has an approved cross-reference, consistent variants, packs, units, prices, locations, codes, and a change path. |
| **Technical implementation and test** | Scope, transport, maps, envelopes, acknowledgments, error routes, layered test evidence, and partner certification cover the versions going live. |
| **Go-live and operations** | Production and test are separated, the cutover window and monitoring are scheduled, and owners can stop, correct, retry, replay, and escalate failures. |

## Common EDI onboarding failure points

**Starting with connectivity.** A working mailbox does not repair duplicate SKUs, wrong pack quantities, or missing location IDs. Make the product and reference-data gate explicit.

**Treating a standard as a contract.** Transaction names do not tell you every partner condition. Use the current guide, companion documents, and written clarifications.

**Reading an acknowledgment as acceptance.** A 997 or 999 reports a defined technical result. Check application responses and business reconciliation.

**Testing only the happy path.** One simple item and one complete shipment will not expose pack, unit, partial, duplicate, timing, or correction problems. Test exceptions and recovery.

**Leaving ownership unmanaged.** Give cross-references, map changes, guide updates, and post-go-live rejects an owner, version, approval path, and review cadence.

## FAQs

### Is EDI onboarding the same as supplier onboarding?

No. Supplier onboarding qualifies the business and establishes its commercial relationship. EDI onboarding configures the electronic exchange and its operating controls. Product and item approval is a related gate that makes individual products sellable and processable. One supplier project may include all three, with different owners and evidence.

### Do all suppliers need an 832, 850, 855, 856, 810, 997, or 999?

No. These are common X12 examples, not a default bundle. The trading partner decides which transactions, versions, directions, profiles, labels, acknowledgments, and tests apply. A partner may use a subset, another standard, or a portal instead of one or more exchanges.

### Can we start EDI mapping before product data is approved?

You can review the guide and draft a mapping, but do not treat the map as ready for certification while item identity, pack hierarchy, units, prices, locations, or cross-references are unresolved. Mapping depends on those values. Resolve the data gate first, then certify with representative records.

### Does a 997 or 999 mean the order, shipment, or invoice was accepted?

No. It reports the type of technical or implementation validation defined by the acknowledgment. The partner's application response, item or order status, receiving result, invoice match, or written confirmation provides the business outcome.

### What is Catalog's role in EDI onboarding?

Catalog is a product-data readiness layer. It can help teams structure and normalize item information before the records are handed to an EDI implementation. Catalog is not an EDI network, mapping service, procurement or tax system, payment setup, or partner-certification authority. Use the resulting data with the systems and teams that own those functions.

### Who owns an EDI failure after go-live?

The owner depends on the failure class. Product and master data own item and attribute errors. EDI and integration own transport, envelope, map, and code errors. Warehouse and logistics own package, label, and shipment discrepancies. Finance owns invoice, tax, and payment-process exceptions. Procurement, legal, quality, and the partner own qualification and compliance decisions. Name those owners before cutover.

When product data is the slowest gate, make it visible and govern it before the EDI project reaches mapping. Catalog can help your team prepare that handoff through [product data integration](https://www.getcatalog.ai/blog/product-data-integration), then your EDI and trading-partner teams can connect, test, certify, and operate the exchange they own.

---

Canonical: https://www.getcatalog.ai/blog/edi-onboarding
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Google Merchant Center feed: a product-data-first setup guide

*October 7, 2026 · Catalog Team · Product Data · 13 min read*

> Set up a Google Merchant Center feed from clean product data, map variants, read diagnostics, separate processing from approval, and keep offers fresh.

A Google Merchant Center feed is the handoff between your product data and Google's commerce systems. A successful fetch can still produce the wrong variant, a stale price, or a product that never becomes visible. The fix starts upstream. We treat the feed as an output of a normalized product record, then use Merchant Center to validate delivery, processing, eligibility, and freshness. Here is how to choose a source, map products and variants, troubleshoot failures, and keep the data current.

## Start with product truth, not a feed file

A product feed is a destination-specific representation of your catalog. It is usually a file, a spreadsheet, an ecommerce-platform connection, or API input. A product data source is the registered path through which Merchant Center receives that representation.

The source should not become your master catalog. Keep a canonical record upstream with clear ownership:

- your ecommerce platform or ERP for price, inventory, and the live product URL;
- a PIM or approved content system for titles, descriptions, and category attributes;
- a DAM for approved images and video;
- supplier or manufacturer records for specifications;
- a product data layer for normalized values, provenance, and channel outputs.

This separation prevents a manual correction in one Google file from becoming a second, ungoverned version of a product. It also gives you one record to reuse for marketplaces, structured product data, internal search, and AI shopping surfaces.

## Choose the source that matches your operating model

Merchant Center supports several ways to add products. The right choice depends on where your product data is governed and how quickly it changes.

| Source | Use it when | Main risk to control |
| --- | --- | --- |
| Connected ecommerce platform | Your storefront is complete, structured, and already owns the product record | Connector mappings and sync delays can hide missing attributes |
| Hosted file, such as CSV, TSV, or XML | Your pipeline can produce a complete, validated catalog snapshot | A broken URL, permission, delimiter, or schema change can stop a refresh |
| Google Sheets | A small team manages a small catalog with infrequent changes | Manual edits and sharing permissions create drift |
| Merchant API | You have engineering ownership and frequent product or inventory changes | Accepted API input still needs processing and approval |
| Automatic website discovery | Your product pages expose reliable structured data and you want Google to find products from the site | Google can only extract what the pages and markup make explicit |

Google documents these methods in its [product upload guide](https://support.google.com/merchants/answer/11586438). A connector can be the right choice for a simple store. A normalized file or the Merchant API gives you more control when multiple systems contribute to one product record. Use one deliberate owner for each item. Running a connector, an automatic source, and a separate primary feed for the same products makes source precedence harder to reason about.

For a primary source, send the full set of active products you want Google to manage. Google recommends using one primary source for your products. A primary source can add or remove products, set language and country targeting, and apply data rules. If a product disappears from the latest primary snapshot, treat that as a product-removal event in your pipeline and alert on unexpected row-count drops.

## Build one normalized row per sellable variant

Google needs product attributes. Your systems usually store them in different shapes. Normalize them before mapping to feed columns or API fields.

At minimum, give every active item a stable identity and a complete offer:

| Product-data layer | Google feed fields | What to keep stable |
| --- | --- | --- |
| Identity | `id`, `brand`, `gtin`, `mpn` | The ID must continue to identify the same sellable item |
| Content | `title`, `description`, `link` | Copy and URL should describe the same product or variant |
| Offer | `price`, `availability`, `condition` | Currency, stock state, and condition must match the offer a shopper can buy |
| Media | `image_link`, `additional_image_link` | The primary image must represent the submitted item |
| Taxonomy | `product_type`, `google_product_category` | Map only after your internal category is controlled |
| Variant relationship | `item_group_id`, `color`, `size` | The parent relationship and option values must be explicit |

These attributes are part of Google's [product data specification](https://support.google.com/merchants/answer/7052112). Requirements vary by product and destination, so carry the target country and marketing method alongside the product record.

Consider a waterproof commuter jacket with a navy, medium variant. The normalized record should make these relationships explicit:

```text
product_id: northline-commuter-jacket
variant_id: northline-commuter-jacket-navy-m
sku: NL-JKT-NVY-M
item_group_id: northline-commuter-jacket
brand: Northline
title: Northline Waterproof Commuter Jacket, Navy, Medium
color: navy
size: M
price: 148.00 USD
availability: in_stock
link: https://example.com/products/northline-commuter-jacket?variant=navy-m
image_link: https://example.com/images/northline-jacket-navy-m.jpg
```

The `id` in the output should identify the sellable variant, not only the product family. The `item_group_id` joins variants that shoppers understand as one product. Price, inventory, image, URL, and identifiers belong to the variant whenever they differ.

Do not use a title to infer relationships. A navy medium jacket and a navy large jacket need separate offer states even when they share a product page. A two-pack is a different offer from a single unit. An accessory is a related product, not a variant. Your canonical model should represent those distinctions before Google receives the data.

## Register and submit a primary data source

In Merchant Center, open **Settings → Data sources → Product sources → Add product source**. Choose the method that owns your normalized output, then set:

1. target countries;
2. content language;
3. data source label, when you need country or campaign grouping;
4. marketing methods and destinations;
5. the source name and file name, if the method requires them.

The [data source setup instructions](https://support.google.com/merchants/answer/14990942) list the current fields and source types. A file URL must point directly to the data file. It cannot point to a page that renders the file in HTML. The file also needs the exact filename and extension configured in Merchant Center when you use SFTP or a similar upload path.

Before the first submission, validate a sample and the whole export:

- every row has a unique, stable `id`;
- each variant has the right parent relationship and option values;
- every URL resolves to the matching product or variant page;
- price, currency, availability, and condition are internally consistent;
- image URLs are reachable and match the item;
- delimiters, headers, encodings, and line breaks are valid;
- target country and language rules are applied to the right records.

For scheduled files, give Google's crawlers access to the file and its directory. Google says scheduled files must be smaller than 4 GB, must not block `Googlebot` or `AdsBot-Google`, and must use a supported file format. Configure the [fetch schedule](https://support.google.com/merchants/answer/14991445) after the export is ready so the first scheduled fetch does not capture an intermediate file.

A supplemental source can add or override fields on products that already exist in a primary source. It cannot add or remove products on its own. Keep it as a controlled overlay for a narrow need, such as a custom label or a fast price and availability update. The primary record and its stable ID remain the join layer.

## Separate submission, processing, approval, and visibility

These are different states. Treating them as one status is the source of many false success reports.

| State | What it proves | What it does not prove |
| --- | --- | --- |
| Submitted or fetched | Merchant Center received the file or API input | The row parsed correctly or the product can serve |
| Processed | Google parsed the item and produced a product record | The item passed policy, landing-page, or image review |
| Approved | The product data is eligible for a destination | The product is currently visible in every destination |
| Visible | The product is appearing in the selected surface | The source will stay current or the offer will remain in stock |

For file sources, the **Latest update** report shows the upload status, attribute problems, and file-level issues. Google says this report checks basic file and data problems. The **Products → Needs attention** area contains the broader set of product and account issues.

The same distinction applies to API integrations. A successful `productInputs.insert` call means the input was accepted and processing started. It does not mean Google approved the product. The [Merchant API product guide](https://developers.google.com/merchant/api/guides/products/add-manage) exposes the processed product and its status separately.

An item can also be approved and still not be visible. Google's product table separates **Status** from **Visibility**. A product may have approved data while another destination, account, policy, or store-availability issue prevents it from appearing. Read both fields before changing a feed that already processed successfully.

## Diagnose from the source outward

Start with the earliest failed stage. Do not rewrite titles when Google never fetched the file.

| Symptom | Inspect first | Practical correction |
| --- | --- | --- |
| Fetch or upload failed | URL, permissions, file extension, response content, SFTP filename, crawler access | Return the raw file directly, fix access, and publish a complete valid file |
| Processing errors | Header names, delimiter count, line breaks, encoding, required fields, invalid values | Validate the whole file before resubmitting; include a known-good row and a variant in validation |
| Products missing | Primary-source snapshot, IDs, exclusions, target country, source ownership | Compare expected IDs with the submitted snapshot and investigate unexpected removals |
| Wrong variant or image | `id`, `item_group_id`, `color`, `size`, variant URL, image URL | Map each sellable item as its own row and keep option values and media aligned |
| Price or availability disapproval | Product page, structured data, checkout, currency, shipping context | Reconcile the same offer across feed, page, structured markup, and checkout |
| Approved but not visible | Visibility, destination, account diagnostics, policy, store availability | Fix the visibility blocker instead of resubmitting unchanged data |
| Stale image or offer | Last update, source fetch time, image crawl, cache, upstream publish time | Measure the full lag and shorten the slowest step |

Google's [data-source troubleshooting guide](https://support.google.com/merchants/answer/13760862) recommends starting with the source's processing report. For price and availability, compare the row with the landing page and checkout. Google's landing-page requirements say the product page should clearly show the title, description, image, price, currency, availability, and a way to buy the submitted product or variant. A valid file cannot repair a page that shows a different offer.

Record each failure with the source version, product ID, variant ID, timestamps, processing result, status, visibility, and owner. That turns a vague “feed issue” into a traceable data change.

## Set freshness by field risk

One schedule for every field is easy to administer and wrong for most catalogs. Price and availability can change several times in a day. Product copy and specifications usually change through an approval workflow. Images change when a new asset is approved.

Set refresh targets by risk:

- **Price, availability, and inventory:** event-driven updates or the most frequent reliable schedule your source supports.
- **New products and discontinued products:** publish as part of the primary catalog snapshot, with an alert for unexpected additions or removals.
- **Titles, descriptions, and attributes:** update after approval, then on a predictable daily or event-based cadence.
- **Images:** update after asset approval and URL validation. Keep the old image available until the new URL is reachable.
- **Country, language, and destination settings:** change through controlled configuration, followed by a targeted diagnostic review.

Record four timestamps for every important item: source update, output publish, Merchant Center fetch, and processed-product update. The gap between them is your freshness lag. Alert when it exceeds the promise you make to shoppers or when the primary file's row count changes sharply.

A scheduled file is not real-time delivery. An API can accept an update quickly, while the processed product still takes time to appear. Google also says new products can take up to two days to appear after submission in some data-source setups. Build monitoring around observed processing and visibility, rather than promising an instant change after upload.

## Where Catalog fits

Merchant Center is a channel destination. Catalog is the product-data layer upstream of that destination.

We help brands collect product facts from their existing systems, normalize identities and variants, enrich missing structured attributes, keep records synchronized, and publish live machine-readable product objects to AI commerce surfaces. That same normalized record can feed a Google output without turning Google into the place where product truth is maintained.

Use a feed-management workflow when your source data is already reliable and you mainly need destination mapping. Use Catalog when the underlying problem is that product data is fragmented, thin, inconsistent across variants, or difficult for AI systems to interpret. Catalog works beside your storefront, PIM, ERP, DAM, and channel feeds. It gives each output a better-controlled product record to consume.

For a broader view of the source-to-channel model, read our guide to [ecommerce product data](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai). For channel mapping and ongoing distribution, see [product feed management](https://www.getcatalog.ai/blog/product-feed-management). Those are separate concerns from the Google source lifecycle described here.

## FAQ

### Is a Google Merchant Center feed the same as a data source?

A feed is the product data you send. A data source is the registered method Merchant Center uses to receive it, such as a file, Sheet, connected platform, or API. One source can receive repeated updates.

### Why did my feed process successfully while products remain disapproved?

Processing validates the file and basic product data. Approval also considers product policies, landing pages, images, price, availability, and other destination requirements. Start with **Products → Needs attention** and the item-level issue details.

### How often should a Google Merchant Center feed update?

Update price and availability as often as those values change. Refresh slower fields after approval or on a daily schedule. Choose the cadence that keeps the offer on Google aligned with the offer shoppers can buy.

### Should I use a supplemental source for my whole catalog?

No. A supplemental source is an overlay for products already present in a primary source. Keep the complete catalog and product lifecycle in the primary source, then use supplemental data for scoped additions or overrides.

A reliable Google Merchant Center feed starts upstream. [Run a Catalog audit](https://www.getcatalog.ai/audit) before you add another destination or another layer of manual fixes.

---

Canonical: https://www.getcatalog.ai/blog/google-merchant-center-feed
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Amazon product listing optimization starts with data readiness

*October 6, 2026 · Catalog Team · Product Data · 17 min read*

> A practical Amazon product listing optimization workflow covering product types, attributes, titles, images, variants, validation, and freshness.

An Amazon listing is a product record, an offer, and a set of assets that Amazon has to classify, validate, display, and keep current. Copy changes are only one part of that work. A missing identifier, wrong product type, broken variation relationship, stale quantity, or invalid image can matter as much as a weak title.

We treat Amazon product listing optimization as a data-readiness workflow. The process prepares the underlying record, writes the customer-facing fields, submits through Amazon's current schema-based workflows, and maintains the listing after it goes live.

At Catalog, we help teams [normalize and enrich product data](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) so channel outputs have explicit attributes, variant relationships, and freshness signals. Amazon still requires its own schema and validation rules.

## What Amazon product listing optimization includes

Amazon describes a listing as a product detail page paired with one or more seller offers. The detail page carries the product identity, content, attributes, and images. The offer carries information such as condition, price, fulfillment, and available quantity. Those layers are related, but they do not have the same owner, update cycle, or validation rules. See our [product listing glossary](https://www.getcatalog.ai/glossary/product-listing) for the broader ecommerce definition.

That distinction keeps the work focused:

- **Listing content** describes the product: title, bullets, Item Highlights, description, attributes, and images.
- **Catalog structure** tells Amazon what the product is: identifier, product type, category or browse path, and variation relationships.
- **Offer data** tells Amazon whether and how the product can be bought: price, condition, fulfillment, and availability.
- **Operations** keeps each layer valid as products, inventory, and Amazon's schemas change.

Advertising, account services, and listing tools can support the work. They do not replace a correct product record. The workflow below covers the listing and its source data. Run advertising and promotions separately.

## Build one channel-ready product record first

The most reliable workflow starts with a normalized source record and produces Amazon-specific output from it. Keep facts typed and traceable instead of burying every value in prose.

At minimum, the record should include:

- seller SKU, parent SKU, variant SKU, and internal product ID;
- brand, manufacturer, model or part number, and relevant GTIN or product identifier;
- Amazon marketplace, locale, product type, and category or browse classification;
- dimensions, weight, material, color, size, capacity, compatibility, components, and other product attributes;
- parent-child variation relationships and the values that define each child;
- title, feature facts, description, and Item Highlights source content;
- main and alternate image references with variant roles and provenance;
- offer price, currency, condition, fulfillment channel, available quantity, and release dates;
- source, owner, approval status, last-updated time, and validation status.

This is the same principle we use in [our product attributes guide](https://www.getcatalog.ai/blog/product-attributes-guide): attributes should be explicit, consistent, and reusable across downstream destinations. Amazon still gets its own channel mapping, because Amazon's field names, allowed values, and conditional rules are specific to the marketplace and product type.

![A shopper-facing product record connected to a structured product-data layer and downstream commerce systems](https://www.getcatalog.ai/images/blog/amazon-listing-data-layer.svg)

## 1. Match the product, marketplace, and type before editing copy

Start with identity. Search Amazon's catalog using the product identifier or relevant keywords. If the exact product exists, match the offer to the correct ASIN. Otherwise, prepare a new catalog item. Amazon's [listing lifecycle guide](https://developer-docs.amazon.com/sp-api/lang-en_US/docs/manage-product-listings-guide) frames this as discovery, creation, and maintenance.

Check these values together:

1. **Product identity.** A GTIN, UPC, EAN, JAN, or ISBN identifies the physical product when the category requires one. An ASIN is Amazon's catalog identifier. A seller SKU identifies your offer in your systems and Seller Central. They are not interchangeable.
2. **Marketplace and locale.** Requirements and allowed values can vary by Amazon store. Keep `marketplace_id` and language tags with every localized value.
3. **Product type.** Use Amazon's `searchDefinitionsProductTypes` recommendation or search workflow. The type controls the schema, attributes, and conditional rules that follow.
4. **Category and browse classification.** Select the path that describes the actual product. Do not choose a category because its fields look easier or because a keyword appears popular.
5. **Eligibility.** Existing ASINs can have listing restrictions. Check eligibility and condition requirements before preparing an offer.

If a product has no GTIN, use Amazon's eligibility process for a GTIN exemption. Do not create a number, reuse another product's identifier, or treat an exemption as a way to avoid identity controls. Amazon's [GTIN guidance](https://sell.amazon.com/blog/amazon-gtin-guide) explains the difference between global identifiers and Amazon's ASIN.

The practical output of this step is a product identity record with a marketplace, product type, category, and match decision. Do not write a title until those values are stable.

## 2. Use Amazon's product-type schema for required and conditional attributes

There is no universal Amazon attribute checklist. Required and conditional fields depend on the product type, marketplace, listing purpose, and variation level. The Product Type Definitions API returns a JSON schema with the attributes, constraints, and conditionality for a product type. Use it to validate a payload or map it to an ERP.

Call `getDefinitionsProductType` for the chosen product type and marketplace. For a listing with product facts and offer data, request `requirements=LISTING` and use the enforced requirements when appropriate. Cache the schema with its product-type version and refresh it when Amazon publishes a new version. The [Product Type Definitions API guide](https://developer-docs.amazon.com/sp-api/lang-en_US/docs/retrieve-a-product-type-definition) explains how to retrieve the schema document and its temporary links.

Map your source record into the schema's property groups. Common groups include:

| Data group | Typical fields | Readiness check |
| --- | --- | --- |
| Product identity | Brand, item name, manufacturer, model number, GTIN, item type | The value identifies this product and matches its evidence |
| Product details | Description, bullet points, material, color, size, capacity, compatibility | Values use the type's accepted format and controlled values |
| Offer | Condition, price, currency, fulfillment, quantity, release date | Offer values are current for this marketplace and SKU |
| Images | Main image, alternate images, swatch, safety or detail images | Every URL maps to the right product and image role |
| Shipping | Item dimensions, package dimensions, package weight | Units are normalized and match the physical item or package |
| Variations | Parentage level, parent SKU, relationship type, variation theme | The relationship and child values satisfy the selected theme |
| Safety and compliance | Batteries, hazmat, country of origin, warnings, certifications | Claims and compliance evidence are available before submission |

A field can be optional in one context and required after another value is selected. A variation theme can make color, size, or quantity mandatory. A battery flag or hazardous-material declaration can trigger compliance fields. Preserve these dependencies in validation instead of maintaining a static “required fields” spreadsheet.

For an item with no variation relationship, request the standalone schema with `parentageLevel=NONE`. For a parent or child, request the relevant `PARENT` or `CHILD` schema. This narrows the returned requirements and makes it harder to send parent-only fields to a child SKU.

## 3. Write titles, bullets, and Item Highlights from verified facts

Amazon's current product-detail-page rules are shorter and more structured than many older optimization guides suggest. For U.S. listings, titles are limited to **75 characters including spaces in every product type except media**. Amazon's July 2026 [Item Highlights update](https://sellercentral.amazon.com/seller-forums/discussions/t/145b6d0f-999c-4555-896c-c694bda2e470) adds a searchable field with a **125-character limit including spaces** for material, recommended use, or other comparison detail. Older advice about a 200-character title limit is outdated for this policy.

Use the fields for different jobs:

| Field | What to put there | Data rule |
| --- | --- | --- |
| Title | Brand, product type, key differentiator, and the most useful variant or pack fact | Keep it within the current limit and use only facts supported by the record |
| Bullet points | Distinct features, dimensions, compatibility, care, included components, or constraints | Give each bullet one clear job; do not turn the field into a keyword dump |
| Item Highlights | A concise material, use case, or comparison detail | Keep the field at 125 characters or fewer including spaces |
| Product description | A readable explanation of what the product is and how it is used | Expand on the structured facts without introducing new claims |
| Search terms | Relevant alternate language that is absent from visible fields, where the type exposes it | Use relevant terms only and follow Amazon's field-specific rules |

Use normal capitalization. Keep the product name, type, size, color, and pack count consistent across the title, attributes, images, and variation selection. Do not add reviews, contact information, promotions, unsupported certifications, or claims such as “best” or “guaranteed.” Amazon's [detail-page rules](https://sellercentral.amazon.com/help/hub/reference/external/G200390640?langue=en_US) prohibit misleading content and require titles, descriptions, and bullets to help customers understand the product.

A useful source-to-copy pattern looks like this:

- **Source fact:** 750 ml stainless-steel bottle, leak-resistant lid, tested cold retention.
- **Title:** Brand + stainless-steel bottle + 750 ml.
- **Bullet:** State the lid design and the included component.
- **Item Highlight:** State the material or intended use within the 125-character field.
- **Image:** Show the lid, scale, and included bottle rather than an unrelated lifestyle prop.

The copy describes the record. It should not be the place where your team quietly fixes missing attributes.

## 4. Treat images as structured listing data

Every detail page needs at least one compliant main image. Amazon recommends six additional images and one video, although category guidance can add requirements. Amazon selects which submitted images appear on the page, so an upload is not a display guarantee.

For the main image, validate the current baseline before submission:

- use a realistic, professional image of the product being sold, showing the complete product and correct quantity;
- use a pure white background, RGB `255, 255, 255`, unless a category rule provides an exception, and make the product fill about 85% of the image area;
- include only the product and included accessories, without text, price, badges, watermarks, reviews, or Amazon marks;
- use a supported format and at least 500 pixels on the longest side; 1,000 pixels or more enables zoom;
- name bulk-upload files with the product identifier and image variant code when that workflow requires it.

Alternate images can show angles, use, scale, features, ingredients, safety information, or packaging. Tie each image to a specific attribute or buyer question. A size chart should match the actual variant. A “what is included” image should not show an accessory that is sold separately.

Read the [current image guide](https://sellercentral.amazon.com/help/hub/reference/external/G1881?ld=a) alongside the category style guide. If an image contains photorealistic people generated entirely by AI, Amazon's current guidance also calls for the `contains-synthetic-performer` IPTC/XMP metadata tag in applicable jurisdictions.

## 5. Model identifiers and variations without ambiguity

A variation family is a catalog relationship, not a way to combine unrelated products. Use it when products share the same core item and differ by a supported variation theme such as size, color, or pack quantity. Amazon's allowed themes are category-specific.

For each family, keep a relationship table with:

- parent SKU and child SKU for every child;
- ASIN and GTIN or approved identifier for each sellable item;
- the exact variation theme and its controlled values;
- child-specific price, quantity, image, dimensions, and other attributes;
- the parent-child relationship type and marketplace;
- a check that every child represents a real combination, with no orphaned or duplicate values.

In the SP-API workflow, a parent listing is a non-buyable container. It carries the parentage and variation theme. Each child is a sellable listing with the same theme, a `parent_sku`, and the fields required by that theme. Amazon's [variation workflow](https://developer-docs.amazon.com/sp-api/lang-en_US/docs/building-listings-management-workflows-guide) shows the relationship and the conditional attributes that a theme can activate.

Do not put a child-only color or size in the parent title. Do not group a bundle with a single item simply because shoppers might compare them. If the product is not eligible for a variation family, use standalone listings.

## 6. Keep price and availability current at the offer layer

Price and inventory are part of listing readiness even though they are not copy. In the product-type schema, offer data can include `purchasable_offer`, condition, list price, fulfillment availability, merchant shipping group, and release dates. A `putListingsItem` call can create a SKU and update attributes such as price or inventory. `patchListingsItem` can update selected top-level attributes.

Treat these values as live operational data:

- send the right currency and marketplace ID with every price;
- update available quantity from the system that owns inventory, distinguishing FBA and seller-fulfilled quantities;
- keep condition, release dates, and fulfillment codes aligned with the actual offer;
- remove or suppress an offer when the product cannot be purchased instead of leaving stale availability;
- never put a temporary price, coupon, shipping promise, or stock claim in the title or image.

Catalog's [product feed management guide](https://www.getcatalog.ai/blog/product-feed-management) explains why channel outputs need their own mapping and refresh logic. Amazon's offer layer should consume the same approved source of truth, with a clear owner for every price and inventory field.

## 7. Validate before you submit

Run validation in two places: locally against the current Product Type Definition JSON schema, and through Amazon's preview or submission response.

A practical validation sequence is:

1. Resolve the ASIN or new-item decision with the correct identifier.
2. Fetch the latest schema for the marketplace, product type, requirements, and parentage level.
3. Map typed source data to Amazon attribute names, language tags, units, and controlled values, then evaluate conditional rules.
4. Check character limits, capitalization, prohibited content, image roles, and URL availability.
5. Use `VALIDATION_PREVIEW` when you need to preview Listings Items API errors without persisting the data.
6. Submit with `putListingsItem`, `patchListingsItem`, or `JSON_LISTINGS_FEED`, and capture every response issue with its SKU and marketplace.

Amazon's [workflow documentation](https://developer-docs.amazon.com/sp-api/lang-en_US/docs/building-listings-management-workflows-guide) distinguishes an accepted submission from the later catalog processing state. An accepted response means initial validations passed. It does not remove the need to inspect later issues and status changes.

If your integration still sends the old XML or flat-file listing feeds through the Feeds API, change that path. Amazon stopped supporting legacy XML and flat-file listing feeds for pricing, inventory, relationships, and images on July 31, 2025. Use the Listings Items API or the interoperable `JSON_LISTINGS_FEED` format for those listing operations. This migration note applies to the SP-API integration path. Seller Central's own workflows are a separate interface.

## 8. Monitor buyability, discoverability, and freshness

Submission is the beginning of maintenance. Query `getListingsItem` with data sets such as `summaries`, `attributes`, `issues`, `offers`, and `fulfillmentAvailability`. The response can show the product type, current item name, price, quantity, main image, issues, and statuses.

Two statuses deserve separate monitors:

- **BUYABLE** means shoppers can purchase the listing in the marketplace.
- **DISCOVERABLE** means the associated ASIN can appear in Amazon search results.

A listing can lose one status without losing the other. Your alerting should show which state changed, the affected SKU and ASIN, the marketplace, the issue severity, and the last successful source refresh.

For event-driven maintenance, subscribe to `LISTINGS_ITEM_STATUS_CHANGE` and the newer `2023-12-13` version of `LISTINGS_ITEM_ISSUES_CHANGE`. Amazon says these notifications cover changes to buyability and listing issues, including enforcement actions such as listing suppression, attribute suppression, catalog-item removal, and search suppression. Also listen for `PRODUCT_TYPE_DEFINITIONS_CHANGE` and `ITEM_PRODUCT_TYPE_CHANGE` when your account and brand relationship support them. Re-fetch schemas and revalidate affected records after a product-type version changes.

A practical maintenance schedule has three loops:

- **Near real time:** price, quantity, fulfillment, and offer changes.
- **Each submission:** schema validation, image checks, response capture, and issue remediation.
- **On change events:** product-type versions, category changes, variation edits, image replacements, compliance changes, and Amazon issue notifications.

Track freshness per field rather than only per product. A title might be approved for months while inventory changes every few minutes. A product record is ready only when each downstream field is within its acceptable age.

Amazon still owns the listing rules. A product data layer makes those rules operational at scale.

## Amazon listing optimization checklist

Before you create or update a listing, confirm that your team can answer yes to each question:

- Is the product matched to the correct ASIN or assigned a valid identifier path?
- Are the marketplace, locale, product type, category, and eligibility decision recorded?
- Did you fetch the current JSON schema for the correct requirements and parentage level?
- Are required and conditional attributes populated with valid values and units?
- Does the title meet the current character and content rules?
- Are bullets, Item Highlights, and description derived from verified facts?
- Does every image map to the right SKU, role, quantity, and variant?
- Are identifiers, parent-child relationships, variation themes, and controlled values consistent?
- Are price, currency, condition, fulfillment, and quantity current at the offer layer?
- Did local validation and Amazon preview or submission return no unresolved errors?
- Do you monitor `BUYABLE`, `DISCOVERABLE`, issues, and schema-version changes after submission?
- Does every field have a source, owner, approval state, and freshness signal?

The result is a listing that Amazon can classify and process, shoppers can understand, and your team can maintain. It is a more durable approach than rewriting the same title every time performance changes.

## Frequently asked questions

### What is Amazon product listing optimization?

It is the work of improving the product information, catalog structure, media, and offer data attached to an Amazon listing. A complete process covers identity, product type, attributes, title and feature content, images, variations, price, availability, validation, and maintenance. Advertising and account services are separate activities.

### What is the current Amazon title limit?

For U.S. listings, Amazon's current rules limit titles to 75 characters including spaces for all product types except media. Category-specific requirements can be stricter. Item Highlights is a separate searchable field with a 125-character limit including spaces.

### Are Item Highlights the same as bullet points?

No. Item Highlights is a separate field that Amazon introduced for concise material, recommended-use, or comparison information. Bullets provide a broader set of product features and details. Keep both grounded in the same typed product record and follow the fields exposed by the product type and marketplace.

### How do I know which Amazon attributes are required?

Retrieve the product type definition for the marketplace and listing purpose. Its JSON schema describes required, optional, and conditional attributes. If the product has variations, retrieve the parent or child schema, or use `parentageLevel=NONE` for a standalone listing.

### Can I optimize a listing without a GTIN?

Some products and categories can use a GTIN exemption. Eligibility is specific to the seller, brand, category, and product. Apply through Amazon's process when appropriate. Never invent, borrow, or recycle a product identifier.

### Is Amazon listing optimization the same as Amazon advertising?

No. Listing optimization prepares the catalog item and offer so Amazon can represent it accurately. Advertising buys placements or traffic. Ads may use listing data, and listing changes can affect an ad destination, but the workflows, controls, and measures are different.

### How often should an Amazon listing be updated?

Update fields when their source facts change, then revalidate the affected payload. Price and quantity may need near-real-time updates. Content and images need updates when the product, packaging, compliance information, or Amazon rules change. Schema and issue notifications should trigger a review rather than a fixed annual rewrite.

If you need a channel-ready product record for Amazon and other destinations, [talk to Catalog](https://www.getcatalog.ai/) about keeping attributes, variants, and freshness signals in one controlled data layer.

---

Canonical: https://www.getcatalog.ai/blog/amazon-product-listing-optimization
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product feed optimization: a Google Shopping-first guide

*October 6, 2026 · Catalog Team · Product Data · 21 min read*

> Learn product feed optimization with a Google Shopping-first workflow for eligibility, field quality, feed validation, freshness, testing, and measurement.

A product feed is the version of your catalog a shopping channel can read, validate, and use. A product can be available in your store yet miss Shopping, match the wrong query, or show the wrong price when its feed record is incomplete or stale. Optimization fixes that at the data level.

Use Google Merchant Center as the primary example, then carry the same record into marketplaces and other channels. Separate eligibility from performance, improve fields in order, and close the loop with diagnostics, landing-page checks, controlled tests, and business metrics.

## What product feed optimization means

Product feed optimization is the process of improving product records and their channel-specific output so products are eligible, understandable, discoverable, and useful after a shopper clicks. It includes the content of each field, the relationships between fields, the format emitted for a destination, the freshness of changing values, and the evidence that the output matches the offer a shopper can buy.

A feed row usually represents a product or a purchasable variant. Its fields can include an ID, title, description, URL, image, brand, identifiers, category, attributes, price, currency, availability, and variant relationships. Google calls the submitted row an item and distinguishes it from the underlying product and its variants in the [product data specification](https://support.google.com/merchants/answer/7052112?hl=en).

Optimization has two separate gates:

1. **Eligibility and compliance:** the channel can parse the record, accept its values, and show the offer without violating its requirements.
2. **Performance:** the record gives the channel enough relevant, specific information to match the product to useful searches and gives shoppers a reason to click and buy.

Passing the first gate does not prove the second. A feed with a valid title, image, price, and availability can still use generic language, omit the attributes shoppers compare, or send every variant to the same landing-page state.

### How this differs from related product-data work

The terms overlap, but they describe different jobs. Keep the distinction clear so a feed project has the right owner and success measure.

| Term | Primary job | Typical output |
| --- | --- | --- |
| **Product feed optimization** | Improve product fields and channel outputs for eligibility, matching, clicks, and sales | A better feed record, a validated channel output, and measured test results |
| [Product feed management](https://www.getcatalog.ai/blog/product-feed-management) | Collect, normalize, map, deliver, and monitor feeds over time | A repeatable feed operation with source ownership and sync workflows |
| [Product data quality](https://www.getcatalog.ai/blog/product-data-quality) | Keep product information accurate, complete, consistent, current, valid, and fit for use | Quality dimensions, audits, controls, and ownership across systems |
| [Product attributes](https://www.getcatalog.ai/blog/product-attributes-guide) | Define the facts that describe, classify, compare, and filter a product | Typed fields such as material, size, compatibility, dimensions, and finish |
| [Product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) | Transform and distribute product information to many destinations | Channel-specific listings, feeds, APIs, and synchronized updates |

The [product feed glossary entry](https://www.getcatalog.ai/glossary/product-feed) covers the concise definition. This guide focuses on the optimization loop after you have a source record and a destination to serve.

## Start with an eligibility and performance audit

Do not begin by rewriting every title. First separate hard blockers from opportunities. A disapproved product cannot benefit from a better title, and a product with no impressions needs a different diagnosis from one with many impressions and few clicks.

### Audit eligibility first

For a Google Shopping feed, start with the required core fields: `id`, `title`, `description`, `link`, `image_link`, `price`, and `availability`. Brand is required for most new products, and category-specific rules can add fields. Identifiers such as GTIN and MPN are conditional, yet accurate values help Google identify the product. The [Merchant Center data specification](https://support.google.com/merchants/answer/7052112?hl=en) is the source of truth for a product type, country, and destination.

![Google Merchant Center specification for stable IDs and titles](https://www.getcatalog.ai/images/blog/google-merchant-center-fields.svg)

Check each emitted item for:

- required fields present and in the accepted format;
- stable, unique IDs and valid variant relationships;
- accurate identifiers, with no invented GTINs or MPNs;
- crawlable URLs and images;
- price, currency, availability, and sale dates that match the landing page and checkout;
- category and attribute values that fit the product;
- policy, shipping, returns, language, and destination requirements;
- no duplicate or contradictory data across the feed, page, structured data, and checkout.

Record both item-level and field-level results. “98% of rows uploaded” hides whether the 2% are your highest-revenue products or whether every row has a stale availability value.

### Then audit performance

For eligible products, group the work by a measurable problem:

| Signal | What it can indicate | First place to look |
| --- | --- | --- |
| High impressions, low click-through rate | The product is eligible and visible, but the listing is unclear or uncompetitive | Title, primary image, price, and variant detail |
| Clicks, low conversion rate | The listing creates an expectation the page or offer does not meet | Variant URL, price, availability, delivery, description, and page content |
| Low impressions, accurate eligibility | The channel lacks product context or the product has little demand | Taxonomy, identifiers, category attributes, and title language |
| Repeated disapprovals | A source, mapping, or channel rule is failing | Diagnostics, emitted values, and the owning source field |
| High revenue or margin | A small improvement can have a meaningful business effect | Complete data, freshness, and controlled tests before broad rollout |

Prioritize high-value products, products with high impressions and weak engagement, and products with recurring diagnostics. Google also recommends focusing resources on valuable products and using experiments to identify what works for your audience in its [optimization guidance](https://support.google.com/merchants/answer/7380908?hl=en).

## Improve the fields that shape every output

Use one trusted source record, then create channel-specific outputs from it. The fields below are the practical order for a Google Shopping-first implementation. Eligibility checks come before copy tests.

### 1. Stabilize IDs, identifiers, and variants

Identity is the layer that lets a channel accumulate history and connect price, inventory, images, and performance to the right item.

For Google:

- Keep `id` unique and stable. Use the SKU where possible, keep it the same when updating data, and use the same ID for the same product across countries or languages. Google limits the field to 50 characters.
- Send one row for each purchasable variant when the variant has its own price, stock, image, or landing state.
- Give variants a shared `item_group_id`, keep that value stable, and use variant fields such as `color`, `size`, or `material` to distinguish children. The group ID is required for variants in the US and several other markets.
- Send the product's real `brand` when it has one. Do not use values such as `N/A`, `Generic`, or `No brand` as a substitute for missing brand data.
- Send a valid manufacturer GTIN when you have one. If no manufacturer-assigned GTIN exists, use the manufacturer-assigned MPN and brand when the category requires them. Never guess an identifier. An incorrect GTIN or MPN can cause a disapproval.

A useful variant record looks like this:

```text
id: JKT-001-NAVY-M
item_group_id: JKT-001
brand: Northline
gtin: GTIN_FROM_MANUFACTURER_IF_AVAILABLE
color: Navy
size: M
price: 148.00 USD
availability: in_stock
link: https://example.com/products/waterproof-commuter-jacket?color=navy&size=m
image_link: https://example.com/images/jkt-001-navy-m.jpg
```

The parent group is shared. The ID, URL, image, price, availability, and distinguishing options belong to the variant. Do not group separate products simply because they look similar, and do not collapse a multipack or a bundle into a single item when the offer and identifier represent something different.

### 2. Write titles for matching and scanning

The title is both product language and a compact display field. Put the details that identify the item and distinguish the variant near the front. A practical order is:

`brand + product type + key differentiator + material or use case + variant detail`

For example:

| Weak title | More useful title |
| --- | --- |
| `Jacket` | `Northline Women's Waterproof Commuter Jacket, Recycled Nylon, Navy, Medium` |
| `Bottle` | `Trailmark Insulated Stainless Steel Water Bottle, 32 oz, Black` |

Use the product's real terms, including the same color and size names that appear on the landing page. Current Google specifications allow up to 150 characters for `title`, prohibit promotional text and gimmicky characters, and require the title to describe the product accurately. Google also advises placing details that are not visible in the image near the beginning because titles are truncated in many formats.

A title is not a place to add every query or claim. Do not stuff synonyms, shipping messages, discount language, or claims the product page cannot support. If a title change makes the feed more relevant while making the landing page feel inconsistent, the source record and page need attention together.

### 3. Make descriptions specific and factual

A description should answer the questions that a title cannot. For the jacket example, state the fabric, weather protection, construction, fit, care, and included features. Keep claims tied to a source such as approved product content or a manufacturer specification.

Google's current `description` field accepts up to 5,000 characters. It should contain product information, match the landing page, and exclude store links, sales language, competitor references, and details about unrelated accessories. Use paragraphs or lists when the destination supports them. Do not turn the description into a keyword list.

Descriptions are performance work after the core record is valid. They help when shoppers need more context to compare products, yet they cannot compensate for a missing variant, wrong price, or broken image.

### 4. Map taxonomy deliberately

Google has two different category concepts:

- `google_product_category` is Google's predefined taxonomy. It is optional in general, except for particular products and programs. When you send it, use one relevant category as either its numeric ID or full path, not both.
- `product_type` is your own hierarchy. Use a detailed path such as `Apparel > Women's Clothing > Outerwear > Rain Jackets`. Google says the first `product_type` value is used for organizing bidding and reporting in Shopping campaigns.

Use category values to describe what a product is. Keep search phrases, synonyms, promotions, and audience labels in the fields intended for them. A wrong category can trigger category-specific requirements and can make otherwise accurate attributes look contradictory.

For each category, define the minimum set of attributes that a shopper or channel needs. Apparel often needs color, size, gender, age group, fit, and material. Electronics may need model, compatibility, dimensions, capacity, operating system, and included components. A category map should state which values are required, controlled, recommended, and optional for each destination.

### 5. Add attributes that explain the buying decision

Attributes are useful when they reduce uncertainty or help a system match a constraint. Prefer explicit values over vague copy:

| Category | Useful structured facts |
| --- | --- |
| Apparel | color, size, fit, material, pattern, gender, age group, size type |
| Furniture | width, depth, height, material, finish, assembly, room, weight capacity |
| Electronics | model, compatibility, ports, capacity, dimensions, power, warranty, included components |
| Beauty | ingredients, skin or hair type, volume, form, concerns addressed, fragrance information |

Normalize values before mapping them. If one variant says `Midnight Sky`, another says `Dark Blue`, and the landing page says `Navy`, the channel and the shopper receive three versions of one fact. Keep units consistent, use controlled values where a channel expects them, and retain the source value so every transformation is traceable.

Custom labels can help you segment campaigns, reporting, or testing groups by margin, season, launch status, or inventory risk. Google describes them as tools for organizing bidding and reporting. Treat them as campaign segmentation, not a ranking signal. They do not make a product more eligible.

### 6. Use images that pass policy and represent the item

The primary image should show the product accurately, use a crawlable URL, and match the variant in the row. Google lists JPEG, WebP, PNG, non-animated GIF, BMP, and TIFF as accepted formats for `image_link`. It prohibits promotional text, watermarks, borders, placeholders, and generic images. Additional images can show the product in use or provide relevant detail, and Google supports up to 10 additional image links.

Google's current specification announces a minimum of 500 by 500 pixels for product images, with enforcement beginning **January 31, 2027**. Treat that as an announced future enforcement date in your image pipeline. This is a dated requirement, so image validation should record dimensions as well as URL status, file type, and variant match.

For a color or size variant, send the image that a shopper expects after clicking. Do not use a black product image for a white variant simply because the image URL is convenient. A clear image can improve engagement, but it cannot rescue a wrong offer or an unavailable item.

### 7. Keep price and availability current

Price and availability are eligibility fields and trust signals. For Google, send `price` with a numeric amount and ISO 4217 currency. Match it across the feed, landing page, structured data, and checkout. Send `sale_price` alongside the non-sale `price`, and use `sale_price_effective_date` when the sale has a defined window.

For bulk products, minimum order quantities, bundles, and multipacks, the submitted price must represent the minimum purchasable quantity and be shown clearly on the landing page. In the US and Canada, Google says the `price` value excludes sales tax; other countries can require VAT or GST in the submitted price. Regional rules belong in the channel adapter, not in a single global value.

Send one of Google's supported availability values, such as `in_stock`, `out_of_stock`, `preorder`, or `backorder`. Match the page, checkout, and structured data. For preorder or backorder items, supply the required availability date and show that date clearly to shoppers. When an item is out of stock, its price still needs to be visible on the landing page.

Set a freshness policy by field rather than using one schedule for the entire catalog:

| Field group | Baseline update trigger | Why |
| --- | --- | --- |
| Price, sale price, and availability | Every source change, or frequent intraday delivery | These values can invalidate an offer quickly |
| Titles, descriptions, and attributes | Approved content change or scheduled daily publish | These fields need review and consistency |
| Images | Asset approval and URL validation | A replaced asset can break a listing or misrepresent a variant |
| Taxonomy and mappings | New product type, channel taxonomy change, or rule change | Classification affects required fields and reporting |
| Diagnostics and landing-page parity | Daily monitoring, plus an alert on a material change | Accepted files can still create bad live offers |

Google recommends automated or intraday delivery, the Merchant API, or structured data for price and availability freshness. The right cadence depends on how quickly the source changes. Keep a timestamp and source version for every emitted value so a mismatch has an owner.

## Keep the output channel-aware

One normalized product record can support several destinations. One unmodified feed should not be expected to satisfy all of them. The adapter should translate field names, controlled values, limits, category rules, and eligibility without changing the underlying product truth.

| Destination | What to preserve from the source record | What needs a channel-specific adapter |
| --- | --- | --- |
| **Google Merchant Center** | Stable IDs, variants, identifiers, title, description, image, price, availability, taxonomy, and attributes | Google attributes, country and language rules, image requirements, shipping and returns, and diagnostics |
| **Amazon** | Product identity, variation relationships, approved content, media, offer state, and inventory | Product-type inventory-file template, required and conditional fields, variation theme, accepted values, and offer columns |
| **TikTok Shop** | Accurate product facts, brand, images, variants, price, and disclosures | Listing policy, category rules, variation grouping, and content restrictions |
| **AI or developer-facing commerce feeds** | Stable item and variant IDs, structured product facts, price, availability, and regions | The destination's schema, eligibility flags, update contract, and freshness behavior |

Amazon's [US inventory-file guidance](https://sellercentral.amazon.com/help/hub/reference/external/581?locale=en) uses product-type-specific templates with required, conditional, and optional fields. TikTok Shop's [listing policy](https://seller-us.tiktok.com/university/essay?knowledge_id=3196690250417921) requires accurate listing details and groups valid variations under one product page, while prohibiting misleading titles, brands, attributes, and duplicate listings. Those are different data contracts from Google Merchant Center. Map from a trusted record instead of copying a Google export and hoping the destination accepts it.

For custom Google integrations, account for the API transition as part of feed operations. Google's [sunset notice](https://developers.google.com/shopping-content/guides/deprecation-and-sunset) says the legacy Content API for Shopping was sunset on **August 18, 2026**. Requests without an active extension can fail intermittently from **September 1, 2026**, and full decommissioning is planned for **early 2027**. Move custom integrations to the [Merchant API](https://developers.google.com/merchant/api), and keep API migration separate from field-level optimization so a transport change does not hide feed-quality regressions.

## Validate the emitted feed, not only the source record

A source catalog can look complete while the emitted feed drops a field, maps the wrong value, or points every variant to one page. Validate the final output that a channel receives.

Use this sequence for each feed release:

1. **Freeze the input version.** Record the source snapshot, mapping version, target country, language, destination, and product cohort.
2. **Run schema checks.** Confirm required columns or object properties, accepted enums, character limits, number and currency formats, URL encoding, and unique IDs.
3. **Run relationship checks.** Confirm each variant has one stable parent group, each ID is unique, and variant-specific price, availability, image, and URL values are coherent.
4. **Run semantic checks.** Compare title, description, category, attributes, image, and identifiers. Flag contradictions such as `red` in the title and `Blue` in the color field.
5. **Inspect the emitted file or API payload.** Review representative rows from high-value products, each category, each variant pattern, each price state, and each availability state. Do not rely on the source database view.
6. **Read channel diagnostics.** In Merchant Center, use the product issue details and diagnostics to separate errors, warnings, limited eligibility, and item-level disapprovals. Classify each recurring issue by source field, mapping rule, or channel rule.
7. **Open the landing page from the emitted link.** Confirm it resolves, shows the submitted product and variant, exposes the same title, description, image, price, currency, availability, and relevant structured data, and allows the submitted offer to be purchased.
8. **Check the checkout path.** A page can show one price while checkout applies a different currency, membership condition, minimum quantity, or availability state. The submitted offer must be purchasable on its stated terms.
9. **Measure freshness.** Compare the event time in the source, emitted feed, channel receipt, landing page, structured data, and checkout. Alert when a field exceeds its allowed lag.
10. **Save the evidence.** Keep the row, diagnostic reason, page result, source version, owner, fix, and next observation window together.

This workflow catches both gates. Diagnostics answer whether a channel accepted the data. Landing-page and checkout checks answer whether the accepted data describes an offer a shopper can trust.

## Test changes and measure business impact

Feed optimization is a series of hypotheses. Treat it like an experiment rather than a permanent rewrite.

### Build a clean test

1. Choose one field family and one product cohort. For example, add color and fit to titles for a sample of apparel variants.
2. Define a control group that keeps the old output and a treatment group that receives the new rule. Match groups by category, price band, historical impressions, and sales where possible.
3. Record a baseline for eligibility, diagnostics, completeness, impressions, clicks, click-through rate, conversions, conversion rate, revenue, cost, and return on ad spend. Add gross margin, return rate, and stock-out rate when those are available.
4. Keep campaign budget, bids, promotion, price, image set, landing page, and inventory policy steady during the observation window. If another change is unavoidable, record it as a confounding event.
5. Compare rates and product-level distributions, not only totals. A larger group can produce more clicks without improving the product record.
6. Roll out only when the treatment improves the intended metric without breaking eligibility, margin, inventory, or customer experience guardrails.

A title test might ask whether `Women's Waterproof Commuter Jacket, Navy, Medium` earns a better qualified click rate than `Jacket`. A description test might add material and care facts. An attribute test might fill compatibility or dimensions. Change one family at a time so the result explains what moved.

### Track two scorecards

Keep operational and commercial measures separate:

| Scorecard | Measures |
| --- | --- |
| **Eligibility and data health** | Required-field completeness, valid identifier coverage, variant integrity, diagnostic error and warning rate, disapproval rate, image dimension and URL pass rate, price and availability mismatch rate, freshness lag |
| **Performance and business** | Impressions, click-through rate, qualified clicks, conversion rate, revenue, cost per order, return on ad spend, gross margin, return rate, and stock-out rate |

Use product groups and custom labels to connect the scores. For example, report the title treatment by product type, margin band, and inventory status. Custom labels organize analysis and campaign controls. They do not replace product relevance or fix missing data.

A successful upload is the start of an observation window, not the result. Keep the old and new emitted rows, diagnostics, landing-page evidence, and business metrics tied to the same product IDs. That gives you a defensible answer when performance changes and makes it possible to reverse a rule without losing history.

## A practical optimization order

When the catalog is large, use this sequence:

1. Fix disapprovals and missing required fields for high-value products.
2. Stabilize IDs, identifiers, variants, and canonical URLs.
3. Remove price, availability, and landing-page mismatches.
4. Validate primary images, variant images, dimensions, and crawlability.
5. Improve titles and descriptions with facts shoppers use to choose.
6. Complete category attributes and taxonomy for each product family.
7. Add channel-specific mappings for Amazon, TikTok Shop, or other destinations.
8. Establish field-level freshness and diagnostic ownership.
9. Run one controlled test at a time.
10. Scale rules that improve performance without degrading eligibility, margin, or trust.

Catalog helps teams structure product data into live, normalized product records, keep changes synced, and measure outcomes across channel outputs and machine-readable commerce surfaces. If your channel work is blocked by thin or inconsistent source data, [explore Catalog's product data layer](https://www.getcatalog.ai/).

## FAQ

### How often should a product feed be optimized?

Review diagnostics and freshness continuously, then schedule a recurring performance review. Price and availability should update whenever the source changes. Titles, descriptions, attributes, and mappings should change through an approved workflow or a measured test. A fixed monthly rewrite is less useful than a field-level process tied to changes, errors, and performance signals.

### Can one product feed serve every channel?

One normalized source record can support every channel. The emitted output should still be channel-specific because Google Merchant Center, Amazon, TikTok Shop, and other destinations use different schemas, required fields, taxonomies, limits, and policies. Share product truth. Adapt the contract.

### Which fields should be optimized first?

Start with eligibility and trust: IDs, variant relationships, identifiers, image URLs, price, availability, and landing-page parity. Then improve titles, descriptions, taxonomy, and category attributes for products with meaningful impressions or commercial value. This order prevents copy work from masking a broken offer.

### Is `google_product_category` required for Google Shopping?

It is optional for general products, with exceptions for certain products and programs. Google automatically categorizes products. When you provide `google_product_category`, send one relevant Google taxonomy value as an ID or a full path, not both. Keep it separate from your own `product_type` hierarchy.

### Do custom labels improve product ranking?

Custom labels are useful for campaign grouping, reporting, and testing. They help you decide where to spend or how to compare cohorts. They are not a substitute for complete product data and are not a direct product-ranking signal.

---

Canonical: https://www.getcatalog.ai/blog/product-feed-optimization
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Vendor onboarding process for ecommerce brands

*October 5, 2026 · Catalog Team · Product Data · 19 min read*

> Build a vendor onboarding process for ecommerce that covers approvals, documents, vendor-master setup, product data, validation, distribution, and KPIs.

A vendor can be approved and still be impossible to sell. The legal entity may be ready for a contract and a payment run while its product file contains duplicate SKUs, missing variants, and category values your channels cannot use.

A strong vendor onboarding process handles both gates. It moves the supplier into your approved vendor master, then turns the supplier’s product records into accurate, usable commerce data. Here is the baseline workflow, the product-data handoff, and the checks that keep a new vendor from creating catalog work after launch.

## What vendor onboarding means for ecommerce

Vendor onboarding is the controlled process of moving a prospective supplier from intake to an approved, operational vendor record. It usually includes qualification, document collection, compliance and risk review, commercial terms, approvals, and activation in the systems that purchase from and pay the supplier.

Supplier onboarding and vendor onboarding are usually used interchangeably. Ecommerce teams need one extra distinction: approving a company is different from approving its items for sale.

| Gate | The question to answer | Exit record |
| --- | --- | --- |
| **Vendor approval** | Can this business supply us under agreed terms and pass the checks that apply to it? | One approved vendor record, contract, owners, and operating rules |
| **Product approval** | Can shoppers and downstream channels identify, understand, and buy each item? | Validated product, variant, offer, and media records |

Keep these gates connected, but do not collapse them into one status. A supplier can pass finance and compliance review while its catalog needs remediation. A product file can be data-ready while the contract is still waiting for approval. Each gate needs its own owner and evidence.

## The standard vendor onboarding process

The names and approvers vary by company. The baseline below works for a brand, retailer, or marketplace that adds suppliers for resale.

### 1. Start with intake and a process owner

A business owner should submit the reason for adding the vendor before anyone creates a record. Capture:

- legal and trading names, primary contacts, and operating countries;
- product categories, expected SKU or variant count, and launch markets;
- sales model, such as wholesale, dropship, marketplace, or direct fulfillment;
- expected order volume, fulfillment locations, lead times, and service contacts;
- the supplier’s product-data source, submission format, and update cadence;
- the target launch date and the teams that must approve the relationship.

Check the existing vendor master for a matching legal entity, trading name, address, or tax identifier. Assign one process owner to track the request from intake through activation. The owner can route work to procurement, finance, legal, compliance, information security, product operations, and merchandising without making all of those teams responsible for the whole workflow.

### 2. Qualify the supplier and set the review tier

Qualification asks whether the supplier can support the proposed relationship. Review the capabilities that affect your business, such as:

- product quality and category experience;
- production or inventory capacity;
- minimum order quantities, lead times, and replenishment rules;
- countries served, warehouse locations, and delivery coverage;
- returns, recalls, customer support, and escalation capability;
- data exchange options, technical contacts, and change-notification practices.

Use a tier that matches the exposure and complexity of the relationship. A supplier that provides a small, low-risk assortment does not need the same review as one that supplies regulated products, handles customer data, or supports a high-volume launch. The tier should determine which reviews and documents are required. It should not become a reason to skip the basic duplicate check or a product-data sample.

### 3. Collect compliance and commercial documents

Give the supplier one secure, versioned request for the documents that apply to its tier and jurisdiction. Common examples include:

- registered business name, address, and registration details;
- tax forms or tax identifiers, such as a US [W-9](https://www.irs.gov/forms-pubs/about-form-w-9) where applicable;
- bank and remittance details, collected through an approved secure process;
- insurance certificates, licenses, safety documents, or product certifications when required;
- ownership, sanctions, security, or privacy information required by your policy;
- signed terms, code of conduct, data-processing terms, or master agreement.

The exact list is policy- and jurisdiction-specific. Record who owns each document, when it expires, and what blocks activation. Do not treat an email attachment as a durable document system or let a product launch depend on a missing file that no one owns.

### 4. Validate the submission and route approvals

Review the submitted information for completeness, internal consistency, and policy requirements. Finance may validate tax details and independently confirm bank changes. Compliance or risk may run screening. Legal may review contract language. Information security may assess system access. Procurement or the category owner may approve the commercial case.

Use explicit statuses such as `submitted`, `needs information`, `under review`, `approved`, and `rejected`. Save the decision, approver, date, conditions, and follow-up work with the vendor record. If a document is incomplete, return a precise exception, such as “certificate expires before launch” or “remittance name does not match the registered entity.” A supplier should not have to guess which field is blocking progress.

### 5. Agree on terms and operating rules

Before the first purchase order or product launch, document the rules that teams will use every day:

- wholesale pricing, discounts, minimums, and price-change notice;
- payment terms and invoicing requirements;
- order cutoffs, fulfillment times, shipping services, and delivery regions;
- returns, cancellations, damages, recalls, and customer-service ownership;
- service levels, escalation contacts, and review cadence;
- product-data format, field definitions, update frequency, and change alerts;
- credentials, environments, permissions, and technical support contacts.

The contract and the product-data submission guide should agree. A vendor that promises a 48-hour dispatch window needs a record that can represent that promise. A brand that requires a GTIN for a channel should state that requirement before the first file arrives.

### 6. Activate one vendor-master record

After the required reviews and terms are complete, create or activate the vendor once in the appropriate ERP, procurement, accounts-payable, or vendor-management systems. Map the verified legal and remittance names, vendor ID, terms, currency, tax coding, locations, contacts, status, and owning team.

Limit access to what the integration and users need. Record the activation date and the conditions for suspension or re-review. Vendor-master activation means your company can transact with the supplier. It does not make every supplier item ready for sale.

### 7. Pilot the product data before launch

Request a representative sample before loading the full assortment. Include a simple item, a multi-variant item, a product with multiple images, and an item with a known exception. Run the sample through identity matching, mapping, validation, channel output, and approval. Fix the process and the supplier instructions before scaling the import.

This product-data gate is where many otherwise careful vendor onboarding workflows stop too early.

![A shopper-facing product record connected to a machine-readable product-data layer and distribution channels.](https://www.getcatalog.ai/images/blog/vendor-product-data-handoff.svg)

The goal of [product catalog management](https://www.getcatalog.ai/glossary/product-catalog-management) is one product truth that can serve a storefront, a feed, a marketplace, and machine-facing commerce surfaces without rebuilding the record for each destination.

## The product-data handoff: from supplier file to approved catalog

Treat the supplier’s file as a source submission, not as your canonical model. A source may be a CSV or spreadsheet, an XML or JSON feed, an EDI exchange, a PDF line sheet, or an API. If a supplier publishes through [GS1 GDSN](https://www.gs1.org/services/gdsn), define which values you accept and how you resolve conflicts with direct submissions. Choose the formats you will accept, define the required fields, and version the mapping rules.

### 1. Define the product submission contract

Tell the supplier what each field means, which values are accepted, and who owns corrections. A practical baseline includes:

| Record area | Example fields | Why it matters |
| --- | --- | --- |
| Identity | Supplier SKU, internal SKU, GTIN or other assigned identifier, MPN, brand | Joins the item across systems and prevents duplicates |
| Content | Title, description, bullets, claims, care or usage instructions | Gives shoppers and machines useful product context |
| Variants | Parent ID, variant ID, size, color, pack, configuration | Preserves the relationship between a product family and its sellable items |
| Attributes | Material, dimensions, ingredients, compatibility, capacity, fit | Supports filtering, comparison, recommendations, and channel fields |
| Commercial state | Cost, price, currency, availability, lead time, minimums | Represents what can be bought and under which conditions |
| Media and evidence | Image URLs, manuals, certifications, source, last updated | Supports presentation, trust, validation, and traceability |
| Logistics | Weight, package dimensions, case quantity, shipping restrictions | Prevents fulfillment and channel surprises |

Separate vendor facts from product facts. A legal name and payment term belong to the vendor record. A product’s material, size, image, and GTIN belong to the item record. A cost or availability value may belong to an offer tied to a specific market or channel.

### 2. Resolve identifiers and variant relationships

Keep every useful identifier with its source and meaning. A supplier SKU is useful inside the supplier’s system. Your internal SKU is useful inside your catalog and operations systems. A GTIN identifies a trade item where the brand or manufacturer has assigned one. An MPN identifies a manufacturer’s part or model. They are related fields, not interchangeable values.

[GS1 identification keys](https://www.gs1.org/standards/id-keys) give trading partners globally unique identifiers for products, parties, locations, and other entities. Use an assigned identifier when it exists. Do not invent a GTIN to fill an empty field. Store the original value, the normalized value, the source, and any match confidence.

Model a parent product and its sellable variants explicitly. A linen shirt may have one parent record and separate child records for each size and color, with variant-specific images, availability, and identifiers. A two-pack may be a different sellable item from a single unit. A bundle may need relationships to its component products. Do not flatten those distinctions into one title or one stock value.

Google’s [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) illustrates the operational principle: keep a stable item ID, group variants with an item-group identifier, and submit distinguishing fields such as color and size when they apply. The exact fields differ by destination, so keep the parent-child model in your own product data layer rather than making one channel’s feed the master.

### 3. Normalize attributes, units, and taxonomy

Supplier values are rarely consistent enough to publish directly. Normalize them into your model while retaining the source value for audit and correction.

- Map `navy`, `navy blue`, and `midnight` to the controlled color value your business uses.
- Convert measurements into a canonical unit while preserving the supplier’s original measurement and precision.
- Split compound fields such as `cotton / elastane` into the material structure your category needs.
- Define accepted values for fields such as condition, gender, fit, finish, voltage, and pack size.
- Map supplier categories to your internal taxonomy and the taxonomy required by each destination.

For cross-company classification, [GS1 GPC](https://www.gs1.org/standards/gpc/how-gpc-works) gives trading partners a shared product language. Use it as a reference where it fits your assortment, then maintain explicit mappings to your own and channel taxonomies. A mapping should be versioned and owned. It should not silently change because a supplier renamed a category in a spreadsheet.

Our [product attributes guide](https://www.getcatalog.ai/blog/product-attributes-guide) explains why category-specific fields matter. A generic “color” field cannot replace width and fit for footwear, compatibility for electronics, or ingredients and shade for beauty.

### 4. Validate before publishing

Run validation at the record, relationship, and destination levels. Useful checks include:

1. **Completeness:** required fields exist for the category, market, and destination.
2. **Format:** identifiers, URLs, dates, units, currencies, and enumerated values follow the agreed rules.
3. **Uniqueness:** vendor SKUs, internal SKUs, GTINs, and variant IDs do not collide where they must be unique.
4. **Relationships:** every variant points to the correct parent, and every bundle or accessory relationship resolves.
5. **Accuracy:** product facts match supplier specifications, approved documents, packaging, or another named source of truth.
6. **Media:** image URLs resolve, images match the variant, and required assets meet destination rules.
7. **Commercial consistency:** price, currency, availability, and lead time agree with the offer and the customer-facing page.
8. **Taxonomy:** category and attribute values are valid for the destination.
9. **Provenance:** each important value has a source, owner, and last-updated timestamp.

Google warns that missing or incorrect product information can cause disapprovals, limited eligibility, or incorrect displays, including when IDs, variant attributes, images, or feed and website values conflict. That is why validation belongs before distribution. A successful file upload is not proof that the records are useful.

Route failures to an exception queue with the vendor, record ID, field, current value, required correction, owner, and due date. Reject a record when a fact is missing or contradictory. Do not fill a product claim with a guess simply to raise the completion rate. For a broader framework, use our guide to [product data quality](https://www.getcatalog.ai/blog/product-data-quality).

### 5. Approve, distribute, and monitor the records

Product operations or merchandising should approve the validated sample and the full launch according to your policy. Then transform the approved model into the outputs each destination needs:

- storefront and search records;
- Google or other commerce feeds;
- marketplace and retail-partner submissions;
- APIs and partner exports;
- AI shopping and answer-engine product context.

The destination format is an output. Keep the normalized product model upstream so a taxonomy or channel change does not force another supplier re-onboarding.

This is where we fit. We built Catalog as the product-data layer for structuring and enriching product inputs, keeping live product records synchronized, distributing machine-readable product data, and measuring how AI shopping surfaces use it. We do not replace procurement approvals, tax or banking validation, payment setup, contract management, or vendor-risk screening. Those controls stay in the systems and teams responsible for them.

Read the guide to [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) for the work that makes supplier records more useful, then use [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) for the distribution step. Track inventory signals through your [inventory management process](https://www.getcatalog.ai/blog/inventory-management-process) while monitoring both the supplier connection and the product records it produces.

| Data type | Update approach | What to watch |
| --- | --- | --- |
| Price, availability, and inventory | Near real time or frequent scheduled updates when they change quickly | Stale offers, overselling, and source-to-channel lag |
| Content and category attributes | After approval, on a scheduled or event-based cadence | Unapproved edits, missing fields, and mapping drift |
| Images and supporting assets | After rights approval and URL validation | Broken URLs, wrong-variant images, and missing media |
| Identifiers and taxonomy mappings | On a controlled change with an owner | Duplicate IDs, changed categories, and downstream rejects |
| Vendor documents | Separate compliance calendar and re-review workflow | Expired certificates, changed terms, or suspended status |

Track what shoppers and channels actually receive. Our [structured data glossary](https://www.getcatalog.ai/glossary/structured-data) describes the difference between organized product facts and the feeds or APIs that deliver them.

## Vendor onboarding checklist for ecommerce

Use the checklist as a handoff between teams. Adapt documents, approvers, and fields to your jurisdiction, category, risk tier, and destinations.

| Phase | Confirm before moving on | Primary owner |
| --- | --- | --- |
| Intake | Business case, duplicate check, scope, markets, contacts, product count, process owner | Requesting team |
| Qualification | Capability, capacity, fulfillment coverage, category fit, review tier | Procurement or category owner |
| Documents | Legal, tax, banking, insurance, licenses, certifications, and policies required for the tier | Finance, legal, and compliance |
| Approval and terms | Approvers, contract, pricing, payment, shipping, returns, service levels, escalation path | Procurement and legal |
| Vendor-master activation | One vendor ID, verified names, terms, coding, locations, contacts, status, access controls | Vendor master or finance |
| Product-data intake | Submission format, field definitions, identifiers, variant model, media, source and update cadence | Supplier and product operations |
| Validation and pilot | Sample mapping, duplicate checks, required fields, taxonomy, media, offers, exception owners | Product and channel operations |
| Launch and monitoring | Sign-off, distribution outputs, sync schedule, dashboards, alerts, re-review dates | Operations and channel owners |

Keep the vendor approval record and product approval record linked. That gives teams a clear answer when a product is blocked because of a missing certificate, a bad identifier, or a contract condition.

## KPIs for vendor and product-data onboarding

Cycle time is useful only when the controls remain intact. Measure the two gates separately:

| KPI | What it tells you |
| --- | --- |
| Request-to-vendor approval time | How long qualification, documents, review, and terms take by vendor tier |
| Approval-to-master activation time | Whether an approved vendor is getting set up without re-keying or queue delay |
| First submission-to-data-ready time | How quickly the supplier’s first product sample becomes publishable |
| First-pass validation rate | How often records clear checks without correction |
| Required-field completeness | Whether records meet category and destination requirements |
| Identifier match and duplicate rate | Whether records join cleanly without collisions or split items |
| Variant relationship accuracy | Whether parent, child, pack, and bundle relationships resolve correctly |
| Taxonomy mapping pass rate | Whether records reach the intended category in each destination |
| Channel rejection or warning rate | Which product data issues block distribution after approval |
| Freshness lag | Time between a source change and the updated value reaching each destination |
| Exception resolution time | Whether supplier and internal owners can clear failures quickly |
| Early post-launch issue rate | Whether the vendor or product setup creates returns, cancellations, or support work |

Review the metrics by vendor, category, destination, and tier. A high first-pass rate can hide weak requirements. A low rejection rate can hide products that never reached a channel. Pair operational metrics with a sample of live records.

## Common failure points

- **One approval status covers everything.** Separate vendor eligibility from product readiness so a clean contract does not hide a broken catalog.
- **A new vendor record is created before the duplicate check.** Search legal names, addresses, tax identifiers, and existing relationships before assigning a new ID.
- **The supplier taxonomy becomes the master.** Keep your own taxonomy and versioned mappings to destinations.
- **Variants are flattened into titles.** Preserve parent-child relationships, variant-level identifiers, images, offers, and inventory.
- **Teams clean the data only at the channel edge.** Fix the source mapping or canonical record so the same error does not return in the next file.
- **Missing values are guessed.** A fabricated material, dimension, or compliance claim is worse than an explicit exception.
- **No one owns the exception queue.** Every failure needs a named owner, a correction, and a due date.
- **Upload success is treated as launch readiness.** Test what shoppers see and what the destination accepts, then monitor after launch.
- **Vendor compliance is mixed with product-data tooling.** Keep procurement, finance, legal, and risk controls in their systems. Use the product-data layer for the records that describe what you sell.

## FAQs

### What is the vendor onboarding process?

It is the repeatable workflow for collecting, qualifying, verifying, approving, contracting, and activating a supplier in the systems that transact with it. For ecommerce, it should also include a separate product-data gate that validates the supplier’s items before they go live.

### Is supplier onboarding different from vendor onboarding?

Most teams use the terms for the same workflow. Some use supplier for a company that provides goods for resale and vendor for any company they pay. Choose one definition in your policy and keep the process and records consistent.

### What documents are needed for vendor onboarding?

The list depends on the vendor type, jurisdiction, risk tier, and product category. Common examples are legal registration details, tax information, remittance and bank details, insurance, licenses or certifications, signed policies, and contract terms. Collect only what your policy requires, and track owners and expiry dates.

### When is a vendor ready to transact?

A vendor is ready when the required reviews and terms are approved and one verified vendor-master record is active in the systems that handle purchasing and payment. That does not mean every product is ready for sale. Product records still need identity, attribute, variant, offer, media, and destination validation.

### What product data should a new supplier provide?

Start with supplier and internal identifiers, GTIN or other assigned identifiers, brand, title, description, category, parent and variant relationships, category-specific attributes, images, price or cost, currency, availability, lead times, dimensions, packaging, and relevant certifications or restrictions. Define the exact fields and accepted values in the submission contract.

### How long should vendor onboarding take?

There is no responsible universal timeline. A low-complexity supplier with complete documents and a clean sample can move faster than a high-risk or multi-market supplier. Measure each stage separately, then reduce waiting and rework without removing a required control.

### Can Catalog replace vendor onboarding software?

No. We are the product-data layer. Catalog helps turn supplier and brand inputs into structured, normalized, machine-readable product records, keep them synchronized, and distribute them to commerce and AI shopping surfaces. Procurement workflow, tax and payment setup, contracts, and vendor-risk screening remain separate responsibilities.

If your vendors are approved but their product data still arrives as inconsistent files, [run a Catalog audit](https://www.getcatalog.ai/audit) to see what AI shopping surfaces can read and where the record needs work.

---

Canonical: https://www.getcatalog.ai/blog/vendor-onboarding-process
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Perpetual vs. periodic inventory systems: An ecommerce decision guide

*October 3, 2026 · Catalog Team · Product Data · 15 min read*

> Compare perpetual and periodic inventory systems for ecommerce, with accounting differences, channel impacts, reconciliation, and a decision checklist.

Inventory records can look current in one system while your storefront and marketplace make different promises. The choice between perpetual and periodic inventory affects how quickly a sale changes available-to-sell stock, how often your team reconciles, and whether channel updates keep pace. This guide puts the accounting distinction beside the operating reality: variants, locations, reservations, returns, and feed freshness.

## Perpetual vs. periodic inventory systems at a glance

A **perpetual inventory system** updates the inventory record as each inventory-affecting event is captured. Receipts, sales, transfers, returns, and approved adjustments change the book balance continuously or close to it.

A **periodic inventory system** updates the inventory balance at scheduled intervals, usually after a physical count or period close. Purchases and sales can still be recorded in other systems during the period, but the inventory balance is not the authoritative measure of what is sellable until the next update.

For the broader inventory-management model, see our [inventory management glossary](https://www.getcatalog.ai/glossary/inventory-management). The comparison below focuses on the record-update method.

| Dimension | Perpetual system | Periodic system |
| --- | --- | --- |
| Inventory record | Changes with captured receipts, sales, transfers, returns, and adjustments | Changes at a planned count or reconciliation |
| Availability between counts | A current book balance, if events and identifiers are reliable | A previous count or estimate, until the next count |
| Cost of goods sold (COGS) | Available as transactions post, subject to the chosen cost-flow rule | Calculated at period close from beginning inventory, purchases, and ending inventory |
| Main control | Event capture, integrations, exception handling, and physical checks | Count schedule, receiving and sales records, and period-end adjustments |
| Typical operating fit | Fast-moving SKUs, many variants, multiple locations, or shared channels | Small catalog, low velocity, one location, and low cost of stale availability |
| Setup and labor | More system setup, integration, training, and ongoing monitoring | Lower system setup, with more count labor and operational interruption |
| Main risk | A missed event or wrong SKU can make a fast update wrong | Shrinkage, overselling, and receiving errors can stay hidden between counts |

The important boundary is authority. A spreadsheet that is edited every night may be a scheduled process, while a warehouse system that posts a sale immediately is operating perpetually. The label follows when the inventory balance changes, not whether the team uses software.

Catalog sits downstream of this choice. We do not own warehouse counts or order transactions. We help normalize and expose product, variant, availability, and channel facts from the operational source so storefronts, feeds, marketplaces, search, and AI-shopping surfaces can use them. That handoff is useful only when the source cadence and product identities are clear.

## What a perpetual inventory system records

Perpetual tracking turns inventory movement into a sequence of ledger events. A typical flow looks like this:

1. A receipt adds accepted units to a specific SKU and location.
2. An order reserves or commits units according to the merchant's allocation rule.
3. A shipment, cancellation, return, transfer, damage report, or adjustment changes the relevant status and quantity.
4. The source system recalculates on-hand, reserved, and available-to-sell quantities.
5. The new availability is sent to the storefront, marketplace, feed, or other destination.

This gives an operator a usable answer between physical counts and a trail for investigating changes. It only works when systems use the same product and location identities and send complete events. A perpetual ledger can be wrong for weeks if a point-of-sale sale is missed, a return never moves out of quarantine, or a marketplace listing maps to the wrong variant.

Perpetual does not mean every destination updates at the same instant. The ledger may change when an order is captured while a marketplace receives the update in a batch. Record cadence and downstream synchronization are separate decisions.

## What a periodic inventory system records

Periodic tracking treats the physical count as the point at which the inventory balance becomes known. Purchase orders, sales orders, and shipment records can support operations during the period, but they do not replace the scheduled measurement.

At the end of the period, the team counts stock, investigates differences, and updates the books. The familiar [COGS calculation](https://courses.lumenlearning.com/suny-clinton-financialaccounting/chapter/periodic-inventory-system-compared-to-perpetual/) is:

> Beginning inventory + net purchases - ending inventory = COGS

That approach can be practical when a count is quick and stale availability has little commercial impact. It becomes harder when the team has many variants, stock spread across locations, or a shared pool promised across several channels. A product can sell out on Tuesday and still look available to another channel until the next count or manual adjustment.

Periodic does not mean inaccurate by definition. A careful count can correct receiving errors, shrinkage, and damaged stock that a perpetual system missed. The trade-off is that the correction arrives at the count interval rather than when the event happens.

## The accounting distinction: update cadence versus cost flow

Perpetual and periodic describe **when the quantity and inventory accounts are updated**. They do not describe **how the cost of each unit is assigned**. FIFO, weighted average, specific identification, and other cost-flow assumptions are separate choices. The same cost-flow approach can be implemented with either record-update method, with different timing and calculation mechanics.

In a typical perpetual ledger, a purchase increases inventory and a sale records COGS and reduces inventory as the transaction posts. In a periodic ledger, purchases are accumulated during the period and ending inventory is measured before COGS is finalized. The exact accounts, timing, returns treatment, and cost rules depend on the accounting setup.

For U.S. tax context, [IRS Publication 538](https://www.irs.gov/publications/p538) describes perpetual or book inventory under sound accounting practices and says a physical inventory should be taken at reasonable intervals, with the book amount adjusted to actual inventory. That is a useful guardrail: transaction-level records still need physical controls. Tax and financial-reporting rules vary by jurisdiction, reporting basis, and business circumstances, so use your accountant for a method change or filing decision.

## Example: one variant across a warehouse, store, and marketplace

Consider Northline Apparel's blue jacket, size medium, with SKU `JKT-BLU-M`. The parent product has other colors and sizes, but this child variant is the unit that must be received, sold, counted, and published. Northline has 10 units in warehouse `WH-A` and four in `Store-1`. Two warehouse units are reserved for direct-to-consumer orders, leaving 12 available to sell before safety-stock rules.

The day then produces five events:

- **Marketplace order:** one `JKT-BLU-M` is committed from `WH-A`. A perpetual record reduces available-to-sell stock as soon as the order is captured or allocated, according to Northline's rule. The marketplace and storefront can receive the lower quantity.
- **Point-of-sale sale:** one unit sells in `Store-1`. The perpetual record updates the store location, while the shared availability view recalculates the total. A periodic record can retain the last counted balance until the next count.
- **Transfer:** two units move from `WH-A` to `Store-1`. Perpetual tracking records the origin, destination, and in-transit status so the units are not promised twice. Periodic tracking needs a transfer log and a later count to make the location balances authoritative.
- **Return:** a customer sends one jacket back. Perpetual tracking can place it in a returned or quarantine status and add it to sellable stock only after inspection. A periodic process may not reflect the returned unit until a person counts it and decides its condition.
- **Damage adjustment:** one jacket is damaged during handling. A perpetual adjustment removes it from sellable stock with a reason and audit trail. Under periodic tracking, the damage can remain invisible to channel availability until the count.

The example exposes the operational difference. Perpetual tracking gives each event a place in the SKU-and-location ledger. Periodic tracking gives the team a measured snapshot at the next count. Neither works if the marketplace uses `BLUE-M`, the POS uses `JKT-BLU-M-STORE`, and no mapping tells the source system that these are the same variant. Fast propagation of a mismatched identity only spreads the error faster.

![Two inventory workflows compare transaction updates with scheduled physical counts across locations and channels](https://www.getcatalog.ai/images/blog/perpetual-vs-periodic-inventory-workflow.svg)

## Pros and cons for ecommerce operators

### Perpetual system

**Advantages**

- **Current operating signal.** You can calculate available-to-sell stock from captured events instead of waiting for the next count.
- **Better multi-location coordination.** Transfers, reservations, and store or warehouse balances can share one event history.
- **Faster decisions.** Reorder triggers, allocation rules, and channel availability can react to sales and receipts sooner.
- **Clearer investigation.** An event trail helps isolate a missed receipt, unprocessed return, wrong location, or manual adjustment.

**Trade-offs**

- **More implementation work.** You need stable SKU and location identifiers, integrations, status rules, and staff training.
- **Integration dependency.** An outage or missing webhook can leave the book balance behind the physical stock.
- **Garbage-in risk.** A wrong variant, duplicate SKU, or unapproved receipt makes the ledger precise and wrong.
- **Physical controls still matter.** Counts and adjustments find shrinkage and events that software never captured.

### Periodic system

**Advantages**

- **Low initial complexity.** A small team can start with a count sheet or simple system rather than integrating every movement.
- **A clear close.** A scheduled count can establish the inventory balance needed for a period-end report.
- **Appropriate for low-risk stock.** Slow-moving items in one location may not justify transaction-level infrastructure.
- **Physical visibility.** Counts expose damage, shrinkage, and receiving mistakes that an event ledger cannot infer.

**Trade-offs**

- **Stale availability.** Between counts, the team may not know which variant or location can fulfill an order.
- **Count burden grows with scope.** More SKUs, bins, stores, and channels make counts slower and more disruptive.
- **Delayed exception response.** Oversells, stockouts, and shrinkage may surface only after the period closes.
- **Less timely COGS.** In-period COGS and margin views may be estimates until ending inventory is measured.

## When each system fits

Choose periodic tracking when most of these statements are true:

- You carry a small number of low-velocity SKUs.
- Stock sits in one location or is not shared across locations.
- Orders are infrequent enough that a count can keep up.
- Customers can tolerate a manual availability check or a conservative stock buffer.
- The cost of a stale promise is lower than the cost of event-level infrastructure.

Choose perpetual tracking when any of these conditions creates meaningful risk:

- A fast-selling or scarce variant can sell through between counts.
- Online, in-store, wholesale, or marketplace orders draw from the same stock.
- You promise ship-from-store, pickup, regional availability, or a tight delivery window.
- Replenishment, allocation, or margin decisions depend on current SKU-level quantities.
- Overselling, canceled orders, or a channel suspension costs more than the implementation effort.

Many operators use a risk-based combination. They maintain transaction-level records for high-velocity or high-value items and locations, run cycle counts across the wider catalog, and keep a periodic full count for physical control. Define the boundary clearly. A SKU should have one named source of truth for each location and status, even if different categories receive different control intensity.

## Reconciliation and data freshness determine trust

The useful question is whether a customer-facing availability promise is based on a known, recent, reconciled record. Our [inventory management process](https://www.getcatalog.ai/blog/inventory-management-process) covers the wider operating loop. For this decision, focus on these controls.

### Reconcile a perpetual record

1. **Set a baseline.** Count by location and record opening on-hand, reserved, damaged, in-transit, and available-to-sell quantities.
2. **Capture every event.** Include receipts, reservations, shipments, cancellations, returns, transfers, damage, shrinkage, and adjustments.
3. **Compare expected with counted.** Investigate differences by event type, location, operator, and time window. Do not hide a variance inside an unexplained adjustment.
4. **Test identity and cycle-count risk.** Confirm SKU, variant, barcode, bundle, and location mappings, then count fast movers, high-value items, high-variance locations, and repeated channel errors more often.

### Reconcile a periodic record

1. Set a cadence based on velocity, margin, shrink risk, and the cost of a wrong promise.
2. Freeze or timestamp movement while counting so receipts, picks, transfers, and returns are not counted twice or missed.
3. Compare the count with purchase, sales, transfer, and return records, and record the reason for each adjustment.
4. Publish a conservative availability state between counts. Shorten the interval or move high-risk SKUs to transaction-level tracking when exceptions repeat.

### Separate ledger freshness from channel freshness

Ecommerce inventory has at least three clocks:

- **Event freshness:** how long after a receipt, sale, return, or adjustment the source record changes.
- **Propagation freshness:** how long the new record takes to reach a storefront, marketplace, feed, search index, or shopping agent.
- **Truth freshness:** how recently the physical stock was checked against the record.

A perpetual ledger can have strong event freshness and weak propagation freshness if feeds run nightly. A periodic system can have strong truth freshness at the moment of a count and weak truth freshness afterward. Track the source timestamp and destination acceptance time. In [Google Merchant Center's product data specification](https://support.google.com/merchants/answer/7052112?hl=en), availability must match the landing page, checkout, and structured data. Channel propagation is therefore part of inventory control.

This is also why perpetual inventory is not the same as real-time data synchronization. [Data synchronization](https://www.getcatalog.ai/glossary/data-synchronization) describes how changes move between systems. Perpetual inventory describes when the inventory record changes. A reliable setup needs both a complete event record and a delivery path that meets the channel's freshness tolerance.

## A practical decision checklist

Answer these questions with numbers or named owners before choosing a method:

1. **What is the source of truth?** Name the system that owns on-hand, reserved, and available-to-sell stock for every location.
2. **Which events change sellable stock?** Write down the exact trigger for receipt, reservation, shipment, cancellation, return, transfer, damage, and adjustment.
3. **How many SKUs and variants move each day?** Include bundles, kits, and channel-specific listings, not only parent products.
4. **How many locations and channels share units?** Count warehouses, stores, third-party logistics providers, your storefront, marketplaces, and wholesale allocations.
5. **How stale can a promise be?** Set a maximum age for availability by channel. A weekly count is different from a 15-minute ship-from-store promise.
6. **What is the cost of being wrong?** Estimate margin loss, canceled orders, expedited shipping, marketplace penalties, support work, and lost trust from an oversell or stockout.
7. **Can systems capture events and catch drift?** Check identifiers, webhook or file reliability, offline behavior, retries, duplicate handling, cycle-count rules, and adjustment ownership.
8. **What does finance need during the period?** Decide whether current COGS and inventory balances are required for operating decisions or only at close, then confirm the treatment with your accountant.

If the answers show low velocity, one location, and a high tolerance for stale availability, periodic tracking may be enough. If they show shared stock, fast movement, or costly oversells, use perpetual tracking for those flows. If the answers differ by category, start with a controlled transition:

1. Normalize SKU, variant, location, and channel identifiers.
2. Take and approve a baseline count, then connect the highest-risk event sources first.
3. Run old and new balances in parallel through one reconciliation cycle.
4. Move priority SKUs and channels to transaction-level updates, then expand as exception rates and freshness metrics improve.

## FAQ

### Is a perpetual inventory system truly real time?

It is transaction-level tracking, not a promise that every destination updates instantly. A source ledger may update when an order is captured while a marketplace or feed receives the change later. Measure the end-to-end freshness that your customer sees.

### Do perpetual systems eliminate physical inventory counts?

No. Physical counts find shrinkage, damage, mispicks, receiving errors, and missed events. Use cycle counts and periodic physical controls to adjust the book record to what is actually present.

### Is a periodic inventory system inaccurate?

It can be accurate at the time of a well-controlled count. Its weakness is the interval between counts, when sales, returns, transfers, and damage can make the last measured balance stale.

### Can perpetual and periodic systems use FIFO or weighted average cost?

Yes. Record-update cadence and cost-flow assumption are separate decisions. Your accountant should confirm which cost method and implementation meet the rules for your reporting and tax situation.

### Can a small ecommerce business use periodic inventory?

Yes, if its catalog, velocity, location count, and customer promises allow the team to count often enough. Use conservative buffers and manual exception handling when the storefront or marketplace cannot receive a current quantity.

### Does Catalog replace an inventory management system?

No. Catalog does not own warehouse counts, purchasing, order routing, POS transactions, or fulfillment. We help turn the product and availability records from those systems into normalized, machine-readable product data for storefronts, feeds, marketplaces, search, and AI-shopping surfaces. If you need to make those records consistent across destinations, [explore Catalog](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/perpetual-vs-periodic-inventory-system
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product identifiers: An ecommerce crosswalk that stays intact

*October 3, 2026 · Catalog Team · Product Data · 18 min read*

> Map GTIN, UPC, EAN, ISBN, SKU, MPN, ASIN, and offer IDs across variants, feeds, schema, marketplaces, and AI catalogs without corrupting data.

Product identifiers fail when one code is expected to do five jobs. A GTIN identifies a trade item. A SKU tracks a seller's stock. An ASIN belongs to Amazon. An offer ID identifies a seller's terms. These values can point to the same product, while living in different namespaces.

This guide gives you a crosswalk you can implement: define scope and grain, model variants and packaging, preserve leading zeros, validate values, and map one canonical record to feeds, product schema, marketplaces, and AI catalogs. Catalog structures normalized product data and publishes typed product objects without turning one identifier into another.

## A product identifier is a value with a scope

A product identifier is a value that lets a system distinguish one product, item, variant, package, or offer from another. The useful question is not only “what does this code mean?” It is also:

- **Who assigned it?** GS1, an ISBN agency, a manufacturer, your business, or a channel.
- **Where is it unique?** Globally, within a manufacturer, within your catalog, or inside one feed.
- **What does it identify?** A title, trade item, sellable variant, package level, listing, or offer.
- **How long must it stay stable?** Usually across price and inventory changes, and sometimes across channel or catalog migrations.

Treat those answers as data. A robust identifier record has at least `namespace`, `value`, `authority`, `entity_level`, `market`, and `status`. For example:

```json
{
  "namespace": "gtin",
  "value": "0012345678905",
  "authority": "GS1",
  "entity_level": "each",
  "market": null,
  "status": "assigned"
}
```

The value above is illustrative. A check digit can catch a transcription error, but it cannot prove that a number was assigned to your product. Keep assignment evidence and source provenance beside the value.

## The ecommerce identifier crosswalk

Start with one canonical product model. Store every external identifier in its own field, then map it to destination-specific names. Never use a generic `product_id` column as a container for values with different owners.

| Field or identifier | Namespace and authority | What one value identifies | Primary use | Stable when price or stock changes? |
| --- | --- | --- | --- | --- |
| `catalog_id` | Your catalog | Your canonical product or record | Joins, APIs, lineage, and internal updates | Yes |
| `variant_id` | Your catalog | One sellable variant | Inventory, URLs, media, and variant updates | Yes |
| `sku` | Merchant | Your stock-keeping unit | Inventory, fulfillment, and reporting | Yes |
| `gtin` | GS1 | An exact trade item at a defined package level | Cross-retailer matching and feeds | Yes |
| `upc` | GTIN-12, commonly called UPC | An exact GTIN-12 trade item | North American retail workflows | Yes |
| `ean` | GTIN-13, commonly called EAN | An exact GTIN-13 trade item | International retail workflows | Yes |
| `isbn13` | ISBN system | A book or book-like title, edition, and format | Book supply chains and feeds | Yes |
| `mpn` plus `brand` | Manufacturer | A manufacturer model or part | Technical matching and channel identifiers | Yes for the same model |
| `asin` | Amazon | An item in Amazon's catalog | Amazon listing and offer matching | Yes |
| `item_id` or feed `id` | Channel or feed | One row or item in that destination | Updates, deduplication, and diagnostics | Yes |
| `item_group_id` or `group_id` | Channel or feed | A parent listing or variant family | Connecting variants | Yes |
| `offer_id` | Seller and channel | One seller's offer for an item | Price, stock, fulfillment, and seller state | Yes |

This table is a crosswalk, not a conversion chart. A SKU does not become a GTIN because a feed calls its column `gtin`. The mapping preserves the original namespace and records the destination field separately.

Catalog's [product schema guide](https://www.getcatalog.ai/glossary/product-schema) and [SKU guide](https://www.getcatalog.ai/blog/what-is-a-sku) cover the adjacent concepts. The operating rule is simple: one canonical record can hold many identifiers, while each identifier keeps its own scope.

## Global and standard identifiers

### GTIN, UPC, EAN, and the barcode carrier

A GTIN is the GS1 identifier value for a trade item. GS1 defines GTIN-8, GTIN-12, GTIN-13, and GTIN-14 formats. GTIN-12 is commonly called UPC, and GTIN-13 is commonly called EAN or JAN. GTIN-14 is commonly used for cases and packaging. The exact value depends on the trade item and the package level. [GS1's GTIN guidance](https://support.gs1.org/support/solutions/articles/43000734124-what-is-the-difference-between-a-gs1-gtin-a-barcode-an-ean-and-a-upc-) explains the distinction.

A barcode is the printed or digital carrier. The GTIN is the number encoded by that carrier. A UPC-A or EAN-13 symbol can carry a GTIN value, and the same value can also travel in a feed or schema field without an image of the bars. Store the number as a string, with the exact digits and no display formatting in your outbound feed.

A GTIN identifies a specific trade item. It does not identify a variant family. If a manufacturer assigns separate GTINs to a red shirt and a blue shirt, retain both values on their respective variants. If a case, inner pack, and each unit are separate trade items, model their package-level GTINs separately. Catalog's [GTIN explanation](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number) provides a reference for teams documenting the policy.

### ISBN

An ISBN identifies a book or book-like product within the ISBN system. It identifies a title or particular edition from a publisher, so each format or binding, such as hardcover, paperback, ebook, or audiobook, can require its own ISBN. A revised edition also needs a new ISBN. [ISBN.org's FAQ](https://www.isbn.org/faqs_general_questions) documents those edition rules.

ISBNs assigned under the current system are ISBN-13 values. ISBN-10 values still appear in older records. Keep both in a migration field when you need historical lookup, then send the format required by the destination. [Google Merchant Center accepts an ISBN as a GTIN](https://support.google.com/merchants/answer/160161?hl=en), while the current [OpenAI product feed specification](https://developers.openai.com/commerce/specs/file-upload/products) says to submit ISBN-13 and omit ISBN-10.

An ISBN is a number. A barcode is a graphic that carries numerical data. Keep `isbn13` and `barcode_image` as separate fields, just as you keep `gtin` and the barcode asset separate.

## Merchant, manufacturer, and platform identifiers

### SKU: your inventory namespace

A SKU is a seller-defined stock-keeping unit. It is useful for inventory, picking, fulfillment, reporting, and internal integrations. Shopify describes SKUs as internal codes for tracking inventory and sales, and recommends a unique SKU for each product variant in its admin. Read [Shopify's SKU guidance](https://help.shopify.com/en/manual/products/details/sku) for that implementation context.

A SKU has no universal meaning outside the merchant that created it. Two retailers can use different SKUs for the same GTIN. A single retailer should keep each sellable variant's SKU unique within the scope used by its inventory and order systems. If you operate multiple stores or regions, document whether uniqueness is global, per legal entity, or per location.

Use a stable SKU that helps people operate the catalog, while keeping the canonical `variant_id` independent. If an ERP migration changes SKU policy, you can preserve the product relationship and retain the old SKU as an alias instead of breaking every destination join.

### MPN and brand: a manufacturer pair

An MPN is the manufacturer's part or model number. Its authority is the manufacturer, and its meaning depends on the associated brand. Store `mpn` and `brand` as separate fields, then validate them as a pair when a channel expects both.

Do not promote a merchant SKU into an MPN. Do not invent an MPN when a manufacturer has not assigned one. For a product with multiple manufacturer variants, use the most specific manufacturer value available and keep the variant relationship explicit. Google's [unique identifier rules](https://support.google.com/merchants/answer/160161?hl=en) warn against guessing values or placing internal SKUs in the wrong identifier fields.

Brand is descriptive identity and matching context. It is not a replacement for GTIN or MPN. A brand name alone can describe thousands of products, so keep it alongside the identifier it qualifies.

### ASIN: Amazon's catalog namespace

An ASIN is Amazon's 10-character alphanumeric identifier for an item in the Amazon store. Amazon assigns it to a catalog listing, and Amazon's own [ASIN guide](https://sell.amazon.com/blog/what-is-an-asin?mons_sel_locale=en_US) explains how sellers use it to match an offer to an existing product page. Books use their ISBN as the underlying book identifier in Amazon workflows, as Amazon's [listing guide](https://sell.amazon.com/blog/how-to-create-a-new-asin-amazon?mons_sel_locale=en_US) explains.

An ASIN is platform-scoped. Keep it in an `amazon.asin` field and never use it as your global product key. A product sold on Amazon, Google, and your storefront can have one ASIN, one GTIN, one merchant SKU, and three different feed IDs. Those values form a crosswalk; none replaces the others.

When the same record travels through several marketplaces, keep those channel mappings beside the core identity. Catalog's guide to [third-party marketplaces](https://www.getcatalog.ai/blog/third-party-marketplace) explains why each listing is a structured offer with its own rules.

## Items, groups, offers, and packaging are different grains

The hardest identifier errors come from mixing the thing being sold with the listing that presents it and the offer that makes it purchasable.

- **Product or group:** A family such as “Commuter jacket.” It can contain color and size choices.
- **Item or variant:** “Commuter jacket, navy, medium.” It has its own inventory, URL or selected options, image, and often its own SKU and GTIN.
- **Offer:** A seller's commercial promise for that item, including price, availability, seller, fulfillment, region, and returns. Multiple sellers can offer the same item.
- **Package or trade item:** A unit, inner pack, case, or pallet that can have its own quantity, dimensions, and GTIN.

A parent ID groups records. It does not identify a purchasable unit. An item ID identifies the row or sellable item in a destination. An offer ID identifies seller-specific commercial state. Keep them as separate columns even when a destination uses a single word such as “id.”

### Variants

Define a variant rule before assigning IDs. A color or size creates a new variant when it changes the sellable item, inventory, price, image, fulfillment, or identifier. A seller-created display option that does not change the item can remain an attribute. Record the decision in your catalog policy instead of letting each channel decide independently.

For every sellable variant, keep:

- a unique `variant_id` and merchant SKU;
- a stable parent or group relationship;
- the variant's own price and availability;
- the selected option values, such as `color` and `size`;
- the exact GTIN or MPN when assigned to that variant;
- a selected-variant URL and image when the destination supports them.

OpenAI's current feed model makes this separation explicit: `item_id` identifies the specific item, `group_id` identifies the parent listing, and `offer_id` identifies the seller's offer. It asks for a separate row per variant, with a distinct item ID and the same group ID. Google's feed model uses `id` and `item_group_id` for a similar distinction. These are destination contracts, so map them from your canonical model rather than renaming your source fields.

![OpenAI product feed fields for variant groups, item IDs, and group IDs.](https://www.getcatalog.ai/images/blog/openai-product-feed-variants.svg)

### Packaging and multipacks

Add a package-level field such as `package_level` with values like `each`, `inner`, `case`, or `pallet`, plus `units_per_package`. That makes a 12-pack distinguishable from one unit even when the product title looks similar.

A manufacturer-created multipack can be its own trade item with its own GTIN. A retailer-created bundle may have no manufacturer GTIN, so represent the bundle with your own `catalog_id`, SKU, offer, and component relationships, then follow the destination's bundle rules. Never send the single-unit GTIN as though it identifies the bundle. That makes the feed describe a different quantity than the shopper receives.

## Store identifiers as typed strings and validate them in layers

Identifiers should be handled as typed strings. A numeric import can turn `0012345678905` into `12345678905`, permanently changing the value.

Keep a normalized value for machine output and an optional display value for people. For example:

```json
{
  "gtin": "0012345678905",
  "gtin_display": "00 123456 78905",
  "sku": "NL-JKT-NVY-M",
  "mpn": "NL-JKT-24-NVY-M"
}
```

The display value is optional. The canonical value must preserve leading zeros. Do not remove punctuation from an MPN unless the destination explicitly requires it. Do not trim or convert ISBN values with a generic GTIN function.

Use layered validation:

1. **Syntax:** Check allowed characters and the expected length for GTIN-8, -12, -13, or -14, ISBN-10 or ISBN-13, ASIN, and each channel ID.
2. **Check digit:** Validate GTIN and ISBN check digits with their own algorithms. For a GTIN, calculate from the rightmost digit before the check digit using alternating weights of 3 and 1, then require the total to be divisible by 10.
3. **Assignment:** Confirm the value came from the relevant GS1, ISBN, manufacturer, or channel record. A mathematically valid value can still be unassigned or assigned to a different item.
4. **Scope uniqueness:** Reject duplicates within the namespace and entity level. The same string can be valid in separate namespaces, such as a merchant SKU and an ASIN.
5. **Cross-field consistency:** Check brand plus MPN, GTIN plus package level, ISBN plus format, and variant attributes against the source record.
6. **Relationship integrity:** Ensure each item belongs to one intended group, each offer points to one item, and package components resolve to real records.
7. **Destination rules:** Validate the final feed, schema, and marketplace output after mapping. A clean source value can fail if a destination expects a different field, format, or omission rule.

Use `null` or an explicit missing state when an identifier does not exist. Empty strings and guessed values create ambiguous records. Google advises omitting GTIN, brand, and MPN when no assigned identifier exists, and using the destination's missing-identifier flag where applicable. Catalog's [product data quality guide](https://www.getcatalog.ai/blog/product-data-quality) covers the broader checks for invalid, duplicate, mismatched, and stale values.

## Map the canonical record to feeds, schema, and AI catalogs

The source catalog remains the system of record. A feed, page schema, or AI catalog object is a view with its own contract.

| Canonical field | Google Merchant Center | Schema.org | AI catalog feed example |
| --- | --- | --- | --- |
| `variant_id` | `id` or stable feed ID | `Product.sku` when it is the merchant SKU | `item_id` |
| Parent `catalog_id` | `item_group_id` | `ProductGroup` and `isVariantOf` relationships | `group_id` |
| `gtin` | `gtin` | `gtin`, `gtin8`, `gtin12`, `gtin13`, or `gtin14` | `gtin` |
| `isbn13` | `gtin` when the destination accepts ISBN as GTIN | `gtin13` | `gtin` as ISBN-13 |
| `mpn` | `mpn` | `mpn` | `mpn` |
| `brand` | `brand` | `brand` | `brand` |
| Seller-specific offer | Channel offer fields | `Offer` and seller context | `offer_id` |
| Variant options | `color`, `size`, and other destination fields | `hasVariant` and typed properties | `variant_dict` |

Google defines its feed `id` as a stable value for the same item and says a SKU can be used where appropriate. That field still sits beside `gtin`, `mpn`, `brand`, and `item_group_id`; it does not replace them. Its [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) also warns that incorrect identifiers and variant relationships can cause disapprovals, limited eligibility, or incorrect displays.

Schema.org provides distinct properties for merchant SKU, GTIN forms, MPN, brand, and generic identifiers. Use the property that matches the value, then make the markup agree with the visible product page. Google's [Product structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/product) describes eligibility and variant relationships; it does not guarantee a particular display.

For an AI catalog, expose the same typed object rather than flattening it into a title. OpenAI's current product-feed spec requires a stable item ID per item or variant, separates `group_id` and `offer_id`, preserves GTIN leading zeros, and pairs MPN with brand. It also says to keep IDs stable when price, stock, title, or images change. Feed access and supported fields depend on the integration, so keep your mapping versioned.

This is where Catalog fits. We normalize product records, retain identifier provenance, map fields to channel contracts, publish live product data to AI shopping surfaces, keep updates synchronized, and measure outcomes. We do not manufacture a missing GTIN or treat an SKU as a global identity. The value is a product data layer that keeps the crosswalk intact as each destination changes shape.

## Common identifier mistakes

- **Putting a barcode image in the GTIN field:** A barcode is a carrier. Extract and validate the encoded value separately.
- **Treating UPC, EAN, and GTIN as unrelated systems:** UPC and EAN are common names for GTIN formats. Keep the source format and normalized GTIN representation.
- **Loading identifiers as numbers:** Leading zeros disappear in spreadsheets, JSON transforms, and databases. Store strings from ingestion through export.
- **Using one value for every variant:** A parent listing can share a group ID, while each sellable variant needs its own item and inventory identity.
- **Using the unit GTIN for a case or bundle:** Match the identifier to the quantity the shopper receives.
- **Sending a SKU as GTIN or MPN:** A merchant-defined value cannot stand in for a manufacturer or GS1 value.
- **Guessing an identifier:** A valid-looking code can belong to another product. Preserve missing state and assignment evidence.
- **Using an ASIN as a global key:** ASIN belongs to Amazon's catalog. Keep it as a channel mapping.
- **Reusing an ISBN across formats:** Hardcover, paperback, ebook, audiobook, and revised editions can have separate ISBNs.
- **Changing IDs with commercial state:** Price and stock updates should change offer fields, not the item or group key. Keep price out of offer IDs.
- **Letting each feed define the source model:** Destination schemas change. Version the mapping and fix the canonical record upstream.

## Product identifier implementation checklist

Use this sequence when you build or repair a crosswalk:

1. **List namespaces:** Document every authority, including GS1, ISBN, manufacturers, your catalog, Amazon, marketplaces, and feed contracts.
2. **Set the grain:** Decide whether each field identifies a family, variant, package, feed row, or offer.
3. **Define ownership:** Name the source and accountable owner for every identifier field.
4. **Create typed fields:** Separate `catalog_id`, `variant_id`, `sku`, `gtin`, `isbn13`, `mpn`, `brand`, platform IDs, group IDs, and offer IDs.
5. **Store strings:** Preserve leading zeros, exact MPN casing, ISBN format, and source formatting in separate canonical and display fields.
6. **Model relationships:** Add parent, variant, package, component, seller, and offer relationships before exporting.
7. **Validate in layers:** Run syntax, check-digit, assignment, uniqueness, cross-field, relationship, and destination checks.
8. **Map by contract:** Create versioned mappings for feeds, Schema.org, marketplaces, and AI catalog integrations.
9. **Test the rendered output:** Compare each sample product page, feed row, schema object, and channel record against the same source variant.
10. **Monitor the loop:** Track rejected rows, duplicate values, stale mappings, variant mismatches, and time from source change to destination update.

## FAQs

### Is a product identifier the same as a SKU?

No. A SKU is one kind of product identifier, scoped to the merchant that created it. A GTIN or ISBN can identify an item across trading partners, while a SKU supports one seller's operations. Keep both when you have both.

### Are UPC, EAN, and GTIN the same thing?

UPC and EAN are common names for GTIN-12 and GTIN-13 values. They describe formats within the GTIN family. A barcode symbol is the carrier, so the barcode image and the GTIN value still belong in separate fields.

### Can I use a SKU as a GTIN?

No. Use a SKU in the destination's item or merchant-ID field when allowed. Submit a GTIN only when the manufacturer or relevant authority assigned that value. If no identifier exists, use the destination's supported missing-identifier state.

### Does every product need a GTIN?

No. Some products, custom goods, and bundles have no assigned GTIN. Keep the field empty, retain the reason and source evidence, and follow each destination's rules for `identifier_exists` or an equivalent field. Never fill the gap with a guessed number.

### Should variants share a GTIN?

A GTIN identifies a trade item, so variants with different assigned trade-item identities need different values. Variants can share a parent or group ID. The correct split depends on the physical item, package, manufacturer assignment, and destination rules.

### Is an ISBN also a GTIN?

ISBN-13 is a book identifier that can be carried in a GTIN field where a destination accepts it. Keep `isbn13` as its source field so you retain the book-specific meaning, and follow the destination's format rules for older ISBN-10 records.

### What is the difference between an item ID, group ID, and offer ID?

An item ID identifies one destination item or variant. A group ID connects related variants under one listing. An offer ID identifies a seller's commercial offer for an item. They can all refer to the same product while representing different grains and ownership.

### How does Catalog help with product identifiers?

Catalog gives merchants a structured product data layer for normalizing identifiers, mapping variants and offers, publishing machine-readable product objects, keeping updates synchronized, and measuring how downstream AI shopping surfaces use the catalog. Your existing storefront and operational systems can remain in place.

## Keep the crosswalk intact

A product identifier only works when its namespace, authority, and entity level travel with the value. Give every sellable item a stable internal key, preserve assigned external IDs, model groups and offers separately, validate before publishing, and map each destination from the same canonical record.

Catalog helps brands turn that model into live, normalized product data for feeds, structured pages, marketplaces, and AI commerce. [See how Catalog can structure and distribute your catalog](https://www.getcatalog.ai/) while your storefront stays in place.

---

Canonical: https://www.getcatalog.ai/blog/product-identifier
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# ASIN number: what it is and how to use it

*October 3, 2026 · Catalog Team · Product Data · 14 min read*

> Learn what an ASIN number is, where to find it, how Amazon assigns one, and how to map ASINs to GTINs, SKUs, and product variants for Amazon listings.

If your team sells on Amazon, one code determines whether you join the right detail page or create a duplicate. That code is the ASIN. It belongs to Amazon’s catalog, while your GTIN, SKU, and MPN identify the product elsewhere or inside your own operations.

Find the value in the URL, product details, or Seller Central. Then use it to decide whether to match an existing listing or submit a new one, model parent and child variations, and connect Amazon identity to normalized product data. Catalog helps teams structure that record. Amazon assigns the ASIN.

## What is an ASIN number?

An **ASIN**, short for **Amazon Standard Identification Number**, is a unique 10-character alphanumeric identifier that Amazon assigns to a product in its store. It identifies the product record and its detail page inside Amazon’s catalog. A non-book example looks like `B0D1XD1ZV3`.

Amazon’s current [ASIN guide](https://sell.amazon.com/blog/what-is-an-asin?mons_sel_locale=en_US) describes the code as 10 characters, so “10-character” is the accurate description. “10-digit ASIN” is an older phrase that misses the letters in most product codes.

An ASIN has a narrow job:

- **Owner:** Amazon assigns and controls it.
- **Scope:** It identifies a product in the Amazon catalog, rather than across every retailer.
- **Length:** It contains 10 letters and numbers.
- **Listing role:** It anchors a product detail page where one or more sellers can place offers.
- **Seller role:** You use it to match inventory, manage listings, run Amazon Ads, and connect marketplace data to the right product.

An ASIN identifies the product page. A seller’s offer on that page carries changing facts such as price, quantity, condition, and fulfillment method. Several sellers can offer the same product through one ASIN, and each seller can use a different SKU for that offer.

Books have a special case. Amazon uses the book’s ISBN as its product identifier, and an Amazon book ASIN may match an ISBN-10 value. The current ISBN standard is 13 digits, and separate editions and formats receive separate ISBNs. Do not assume that an ISBN-13 can be copied into a generic 10-character ASIN field.

## Where to find an ASIN

You can usually find an ASIN in three places.

1. **Product URL.** In an Amazon product URL, look for the value after `/dp/`. For example, in `amazon.com/dp/B0D1XD1ZV3`, `B0D1XD1ZV3` is the ASIN. Some Amazon URLs use a longer path or add tracking parameters, so use the `/dp/` value rather than the title slug.
2. **Product information.** On the detail page, scroll to **Product information** or **Product details**. The ASIN appears in the technical details table alongside fields such as manufacturer and model number.
3. **Seller tools.** In Seller Central, the product’s listing and inventory views expose the ASIN. Amazon’s seller guide also points sellers to **Manage All Inventory** for lookup.

![Amazon product information showing the ASIN field.](https://www.getcatalog.ai/images/blog/asin-product-details.svg)

For a product with color, size, pack, or other variations, select the exact option before recording the value. A variation page can group several child products, and each buyable child has its own ASIN. Store the child ASIN for the item you stock and sell, along with the parent relationship.

The quickest programmatic lookup is usually the detail-page URL, but the URL alone is not a product-match decision. Confirm the brand, model, pack count, and variant attributes before you connect an ASIN to your catalog.

## ASIN vs. GTIN, UPC, EAN, SKU, MPN, and ISBN

Product teams often put several identifiers in the same spreadsheet column. They answer different identity questions, so keep them in separate fields.

| Identifier | Who assigns it | What it identifies | Where it works |
| --- | --- | --- | --- |
| **ASIN** | Amazon | A product record in Amazon’s catalog | Amazon’s store and seller tools |
| **GTIN** | GS1 | A globally unique trade item | Retailers, marketplaces, feeds, and supply-chain systems |
| **UPC** | GS1 | A common 12-digit GTIN format, GTIN-12 | Retail and product matching, especially in North America |
| **EAN** | GS1 | A common 13-digit GTIN format, GTIN-13 | Retail and product matching, especially outside North America |
| **Seller SKU** | The seller or merchant | Your inventory item or variant | Your store, ERP, warehouse, and seller account |
| **MPN** | The manufacturer | A manufacturer’s part or model | Manufacturer, distributor, support, and product data systems |
| **ISBN** | An ISBN agency for a publisher | A specific book title, edition, and format | Publishing, bookselling, libraries, and book listings |

A **GTIN** is the global product identifier. UPC and EAN are common GTIN formats, not replacements for an ASIN. GS1’s [identifier explainer](https://support.gs1.org/support/solutions/articles/43000734124-what-is-the-difference-between-a-gs1-gtin-a-barcode-an-ean-and-a-upc-) distinguishes the number from the barcode that carries it. Amazon may use a valid GTIN to find or create a catalog record, then assign an ASIN for that record. For a commerce-operations view of formats and storage, see Catalog’s [GTIN guide](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number).

A **seller SKU** is your operational key. You can choose a value such as `TEE-CRW-BLK-M`, and another seller can choose a different SKU for the same Amazon product. Catalog’s [SKU guide](https://www.getcatalog.ai/blog/what-is-a-sku) explains why that internal code should remain separate from global and channel identifiers.

An **MPN** comes from the manufacturer. It can help you confirm that the model is correct, especially when product titles are similar. It does not give Amazon permission to create a duplicate listing, and it does not replace a GTIN or ASIN.

An **ISBN** is for books and publications. The [International ISBN Agency](https://www.isbn-international.org/index.php/content/what-isbn/10) says that each edition and format should have its own ISBN. Amazon may use that book identifier as the ASIN value, but the two systems still have different owners and scopes.

The practical model is simple: a product can have a GTIN, MPN or ISBN, seller SKU, and ASIN at the same time. Keep all of them. Map them to one canonical product or variant record instead of forcing one code to serve every channel.

## Match an existing ASIN or create a new one

Amazon’s listing workflow has a clear first decision: **find an exact product in the catalog before creating anything**.

### When the product already exists

Use an existing ASIN when the Amazon detail page represents the exact product you sell. In Seller Central, the usual path is **Catalog > Add Products > Product IDs**. Search with the product’s GTIN or another accepted product ID, then inspect the result.

Before matching, compare:

- brand and manufacturer;
- model or MPN;
- GTIN, UPC, EAN, or ISBN where applicable;
- product version, language, region, or voltage;
- size, color, flavor, material, or other variant attributes;
- unit count, pack size, and included components;
- product images and the exact condition you offer.

If the result is exact, choose the option to sell that product and add your offer details, such as price, quantity, condition, and fulfillment method. Amazon may require approval for a brand or category before you can add the offer.

Matching the exact child ASIN prevents a common operational failure: the inventory record says “black, medium, 2-pack,” while the offer points to a single-unit, blue, small product page. Search by title alone makes that mistake more likely.

### When the product is new to Amazon

If no exact product exists, submit a new product detail page through Amazon’s listing workflow. Amazon’s [new-ASIN workflow](https://sell.amazon.com/blog/how-to-create-a-new-asin-amazon?mons_sel_locale=en_US) describes the sequence:

1. Search the catalog with a product ID.
2. Select **Create a new listing** when no matching product appears.
3. Enter product identity, description, product details, offer, and safety or compliance information.
4. Submit the page for review.
5. Receive an ASIN after Amazon accepts the new product record.

You do not choose the ASIN. Amazon assigns it after the listing is accepted. Catalog does not assign ASINs, and GS1 does not issue them.

Product ID, brand, category, and approval requirements vary. Use the identifier that belongs to the product, and follow the listing rules for the category and marketplace. A product that lacks an accepted GTIN may have an exemption path, while another category may require a specific identifier or approval. Never invent a GTIN or borrow one from a similar product to force a match.

For a large catalog, Amazon also supports spreadsheet templates that match existing products or create new listings in bulk. The file should still contain one accurate row per sellable variant, with the right identifiers and attributes. Bulk upload changes the delivery method, not the identity rules.

## Parent and child ASINs for variations

A variation family connects related versions of one product. It has three parts:

- **Parent ASIN:** a virtual, non-buyable connector for the family.
- **Child ASIN:** a buyable product or variant with its own ASIN.
- **Variation theme:** the category-supported attribute that explains the relationship, such as size or color.

For example, a T-shirt family may have a parent that groups black, white, and navy options. “Black, medium” is a child product with its own ASIN, GTIN where applicable, SKU, and inventory. The parent helps shoppers navigate the family. The child is the record that should carry the offer and stock.

Amazon’s [variation guidance](https://sell.amazon.com/blog/amazon-variation-listing) limits variation families to products that share the same type, brand, and style or function. The allowed themes depend on the category. A new model, a materially different product, or an improvised multipack should not be attached to an old family just to combine reviews or traffic. A pack count can be a valid variation in some categories, so use the theme Amazon provides for that category and keep the packaging level explicit.

Model the relationship in your own catalog as well:

| Record | Store | Do not substitute |
| --- | --- | --- |
| Product family | Parent product ID and, when present, parent ASIN | A sellable SKU or child ASIN |
| Sellable variant | Child ASIN, SKU, GTIN, MPN or ISBN, and structured variant attributes | The parent ASIN alone |
| Seller offer | Seller ID, offer status, price, quantity, condition, and fulfillment | Product identity fields |

This separation lets you update a price or stock level without changing product identity. It also prevents a parent code from leaking into a feed that needs the exact child product.

## Common ASIN mistakes

### Creating a duplicate detail page

A product already in Amazon’s catalog should receive another offer on the existing ASIN. Creating a second detail page splits sales, inventory, reviews, and product facts. Search with a product ID first, then match only after the result represents the exact item.

### Treating an ASIN as a universal product ID

An ASIN works inside Amazon’s catalog. It is not a substitute for the GTIN, MPN, ISBN, or your internal SKU when you publish to another retailer, a shopping feed, a warehouse, or your own storefront. Keep the cross-channel identifier beside the ASIN.

### Matching a similar variant

A title can look right while the unit count, size, voltage, region, or included accessory is wrong. Store those attributes as structured fields and compare them before matching. The safest match is an exact product and exact child variant.

### Using a parent ASIN for inventory

The parent is a connector. It does not represent a buyable unit. Use the child ASIN and variant SKU for inventory, offer, fulfillment, and reporting records.

### Reusing or editing an identifier value

Store ASINs as text and preserve every character, including letters, leading zeros, and capitalization. Do not derive an ASIN by changing a SKU, MPN, or GTIN. Do not recycle a retired value for a different product.

### Sending an unauthorized or invented product ID

A GTIN should come from the product’s valid GS1 record and your authorized product source. An MPN should match the manufacturer’s part. An ISBN should match the book edition and format. A plausible-looking identifier is still the wrong identifier if it describes a different item.

### Letting each channel become its own source of truth

A marketplace export may contain an ASIN, while the ERP has a SKU and the supplier file has a GTIN. If each system edits product facts independently, variant relationships and availability drift. Map channel IDs to one canonical record and keep ownership clear for every field.

## ASINs in normalized product data

An ASIN becomes useful outside Seller Central when it sits beside the facts that give it meaning. A normalized record can represent the same product across your storefront, Amazon, retail feeds, and AI shopping surfaces without pretending those channels use the same identifier.

A variant-level record might look like this:

```yaml
product_id: prod_482019
parent_product_id: prod_482000
variant_id: var_482019
brand: Northstar Apparel
identifiers:
  amazon_us_asin: B0ABC12345
  gtin: "00815587001234"
  seller_sku: TEE-CRW-BLK-M
  mpn: NS-TEE-CRW
variant:
  color: black
  size: medium
  pack_count: 1
channel_status:
  amazon_us: matched
  storefront: active
```

The useful rules are:

1. **Keep identifiers typed.** An ASIN is an Amazon channel identifier. A GTIN is a global trade-item identifier. A SKU is an internal operations key. Separate fields make validation possible.
2. **Keep variants explicit.** Color, size, pack count, model, and other attributes should be data fields, not information hidden inside a code.
3. **Keep channel status separate.** `matched`, `create_pending`, `active`, and `retired` describe the relationship with a channel. They are not product identity.
4. **Keep provenance and ownership.** Record whether a value came from Amazon, GS1, your ERP, a manufacturer, or a supplier, and define which system can correct it.

Catalog works at this product data layer. We can normalize identifiers, resolve variant relationships, enrich missing attributes, and publish machine-readable product objects to feeds, APIs, structured data, search, and AI shopping surfaces. We do not issue GTINs or assign ASINs. Amazon remains the source of ASIN assignment, and the identifier still needs an accurate product record around it.

## ASIN number FAQ

### Is an ASIN the same as a GTIN or UPC?

No. An ASIN is assigned by Amazon for its catalog. A GTIN is a GS1 identifier that can identify the same trade item across retailers. A UPC is one common GTIN format. Amazon can use a GTIN to match or create a listing, then assign an ASIN to the Amazon product record.

### How many digits are in an ASIN?

An ASIN has 10 **characters**, which can be letters and numbers. Calling it a 10-digit code is inaccurate for most products. Books can use ISBN-based identifiers, so book values need separate ISBN handling.

### Can a seller create or choose an ASIN?

A seller can submit a new product listing, but Amazon assigns the ASIN after accepting the product detail page. You choose your seller SKU. You do not choose an arbitrary ASIN or turn a GTIN into one yourself.

### Does each product variation have its own ASIN?

Each buyable product variation receives its own child ASIN. A parent ASIN groups related children and is not the inventory identifier. The variation theme and category rules determine which products belong together.

### Is an ASIN the same as a seller SKU?

No. Amazon assigns the ASIN, and it identifies the Amazon product record. You or your selling system assigns the SKU, and it identifies your inventory record or offer. Keep both values in your product data model.

### Can I use an ASIN outside Amazon?

You can store an ASIN in a cross-channel catalog as an Amazon reference, but it does not replace the product’s GTIN, MPN, ISBN, or internal ID elsewhere. Use the identifier required by each destination and map those values to the same canonical variant.

If your team needs one normalized, machine-readable catalog that keeps ASINs beside GTINs, SKUs, MPNs, variants, price, and availability, explore Catalog’s [product data layer](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce).

---

Canonical: https://www.getcatalog.ai/blog/asin-number
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Digital shelf: the operating guide for product visibility

*October 3, 2026 · Catalog Team · Product Data · 14 min read*

> Learn what the digital shelf includes, how to monitor and optimize it, and which product data, channel, and business metrics to manage across channels.

A shopper can discover a product in search, compare it on a marketplace, ask an AI assistant about it, and buy from a brand or retailer. Each handoff changes what the shopper sees and what the channel can understand. A missing attribute, stale price, or broken variant can interrupt the journey.

A digital shelf program gives those touchpoints a shared operating model. It connects product data, channel requirements, shopper signals, and business outcomes so your team can find the next fix instead of guessing.

## What the digital shelf means

The **digital shelf** is the network of online touchpoints where a shopper, or a shopping assistant acting for them, can discover, understand, compare, and buy a product. [Salsify describes it](https://www.salsify.com/what-is-the-digital-shelf) as a collection of diverse, changing digital touchpoints. [Inriver uses a similar frame](https://community.inriver.com/hc/en-us/articles/6774023322140-A-guide-to-understand-the-Digital-Shelf), centered on the places where people find, learn about, and purchase products.

That network includes your storefront, retailer and marketplace listings, product feeds, search and image surfaces, social-commerce catalogs, review pages, and AI shopping interfaces. It also includes the product data behind those surfaces. A shopper may never see a feed or API, yet those inputs affect whether a listing is eligible, complete, current, and understandable.

Digital shelf and ecommerce are related terms with different jobs. Ecommerce is the act of selling and buying online. The digital shelf is the broader set of places and information that shape discovery and evaluation before, during, and after that purchase. Someone can use the digital shelf on a phone in a physical store and complete the purchase at the shelf, at a checkout counter, or later online.

![A shopper-facing product page beside a machine-readable product record](https://www.getcatalog.ai/images/blog/catalog-parallel-storefront.svg)

### Digital shelf, PIM, feed, and analytics are different layers

These terms often appear together, although they describe different parts of the work:

| Term | What it is | The question it answers |
| --- | --- | --- |
| Digital shelf | The customer-facing network of commerce touchpoints | Where can a product be found, understood, compared, and bought? |
| Product information management (PIM) | A system and process for governing internal product information | Which product record is approved and which team owns it? |
| Product feed | A structured file or stream sent to a channel | Which fields and values does this destination receive? |
| Digital shelf analytics | The observation and analysis layer | What is live, visible, accurate, competitive, and performing? |
| Optimization | The action and learning loop | Which product, channel, or operating change should happen next? |

A PIM can be the source of truth. A feed can be one delivery output. A digital shelf analytics tool can show what a retailer or marketplace displays. None of those terms alone describes the whole customer-facing network.

## Why the digital shelf matters

Online product information often carries the job that packaging, shelf placement, and a store associate carry in a physical shop. Shoppers need enough detail to decide whether an item fits their need, budget, compatibility requirements, and delivery expectations.

Common failures include:

- A listing is live, but its main image is missing or fails channel rules.
- A size or color variant has the wrong parent, price, or availability.
- A feed says “in stock” while the product page or checkout says “unavailable.”
- A title omits the attribute shoppers use to narrow the category.
- Reviews belong to a different pack size or variant.
- Search or AI systems cannot identify dimensions, material, compatibility, or current price.

The product can still be good. The digital shelf has failed to make that value legible at the point of choice.

## The main digital-shelf touchpoints

Each touchpoint has its own data contract, rendering rules, and shopper behavior. Start with a common product record, then adapt it to each destination.

| Touchpoint | What shoppers or assistants use | What teams need to manage |
| --- | --- | --- |
| **Owned storefront** | Homepage modules, category pages, site search, product detail pages, checkout, and pickup or delivery options | Full product content, navigation, variants, structured data, page performance, reviews, inventory, price, shipping, and returns |
| **Retailer and marketplace listings** | Retailer search, category shelves, product detail pages, comparison views, seller offers, and retailer reviews | Retailer taxonomy, required attributes, identifiers, images, seller and offer data, content compliance, availability, and retailer-specific rules |
| **Product feeds and search surfaces** | Google Search, Images, Shopping, Lens, Maps, paid listings, affiliates, and comparison services | Feed schemas, product IDs, titles, descriptions, categories, images, price, currency, availability, shipping, returns, and update frequency |
| **Social commerce** | Shoppable posts, creator content, live streams, product tags, and in-app catalogs | Catalog IDs, product links, variant mapping, media, prices, stock, policy fields, and a reliable handoff from content to product page or checkout |
| **AI shopping surfaces** | Conversational discovery, comparison, recommendations, and shopping actions in systems such as ChatGPT, Gemini, Claude, and Perplexity | Machine-readable product facts, clear attributes, variant relationships, current price and availability, shipping and returns, evidence for claims, and source URLs |

Google [lists these ecommerce surfaces](https://developers.google.com/search/docs/specialty/ecommerce/where-ecommerce-data-can-appear-on-google): Search, Images, Lens, the Shopping tab, Business Profile, and Maps. [Merchant Center’s specification](https://support.google.com/merchants/answer/7052112?hl=en) requires attributes such as price and availability, and Google recommends matching them across the feed, landing page, structured data, and checkout. These practices support eligibility and consistency. They do not guarantee a ranking, rich result, conversion, or AI recommendation.

The AI-shopping row is an emerging part of the shelf. Requirements vary by system and continue to change. Treat it as an additional machine-facing destination that depends on the same product truth, rather than as a replacement for storefronts, marketplaces, feeds, or social commerce.

## What to manage on the digital shelf

A useful scorecard joins product-data health with what shoppers can see and do. The exact fields differ by category, country, and channel, yet the core signals are consistent.

### Content quality and completeness

Check each listing for a clear title and description, correct taxonomy, stable identifiers, complete category attributes, variant relationships, and approved media. Common fields include SKU, GTIN, UPC, MPN, brand, dimensions, weight, material, ingredients, fit, compatibility, care, images, video, alt text, and manuals.

Measure completeness by channel and category. Track rejected or suppressed items separately from items that are technically live but thin. A listing can pass a validator and still leave shoppers unable to compare it.

### Availability and fulfillment

Track in-stock, out-of-stock, preorder, and backorder states, plus shipping, pickup, delivery, and return information. Google’s [Merchant Center specification](https://support.google.com/merchants/answer/7052112?hl=en) includes these availability states and requires price and availability to match the landing page and checkout.

Useful measures include in-stock rate, out-of-stock rate, stale inventory rate, promise mismatch rate, and time from an inventory change to each channel update. Keep location and seller dimensions where they affect the offer.

### Price and promotion

Track current price, currency, sale price, promotion dates, unit price where relevant, seller, shipping cost, and membership or subscription terms. Compare equivalent products, pack sizes, sellers, regions, and fulfillment promises. A lower price does not guarantee a higher search position, conversion rate, or recommendation.

### Reviews and trust

Monitor average rating, review count, freshness, rating distribution, verified or moderated status where exposed, unanswered questions, and recurring negative themes. Tie reviews to the correct product family and variant. Track returns, service contacts, and complaint themes alongside review signals.

### Discoverability and performance

Measure whether the right product is present and findable before measuring whether it converts:

- Listing coverage, channel eligibility, suppression, rejection, and missing-listing rate
- Search impressions, category placement, rank, and digital share of shelf
- Click-through rate, product-detail-page views, add-to-cart, and conversion
- Revenue, margin, returns, cancellations, and product-related service contacts

Treat rank and share as observations within a channel and time period. Results vary by query, location, device, seller, inventory, and personalization. Keep the segment and denominator with every metric.

## Monitoring, analytics, and optimization are different jobs

The three terms describe stages in one operating loop.

### Monitoring shows the current state

Monitoring captures what a shopper or channel sees now. It checks whether a listing is live, a field or asset changed, a feed was rejected, or a product disappeared from a search or retailer page. It needs defined sources, refresh intervals, alerts, and an owner for each exception. Stock, price, and promotions need faster refreshes than evergreen specifications.

### Analytics explains patterns

Analytics joins observations over time and across segments. It can show that a category’s share of search fell after a taxonomy change, that one marketplace suppresses a specific attribute, or that a variant family gets clicks but converts poorly when delivery dates are unclear.

A digital shelf analytics program commonly combines visibility, content compliance, competitive pricing, performance, and inventory signals. [Inriver’s supporting guide](https://www.inriver.com/resources/digital-shelf-analytics/) describes those categories and separates continuous monitoring from analysis.

Connect listing observations to add-to-cart, orders, margin, returns, and service contacts. Site analytics misses products that never became eligible. A channel dashboard misses a weak source record that will fail again at the next destination.

### Optimization changes the system

Optimization is the controlled change made after monitoring and analysis:

1. Add a missing attribute, identifier, image, or variant relationship to the source record.
2. Map the product to the destination’s category and accepted values.
3. Correct price, availability, shipping, or return data and refresh the destination.
4. Rewrite a title or description around facts shoppers use to compare products.
5. Improve media, reviews, fulfillment promises, or assortment.
6. Measure against the same channel, query set, product group, and time window.

A dashboard can surface a title problem. It cannot fix the source record on its own. Optimization works when the observation, data change, channel update, and outcome stay connected.

## A practical measurement framework

Start with a scorecard that moves from eligibility to business outcome. Add metrics only when they support a decision.

| Layer | Question | Example measures | Typical action |
| --- | --- | --- | --- |
| **Eligibility** | Can the channel accept and show the product? | Listing coverage, feed acceptance, rejection rate, suppression rate, missing-listing rate | Fix required fields, IDs, taxonomy, image rules, or channel mapping |
| **Presentation** | Does the live listing represent the product accurately? | Content completeness, image compliance, price and availability match, variant accuracy, review coverage | Correct the source record, assets, policies, or syndication output |
| **Discovery** | Can a shopper find the right product? | Impressions, share of search or shelf, category coverage, rank by query and location | Improve attributes, title, taxonomy, assortment, availability, or channel fit |
| **Engagement** | Does the listing earn useful attention? | Click-through rate, PDP views, dwell or engagement where available, add-to-cart rate | Improve content, media, offer clarity, reviews, or landing experience |
| **Commerce and trust** | Does the experience create a healthy order? | Conversion, revenue, margin, cancellations, returns, service contacts, rating and review trends | Fix product fit, promise accuracy, price, fulfillment, or product quality |
| **Freshness** | How quickly do changes reach each surface? | Update latency, stale-field rate, sync failures, time to resolve exceptions | Change refresh cadence, ownership, validation, or delivery method |

Segment by channel, category, country, seller, product family, and variant. A portfolio average can hide a marketplace with high rejection or a size that is regularly unavailable. Use a fixed query set and observation window for search comparisons. Timestamp feed errors, listing observations, and business events so you can see which change happened first.

## Digital shelf data-readiness checklist

Use this checklist before you expand to another retailer, feed, social catalog, or AI shopping surface.

- **Choose a canonical source.** Identify the approved record and owners for titles, attributes, media, price, inventory, policies, and reviews. Keep downstream edits visible.
- **Stabilize identity.** Maintain unique SKUs, GTINs or UPCs, MPNs, brand names, canonical URLs, regional IDs, and parent-child variant relationships. Use the same identifiers wherever the channel supports them.
- **Normalize taxonomy and values.** Map categories, units, colors, sizes, materials, ingredients, compatibility, and product types to controlled values. Record each destination’s transformation.
- **Fill the fields shoppers use.** Include concrete specifications, use cases, constraints, dimensions, capacity, care, fit, and compatibility. Replace vague claims with verifiable facts.
- **Validate media.** Check main-image rules, resolution, aspect ratio, backgrounds, alternate views, video, alt text, manuals, and asset rights for each channel.
- **Keep commercial data live.** Synchronize price, currency, sale dates, stock, preorder or backorder state, shipping, pickup, returns, warranty, and regional restrictions. Refresh fast-changing fields to match their risk.
- **Map each channel’s contract.** Document fields, accepted values, category and image rules, title limits, delivery method, and the exception owner.
- **Expose machine-readable inputs.** Use structured product data, feeds, APIs, and stable URLs where the destination supports them. Google’s [product structured-data guidance](https://developers.google.com/search/docs/appearance/structured-data/product) notes that price, availability, ratings, shipping, returns, and variant details can support richer product results, while the appearance of those results remains at Google’s discretion.
- **Protect trust signals.** Keep ratings, reviews, questions, claims, shipping promises, return policies, and certifications connected to the correct product and region. Record provenance when a field comes from a supplier, retailer, or customer.
- **Instrument the loop.** Define channel, category, variant, observation date, query set, and denominator for every report. Link listing changes to clicks, orders, returns, margin, and service data.
- **Test representative products.** Before a broad launch, test one high-volume item, one long-tail item, and one variant-heavy family in each priority channel. Inspect the submitted data, the rendered listing, the shopper path, and the resulting errors.

## Where Catalog fits

Catalog fits at the product data layer behind the shelf, especially when AI shopping is a new destination. We help brands turn scattered information into live, normalized, machine-readable product objects, keep price, stock, and variants current, expose product facts to AI shopping surfaces, and measure how those systems see and recommend products. Our [product data syndication guide](https://www.getcatalog.ai/blog/product-data-syndication) explains the distribution problem in more detail.

That role complements the stack. Use a PIM or ecommerce platform for internal governance, feed management for channel delivery, retailer or marketplace tools for live listing observations, and digital shelf analytics for cross-channel measurement. Catalog is useful when the bottleneck is the quality, structure, freshness, or machine readability of the product record those destinations consume.

Channel algorithms, inventory, competitor offers, reviews, shopper intent, and fulfillment operations still affect the outcome. A strong data layer makes those variables measurable.

## Frequently asked questions

### Is the digital shelf the same as ecommerce?

No. Ecommerce describes the transaction. The digital shelf includes the storefronts, retailer pages, marketplaces, feeds, search results, social content, reviews, and AI interfaces that influence discovery, evaluation, and purchase. A digital-shelf interaction can also influence an in-store purchase.

### Does the digital shelf include marketplaces?

Yes. Amazon, Walmart, eBay, retailer-owned ecommerce sites, and other marketplace or partner listings are digital-shelf touchpoints. Each has its own taxonomy, required fields, content rules, offers, reviews, inventory, and search behavior.

### What does digital shelf analytics measure?

It measures how products appear and perform across online channels: visibility, content compliance, price and promotion, availability, competitive position, clicks, conversion, inventory, reviews, and business outcomes. It is broader than web analytics because it includes products that may be suppressed, missing, or displayed on third-party sites.

### How does product data affect digital shelf performance?

Structured, accurate, and current data helps channels identify the product, render the right content, validate the offer, and match it to shopper needs. Missing or conflicting data can reduce eligibility, create a misleading listing, or make comparison harder. Product data supports performance. It does not guarantee rankings, conversions, or AI recommendations.

### What is an agentic or AI shelf?

It is an emerging shopping surface where an AI assistant or shopping agent interprets a request, finds products, compares options, answers questions, and may help complete a purchase. It overlaps with the digital shelf and depends on data from storefronts, feeds, APIs, marketplaces, and structured records. Requirements and measurement vary, so treat AI shopping as an additional destination.

### How often should a team monitor the digital shelf?

Monitor price, availability, promotions, feed acceptance, and fulfillment promises as often as those values can change. Review content, media, taxonomy, reviews, and search visibility on a cadence matched to launches, channel changes, category volatility, and business risk. The right cadence is the one that catches an error before it affects a meaningful shopper or revenue segment.

A digital shelf becomes manageable when each product has one trusted record, each channel has a documented contract, and every observation can lead to an owned correction. If your team needs that product data layer for AI commerce, [talk with Catalog](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/digital-shelf
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Ecommerce personalization: an implementation guide

*October 3, 2026 · Catalog Team · AI Commerce · 15 min read*

> Learn how ecommerce personalization turns shopper signals into relevant experiences with normalized product data, controlled tests, and privacy guardrails.

A relevant shopping experience responds to what a shopper is doing now, what they have chosen to share, and what your catalog can actually fulfill. That is the practical meaning of ecommerce personalization. It reaches beyond a “recommended for you” row.

A practical design treats personalization as a decision system: map signals to experiences and KPIs, build a normalized product-data foundation, handle cold starts, run controlled tests, and protect shopper trust.

## What is ecommerce personalization?

Ecommerce personalization adapts a shopping experience to a shopper or a shopping context. The adaptation might change product order, search results, content, recommendations, messages, or navigation. The input can be a current query, a session action, an explicit preference, purchase history, or context such as region and available inventory.

Personalization does not require a name or an account. An anonymous session that searches for “waterproof trail shoes,” filters to a size, and clicks two hiking products has already supplied useful intent. A system can use those allowed, first-party signals to rank relevant products for that session, then discard or retain them according to its privacy policy.

Personalization is a decision layer. It decides which eligible experience to show and in what order. It does not make an unavailable product relevant, repair a missing size attribute, or replace consent management.

### Personalization, merchandising, and recommendations are different

These terms are often used together, but they describe different jobs.

| Concept | Primary question | Typical control | Example |
| --- | --- | --- | --- |
| Merchandising | What should the store promote or prioritize for the business? | Human rules, campaigns, assortment, margin, inventory, and brand priorities | Boost a new, in-stock collection on a seasonal landing page |
| Recommendation | Which products could help this shopper with the current task? | A module or service that selects candidate products | Show compatible filters beside a coffee grinder |
| Personalization | How should this shopper’s experience adapt to their signals and context? | A decision policy that can alter ranking, content, modules, or messages | Rank trail shoes with the shopper’s preferred width and size first |

A recommendation can be generic. “Best sellers” is a recommendation even when every visitor sees the same list. It becomes personalized when the candidate set or order responds to a shopper’s behavior, stated preferences, or context.

Merchandising and personalization should work together. A merchant can require that a campaign includes a new collection, while a personalized ranker orders eligible products within that collection. A merchant can suppress a recalled product, while a recommendation system chooses among the remaining compatible items. [Site merchandising](https://www.getcatalog.ai/blog/site-merchandising) explains the wider set of product surfaces and rules.

## Where personalization appears

Personalization is most useful where a shopper must choose, compare, or return. Start with one surface where the decision and outcome are clear.

![Shopper interacting with an ecommerce site on a laptop](https://www.getcatalog.ai/images/blog/ecommerce-personalization.svg)

- **Search and category ranking:** adapt result order, query expansion, filters, and category sort to current intent and known preferences.
- **Product recommendations:** select similar products, substitutes, compatible accessories, bundles, replenishment items, or recently viewed products.
- **Content and navigation:** change category entry points, promotional modules, educational content, or homepage order for a relevant audience.
- **Guided selling:** use a quiz or preference flow to turn explicit answers into a smaller, explainable set of products.
- **Lifecycle messages:** send browse follow-ups, cart reminders, replenishment prompts, or loyalty messages when the shopper has consented to that channel.
- **Availability-aware experiences:** show the assortment, delivery promise, language, and fulfillment options that apply to the shopper’s region and context.

Do not personalize every surface at once. More variation creates more interactions to instrument, more ways for rules to conflict, and less certainty about what caused an outcome.

## Map signals to experiences and KPIs

A useful personalization plan starts with a chain: **signal → decision → experience → KPI**. Name the signal and its allowed use before choosing a model or vendor. Define a primary key performance indicator (KPI) and a small set of guardrails for each experience.

| Shopper or context signal | Experience it can inform | Primary KPI | Guardrail or diagnostic |
| --- | --- | --- | --- |
| Query, filters, clicks, and zero-result searches | Personalized search ranking, synonyms, and recovery results | Search add-to-cart rate | Zero-result rate, search exits, latency |
| Recently viewed products, cart items, and purchases | Similar items, complements, replenishment, and bundles | Attach rate or revenue per session | Return rate, incompatible recommendations, out-of-stock exposure |
| Explicit preferences from a quiz, profile, wishlist, or survey | Size, category, style, use-case, or price-band recommendations | Conversion by declared preference | Preference completion, opt-out rate, diversity of products shown |
| Region, device, language, and local availability | Fulfillment promise, local assortment, and relevant content | In-stock clicks or conversion by region | Delivery accuracy, availability freshness, performance by device |
| Consented lifecycle engagement and purchase interval | Browse follow-up, replenishment, or loyalty message | Revenue per recipient or repeat-purchase interval | Unsubscribe, complaint, and send frequency |
| New-product attributes and catalog relationships | Cold-start candidate generation and discovery modules | Product-page engagement for new items | Coverage of new and long-tail products, return rate |

The KPI must match the job. A search ranker should not be judged only by email revenue. A replenishment message should not be optimized for clicks if it increases complaints or returns. Define one primary outcome and a small set of guardrails for each experience.

## Build the product-data foundation first

A personalization system can only identify, compare, and recommend products that the product layer describes reliably. Raw feeds often mix parent products with variants, use inconsistent attribute values, and leave relationships implicit in copy. Models and rules inherit those defects.

A normalized product object should include:

1. **Stable identity:** durable product and variant IDs, parent-child relationships, canonical URLs, and a clear rule for deduplication.
2. **Normalized attributes:** category, brand, size, color, material, compatibility, dimensions, use case, and other decision fields. Use controlled values and units, with synonyms mapped to one canonical value.
3. **Product relationships:** explicit links for complements, substitutes, bundles, accessories, compatibility, and exclusions. “Works with” should be a field or relation, not a guess from a product title.
4. **Current operational facts:** price, currency, availability, fulfillment promise, region, effective dates, and variant-level inventory. A stale availability field can turn a helpful recommendation into a dead end.
5. **Quality and provenance:** required-field checks, allowed values, image and content validation, freshness timestamps, source provenance, and a fallback state when a record fails validation.
6. **Safe event joins:** a way to join impressions, clicks, carts, orders, and returns to product and variant IDs without treating every noisy behavioral signal as a product fact.

The same normalized attributes can support search, filters, merchandising rules, recommendation candidates, product feeds, and AI shopping surfaces. Catalog fits here. We turn source data into live, normalized product objects and keep the fields and relationships usable across those surfaces. We do not replace a customer identity graph, a consent-management program, an experimentation system, or channel operations.

For example, a retailer selling replacement parts might normalize `compatible_model`, `voltage`, `connector_type`, and `in_stock`. Search can match “charger for model X,” a recommendation can suggest a compatible cable, and a merchandising rule can exclude parts for a different voltage. The experience becomes more relevant because the product records express the constraints directly. Catalog’s [product data enrichment guide](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) and [ecommerce product data guide](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) cover the wider data workflow.

## A practical implementation sequence

Personalization works better as an operating loop than as a one-time model launch.

### 1. Establish a non-personalized baseline

Record how the current experience ranks, recommends, or messages. Save the business rules, candidate filters, default sort, and eligibility checks. The baseline is the control for later experiments and the fallback for low-confidence decisions.

Make eligibility explicit before relevance. Exclude recalled, unavailable, region-ineligible, or policy-restricted products before ranking. Apply price, margin, campaign, and brand rules as documented business constraints.

### 2. Define the event contract

For each impression and downstream action, capture the minimum fields needed to reconstruct a decision:

- `experience_id` and placement, such as search, product detail page, cart, or email
- product and variant IDs shown, clicked, added, purchased, or returned
- session or account identifier governed by the applicable consent state
- query, filters, context, and eligibility decisions
- model, rule, or content version
- timestamp, channel, region, and device class

A click without an impression cannot tell you what the shopper saw. An order without the variant ID cannot tell you which size, color, or compatibility rule worked.

### 3. Choose one high-intent experience

Search, category ranking, and cart complements are good starting points because the shopper’s task is visible and the next action is measurable. Pick one hypothesis, such as: “For shoppers who select a wide shoe size, ranking in-stock wide-fit products first will reduce search exits without increasing returns.”

Keep the experience narrow enough to explain. Avoid changing ranking, price, email timing, and homepage content in the same first test.

### 4. Generate candidates, then rank them

Separate **eligibility** from **relevance**. First build a candidate set from query matches, product attributes, relationships, availability, and merchant rules. Then rank candidates with session or customer signals. Finally apply diversity and suppression rules.

This architecture makes failures easier to diagnose. If the right product never enters the candidate set, changing the ranker will not help. If candidates are right but the order is poor, investigate the ranking features. If a good item is shown despite being unavailable, fix the eligibility or freshness path.

### 5. Run a controlled experiment

Use a randomized holdout or a defensible baseline. Assign the experience before measuring the outcome, and keep the control stable for the duration of the test. Define the primary KPI, guardrails, audience, and stopping rule in advance.

Report incremental change against the control. A personalized cohort’s raw conversion rate can rise because it contains more returning shoppers, stronger traffic, or a seasonal campaign. That is not evidence that personalization caused the lift.

### 6. Improve inputs before adding complexity

Break down results by new versus returning shopper, device, region, category, product freshness, and consent state. When one segment underperforms, inspect missing attributes, stale inventory, broken variant links, query interpretation, and suppression rules before adding another model.

Personalization quality is often limited by product-data quality. [Search merchandising](https://www.getcatalog.ai/blog/search-merchandising) and [ecommerce filters](https://www.getcatalog.ai/blog/ecommerce-filters) show how missing or inconsistent attributes affect discovery even without a personalization layer.

## Cold starts need useful fallbacks

Cold starts occur when a shopper, product, or context has little history. Design for them rather than hiding them behind a confident-looking score.

**For a new or anonymous shopper:** use the current query, category, filters, explicit choices, locale, availability, and a transparent category baseline. “Popular in waterproof trail shoes” is a more useful fallback than a site-wide bestseller list. Use only signals the shopper has allowed you to use.

**For a new product:** use normalized attributes, category, compatibility, price band, availability, and merchant eligibility. Reserve a measured share of exposure for new or long-tail products so the system can learn without displacing every relevant result.

**When consent is withheld or history is missing:** fall back to session-only or non-personalized behavior permitted by your policy. Do not silently recreate a profile from data the shopper declined to share.

**When model confidence is low:** show the baseline and record the fallback reason. Fallback rate is an operational KPI. A model that appears accurate only when it can avoid hard cases is not ready for broad traffic.

## Watch for bias and feedback loops

Personalized ranking can over-serve products that already receive the most clicks. Those products collect more impressions, generate more clicks, and become even more likely to rank. The loop can hide new products, niche needs, and useful alternatives.

Use controls that make the trade-off visible:

- Track exposure and conversion by product age, popularity band, category, region, device, and customer lifecycle.
- Add diversity or novelty constraints where discovery matters.
- Reserve measured exploration for new and long-tail products.
- Separate “popular” from “relevant” in the ranking features and reports.
- Review returns, complaints, and suppression outcomes, not only clicks.
- Avoid inferring sensitive traits or using proxies that create unequal treatment.

Keep a human-readable reason for a rule or decision. “Because you viewed compatible lenses” gives a shopper a useful explanation. It also gives a merchant and analyst a path to debug the system.

## Privacy and trust are part of the experience

Personalization uses information about people, even when the interface only shows products. Treat each signal as a data-use decision with a purpose, allowed source, retention period, access control, and deletion or opt-out path.

The [GDPR text](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679) sets out purpose limitation and data minimization principles, and includes a right to object to direct marketing, including related profiling. The UK [ICO storage and access guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/) addresses consent for technologies used for tracking or profiling. In California, the [California Privacy Protection Agency FAQ](https://cppa.ca.gov/faq) describes opt-outs for sale or sharing in cross-context behavioral advertising and recognizes preference signals such as Global Privacy Control.

These rules do not produce one universal consent recipe. Your implementation should carry consent state into event collection and decisioning, honor suppression and deletion requests, limit retention, and explain the value of a preference or account when asking for one. Keep personalization useful when a shopper declines.

Treat individualized pricing as a separate policy decision. Reordering products or showing a compatible accessory is different from changing a person’s price. The [FTC’s surveillance-pricing study](https://www.ftc.gov/news-events/news/press-releases/2025/01/ftc-surveillance-pricing-study-indicates-wide-range-personal-data-used-set-individualized-consumer) describes how granular behavioral and location data can be used to set individualized prices. Relevance and availability are safer places to start. Price changes need separate legal, commercial, and trust review.

## Measurement that survives scrutiny

A personalization dashboard should answer three questions:

1. **Did the experience cause an incremental outcome?** Compare the treatment with its control, and report confidence intervals or another uncertainty measure appropriate to the test.
2. **Where did it help or harm?** Segment by shopper state, device, region, category, product freshness, and consent state.
3. **Did the system remain trustworthy?** Track data completeness, freshness, fallback rate, out-of-stock exposure, returns, complaints, opt-outs, and message frequency.

Useful measures include:

- Search conversion, add-to-cart rate, search exit rate, and zero-result rate.
- Recommendation click-through, attach rate, revenue per session, items per order, and return rate.
- Content or navigation engagement, conversion by audience, and suppression rate.
- Lifecycle revenue per recipient, repeat-purchase interval, unsubscribe rate, and complaint rate.
- Product-data completeness, relationship coverage, freshness, and the share of decisions using fallback logic.

Use attributed revenue to understand a module’s path, then use a holdout to estimate incremental revenue. Do not add every downstream order to every recommendation slot. Attribution and causality answer different questions.

## Ecommerce personalization FAQ

### Is ecommerce personalization the same as product recommendations?

No. Recommendations are one experience type. They may be generic, rule-based, or personalized. Personalization can also change search ranking, category order, content, navigation, guided selling, fulfillment messaging, or lifecycle communication.

### Can I personalize for anonymous visitors?

Yes, when your privacy design allows the signals. Current-session query, filters, clicks, explicit choices, locale, and available inventory can support useful decisions without an account. Keep the experience session-based when history is unavailable, and use the baseline when consent or confidence is missing.

### What data do I need to start?

Start with stable product and variant IDs, normalized categories and attributes, availability, price, relationships, event impressions, and a non-personalized baseline. Add behavioral history only after the event contract, consent state, and retention rules are clear. More data cannot compensate for wrong product identity or stale inventory.

### How is personalization different from segmentation?

Segmentation assigns a shopper to a group, such as “returning customers who browsed outerwear.” Personalization can use that group as one input and still adapt to the individual session, product context, and preferences. Segments are useful controls. They are not a substitute for a decision that responds to current intent.

### What should ecommerce personalization software support?

Evaluate the complete loop: product and variant ingestion, attribute normalization, candidate eligibility, rule controls, event logging, consent and suppression handling, experimentation, explainability, and exports for analytics. Check whether the tool can return a useful baseline and whether merchants can inspect why a product was selected. A recommendation model without reliable catalog and event data leaves the hardest work outside the demo.

### Is personalized pricing part of ecommerce personalization?

It can be technically related, but it deserves separate governance. Personalizing relevance, content, or availability does not carry the same policy questions as assigning different prices from behavioral or location data. Treat price logic as a separately reviewed capability.

## Start with the product record

Personalization becomes easier to operate when every experience draws from the same live product facts and relationships. If your search, recommendation, and AI commerce projects are blocked by inconsistent attributes, variant identity, or stale availability, [Catalog can help structure the product data layer](https://www.getcatalog.ai/) without changing your storefront.

---

Canonical: https://www.getcatalog.ai/blog/ecommerce-personalization
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Ecommerce product recommendations: a practical build guide

*October 3, 2026 · Catalog Team · Product Discovery · 18 min read*

> Learn how ecommerce product recommendations work, which data and rules they need, how to build or buy a system, and how to measure relevance and lift.

An ecommerce recommendation is a decision about what deserves a shopper’s attention next. The visible carousel is only the last step. Behind it, a system chooses candidates, checks whether they can be shown, ranks them for the current context, and records what happened.

The quality of that decision depends on the placement, the product relationships, the shopper signals, and the freshness of the offer. Designing, building, evaluating, or buying the system starts with those operational details, rather than a black-box model.

## What ecommerce product recommendations are

Ecommerce product recommendations are product suggestions selected for a shopper, a product context, or a shopping moment. Examples include similar products on a product detail page, compatible accessories in a cart, and recently viewed items on a home page.

A recommendation system usually does four jobs:

1. **Generate candidates** from product similarity, shopper behavior, explicit rules, or a combination.
2. **Remove ineligible items** such as unavailable products, incompatible variants, and products the shopper already owns when the placement calls for something new.
3. **Rank and assemble a set** for the placement’s goal, with controls for price, diversity, category, or business priorities.
4. **Deliver and log the result** with the exact product or variant shown, its position, and the recommendation strategy that produced it.

The distinction from adjacent systems matters:

| System | Primary question | Typical output |
| --- | --- | --- |
| **Recommendations** | What should this shopper consider next in this context? | A ranked set of products related to a product, intent, or behavior |
| **Search** | Which products answer the shopper’s explicit query? | Results ranked against words, filters, and query intent |
| **Merchandising** | How should the business shape an assortment or ranking? | Boosts, pins, exclusions, campaigns, collections, or sort rules |
| **Broad personalization** | Which parts of the experience should adapt to this shopper or context? | Personalized content, ranking, offers, messages, navigation, or recommendations |

Recommendations can use personalization, merchandising rules, or search context. They remain a discovery layer with a specific next decision. [Google’s recommendation overview](https://developers.google.com/machine-learning/recommendation/overview) describes recommendations as a way to surface items people might not have thought to search for. Search and recommendations should work together, rather than compete for the same job. For the broader storefront context, see our guide to [site merchandising](https://www.getcatalog.ai/blog/site-merchandising) and the narrower rules in [search merchandising](https://www.getcatalog.ai/blog/search-merchandising).

## Match the recommendation to the placement

A product relationship has meaning only in context. A second sofa may help someone compare styles on a product page, then distract them in the cart when the next decision is delivery. Define the shopper’s job before choosing a model.

| Placement | Shopper’s job | Recommendation intent | Useful fallback |
| --- | --- | --- | --- |
| Product detail page | Compare or complete the item being viewed | Similar or substitute products; compatible and complementary products | Attribute-matched products in the same category |
| Cart or add-to-cart page | Finish the purchase | Frequently bought together, accessories, consumables, or a bundle | Rule-based complements with verified compatibility |
| Home page or landing page | Start or resume discovery | Recommended for you, trending products, new arrivals, or category entry points | Category bestsellers with current availability |
| Category page | Narrow a broad assortment | Personalized ordering or alternatives within the category | Relevance-ranked in-stock products |
| Recently viewed module | Resume consideration | Exact products viewed in the current session or account | Popular products in the same category |
| Guided selling or quiz | Translate a stated goal into products | Goal-, preference-, or constraint-based recommendations | Rules that map answers to eligible products |
| Post-purchase or account area | Replenish or extend ownership | Reorder, consumables, compatible upgrades, or care products | Time-based replenishment rules |
| Email or notification | Continue a prior shopping task | Recently viewed, back-in-stock, replenishment, or personalized discovery | Consent-aware bestseller or category list |

[Shopify’s recommendation documentation](https://shopify.dev/docs/storefronts/themes/product-merchandising/recommendations) separates **related** products, which can be substitutes, from **complementary** products, which help complete a purchase. Treat those as separate intents in your data and reporting. A single “recommended for you” endpoint makes it harder to explain why an item appeared or whether it helped.

## Choose a recommendation method

You do not need a complex model for every placement. Start with the method that matches your catalog quality, event volume, and control requirements.

| Method | How it works | Strength | Trade-off |
| --- | --- | --- | --- |
| **Rule-based** | A merchant or developer specifies conditions such as category, compatibility, price band, season, or campaign | Transparent, deterministic, and useful before behavioral data accumulates | Rules require maintenance and can become stale or overfit to a narrow use case |
| **Content-based** | Matches products using attributes, taxonomy, text, images, or learned product representations | Works for new products when their records are complete; easy to constrain to a category or use case | It can only see the properties represented in the catalog and may repeat similar items |
| **Collaborative** | Learns from co-view, co-click, cart, purchase, or other interaction patterns across shoppers | Finds relationships that a team may not have encoded, such as products often bought together | Needs joined event history; it can over-serve popular products and has a cold start for new items |
| **Hybrid** | Combines catalog similarity, behavioral signals, context, and rules | Balances cold-start coverage with behavioral relevance and operational control | Requires clear feature ownership, monitoring, and a way to resolve conflicting signals |

A practical system often uses several candidate sources. For a camera product page, content-based retrieval can find lenses with the right mount, collaborative signals can find a case commonly purchased with that camera, and a rule can remove accessories for a different mount. The final ranker should receive relationship type, price, availability, and confidence as explicit inputs.

Treat embeddings or generative models as techniques inside this pipeline. They do not remove the need for stable product identity, eligibility rules, or measurement.

## Build the product and event data contract first

A recommendation engine cannot rank what it cannot identify, describe, or serve. Start with a canonical product record, then connect shopper events to the same IDs.

![Product catalog and shopper events flowing into recommendation placements](https://www.getcatalog.ai/images/blog/ecommerce-product-recommendations-flow.svg)

### Product catalog fields

| Data group | Fields to include | Why it matters |
| --- | --- | --- |
| Identity | Stable product ID, variant ID, parent ID, SKU, GTIN or MPN when available, canonical URL | Prevents duplicate items and joins recommendations to the product that can be purchased |
| Description and taxonomy | Title, product type, category path, brand, normalized attributes, use cases | Supports similarity, category constraints, filtering, and explanations |
| Variants | Size, color, pack, configuration, item-group relationship, variant URL and image | Keeps a product family together while preserving the sellable choice |
| Relationships | Substitute, complementary, compatible, bundle, accessory, replenishment, or successor relationship; source and confidence | Gives models and rules a clear meaning for each product pair |
| Offer state | Price, currency, sale dates, availability, inventory, region, fulfillment, channel eligibility | Stops the system from presenting an offer the shopper cannot buy |
| Media and trust | Primary image, variant images, ratings, reviews, policies, and compliance fields where relevant | Helps the shopper assess the item and lets the system distinguish products |
| Provenance | Source system, owner, last-updated timestamp, confidence, and validation status | Makes stale or inferred values visible before they affect ranking |

The right attributes vary by category. Apparel may need fit, fabric, size, care, and color family. Electronics may need ports, compatibility, power, and included components. Beauty may need ingredients, skin type, shade, and warnings. [Catalog’s guide to product attributes](https://www.getcatalog.ai/blog/product-attributes-guide) explains why reusable, normalized fields support search, filters, feeds, and recommendations together.

### Shopper events

Capture the events that explain both interest and opportunity:

- product and variant impressions, including the placement, position, and full set shown;
- product-detail views, search queries, category views, filter use, and wishlist actions;
- recommendation clicks, add-to-cart, removal, purchase, return, and replenishment events;
- session or visitor ID, timestamp, device or region context, and consent state where applicable;
- cart contents, order ID, revenue, currency, and the product or variant IDs involved;
- recommendation request ID, placement, model or rule version, candidate source, and attribution token.

Log impressions as carefully as clicks. Without the items actually shown, a click-through rate can hide whether the system had a fair chance to earn attention. Keep product IDs consistent between catalog and events. [Google Cloud’s event guidance](https://docs.cloud.google.com/retail/docs/user-events) specifically calls out consistent visitor IDs, joined product IDs, revenue and currency on purchase events, and multi-item baskets for co-purchase patterns.

Keep behavioral data bounded by your privacy, consent, retention, and access requirements. An anonymous session can still supply useful context. It does not require a permanent identity profile.

## Apply eligibility and business rules before ranking

A high score does not make an item eligible. Put hard constraints before model ranking so the system cannot trade safety or accuracy for engagement.

Use a policy layer that can:

1. **Check commercial state:** remove inactive, out-of-stock, region-ineligible, restricted, or price-invalid offers. Use the right sellable variant alongside its parent product.
2. **Check relationships:** enforce compatibility, bundle contents, category scope, age restrictions, and pack or size constraints.
3. **Suppress duplicates:** remove the context product, duplicate variants, products already in the cart, and purchased items when the placement seeks discovery. Keep purchased items when the intent is replenishment.
4. **Apply business controls:** enforce campaign dates, price bands, inventory thresholds, margin or brand policies, and channel eligibility. Give every rule an owner and expiry path.
5. **Shape the set:** cap repeated brands or categories, remove near-duplicates, and set a minimum relevance threshold so diversity does not become noise.
6. **Choose a fallback:** return a useful category, popular, recently viewed, or rule-based set when the primary method has too few eligible items.

[AWS documents filtering recommendations](https://docs.aws.amazon.com/personalize/latest/dg/filter.html) to exclude items such as products a shopper has already purchased or to apply segment criteria. Filtering is a general design requirement, independent of the vendor you choose.

## Handle cold starts and exploration deliberately

Every recommendation system starts with incomplete evidence. There are two cold starts: a shopper with little history and a product with little interaction data.

### A new or anonymous shopper

Use the current product, query, category, session events, declared preferences, region, and available inventory. A category bestseller list or a broad popularity fallback is acceptable when it is labeled honestly in the experience. As the session develops, update the context from views, clicks, and cart actions. When consent is missing, keep the experience useful with session and page context instead of silently building a long-lived profile.

### A new product

Use its structured attributes, relationships, launch date, availability, and category position. Content-based retrieval and explicit rules can place it before collaborative signals have enough history. Exploration can reserve a controlled share of impressions for items with limited interaction data, then learn from the resulting impressions and actions. [Amazon Personalize’s exploration guidance](https://docs.aws.amazon.com/personalize/latest/dg/create-recommender-configure-exploration.html) describes this as testing less-established items to learn how shoppers respond.

Exploration needs guardrails: eligibility still applies, exposure should be measurable, and a new item should not displace a clearly better match in a high-intent placement. Track coverage and long-tail exposure alongside clicks and orders so popularity does not become a closed loop.

## A practical implementation workflow

Use a narrow first release. One placement with one job gives you a clean baseline and a smaller debugging surface.

### 1. Define the decision

Write down the placement, context, eligible assortment, primary outcome, guardrail metrics, and fallback. “Increase revenue” is too broad. “Suggest compatible, in-stock camera accessories on the add-to-cart page” is testable.

### 2. Normalize the catalog

Create stable IDs, parent-child variant links, category paths, typed attributes, relationship labels, current offers, and provenance. Validate the records before you train or query a model. Fix missing product facts before adding model complexity.

### 3. Specify and instrument events

Create one event schema for the storefront, app, email, and recommendation service. Send impressions before clicks, preserve the list position, and attach a request or attribution ID to downstream actions. Test joins with real product and variant IDs.

### 4. Generate candidates

Use several sources where they make sense: related attributes, compatible relationships, co-purchase or co-view patterns, recent session items, a curated set, and a category-aware popular fallback. Keep the source and relationship for each candidate.

### 5. Filter and rank

Apply hard eligibility rules, then score the remaining candidates for the placement’s objective. Blend relevance with freshness, availability, price, diversity, and controlled business priorities. Store the model or rule version with every response.

### 6. Serve a stable response

Return a request ID, placement, context IDs, product and variant IDs, relationship or reason, position, and expiry or freshness metadata. Keep the rendering layer separate from candidate logic so a web module, app, email, or AI shopping surface can use the same contract.

A minimal response shape might look like this:

```json
{
  "request_id": "rec-8f31",
  "placement": "pdp_complementary",
  "context_product_id": "camera-x200",
  "items": [
    {
      "product_id": "battery-bp1",
      "variant_id": "battery-bp1-us",
      "relationship": "compatible_accessory",
      "position": 1
    }
  ],
  "strategy_version": "hybrid-2026-09"
}
```

### 7. Test against a baseline

Start with the current hand-picked list, category popular list, or no-module experience. Randomize the treatment and control groups when traffic allows. Review results by placement, device, category, new versus returning shopper, and product freshness.

### 8. Operate the loop

Monitor stale offers, unjoined events, empty responses, latency, rule conflicts, and sudden concentration in a few products. Feed data-quality fixes back to the catalog owner. A model retrain cannot repair a broken variant relationship or an unavailable offer.

## Measure relevance and incremental impact

Use offline metrics to diagnose the model and online metrics to decide whether the experience earns its place.

### Offline and system metrics

| Metric | What it answers |
| --- | --- |
| Coverage | How much of the eligible catalog the system can recommend |
| Precision@k and recall@k | Whether relevant items appear in the top k and how many relevant items are retrieved |
| MRR and NDCG | Whether relevant items are near the top and whether the full order is useful |
| Diversity and novelty | Whether a list avoids near-duplicates and gives long-tail items a fair chance |
| Eligibility and variant error rate | Whether responses contain unavailable, duplicate, or wrong-variant items |
| Latency, empty-response, and fallback rate | Whether the service works reliably at the point of decision |

[Amazon’s evaluation documentation](https://docs.aws.amazon.com/personalize/latest/dg/evaluating-recommenders.html) defines coverage, mean reciprocal rank, normalized discounted cumulative gain, and precision for recommender evaluation. Use a time-based holdout for offline tests when possible so future events do not leak into the past.

### Online and business metrics

- **Recommendation CTR:** recommendation clicks divided by recommendation impressions, segmented by placement and intent.
- **Downstream action rate:** add-to-cart, purchase, or other chosen action after an impression or click. Keep the denominator explicit.
- **Attach rate:** qualifying orders that include a recommended complement or accessory.
- **Conversion rate, revenue per session, order value, and margin:** useful business outcomes, compared with a control rather than reported as attributed totals alone.
- **Returns, cancellations, and support contacts:** guardrails against recommendations that look relevant but create poor fit or compatibility.
- **Coverage, freshness, out-of-stock exposure, and fallback rate:** operational measures that explain why a business metric changed.

A recommendation click is attribution. It is not proof of incremental impact. Run a randomized holdout or a sound experiment for each material strategy change. [AWS recommends A/B testing recommendation strategies](https://docs.aws.amazon.com/personalize/latest/dg/measuring-recommendation-impact.html) to compare groups and measure impact.

## Buy, build, or combine

The right choice depends on your catalog, traffic, team, and need for control.

| Approach | Fits when | Watch for |
| --- | --- | --- |
| **Buy a service** | You need a supported integration, production operations, and a shorter path to several placements | Opaque candidate logic, limited data ownership, weak variant controls, or pricing tied to requests or attributed revenue |
| **Build in-house** | You have a strong data and ML platform, distinct relationships or constraints, and the team to operate experiments and serving | Long time to production, missing instrumentation, and a model that works in notebooks but lacks storefront safeguards |
| **Combine systems** | You want managed retrieval or modeling with your own catalog, eligibility, ranking, or measurement layer | Ambiguous ownership between the model, catalog, and business rules |

### Vendor-selection checklist

Ask each vendor to demonstrate the workflow on a representative sample of your catalog, including variants and unavailable offers. Evaluate:

- **Intent and placement support:** Can you configure related, complementary, replenishment, recently viewed, and goal-based experiences separately?
- **Catalog ingestion:** How are IDs, variants, relationships, category attributes, price, inventory, and freshness mapped? Can you export the normalized records?
- **Event quality:** Can the system ingest impressions, clicks, carts, orders, returns, anonymous sessions, and context in real time? Are raw events and recommendation responses available to you?
- **Eligibility and controls:** Can you enforce compatibility, region, stock, suppression, price, campaign, and diversity rules before ranking?
- **Cold start and exploration:** What does a first-time shopper see? How are new products introduced? Can you set exposure limits and inspect exploration?
- **Serving contract:** What are the API, SDK, batch, email, and app options? What latency, caching, rate limits, and rollback controls apply?
- **Measurement:** Does the system log the exact list shown? Can you compare against a holdout and export event-level data? Which metrics are diagnostic and which are business outcomes?
- **Security and ownership:** Who owns catalog and event data? How are consent, retention, access, deletion, and regional processing handled?
- **Commercial fit:** Is pricing based on traffic, items, requests, orders, or attributed revenue? What happens when you stop using the service?

Reject a demo that shows only a polished carousel. Ask for an explanation of candidate generation, an ineligible-item test, the selected variant, the fallback response, and a holdout plan.

## Product data is the foundation

Recommendations can only be as reliable as the product objects underneath them. Missing material, inconsistent color values, disconnected variants, stale stock, or an untyped “accessory” relationship each creates a different failure mode. Better copy alone does not fix those joins.

We built Catalog around this product-data problem for AI commerce. Catalog structures product data into live, normalized, machine-readable records, keeps attributes, variant relationships, price, and availability current, and distributes those records to AI shopping surfaces. That work complements an onsite recommendation service. It does not replace your event pipeline, identity and consent controls, ranking model, or experiment design.

The same product object can support onsite search, filters, merchandising, recommendations, feeds, and AI shopping. Our [product-data enrichment guide](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) explains the workflow from messy source records to validated objects, while our [product feed guide](https://www.getcatalog.ai/blog/product-feed-management) covers the operational work of keeping product facts current across destinations. If AI shopping is part of your distribution plan, start by checking whether the systems consuming your catalog can distinguish the right product, variant, relationship, and offer.

## Frequently asked questions

### Are product recommendations the same as ecommerce personalization?

No. Personalization can change search order, content, offers, messages, and navigation for a shopper or context. A product recommendation is one decision within that experience: which products to surface next, for a defined placement and intent. A recommendation can also be non-personalized, such as a category bestseller or a rule-based compatible accessory.

### Do recommendations replace ecommerce search?

No. Search responds to an explicit query and its constraints. Recommendations help shoppers discover items they did not specify, continue a product decision, or complete a purchase. Use search for exact products, attributes, and filters. Use recommendations to extend that intent with relevant alternatives and complements.

### What data does a recommendation system need?

At minimum, it needs stable product and variant identity, usable attributes and taxonomy, current price and availability, and a clear placement context. Behavioral systems also need joined impressions and actions such as views, clicks, carts, and purchases. Rules and content-based methods can start with catalog data while event history builds.

### How should a system recommend new products?

Use attributes, relationships, category context, availability, and launch rules to create initial candidates. Add controlled exploration so selected shoppers can discover low-history products. Keep hard eligibility checks and measure exposure, coverage, and downstream actions separately from established products.

### How do you know whether recommendations work?

Track relevance and system health with coverage, ranking metrics, eligibility errors, latency, and fallback rate. Track shopper and business outcomes with clicks, add-to-cart, conversion, attach rate, revenue per session, margin, and returns. Compare a treatment with a randomized baseline to estimate incremental impact.

### Can Catalog provide the recommendation engine?

Catalog provides the product-data layer for AI commerce. It makes product records structured, current, and available to AI shopping surfaces. You still need a recommendation strategy and service for shopper-event modeling, placement ranking, eligibility decisions, and experimentation.

If you want to see how AI shopping surfaces currently read your catalog, [run a Catalog product-data audit](https://www.getcatalog.ai/audit).

---

Canonical: https://www.getcatalog.ai/blog/ecommerce-product-recommendations
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Google product category: a practical mapping guide

*October 3, 2026 · Catalog Team · Product Data · 12 min read*

> Learn when to use google_product_category, how it differs from product_type, how to map one supported value, and how to maintain clean feed data.

Google assigns every product a category automatically. The `google_product_category` attribute is an optional way to override that assignment when the category affects requirements, campaign structure, or compliance. The hard part is knowing when to leave categorization to Google, when to intervene, and how to keep the mapping correct as a catalog changes. This guide covers that decision, the difference between `google_product_category` and `product_type`, and a maintenance workflow for large catalogs.

## What `google_product_category` does

`google_product_category` accepts one category from Google's predefined product taxonomy. You can send the category's numeric ID or its full path. Google uses the value to classify the product and, in eligible countries, to support category-based Shopping campaign structures. It is a channel field, not a replacement for your own catalog hierarchy.

Google says that all products receive an automatic category. Accurate titles, descriptions, prices, brands, and GTINs help its systems classify products correctly. The attribute is therefore an override for specific cases, rather than a field that every merchant must fill for every product. Read [Google's attribute guidance](https://support.google.com/merchants/answer/6324436?hl=en) alongside the [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) before adding it to a feed.

When you do provide a value, Google expects one predefined category. The value must be either the ID or the full path, never both. Google recommends the ID because it is shorter and less exposed to path spelling or formatting errors.

## When Google's auto-categorization is enough

Leave `google_product_category` out when Google's automatic category matches the product and none of the following conditions apply:

- Google has assigned the item to a category with requirements that do not fit the product.
- You organize a Google Ads campaign by Google product category and need a deliberate grouping.
- The product is covered by a category-specific rule, such as alcohol, gift cards, contract phones, or software subscriptions.
- Your source data clearly describes the product, yet Merchant Center is classifying it incorrectly.

This is a sensible default for a clean catalog. It avoids maintaining a duplicate classification when Google already has enough product context. It also keeps your team focused on the fields that improve automatic classification, including an accurate title, description, brand, and GTIN when available.

Use an explicit value when you have a reason to change the result. Google's guidance lists three main override cases: correcting category-specific attribute requirements, structuring Google Ads campaigns around the category, and correctly classifying alcohol. Its additional guidance covers prescribed categories for bundles, mobile devices sold with a contract or installment plan, gift cards, and software subscriptions.

## `google_product_category` vs. `product_type`

These fields answer different questions. `google_product_category` asks, “Which category in Google's shared taxonomy best describes this product?” `product_type` asks, “How does this merchant organize the product?”

| Field | `google_product_category` | `product_type` |
| --- | --- | --- |
| Taxonomy | Google's predefined taxonomy | Your own hierarchy |
| Value | One supported ID or full path | Your own text, usually a breadcrumb |
| Primary job | Override Google's automatic categorization when needed | Organize inventory, bidding, and reporting around your business structure |
| Can it be repeated? | No, submit one category | Up to five values can be submitted, but only the first is used for Google Ads bidding and reporting |
| If there is no exact match | Do not invent a Google value | Use your own category here |

Google's [`product_type` guidance](https://support.google.com/merchants/answer/6324406?hl=en) recommends a full, consistent breadcrumb such as `Home > Women > Dresses > Maxi Dresses`. That path can be more specific than Google's taxonomy. Keep it in `product_type` without forcing it into `google_product_category`.

A record can contain both fields:

```text
google_product_category: 2271
product_type: Apparel > Women > Dresses > Maxi Dresses
```

Here, `2271` is the supported Google category for `Apparel & Accessories > Clothing > Dresses`. The second value is the merchant's internal view. They can describe the same item at different levels of detail.

## How to choose the right Google product category

### 1. Identify the product's main function

Start with what the item is primarily sold to do. Google uses an MP3 player as an example: even if it has a clock or other features, its main function is playing music, so the MP3 player category is the relevant one. An MP3 player charger belongs in the accessories category instead.

This rule prevents a secondary feature from deciding the classification. A camera bundled with a bag should use the category of the main product, for example `Cameras & Optics > Cameras > Digital Cameras` with ID `152`.

### 2. Search the official taxonomy

Use Google's [official taxonomy file](https://www.google.com/basepages/producttype/taxonomy-with-ids.en-US.txt), rather than a store menu or a third-party category list. Search for the product noun, then read the parent and child paths around each candidate. The path provides the context that a short label can hide.

![Google taxonomy file pairing category IDs with full paths](https://www.getcatalog.ai/images/blog/google-taxonomy-list.svg)

The file pairs each numeric ID with a full path. Keep both in your mapping record so a reviewer can understand the choice, then submit the ID in the feed. If the taxonomy is not available in your language, Google says to use the English value or numeric ID.

### 3. Choose the most specific relevant category

Choose the deepest category that the product's facts support. “Most specific” does not mean choosing a child category because its name contains a useful keyword. The product must actually fit that category.

Google contrasts a broad `Electronics` category with a more precise MP3 player category. The precise category is better when the item is an MP3 player. If the item is an accessory, use the accessory category. Google's [product-data optimization tips](https://support.google.com/merchants/answer/7380908?hl=en) also recommend values at least two to three levels deep when that level of detail is available.

### 4. Record the choice and its evidence

For each mapping, retain the source category, the Google ID, the path, the taxonomy version used, and a short reason. Record exceptions separately. This turns a one-off lookup into a mapping rule that another person can review and reuse.

## How to submit one supported value

The field is not repeated. Send one value in the format required by your data source.

For a CSV or TSV feed, use either the ID:

```text
google_product_category
2271
```

Or use the path:

```text
google_product_category
Apparel & Accessories > Clothing > Dresses
```

For XML, the same choice looks like this:

```xml
<g:google_product_category>2271</g:google_product_category>
```

Do not include the ID and path in the same value. Do not send multiple Google categories for one item. If you use a path, copy the supported spelling and hierarchy from the taxonomy. An internal category such as `Women > Dresses > Maxi` is valid as `product_type`, but it is not a valid `google_product_category` unless it exactly matches a supported Google path.

Some products have explicit category rules. Google lists these examples:

| Product case | Category guidance |
| --- | --- |
| Gift card | `Arts & Entertainment > Party & Celebration > Gift Giving > Gift Cards & Certificates` (ID `53`) |
| Mobile phone with a contract | `Electronics > Communications > Telephony > Mobile Phones` (ID `267`) |
| Tablet with a contract or installment plan | `Electronics > Computers > Tablet Computers` (ID `4745`) |
| Software subscription | `Software > Computer Software` (ID `313`) or a relevant subcategory, such as ID `5299` for antivirus and security software |
| Alcoholic beverage | `Food, Beverages & Tobacco > Beverages > Alcoholic Beverages` (ID `499676`) or an eligible subcategory |

These values do not replace the relevant product, advertising, or alcohol policies. They identify the product category Google needs for the offer.

## Common mapping errors

| Error | Why it causes trouble | Better fix |
| --- | --- | --- |
| Sending an internal category | Google accepts predefined taxonomy values, not store menu labels | Keep the internal path in `product_type`; map it to a Google ID |
| Sending both ID and path | The specification allows one representation only | Submit the numeric ID and store the path for review |
| Sending multiple Google categories | `google_product_category` is not a repeated field | Choose the one category that best represents the product's main function |
| Choosing a broad parent by default | `Electronics` or `Apparel & Accessories` can hide the product's real type | Use the most specific relevant supported category |
| Mapping from keywords alone | A word in a title may describe an accessory, feature, or use case | Check the product's main function and supporting attributes |
| Using a stale category value | Google updates the taxonomy and translates older values to its latest version | Review the current taxonomy when launching products and when Google changes categories |
| Treating `product_type` as a substitute | A merchant hierarchy cannot override Google's taxonomy | Keep both fields and give each one its intended job |
| Overriding every product | The attribute is optional and Google already categorizes products automatically | Override only when the result, requirements, campaign structure, or policy calls for it |

The most common conceptual mistake is treating category mapping as a naming exercise. It is a classification decision. The product record needs enough normalized facts to support that decision.

## A scalable workflow for clean product data

A spreadsheet can work for a small catalog. It becomes fragile when source categories, variants, campaigns, and channels change independently. A governed crosswalk keeps the decision in one place.

### 1. Normalize the source record

Start with structured facts such as product kind, main function, brand, material, compatibility, audience, and bundle status. Normalize values before mapping. For example, keep `MP3 player charger` distinct from `MP3 player`, even though the names overlap.

Catalog's [product attributes guide](https://www.getcatalog.ai/blog/product-attributes-guide) describes this upstream work: shared fields, controlled values, units, and clear ownership make downstream feeds easier to validate. A Google category should be derived from those facts, not from a last-minute keyword rule.

### 2. Keep a canonical crosswalk

Create one mapping table between your internal category and Google's taxonomy. At minimum, store:

- internal category or product rule
- Google category ID
- Google category path
- taxonomy version or snapshot
- mapping reason and exception flag
- owner and review date

Keep the ID as the machine value and the path as the human-readable evidence. If several source categories map to one Google category, document that many-to-one relationship instead of creating near-duplicate IDs.

### 3. Separate default behavior from overrides

Set auto-categorization as the default policy. Add explicit overrides for category-specific requirements, campaign structures, regulated products, or known classification errors. A rule should explain why an override exists and which product facts support it.

This keeps the Google field small and defensible. It also prevents a team from filling the attribute simply because a feed template has an empty column.

### 4. Generate channel output from the crosswalk

At export, emit one supported Google ID. Keep `product_type` as a separate output from the same normalized record. Do not ask each channel manager to choose a category independently. The mapping belongs upstream, where the source facts and previous decisions are visible.

We use this product data layer approach at Catalog: normalize product facts once, keep channel mappings explicit, and publish consistent outputs. It is the same principle described in our guide to [product feed management](https://www.getcatalog.ai/blog/product-feed-management): a channel feed should be an output of trusted product data, not the place where product truth is invented.

### 5. Validate before and after submission

Before exporting, check that every populated value is:

- a supported ID or exact supported path;
- present only once;
- represented as either an ID or path, never both;
- consistent with the product's main function and source attributes; and
- paired with the required category-specific fields when the category calls for them.

After submission, review Merchant Center diagnostics and the [issue details page](https://support.google.com/merchants/answer/7052112?hl=en). Google identifies incorrect product category values as a possible source of disapprovals, limited eligibility, and incorrect displays. A feed that uploads successfully can still contain a bad classification.

### 6. Review on events, not guesswork

Review a mapping when you add a product family, change a bundle, launch a regulated product, change a campaign structure, or update the taxonomy snapshot. Run a scheduled review as a backstop. Compare the category ID, path, and reason together so a taxonomy change does not silently leave an old path in your source system.

This workflow keeps category maintenance proportional to risk. Simple products can rely on Google's automatic result. Ambiguous, regulated, high-volume, or campaign-sensitive products get a deliberate mapping and a traceable review history.

## FAQ

### Is `google_product_category` required for every product?

No. Google automatically assigns a category, and the attribute is optional for each product. Add it when you need to correct the assignment or meet a category-specific, campaign, or policy need. Omitting the attribute by itself does not mean a product should be disapproved.

### Should I submit the category ID or the full path?

Either is supported, but use one representation only. Google recommends the numeric ID. Keep the path in your mapping table for review and troubleshooting.

### Can I submit more than one Google product category?

No. The field is not repeated. Submit the one predefined category that best describes the product's main function.

### What if Google's taxonomy has no category for my product?

Do not invent a Google value. Use `product_type` for your own hierarchy and leave `google_product_category` unset unless a supported category becomes appropriate. Revisit the taxonomy when Google publishes a relevant update.

### How often should I update category mappings?

There is no universal calendar. Review mappings when the product, bundle, campaign, policy, or taxonomy changes, and run a scheduled check for stale IDs and paths. Keep the taxonomy snapshot and review date with each mapping.

If category rules live across spreadsheets, feed scripts, and channel owners, Catalog can give your team one normalized product data layer and one place to govern the crosswalk. [Run a Catalog audit](https://www.getcatalog.ai/audit) to find the product data issues that make channel mapping harder.

---

Canonical: https://www.getcatalog.ai/blog/google-product-category
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Shopify product variants: setup, limits, and data governance

*October 3, 2026 · Catalog Team · Product Data · 15 min read*

> Learn how Shopify product variants work, add and edit them, manage the 2,048-variant limit, and keep SKUs, inventory, URLs, and data aligned.

Shopify product variants let one product listing represent the choices a customer can buy. They also create the records that inventory, fulfillment, feeds, search, and AI shopping systems must keep straight.

The setup is simple until option names drift, variant-level data goes missing, or a product grows beyond what a theme can render. Use the working model, current Shopify limits, and operating pattern that hold up across your storefront and downstream systems.

## Shopify product variants in one model

Start with four terms:

| Term | Meaning | Example for a sweatshirt |
| --- | --- | --- |
| **Product** | The parent listing that groups one sellable design or model. | Classic Crewneck Sweatshirt |
| **Option** | An attribute customers use to choose a version. | Size or Color |
| **Option value** | One allowed choice within an option. | `M` or `Slate Blue` |
| **Variant** | One sellable combination of option values. | `Size: M` + `Color: Slate Blue` |

If a product has five sizes and four colors, it has 20 possible combinations. Shopify can create all 20 when you add the option values. A catalog can also be sparse. If a particular size and color is not made, do not create a placeholder variant with fake inventory.

A product is the customer-facing group. A variant is the operational unit. Shopify tracks the variant that gets added to the cart, receives the SKU, carries inventory, and determines the price and media shown after a selection.

![Diagram showing a Shopify product branching into size and color choices and resolving to one SKU with its own price and inventory.](https://www.getcatalog.ai/images/blog/shopify-product-variant-model.svg)

Treat the option model as structured data rather than copy. A shopper can understand that `XL`, `Extra Large`, and `X-Large` mean the same thing. A filter, feed mapper, or shopping agent may treat them as three values.

## How to add variants in Shopify

You can create combinations from the product page or add one variant at a time.

### Add options and generate combinations

1. In Shopify admin, go to **Products** and open the product.
2. In **Variants**, select **Add options like size or color**.
3. Enter the option name, such as `Size`.
4. Enter the option values, such as `S`, `M`, and `L`.
5. Select **Add another option** for `Color` or `Material`, if needed. A product can have up to three options.
6. Select **Done**, then **Save**.

Shopify creates the combinations from the values you entered. New variants inherit product defaults in some fields, so open the variant details and set the values that are genuinely variant-specific before publishing. The [Shopify variant setup instructions](https://help.shopify.com/en/manual/products/variants/add-variants) cover category metafields and bulk duplication as well.

To add a value to an existing option, edit the option and enter the new value. Shopify can generate the new combinations across the other options. This is the right workflow when a new color should exist in every available size.

### Add one variant manually

Select **Add variant** in the Variants section and enter its option values. This creates one record. At least one option value must be new, and Shopify will not save an exact duplicate.

Manual creation is useful for a deliberately sparse matrix. It is a poor shortcut for a new value that should apply across every size, because you would need to create each combination yourself.

You can also duplicate an existing variant or select several variants and use the bulk duplicate action. Copy a variant only when its price, shipping, locations, and other fields are appropriate for the new one. Change the option value and then review every copied field.

## How to edit, publish, and remove variants

Open a product, select a variant, and edit its details. Shopify supports individual edits for options, pricing, inventory, shipping, and related fields. From the product details page, you can also change variant image, price, and available inventory per location. Use the bulk editor when the same field needs to change across many variants. The [Shopify variant editing guide](https://help.shopify.com/en/manual/products/variants/edit-variants) shows the current admin paths.

You can edit the option structure separately:

- Rename an option, such as changing `Colour` to `Color`.
- Add or remove option values.
- Drag options and values into a new display order.
- Add a third option with a default value applied to existing variants.
- Delete an option or value, which can remove combinations from the product.

Unpublish a variant when you need to stop selling it while keeping its history, SKU, or future availability. Delete it only when the record should no longer exist. Deletion can break references in orders, feeds, analytics, or external systems that stored the variant ID.

Before saving an option change, compare the resulting variant count with the systems that receive the product. Adding one value to a matrix can create hundreds of new records.

## What belongs on the variant record

Do not put variant facts only in the product title or description. A downstream system needs to select the exact sellable record.

| Field | What to manage at variant level |
| --- | --- |
| **SKU** | A stable, unique identifier for the sellable combination. Use a convention that encodes the parent and options without making the SKU depend on a display label. Our [SKU guide](https://www.getcatalog.ai/blog/what-is-a-sku) explains the identifier's role in inventory and reporting. |
| **Price** | The price and compare-at price for that combination, in the correct currency and market. Never assume every size or material has the product's default price. |
| **Inventory** | Available quantity and inventory policy, tracked by location where your operation requires it. Inventory belongs to the variant that ships. |
| **Media** | The image or other media that should appear after the customer selects the variant. The asset must be part of the product's media list. |
| **Identifiers** | Barcode, GTIN, MPN, or other identifiers when they differ by combination. Keep them distinct from the internal SKU. |
| **Shipping and tax facts** | Weight, country of origin, HS code, taxable status, and shipping requirements when they differ by variant. |
| **Variant attributes** | Material, fit, dimensions, pack size, compatibility, or other facts that change with the option choice. Use variant metafields for specialized internal data when the storefront needs them. |

A selector is only correct when it updates the selected variant's price, availability, media, and add-to-cart ID together. Showing a blue image with the price for the black variant is a data error, even if the page still looks usable.

## Current Shopify variant limits and caveats

Shopify's Admin limit is **2,048 variants per product** and **three options per product**. The limit is high enough for most catalogs, but it is not the same as a universal limit across every Shopify surface.

| Limit or caveat | Operational meaning |
| --- | --- |
| **2,048 variants per product** | The product can contain up to this many variant records in Shopify admin. |
| **Three options per product** | `Size`, `Color`, and `Material` can be axes in one product. A fourth axis needs a different modeling choice. |
| **250 media items per product** | A product can have up to 250 media items. Each variant can have one assigned media item, and that asset must come from the product's media list. |
| **250 variants in Liquid** | `product.variants` returns at most 250 variants. A product can be valid in admin and still fail to render all choices if a theme expects the full array. |
| **Legacy compatibility** | Shopify documents that some third-party themes, theme app extensions, public apps, sales channels, Stocky, legacy Order Printer, and custom apps using the REST Admin API may support fewer than the current Admin limit. The Help Center specifically calls out components that do not support more than 100 variants. |
| **Large-store imports** | Stores with 500,000 or more variants can add up to 10,000 new variants per day through an app or CSV import. Shopify Plus stores are exempt from that daily limit. |

The practical caveat is simple: **2,048 is a data-model ceiling, not a promise that every theme, app, channel, or import path can process 2,048 records.** Check the entire route from source system to storefront before you redesign a high-variant product.

If a product needs more than three options or more than 2,048 true variants, splitting it into separate products may be cleaner than using custom line-item properties. Line-item properties can capture a request, but they do not create a normal variant with its own inventory, SKU, media, and structured-data identity. A third-party app or custom implementation can support specialized workflows, with different tradeoffs.

## Option names are a data contract

Option names appear in the storefront and become keys in feeds, APIs, analytics, and product exports. Set the convention before merchants start adding products.

Use these rules:

1. **Name the customer decision.** Use `Size`, `Color`, `Material`, or `Pack size`, not `Option 1` or a supplier field code.
2. **Use one spelling and case.** Pick `Color` or `Colour` for the relevant market and apply it consistently.
3. **Keep values controlled.** Store `Slate Blue` once. Do not create `Slate`, `Slate-blue`, and `Blue Slate` unless they are different sellable choices.
4. **Do not combine axes.** `Black / Medium` is a variant label, not a good option value. Keep `Color: Black` and `Size: M` separate.
5. **Make the order intentional.** Put the choice customers make first, and keep that order across similar products.
6. **Separate display labels from identifiers.** A value can display as `Extra Large` while the SKU component remains `XL`.

Shopify category metafields can provide reusable option values and make a rename propagate to connected products. That helps when a catalog needs to change a label such as `Black` to `Graphite` in one place. It does not remove the need to review feeds, search synonyms, URLs, or SKUs that were generated from the old value.

## High-variant themes need deferred loading

Shopify restricts `product.variants` to 250 items because loading every variant into a theme can hurt render performance. A Liquid loop that expects all variants will silently see only the first 250. The theme may omit choices, mark a valid combination unavailable, or submit the wrong variant ID.

Shopify's high-variant guidance recommends auditing uses of `product.variants` and `product | json`. For large products, use the `product_option_value` object and granular `option_values` URL selection to load the relevant state only when needed. The [high-variant theme guidance](https://shopify.dev/docs/storefronts/themes/product-merchandising/variants/support-high-variant-products) also points developers to the Storefront API and Ajax API for deferred loading.

A resilient selector should:

- render option values from the product's option model;
- show whether a value is available in the context of earlier selections;
- update the selected variant, price, media, availability, and form ID together;
- avoid serializing every variant into the initial page when the product is large;
- handle a combination that has no associated variant without submitting a null selection.

Test the product in the real theme and in every app extension that reads variant data. A theme update can fix one selector while a search, swatch, bundle, or personalization extension still assumes the old 100-variant behavior.

## Variant URLs and structured-data SEO

A variant needs a stable way to be selected, shared, and understood by crawlers.

Shopify theme guidance supports a direct variant URL such as `?variant=<variant-id>`. It also supports `?option_values=<option-value-id-1>,<option-value-id-2>` for granular selection. When a URL selects a variant, the page should show that variant's image, price, availability, and selector state. A URL that changes only the query string while the page continues to show the default variant is a broken deep link.

For a normal single-page product, keep the base product URL as the canonical URL and use query parameters for selection states. Use stable `key=value` parameters, avoid session or tracking parameters in internal links, and do not create an indexable URL for every combination unless each page has useful, distinct content. Google's [ecommerce URL guidance](https://developers.google.com/search/docs/specialty/ecommerce/designing-a-url-structure-for-ecommerce-sites) recommends a canonical product URL when optional variant parameters identify the same page.

If variants have genuinely separate pages, each page needs complete, self-contained product information and a deliberate canonical plan. A page with only a changed color name and no unique content adds crawl paths without adding search value.

For structured data, model the family as a `ProductGroup` and connect its variants with `variesBy`, `hasVariant`, and `productGroupID`. Give each variant a unique identifier such as its SKU or GTIN. Put variant-specific name, image, offer, price, availability, and URL on the variant `Product` or `Offer`. Google recommends adding `Product` markup in the initial HTML when shopping visibility matters. Its [product-variant structured-data guidance](https://developers.google.com/search/docs/appearance/structured-data/product-variants) includes single-page and multi-page examples.

The markup should describe what shoppers can see. Do not mark every possible combination if Shopify has no corresponding variant, price, inventory state, or add-to-cart path.

## Keep Shopify and downstream systems in sync

Shopify is the commerce system for the product page, cart, and checkout. It may not be the best owner for every product fact. Decide ownership by field and make updates flow through stable IDs.

| Data | Suggested owner | Shopify and channel action |
| --- | --- | --- |
| Product and variant identity | Commerce master or PIM | Preserve parent product ID, variant ID, SKU, and GTIN mappings. |
| Option taxonomy and display values | PIM or product data layer | Normalize names and values before creating combinations. |
| Price and promotions | Pricing system or Shopify, with one declared authority | Send effective price and market currency to the storefront and feeds. |
| Inventory by location | ERP, WMS, or Shopify inventory, with one declared authority | Update the same variant and location keys used for order allocation. |
| Media and technical attributes | DAM or PIM | Assign the right asset and facts to each variant, then publish to Shopify. |
| URL, selector, and structured data | Storefront and theme code | Make the selected variant state, canonical, and markup agree. |
| AI-facing enrichment and distribution | Catalog | Normalize live product data and publish the fields that AI shopping surfaces need. |

Use a reconciliation job or report that checks:

- every Shopify variant maps to exactly one source record;
- each active variant has a unique SKU and expected option tuple;
- inventory and price timestamps are within their freshness windows;
- media references resolve and match the selected option;
- variant counts match across Shopify, ERP, PIM, feeds, and channels;
- unpublished or discontinued variants are removed from customer-facing feeds;
- failed updates are visible to an owner instead of being silently skipped.

Our [product attributes guide](https://www.getcatalog.ai/blog/product-attributes-guide) explains why this field-level consistency matters across search, filters, feeds, and AI commerce. The product page is one surface. Your variant contract should survive every surface that reads the record.

## Shopify product variant checklist

Before you publish or expand a product, confirm:

- The parent product, option, option value, and variant model is documented.
- Option names and values follow one controlled convention.
- The resulting combination count fits Shopify and downstream limits.
- Every sellable variant has a stable SKU and required identifiers.
- Price, inventory, shipping facts, and media are set per variant where they differ.
- The theme updates every selected-variant field together.
- High-variant products use deferred loading instead of assuming all Liquid variants are present.
- Variant URLs select the correct record and follow one canonical strategy.
- ProductGroup and Product markup uses real variants, unique IDs, and current offers.
- ERP, WMS, PIM, feeds, and AI-facing systems share the same parent and variant mappings.

## FAQ

### What is the Shopify variant limit?

Shopify allows up to 2,048 variants and three options per product in admin. Themes, apps, sales channels, and imports can impose lower limits. Liquid returns at most 250 variants, and some older integrations still document a 100-variant ceiling.

### What is the difference between a Shopify option and a variant?

An option is a choice axis, such as `Size`. An option value is one choice, such as `M`. A variant is the sellable combination, such as `Size: M` and `Color: Slate Blue`, with its own inventory and SKU.

### Can each Shopify variant have its own price, SKU, inventory, and image?

Yes. Shopify supports variant-level price, inventory, shipping details, SKU, barcode, and media assignment. The media must come from the product's media list, which is capped at 250 items per product.

### How do I add many variants at once?

Add values to an option to generate combinations, or select existing variants and use bulk duplication. Add a variant manually when you need one sparse combination. Manual creation does not generate every possible combination.

### Can a Shopify product have more than three options?

Not as native variant options. Split the product, use combined listings where they fit, or use an app or custom line-item workflow. A custom option captured outside the variant model will not automatically receive a variant SKU, inventory record, media assignment, or structured-data identity.

### Should every Shopify variant get its own SEO page?

No. Use one product URL with selectable, shareable variant states for most catalogs. Create separate pages only when a variant has distinct content and search intent, then give those pages complete markup and a deliberate canonical strategy.

## Make variant data usable beyond Shopify

A clean Shopify variant is a good start. It becomes valuable when the same product facts stay accurate in your ERP, PIM, feeds, storefront, and AI shopping surfaces.

We structure and normalize that product data, keep operational fields synced, and publish machine-readable product objects to the surfaces where shoppers ask what to buy. Read our guide to [Shopify Agentic Storefronts](https://www.getcatalog.ai/blog/shopify-agentic-storefronts) to see how that distribution path works, then connect your Shopify catalog to Catalog when you need one governed variant model across channels.

---

Canonical: https://www.getcatalog.ai/blog/product-variants-shopify
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Semantic search for ecommerce product discovery

*October 3, 2026 · Catalog Team · Product Discovery · 15 min read*

> Learn how semantic search works for ecommerce, when to use keyword, vector, or hybrid retrieval, and how to implement it with reliable product data.

Shoppers describe what they need in their own language. Product catalogs describe what a brand sells in fields, titles, and specifications. Semantic search closes that gap by retrieving products according to meaning and intent.

For an ecommerce team, the search model is only one part of the system. The quality of the product data it receives determines whether a semantic match is useful or misleading. This guide explains how semantic search works, where it fits alongside keyword and vector search, and how to implement it without losing exact matches, hard constraints, or control over the result set.

## What is semantic search?

Semantic search is an information-retrieval approach that interprets the meaning and intent of a query, then finds content or products that satisfy that meaning. It can connect different words that describe the same idea, understand a natural-language request, and use relationships between entities and attributes.

Consider a shopper searching for **“a jacket for rainy bike rides.”** A keyword engine may return products containing “jacket,” “rain,” or “bike.” A semantic system can connect the request to a *water-resistant commuter shell* even when the query's exact words do not appear in the product data. It should also recognize that water resistance is a selection attribute, that “bike rides” describes a use case, and that size and availability still determine whether the item can be bought.

Semantic search is a goal. Embeddings, vector indexes, natural-language processing, taxonomies, and knowledge graphs are techniques that can help achieve it. The implementation varies by search stack. The outcome should stay the same: a result set that answers the shopper's request with less query reformulation.

Semantic retrieval works best when a search system has complete, typed product facts to work with. We help brands create that foundation at Catalog by structuring product information into live, normalized product data that search systems and AI shopping surfaces can use consistently.

![Semantic search connects shopper intent, product data, and ranked results](https://www.getcatalog.ai/images/blog/semantic-search-flow.svg)

## How semantic search works

A production semantic search system combines several stages. Every implementation has its own architecture, so treat this as a working model rather than a fixed algorithm.

### 1. Prepare the searchable product record

The system ingests product titles, descriptions, categories, attributes, variants, compatibility information, and other fields. It may also ingest reviews, buying guides, images, and query or purchase events. Keep product identity separate from descriptive language: SKU, GTIN, model number, size, price, and stock need typed fields, while use cases and styles can live in text and normalized attributes. Combining everything into one paragraph makes hard constraints harder to enforce.

### 2. Represent meaning

An embedding model turns text, images, or structured fields into numerical representations. Items with related meanings tend to be closer together in the model's vector space. A product representation might combine its title, category, use cases, and selected attributes. The query gets its own representation.

Sentence-BERT is an early, widely used example of this pattern. In the authors' 2019 paper, sentence embeddings could be compared with cosine similarity, reducing a 10,000-sentence similarity search from an estimated 65 hours of pairwise inference to about five seconds while retaining the evaluated accuracy. Read the [Sentence-BERT research](https://aclanthology.org/D19-1410/) for the method and its limits.

Embeddings capture relationships in language. They do not verify stock, compatibility, or budget. Those facts need structured fields and current data.

### 3. Interpret the query

Query understanding identifies concepts and constraints. For **“black waterproof hiking shoes under $140, size 10,”** a parser might identify:

- category: hiking shoes;
- attribute: black;
- performance requirement: waterproof;
- price ceiling: $140;
- variant constraint: size 10.

The semantic portion retrieves related language. The structured portion filters out products that fail the price, size, color, or availability requirements.

### 4. Retrieve candidates

The engine retrieves a larger candidate set using one or more paths:

- lexical matching over titles, brands, SKUs, and attributes;
- vector similarity over embeddings;
- category, compatibility, price, geography, and availability filters;
- entity or taxonomy relationships.

Candidate retrieval is about recall. The system needs to bring plausible products into the set before ranking can choose the best ones.

### 5. Rank, filter, and explain

The final stage orders candidates by relevance and applies business rules such as availability, variant coverage, popularity, margin, freshness, delivery promise, or personalization. A relevance floor comes first. A product that cannot satisfy the query should not rise simply because it sells well.

The result should expose enough product information for the shopper to understand the match. Showing the relevant attribute, variant, price, and availability also gives the team a way to debug why a product appeared.

## Semantic vs. keyword, vector, and hybrid search

These terms describe different layers of a search system. Treating them as interchangeable creates bad implementation decisions.

| Approach | What it does | Where it helps in ecommerce | Main limitation |
| --- | --- | --- | --- |
| Keyword or lexical search | Matches terms and their lexical variations in indexed fields | Exact SKUs, model numbers, brands, product names, and short category queries | Misses paraphrases and needs synonyms or query rules for different shopper language |
| Semantic search | Retrieves according to meaning, intent, and relationships | Natural-language needs, use cases, long-tail queries, and zero-result recovery | Can return a plausible-sounding product that fails a precise constraint |
| Vector search | Uses embeddings and nearest-neighbor similarity to implement semantic retrieval | Fast similarity retrieval across large catalogs and multimodal signals | A technique rather than a complete relevance strategy; similarity alone does not enforce product rules |
| Hybrid search | Combines lexical, semantic, and structured retrieval before ranking | Stores where exact identifiers and open-ended discovery happen together | Requires score fusion, tuning, monitoring, and clear precedence between signals |

**Vector search is often part of semantic search. It is not the definition of semantic search.** A semantic system can also use a taxonomy, synonyms, entity relationships, or a knowledge graph. A vector system can return nearby text while missing an important business constraint.

For most product catalogs, hybrid retrieval is the practical default. Preserve an exact match for **“filter X100”** or **“model AC-2400.”** Use semantic similarity for **“replacement part for my compact air purifier.”** Apply compatibility and availability filters to both paths, then fuse and rerank the eligible candidates.

## Semantic search examples for ecommerce

Semantic search becomes easier to design when each query is connected to the product facts it needs.

| Shopper query | Product facts the system needs | Expected behavior |
| --- | --- | --- |
| “Jacket for rainy bike rides” | Product type, water resistance, use case, weather protection, fit, sizes, stock | Retrieve commuter shells and rain jackets even when “bike” is absent from the title. Keep available sizes visible. |
| “Desk for a 10-foot room” | Dimensions, product type, room or use case, price, delivery region | Use semantic intent to find desks, then enforce a numeric width or depth limit. Vector similarity alone cannot guarantee the fit. |
| “Replacement filter for X100” | Model number, compatible devices, part number, product family, stock | Protect the exact model and compatibility match with lexical and structured retrieval. Do not let a similar-looking filter outrank it. |
| “Gift for a new homeowner under $50” | Use cases, product category, price, availability, giftability signals | Expand an open-ended request into relevant categories, then apply the price ceiling and inventory rules. |
| “Red pumps for a holiday party” | Color family, shoe type, occasion, style, size, stock | Connect occasion language to products with appropriate style and color attributes, even if “holiday” is not in the copy. |

This is where semantic search and [ecommerce filters](https://www.getcatalog.ai/blog/ecommerce-filters) work together. Semantic retrieval helps interpret an open request. Facets and filters let the shopper confirm or tighten the result with attributes such as size, material, price, compatibility, or availability.

Search merchandising adds another layer. A [search merchandising](https://www.getcatalog.ai/blog/search-merchandising) rule can boost an in-stock product or bury an unavailable variant after relevance has been established. It should not turn an unrelated campaign product into the answer to a specific need.

## Product-data requirements for semantic search

Models cannot recover product facts that are absent, contradictory, or stale. Start with a data contract before choosing an embedding model.

### Stable identity and relationships

Keep product, parent, and variant identifiers stable. Include SKU, GTIN, MPN, brand, canonical URL, and relationships between a parent product and its size, color, pack, or bundle variants. Compatibility should connect a replacement part to the devices it fits.

### Taxonomy and typed attributes

Use a category path and category-specific fields. Store **10 in** as a numeric dimension with a unit, not only as text in a description. Normalize color families, materials, sizes, fit, capacity, voltage, ingredients, and other selection attributes. A [product data quality](https://www.getcatalog.ai/blog/product-data-quality) program measures completeness, consistency, validity, and freshness by category.

### Query language and use cases

Capture shopper language, approved synonyms, and use cases. “Commuter shell,” “rain jacket,” and “waterproof cycling jacket” may overlap, while “water-resistant” and “waterproof” may carry different performance promises. Review synonyms with merchandising and product teams so they do not erase meaningful distinctions.

### Commercial and operational facts

Pass current price, currency, inventory, regional availability, delivery promise, return restrictions, and variant-level stock as fields for filters and ranking. Refresh frequently changing values separately from slower-changing embeddings.

### Content, media, and provenance

Descriptions and images add context. Image-derived signals can help with color or visual style, but they need validation. Record the source, update time, confidence, and transformation for enriched attributes so a merchandiser can resolve a questionable match.

Structured product data also supports discovery beyond an onsite search box. Google's [Product structured data guide](https://developers.google.com/search/docs/appearance/structured-data/product) describes fields such as price, availability, shipping, returns, ratings, and product variants that can make product facts machine-readable for search experiences.

Catalog's role is the product data layer: we turn source information into live, normalized, typed product objects that downstream search systems, feeds, and AI shopping surfaces can reuse. The search index remains the system that retrieves and ranks those objects.

## Benefits and trade-offs

Semantic search earns its place when it solves a measurable discovery problem. It also introduces new failure modes.

| Benefit | Trade-off to manage |
| --- | --- |
| Understands paraphrases and natural-language needs | Meaning-based similarity can blur distinctions such as waterproof vs. water-resistant |
| Recovers long-tail and zero-result queries | A broad fallback can hide genuine catalog gaps |
| Helps shoppers discover products by use case or problem | The system may need explanations so merchants can review why a result matched |
| Works across synonyms and, with the right model, multiple languages or media | Model quality varies by category, language, and product vocabulary |
| Reduces manual synonym rules over time | Embedding generation, storage, and reranking add cost and latency |
| Supports recommendations and AI-agent retrieval from the same product context | Stale embeddings can keep retired names, prices, or attributes in the candidate set |

Use lexical protection and hard filters for exact identifiers and constraints. Keep an audit trail for enrichment and ranking decisions. Refresh embeddings when meaningful descriptive fields change, and update price and availability on their own operational schedule.

## How to evaluate semantic search

Do not judge semantic search from a handful of impressive queries. Build an evaluation set from real traffic and failure cases.

### Create a query test set

Include representative examples from each intent class:

- exact product, brand, SKU, and model queries;
- category and attribute combinations;
- natural-language use-case queries;
- compatibility and replacement-part queries;
- misspellings, synonyms, and multilingual variants;
- price, size, color, and availability constraints;
- historical zero-result, no-click, and high-refinement queries.

For each query, label acceptable products, unacceptable products, and required constraints. Include variant-level judgments for parent products with several sizes or colors.

### Measure retrieval and ranking separately

Track **recall@k** to see whether eligible products enter the candidate set. Track **precision@k** or **nDCG@k** to see whether the best matches appear first. Add commerce-specific checks:

- exact-match success for SKU and model queries;
- constraint satisfaction for price, size, color, compatibility, and availability;
- zero-result rate and result-set coverage;
- p95 latency and index freshness;
- explanation or provenance coverage for enriched matches.

High recall with wrong products at the top is a ranking problem. High precision with missing eligible products is a retrieval or data-coverage problem.

### Connect to shopper outcomes

After offline testing, monitor click-through rate, add-to-cart rate, conversion per search, revenue per search, no-click searches, refinements, exits, filter usage, and returns or cancellations by query class, device, and category. Averages can hide failures in high-value or safety-sensitive queries.

Run an A/B test with guardrails for zero-result rate, latency, exact-match success, and out-of-stock exposure. Conversion is one outcome, not the definition of relevance.

## A practical implementation checklist

Use this sequence when moving from a keyword engine to semantic or hybrid retrieval:

1. **Define intent classes and hard constraints.** List the queries where exact identity, compatibility, price, size, or availability must win.
2. **Audit the catalog.** Measure missing attributes, inconsistent values, broken variant links, duplicate identifiers, stale inventory, and thin descriptions by category.
3. **Create a typed schema.** Separate identifiers, variants, attributes, use cases, commercial facts, and provenance. Normalize units and vocabulary.
4. **Choose the retrieval mix.** Start with lexical matching for exact terms, vector retrieval for paraphrases, and structured filters for hard constraints. A hybrid path usually protects the widest range of ecommerce queries.
5. **Define the embedding scope and refresh policy.** Decide which fields are embedded, how category context is included, when records are re-embedded, and how model versions are tracked.
6. **Apply filters before ranking.** Enforce eligibility, compatibility, price, geography, and inventory rules. Do not expect similarity scores to enforce them.
7. **Rerank inside a relevance floor.** Use click, purchase, popularity, margin, freshness, or personalization signals only among products that satisfy the query.
8. **Build an evaluation set.** Label representative queries and track recall, ranking quality, constraint satisfaction, exact matches, latency, and freshness.
9. **Roll out in stages.** Shadow the current engine, inspect edge cases, A/B test query classes, and keep a rollback path.
10. **Monitor and improve the data loop.** Feed no-result, refinement, click, add-to-cart, conversion, and return signals into query rules, catalog fixes, and future ranking training.

If the audit shows that product data is the bottleneck, fix that layer before changing the model. Better embeddings cannot compensate for missing compatibility, inconsistent sizing, or stale stock.

## Where semantic search is useful beyond a store

The same pattern can power site search, support content, knowledge bases, product guides, and AI-agent retrieval. The indexed object changes, while the need for metadata, access control, freshness, and evaluation remains.

For ecommerce brands, a shared product data layer keeps a storefront search engine, marketplace feed, shopping assistant, and agent aligned on product identity, attributes, price, availability, and provenance. That is the foundation for a parallel storefront that machines can read without changing the human storefront.

## FAQ

### Does semantic search replace keyword search?

No. Keyword matching remains safest for exact SKUs, model numbers, brands, and unusual product names. Semantic retrieval handles paraphrases and open-ended intent. Hybrid search combines both with structured filters.

### Is vector search the same as semantic search?

No. Vector search retrieves nearby embeddings. It is a common implementation technique for semantic search. Semantic search is the broader objective of understanding meaning and intent, which can also use taxonomies, synonyms, entities, and knowledge graphs.

### What product data does semantic search need?

Provide stable product and variant identifiers, titles, categories, descriptions, attributes, availability, price, and canonical URLs. Add use cases, compatibility, normalized units, media metadata, and provenance when they affect buying decisions. Keep price and stock fresh.

### How should semantic search handle an exact SKU?

Route exact identifiers through lexical and structured matching, then protect the result during ranking. Semantic similarity can supply alternatives when the SKU is unavailable or misspelled. It should not displace an eligible exact match.

### How do you measure product search relevance?

Use a labeled query set to measure recall@k, precision@k or nDCG@k, exact-match success, constraint satisfaction, zero-result rate, latency, and index freshness. Connect those results to clicks, add-to-cart, conversion, refinements, no-click searches, returns, and cancellations. Review metrics by query type.

### Does semantic search require generative AI?

No. Many systems use language models to create embeddings or classify intent, then retrieve and rank products with conventional search infrastructure. A generative model can interpret or explain a query, while eligibility, price, stock, and compatibility still need governed data and deterministic rules.

Semantic search is only as reliable as the product facts behind it. If your catalog is difficult for a search engine or shopping agent to parse, Catalog can structure and keep those facts current. [Talk to Catalog](https://www.getcatalog.ai/) about building a live product data layer for the discovery surfaces that matter to your brand.

---

Canonical: https://www.getcatalog.ai/blog/semantic-search
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Visual search technology for ecommerce: how it works

*October 3, 2026 · Catalog Team · Product Discovery · 16 min read*

> Learn how visual search technology turns images into product results, what ecommerce data it needs, how to implement it, and how to measure accuracy.

A shopper may have a photo of a chair, a screenshot of a jacket, or a product in front of them, but no useful name for it. A text box forces that shopper to translate what they see into words. Visual search technology makes the image the starting point.

For ecommerce teams, the hard part is not adding a camera icon. The hard part is returning the right product, variant, price, and availability after the image is uploaded. This guide explains how visual search works, where it helps product discovery, which image and catalog conditions it needs, and how to evaluate it without confusing visual similarity with a good match.

## What is visual search technology?

Visual search technology lets a person search with a photo, screenshot, camera frame, or other image instead of typing a query. A computer vision system interprets the image, creates a representation of what it contains, and retrieves matching or related results from an index.

In an ecommerce setting, the result may be a product in your own catalog, a visually similar alternative, or a set of products that can be refined with text. The term also appears in psychology research to describe how people scan a scene. Here, visual search means image-led product discovery.

Visual search usually supports three different jobs:

| Job | What the shopper wants | Typical result |
| --- | --- | --- |
| Exact product identification | “What is this item?” | The same product or SKU, when it is in the index |
| Similar-product discovery | “Find products with this look.” | A ranked set of visually similar products |
| Multimodal refinement | “Find this look in brown and smaller.” | Image matches narrowed by words, filters, or catalog attributes |

Those jobs need different relevance rules. An exact lookup should protect product identity. A style search can favor shape, pattern, color, and material. A multimodal query must give the text instruction enough weight to change the result set.

## How visual search works

Implementations vary, but most visual search systems have the same logical stages.

1. **Capture and select the target.** The shopper uploads an image, takes a photo, pastes an image URL, or selects an object in a busy scene. Object detection, segmentation, a crop tool, or a user-drawn box can identify what to search.
2. **Create a visual representation.** An image encoder turns pixels into a numerical representation, often called an embedding. Similar images land closer together in that representation space. A vision-language model can place text and images in a shared space so a phrase such as “brown velvet chair” can refine an image query.
3. **Retrieve candidates.** The system searches an index of product-image representations, often with approximate nearest-neighbor retrieval. It returns a candidate set rather than making a final purchase decision.
4. **Apply catalog and business filters.** Category, brand, region, price, stock, compatibility, size, and other structured fields remove candidates that look right but cannot satisfy the request.
5. **Rank and present results.** The service combines visual similarity with exactness, text relevance, availability, variant logic, diversity, and sometimes behavioral signals. The interface should show the product record that matches the image, rather than an orphaned image URL.

Research on [product visual-search embeddings](https://arxiv.org/abs/1810.04652) describes learning image representations for content-based retrieval. Newer image-indexing systems also support image and text queries against one index. The architecture is the useful concept. You do not need to train a model from scratch to use it.

![Visual search pipeline from an image query to filtered product results.](https://www.getcatalog.ai/images/blog/visual-search-pipeline.svg)

The catalog remains part of the retrieval system. An embedding can identify a close-looking shoe, but it cannot tell a shopper whether the shoe is available in size 9 unless the result joins to a current product record.

## Visual search vs. image search vs. text search

These terms overlap, which creates implementation confusion.

| Search type | Input | Primary job | Typical ecommerce dependency |
| --- | --- | --- | --- |
| Text search | Words such as “waterproof trail shoes” | Match language to product records | Titles, descriptions, synonyms, attributes, and filters |
| Image search | A text query or an image used to find indexed images and pages | Retrieve images or pages that contain related imagery | Image index, page context, metadata, and crawl coverage |
| Visual product search | A photo or screenshot used to find products or product families | Interpret the visual object and return purchasable matches | Reference images, embeddings, product identity, attributes, variants, price, and stock |

Reverse image search can find the same image elsewhere on the web. Visual product search can find a product that looks like the image even when the pixels differ. An owned-store experience may combine both with text search, filters, and recommendations.

## Ecommerce use cases for visual search

Visual search is useful when a shopper knows what an item looks like but does not know what it is called or how a catalog describes it.

### Photograph-to-product lookup

A shopper photographs a lamp in a hotel, a backpack on a train, or a package on a shelf. The system can identify an exact product if the item and its reference images are in the index. If it is not, the experience should say that it found similar products rather than implying certainty.

### Similar-product discovery

An out-of-stock product can lead to alternatives with a related silhouette, pattern, or material. This is a discovery use case, not a compatibility guarantee. A visually similar phone case, replacement filter, or machine part may still be functionally wrong. Compatibility attributes must remain a separate constraint.

### Shop-the-look inspiration

A shopper uploads an outfit, room, or screenshot from social media. Object selection can isolate the chair, shoes, or bag, then return products with a related style. The shopper can move from inspiration to a product page without knowing the original brand.

### Image plus text refinement

Images express appearance well. Text expresses constraints that an image cannot reliably prove. A shopper might upload a sofa and add “smaller, brown, under $1,000,” or upload a dress and add “long sleeve.” The search service needs structured fields for those constraints, and the interface should make it clear which part came from the image and which part came from the text.

### Marketplace, packaging, and parts search

Marketplaces can use a camera to start a listing or find related offers. A retailer can recognize packaging, barcodes, or a product family and then route the shopper to the right record. Industrial catalogs can use a photograph of a component as a starting point, while still requiring dimensions, standards, and compatibility checks before purchase.

Google describes a similar journey in its [Lens shopping example](https://blog.google/products-and-platforms/products/shopping/visual-search-lens-shopping/): a shopper can photograph or upload an item, see product details across retailers, and refine some fashion and furniture searches with text. A platform example shows what the interaction can look like. It does not guarantee that every catalog receives the same exposure.

## Product-image and catalog-data requirements

Visual search quality depends on two connected assets: the image index and the product data joined to each image. Better embeddings cannot repair missing variants, stale stock, or an image that does not clearly show the product.

### Image requirements

- **Show the product clearly.** Use a clean main image and additional angles that expose the shape, details, and scale. Avoid images where another product dominates the frame.
- **Cover realistic conditions.** Include useful views for front, side, back, different orientations, lighting, and context. [Google Cloud’s reference-image guidance](https://docs.cloud.google.com/vision/product-search/docs/general-tips) describes three to eight representative images for one managed service. That is service-specific guidance, not a universal requirement.
- **Keep the product large enough to inspect.** Follow the destination’s file, format, and dimension rules. For example, [Google Merchant Center’s current guidance](https://support.google.com/merchants/answer/6324350?hl=en) recommends images around 1,500 by 1,500 pixels or larger for best performance and describes a 500 by 500 pixel minimum for products beginning January 31, 2027. Those numbers are channel requirements and recommendations, not a visual-search ranking guarantee.
- **Map every image to an identifier.** Store a stable product ID, variant ID, image role, and image URL together. Do not leave the index with an image that cannot resolve to a sellable record.
- **Keep image URLs stable and crawlable.** A broken, blocked, or frequently changing URL creates gaps between the image index, product page, and downstream feeds.

### Catalog-data requirements

| Requirement | Fields to keep consistent | Why it matters |
| --- | --- | --- |
| Product identity | Product ID, SKU, GTIN or other identifier, canonical URL | Joins the visual result to the right product page and order data |
| Variant relationships | Parent ID, variant ID, color, size, material, pack or configuration | Stops one visual family from collapsing every size or color into one result |
| Visual attributes | Color, pattern, finish, silhouette, material, texture, style, dimensions | Gives filters and multimodal ranking facts that pixels cannot reliably supply |
| Taxonomy and brand | Category path, product type, brand, collection | Narrows candidate sets and makes results easier to explain |
| Commercial state | Price, currency, region, availability, inventory, sale status | Prevents the experience from sending shoppers to an unavailable or misleading offer |
| Freshness and provenance | Source, update time, feed status, approval state | Makes changes traceable when an image or product fact is wrong |

The same discipline improves ordinary [product data quality](https://www.getcatalog.ai/blog/product-data-quality), [product attributes](https://www.getcatalog.ai/blog/product-attributes-guide), and [ecommerce filters](https://www.getcatalog.ai/blog/ecommerce-filters). Normalize values such as “navy,” “navy blue,” and “midnight” when they mean the same thing. Keep values such as “navy” and “black” distinct when they affect the buying decision.

Structured data and feeds matter when an external channel uses them. [Google’s product structured data guidance](https://developers.google.com/search/docs/appearance/structured-data/product) says product markup can make details such as price, availability, ratings, and shipping eligible for richer Search, Images, and Lens experiences. Eligibility and display are not guaranteed. Your product page, feed, image index, and checkout should still agree even when a channel does not require markup.

## How to implement and evaluate visual search

Treat visual search as a retrieval product with a catalog operating model, rather than as a one-time model integration.

### 1. Start with one search job and category

Choose a category where appearance carries intent, such as apparel, furniture, beauty, decor, or visually distinctive parts. Define whether the first release is for exact identification, similar discovery, or image-plus-text refinement. A narrow job makes relevance labels and failure analysis possible.

### 2. Define what counts as a good result

Create a representative test set of customer photos, screenshots, crops, lighting conditions, and multi-object scenes. For each query, label the expected outcome:

- exact product or acceptable variant;
- acceptable similar product;
- wrong category or irrelevant result;
- no result because the catalog does not contain a suitable item.

Keep exact and similar labels separate. A model that returns stylish alternatives can look good on a similarity metric while failing an exact SKU lookup.

### 3. Choose the service boundary

You can use a managed visual or multimodal search service, a commerce-search platform with image support, or an internal retrieval service. An API is an integration boundary, not a quality strategy. Confirm current support, regions, limits, index-refresh behavior, image retention, and pricing before selecting a service. Google Cloud marks its older [Vision API Product Search](https://docs.cloud.google.com/vision/product-search/docs) as maintenance mode. Its docs still illustrate product sets and reference images, while newer [Image Warehouse documentation](https://docs.cloud.google.com/vision-ai/docs/image-warehouse-overview) describes image and text similarity search with annotations. Microsoft’s Bing Search APIs, including its Visual Search API, were [retired on August 11, 2025](https://learn.microsoft.com/en-us/lifecycle/announcements/bing-search-api-retirement). Old tutorials are not implementation plans.

Keep text search and filters available. A camera-first feature should give shoppers a way to add words, select a target, correct the category, or continue with a normal query.

### 4. Build the index and its update path

Generate representations for the approved product images, attach product and variant metadata, and make catalog changes flow to the index. Add new products. Remove discontinued products. Re-embed changed imagery. Update availability and price through the path that serves results, not on a slower manual schedule. Monitor the lag from a source change to the result page.

For teams preparing this shared product data layer, Catalog structures product facts, normalizes attributes, keeps live data synchronized, and publishes machine-readable product objects to AI shopping surfaces. Catalog does not replace the visual retrieval service. It helps make the records that visual search returns consistent across the storefront, feeds, and AI commerce channels.

### 5. Measure offline relevance and online outcomes

Use both relevance tests and shopper behavior. Useful measures include:

| Measure | What it tells you |
| --- | --- |
| Exact recall at 5 or 10 | Whether the known product appears in the first results |
| Similar-result precision | How many shown alternatives are judged relevant by a trained reviewer |
| No-result rate | Where the query or catalog has no usable match |
| Refinement rate | How often shoppers add text, recrop, change category, or search again |
| Result click-through and add-to-cart rate | Whether results lead to useful product exploration |
| Conversion, return, and support rate | Whether the match holds up after the click and purchase |
| Latency, especially p95 | Whether the experience responds fast enough on real devices |
| Catalog coverage and freshness lag | Whether the index contains the products and current state it claims to search |

Review results by category, query type, device, image quality, and in-stock status. Do not compare raw similarity scores across unrelated queries without checking the service’s scoring behavior. Google’s Product Search guidance, for example, says result scores are useful for ordering within a query but are not calibrated for one universal threshold across queries.

## Common failure modes and limits

Visual search has predictable failure modes. Design for them instead of hiding them behind confident labels.

| Failure | What goes wrong | Practical guardrail |
| --- | --- | --- |
| Lookalike, wrong product | Similar color or shape outranks the correct function or brand | Separate exact and similar modes; apply compatibility and category filters |
| Cluttered or occluded query | The model reads the background, another object, or too little of the target | Offer object selection, cropping, and a text fallback |
| Thin image coverage | One front-facing packshot does not represent the item in real use | Add representative angles and context images, then test by query condition |
| Variant collapse | A blue medium result resolves to a red large variant or parent product | Index parent-child relationships and return the chosen variant explicitly |
| Stale index or commerce data | A result is discontinued, unavailable, or shown at the wrong price | Sync product changes and monitor freshness lag |
| Popularity bias | Large or frequently clicked products dominate visually relevant results | Set category, diversity, and availability guardrails; audit tail products |
| Slow or costly retrieval | High-resolution inference and large indexes make camera search frustrating or expensive | Use an appropriate embedding size, candidate limits, caching, and measured refresh schedules |
| Privacy and rights risk | Uploaded photos may contain people, private spaces, or images you cannot store | Document retention and deletion, request consent where needed, and restrict access to query images |
| Unsupported implementation advice | A tutorial points to a retired API or an old model | Check the provider’s current docs, release notes, regions, and limits before building |

Visual similarity is evidence for discovery. It is not proof of identity, safety, fit, authenticity, or compatibility. Product records and human review still matter for high-risk categories.

## FAQ

### Does visual search replace text search?

No. Visual search is a second entry point for shoppers who can show an item more easily than they can name it. Text search remains better for constraints such as size, compatibility, budget, delivery, and use case. The strongest ecommerce experiences combine image, text, filters, and a clear fallback.

### Does visual search require AI?

Modern systems usually use computer vision and machine-learned image representations. Exact duplicate detection can use simpler image hashes, while product discovery typically needs a learned representation and a retrieval index. Generative AI is optional. The system still needs good product data whether the model generates language or only returns nearest neighbors.

### What data does a visual search system need?

It needs query and reference images tied to stable product and variant IDs. It also needs categories, brand, normalized attributes, identifiers, canonical URLs, current price and availability, and a process for updating the index. Feeds or structured data may be required by an external shopping surface, while an owned-store implementation can use its own catalog API.

### Is a visual search API required?

An API is common when a web or mobile interface sends an image to a managed service and receives product IDs. It is not the only deployment model. A commerce platform may provide the feature inside its search stack, or a team may host retrieval internally. Choose the boundary that lets you control catalog updates, privacy, latency, and evaluation.

### How do I improve visual search results?

Start with clearer, representative images and complete image-to-variant mappings. Normalize color, material, shape, and category values. Keep product, price, availability, and URL data current. Then test exact and similar queries separately, review no-result and refinement sessions, and fix the catalog gaps that explain poor results.

### Can visual search identify an exact product from any photo?

No. Exact identification depends on image quality, the object selected, reference-image coverage, catalog coverage, and the service’s ability to distinguish similar items. When certainty is low, label results as similar and give the shopper ways to refine the query.

Visual search works when the image query and the product record tell the same story. If your team needs help turning scattered product information into live, normalized data for AI commerce and product discovery, [see how Catalog can help](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/visual-search-technology
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# XML feed: Ecommerce product data, structure, and validation

*October 3, 2026 · Catalog Team · Product Data · 15 min read*

> Learn what an XML feed is, how product feeds differ from RSS and Atom, how channel schemas work, and how to validate ecommerce data before delivery.

An XML feed is easy to mistake for a single standard. XML supplies the markup and hierarchy. RSS, Atom, Google Merchant Center, and marketplace specifications define what the tags mean. That distinction matters when a channel accepts your file but rejects products, or when a well-formed document carries stale price and availability.

Start with ecommerce use case, then compare XML with CSV, TSV, JSON, and API delivery and validate the output before a channel does. Catalog sits upstream as the product data layer: we help normalize IDs, variants, attributes, price, availability, and provenance before you publish a channel-specific output.

## XML feed means markup plus a destination contract

An XML feed is a regularly delivered XML document that exposes records to another system. XML describes the document's syntax: elements, attributes, nesting, namespaces, and character encoding. It does not define a product's fields, an inventory vocabulary, an update mode, or a channel's approval rules.

An ecommerce product feed usually contains one record for each product or sellable variant. Common facts include:

- stable product and variant IDs;
- titles, descriptions, brands, and categories;
- product and image URLs;
- price, currency, sale price, and availability;
- GTIN, MPN, SKU, or other identifiers;
- color, size, material, dimensions, compatibility, and other attributes;
- shipping, tax, return, region, or channel-specific fields.

The element names vary by destination. One specification may use `<item>`, another `<offer>`, and another `<product>`. A file becomes useful when its vocabulary, required fields, value rules, and update behavior match the receiving system.

Catalog's [product feed glossary](https://www.getcatalog.ai/glossary/product-feed) covers the broader feed concept. Its [data feed glossary](https://www.getcatalog.ai/glossary/data-feed) explains how the same product data can move through files, hosted URLs, and APIs.

## RSS and Atom are XML feeds too, but they solve a different job

The phrase “XML feed” often refers to web-publishing feeds. RSS 2.0 and Atom 1.0 are XML vocabularies for syndicating articles, news, podcast episodes, and other frequently updated content.

RSS 2.0 uses an `<rss>` root with a `<channel>` that contains channel metadata and `<item>` entries. Its required channel fields include `title`, `link`, and `description`, while item fields describe a published piece of content. The [RSS 2.0 specification](https://www.rssboard.org/rss-specification) defines that vocabulary.

Atom uses a `<feed>` root in the `http://www.w3.org/2005/Atom` namespace. An Atom feed requires fields such as `id`, `title`, and `updated`, with each `<entry>` carrying its own identity and update time. The [Atom 1.0 specification](https://datatracker.ietf.org/doc/rfc4287/) defines those rules.

A product feed borrows XML's structure and may use RSS as a container, as Google does. It then adds a destination vocabulary for products. A valid blog RSS file does not become a valid shopping feed simply because both files end in `.xml`.

| Feed type | What it distributes | Typical structure | Who reads it |
| --- | --- | --- | --- |
| RSS or Atom web feed | Articles, news, podcasts, or updates | `<channel>` and `<item>`, or `<feed>` and `<entry>` | Feed readers, aggregators, and publishing tools |
| Ecommerce product feed | Products, offers, and variants | Destination-defined product elements and fields | Ad platforms, marketplaces, retailers, search indexes, and commerce tools |
| XML sitemap | URLs and crawl hints | `<urlset>` and `<url>` | Search-engine crawlers |

A sitemap helps a crawler discover URLs. It does not carry the offer data a shopping channel needs, such as a sellable SKU, price, or availability.

## Read the XML structure before mapping fields

The [XML specification](https://www.w3.org/TR/xml/) separates a document's well-formedness from its destination-specific validity. A well-formed document follows XML's syntax. A valid feed also follows the schema and business rules of the receiving channel.

Look for five building blocks:

1. **Declaration.** The first line can identify XML version and encoding, such as `<?xml version="1.0" encoding="UTF-8"?>`.
2. **One root element.** Every XML document has exactly one document element. All other elements sit inside it.
3. **Nested elements and attributes.** Start and end tags must nest correctly. Attributes belong inside a start tag and use quoted values.
4. **Namespaces.** A namespace maps a prefix or default name to a URI. The prefix is an alias; the URI is the identity. The [XML namespaces specification](https://www.w3.org/TR/xml-names/) explains why an almost-correct URI still identifies a different vocabulary.
5. **Escaped characters.** Reserve `<` and `&` for markup. Use `&lt;` and `&amp;` in product text, or use a correctly formed CDATA section where the destination allows it.

### Example: abbreviated Google Merchant Center RSS 2.0 product feed

The example below is intentionally destination-specific. Google Merchant Center accepts RSS 2.0 and Atom 1.0 product files, and its RSS format uses the Google Merchant Center namespace. The `g:` fields and namespace URI belong to Google's contract. They are not universal product tags.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Northline products</title>
    <link>https://www.example.com</link>
    <description>Current Northline product offers</description>

    <item>
      <g:id>JKT-001-NAVY-M</g:id>
      <g:title>Waterproof Commuter Jacket, Navy, M</g:title>
      <g:description>Waterproof recycled nylon jacket with a packable hood.</g:description>
      <g:link>https://www.example.com/products/commuter-jacket</g:link>
      <g:image_link>https://www.example.com/images/jkt-001-navy-m.jpg</g:image_link>
      <g:availability>in stock</g:availability>
      <g:price>148.00 USD</g:price>
      <g:condition>new</g:condition>
      <g:brand>Northline</g:brand>
      <g:gtin>00012345678905</g:gtin>
      <g:item_group_id>JKT-001</g:item_group_id>
      <g:color>Navy</g:color>
      <g:size>M</g:size>
    </item>
  </channel>
</rss>
```

![Google Merchant Center RSS 2.0 example with namespaced product attributes](https://www.getcatalog.ai/images/blog/xml-feed-google-rss-example.svg)

Here is what matters in the example:

- `<rss>` and `<channel>` provide the RSS container Google expects.
- `xmlns:g` declares Google's exact namespace. Every Google attribute uses the matching `g:` prefix.
- The stable variant ID and `g:item_group_id` let the destination identify the offer and group it with related variants.
- `g:price`, `g:availability`, and `g:condition` use values defined by Google's product specification. Another destination can require different names or accepted values.
- The file can be perfectly well-formed and still fail because a required field is missing, a value is invalid, or the product page disagrees with the feed.

Google's [RSS guide](https://support.google.com/merchants/answer/14987622?hl=en) also says to include every product you intend to keep in Merchant Center, rather than sending only recent changes. The live [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) remains authoritative for category- and market-specific requirements.

## How an ecommerce XML feed is produced

An XML feed is the last mile of a product-data workflow. The source catalog, PIM, ecommerce platform, ERP, DAM, supplier file, or inventory system owns different facts. A reliable flow keeps those facts governed before it serializes them into tags.

1. **Collect source records.** Bring together identity, content, media, commercial state, variants, and policy data.
2. **Normalize the record.** Standardize units, category values, identifiers, availability, and variant relationships. Resolve which system owns price and stock.
3. **Map to the destination.** Translate the normalized record into the channel's field names, namespaces, value lists, conditional fields, and update mode.
4. **Generate and deliver.** Produce the XML file or endpoint, then upload it, host it at a scheduled URL, or send it through the channel's integration.
5. **Monitor the result.** Fetch status, parse errors, schema errors, rejected products, warnings, freshness, and page-to-feed mismatches all belong in the operating record.

The workflow around feeds is broader than the format itself. Catalog's guide to [product feed management](https://www.getcatalog.ai/blog/product-feed-management) covers that operating model. This page stays focused on XML structure, delivery choices, and validation.


## Where XML fits by channel

A channel's current specification determines whether XML is still the right output. The same product record may need XML for one destination, TSV for another, and JSON or an API for a third.

| Channel or use case | XML support and current caveat |
| --- | --- |
| **Google Merchant Center** | Accepts XML product files in RSS 2.0 or Atom 1.0. Google's `g:` namespace and product attributes are destination-specific. Parsing is only the first gate; Merchant Center also evaluates required attributes, values, policy, and consistency. |
| **Meta Commerce Manager** | The [Meta feed API](https://developers.facebook.com/documentation/ads-commerce/catalog/guides/feed-api) documents CSV, TSV, RSS XML, and Atom XML options, including scheduled product feeds. Meta has its own field rules and diagnostics, so a Google feed may need a separate mapping. |
| **eBay MIP** | The [eBay MIP requirements](https://developer.ebay.com/api-docs/user-guides/static/mip-user-guide/mip-feed-requirements.html) support CSV and XML for that specific integration. eBay APIs and other listing workflows can have different contracts. |
| **Amazon Selling Partner API** | Amazon ended support for legacy XML and flat-file listing feeds in the Feeds API on July 31, 2025. Current developer workflows use the Listings Items API or `JSON_LISTINGS_FEED`, as described in Amazon's [listing migration guidance](https://developer-docs.amazon.com/sp-api/lang-en_US/docs/listings-management-workflow-migration). |
| **Walmart Marketplace** | Walmart's newer Item Spec v4.X is available in [JSON Schema format only](https://developer.walmart.com/cl-marketplace/docs/item-spec-v4x). A generic XML export does not satisfy that newer item contract. |
| **Search, affiliates, and retail partners** | XML remains common when a provider publishes an XML schema or a hosted-feed specification. The provider's root element, field names, update cadence, and authentication rules govern the integration. |

These caveats are why a single “universal XML feed” is a brittle design. Keep a shared, governed product record and generate the output each destination actually documents.

## XML vs. CSV, TSV, JSON, and API delivery

The format is a delivery choice. The destination's schema is the contract.

| Method | Strengths | Trade-offs | Good fit |
| --- | --- | --- | --- |
| **XML** | Explicit hierarchy, namespaces, repeating elements, and mature schema tooling such as XSD | Verbose; tag and namespace mistakes can stop processing; requires destination-specific mapping | Channels that require RSS/Atom XML, or records with nested and repeating data |
| **CSV** | Easy to inspect and edit in spreadsheets; compact for flat records | Commas, quotes, line breaks, and encoding need careful escaping; nested data is awkward | Small or flat catalogs and destinations that publish a CSV template |
| **TSV** | Spreadsheet-friendly and less likely to collide with commas in product copy | Tabs and line breaks still need escaping; field hierarchy remains flat | Large tabular exports and channels that prefer tab-delimited files |
| **JSON file** | Natural for arrays, objects, conditional fields, and modern software workflows | Schema and validation rules still vary; human spreadsheet review is less convenient | Destinations such as current Amazon listing feeds that specify JSON |
| **API delivery** | Low-latency updates, partial changes, authentication, and response-level errors | Requires integration work, rate-limit handling, retries, and ongoing version maintenance | Inventory or price changes that need programmatic updates and immediate feedback |

Choose XML when a channel documents it or when hierarchical records reduce ambiguity. Choose CSV or TSV when a channel's template and team workflow are tabular. Choose JSON or an API when the destination defines those interfaces. Keep the underlying product model independent from every output format.

## Validate in layers, then inspect channel diagnostics

A green XML parser result only establishes that the document can be read. A complete validation pass covers syntax, schema, data, delivery, and destination behavior separately.

### 1. Delivered file

- The exact URL or file the channel fetches is the validation target.
- An HTTP success response, expected content type, and complete file are required. An HTML login page or truncated response is a delivery failure.
- Authentication, redirects, file size, compression, and filename rules must match the destination's specification.
- Atomic file generation prevents a scheduled fetch from reading a half-written export.

### 2. Well-formedness

- One root element and correctly nested, closed tags are required.
- Reserved characters such as `&` and `<` must be escaped in product text.
- The declared encoding must match the bytes. UTF-8 is the safest default for most ecommerce exports.
- Invalid control characters and malformed CDATA sections must be removed.

### 3. Namespaces and channel schema

- Every namespace URI and prefix must match the destination's specification. `xmlns:g="http://base.google.com/ns/1.0"` and a similar-looking URI are different contracts.
- The root, container, element names, data types, allowed values, and required order must match the channel's XSD or schema when one is available.
- Empty optional elements and unsupported custom tags should be omitted. A parser can accept a tag that the channel ignores.

### 4. Identity and relationships

- Every product or variant ID must be stable and unique within the destination.
- Parent, child, item-group, bundle, and replacement-part relationships must remain intact.
- GTIN, MPN, brand, and other identifiers belong in the record when the destination and product type require them.
- Each variant needs its correct image, price, availability, color, size, and quantity.

### 5. Commercial facts and URLs

- Price, currency, sale price dates, and availability must agree with the product page and checkout.
- Product and image URLs need to work from a non-authenticated session, with redirect, canonical, locale, and parameter rules resolved before delivery.
- An out-of-stock or discontinued product must follow the destination's removal or availability rule.

### 6. Coverage, freshness, and diagnostics

- Feed product and variant counts should match the intended active assortment.
- The destination's full-catalog or partial-update semantics must be explicit. Google Merchant Center's RSS guidance expects all products intended for the data source; some APIs use partial operations.
- High-risk fields, especially price, availability, and sale dates, need a refresh cadence that matches how quickly they change.
- The destination's processing report supplies the final evidence after an upload or fetch. Warnings that affect eligibility deserve attention alongside fatal parser errors. Google's [feed troubleshooting guidance](https://support.google.com/merchants/answer/13760862?hl=en) makes the same distinction between ingestion and product status.

### Common validation mistakes

| Mistake | What you see | What to fix |
| --- | --- | --- |
| Unclosed tag or raw ampersand | XML parser stops at a line and column | Escape reserved characters and generate tags from an XML library or tested serializer |
| Wrong namespace URI or prefix | File parses, but channel fields are missing or ignored | Copy the exact namespace declaration and prefix required by the destination |
| Unknown field names | File parses, product is incomplete | Map to the channel's vocabulary; XML does not make custom names meaningful |
| Duplicate or changing IDs | Duplicate listings, overwritten variants, or new products on every refresh | Use a stable ID strategy across source, feed, and channel |
| Missing conditional fields | Some categories or variants are rejected | Apply rules based on category, country, condition, and other trigger fields |
| Stale price or availability | Disapprovals, mismatched offers, or unavailable products in ads | Source commercial facts from the system that owns them and refresh frequently |
| Feed and page disagree | Channel flags price, page, image, or availability mismatch | Reconcile the feed, product page, structured data, and checkout |
| Delta sent where a full file is expected | Products disappear or old records remain | Follow the destination's full-catalog and deletion semantics |

## FAQs

### Is an XML feed the same as an RSS feed?

No. RSS is one XML vocabulary for publishing content. An ecommerce feed may use RSS as a container, as Google's product format does, or it may use a different root and product schema. The receiving specification determines what the file means.

### Is an XML feed the same as an XML sitemap?

No. A sitemap lists URLs and crawl metadata. A product feed carries product records and offer facts for a downstream commerce system. A product URL appearing in a sitemap does not supply price, stock, variants, or channel attributes.

### Can I send one XML product feed to every channel?

Use one normalized product record as the shared source, then map it into each channel's documented output. Google, Meta, eBay, Amazon, and Walmart have different contracts and current format support. Reusing a file is safe only when the destination explicitly supports that vocabulary and update mode.

### Does valid XML guarantee product approval?

No. Well-formedness is the first gate. A channel can still reject a feed for missing fields, invalid values, duplicate IDs, inaccessible URLs, policy issues, stale commercial facts, or mismatches with the product page.

### How often should an XML feed update?

Match the cadence to the risk of the field. Price, inventory, and sale windows need frequent refreshes. Descriptions and attributes can follow a reviewed content schedule. Monitor the time between a source change and a successful channel fetch, then shorten it when shoppers could see an offer you cannot honor.

## Keep XML as an output of a governed product-data layer

An XML file with a title, image, price, and URL can satisfy a basic listing contract. AI commerce and richer discovery need more context: attributes, variants, compatibility, constraints, policies, identifiers, provenance, and freshness. XML alone does not make a catalog machine-ready.

Catalog helps merchants and brands create normalized, enriched, machine-readable product records from the systems where product facts already live. Those records can feed a Google or Meta XML output, a marketplace-specific file, an API, a search index, or an AI-shopping surface. We keep the product data layer separate from each destination's syntax, so a namespace change does not become a new source of truth.

If your team is maintaining XML exports by hand or reconciling different prices, variants, and availability across channels, [talk to Catalog](https://www.getcatalog.ai/) about building a reliable product data layer.

---

Canonical: https://www.getcatalog.ai/blog/xml-feed
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product data API: a practical buyer and builder guide

*October 2, 2026 · Catalog Team · Product Data · 19 min read*

> Learn what a product data API should return, how to model variants and offers, and how to benchmark coverage, freshness, latency, reliability, and cost.

An endpoint that returns a title, price, and image is easy to call. A production product data API must preserve identity across normalization: a group stays linked to its variants, variants to their offers, and volatile values to source and observation time.

Catalog provides a structured product-data layer for AI and agentic commerce. You get the record model, contract questions, and a repeatable evaluation scorecard. For source mechanics, see our [product data extraction](https://www.getcatalog.ai/blog/product-data-extraction) and [price monitoring API](https://www.getcatalog.ai/blog/price-monitoring-api) explainers.

## A product data API is a source-to-record contract

A product data API accepts a product URL, catalog identifier, feed, or search request and returns a typed product record. The record should be safe to store, compare, join, and pass to another system without parsing page markup again.

“Typed” means that a price has an amount and currency, availability uses a documented value set, timestamps have a stated time zone, and an array is different from a free-form string. “Identity-preserving” means the response keeps stable IDs and relationships while it normalizes names, units, and values.

The API contract covers the whole interaction. It includes authentication, request parameters, response schemas, pagination, asynchronous execution, null behavior, errors, rate limits, versioning, retries, and cost. An endpoint description that says only “send a URL and get JSON” leaves the parts that break integrations undefined. An [OpenAPI description](https://spec.openapis.org/oas/latest.html) is a useful baseline because it makes operations, parameters, content types, and schemas inspectable.

A product data API can sit between several kinds of source:

| Source or interface | What it usually returns | When it fits |
| --- | --- | --- |
| First-party catalog API | A merchant’s canonical products, variants, inventory, and offers | You control the store or have an authorized integration |
| Product feed or export | A scheduled snapshot in a file or feed schema | You need bulk loads and can tolerate scheduled updates |
| Product data API | Normalized records from one or many source systems | You need a stable shape across merchants, platforms, or public URLs |
| HTML or scraper output | Page markup and parser-specific fields | You have no structured source and own the parser and its upkeep |

A product data API earns its place when the record is more useful than the page that produced it. The test is whether a downstream developer can rely on field types, identity links, provenance, and failure states without reverse-engineering the response.

![Product group, variants, offers, freshness, and provenance in a product data API](https://www.getcatalog.ai/images/blog/product-data-api-model.svg)

## Model the record at the right grain

The word *product* can mean a product family, a sellable option combination, or a seller’s offer. Pick a grain before you compare APIs. A practical model has three levels:

| Level | Meaning | Fields that belong here |
| --- | --- | --- |
| Product group or family | The shared concept, such as a running shoe model | Group ID, title, brand, shared description, category, and the dimensions that vary |
| Variant | One exact option combination, such as size 9 in black | Variant ID, parent group ID, option values, SKU, GTIN or MPN, variant media, and variant-specific attributes |
| Offer | A seller’s proposition for one variant in a market | Offer ID, seller, channel, country, price, currency, availability, condition, fulfillment, and observation time |

The group describes what the item is. The variant describes which sellable configuration it is. The offer describes who is selling that configuration, where, and under what commercial terms.

A group can have one default variant. A variant can have several offers. A product data API may flatten these objects for convenience, but it should still expose parent IDs and offer-to-variant links so you can reconstruct the relationships.

This separation matches the shape of established commerce vocabularies and APIs. Shopify models a `Product` with `ProductVariant` records, while Google Merchant uses an `offerId` and an `itemGroupId` to identify an offer and link related variants. Schema.org separates `ProductGroup`, `hasVariant`, `variesBy`, and `offers`. Each model is platform-specific. Together, they show why a parent title with a bag of option strings is insufficient. See the [Shopify Product](https://shopify.dev/docs/api/admin-graphql/latest/objects/product), [Shopify ProductVariant](https://shopify.dev/docs/api/admin-graphql/latest/objects/productvariant), [Google Merchant product resource](https://developers.google.com/merchant/api/reference/rest/products_v1/accounts.products), and [Schema.org ProductGroup](https://schema.org/ProductGroup) definitions for the underlying semantics.

A canonical response can preserve those relationships without forcing every provider into the same vocabulary:

```json
{
  "schema_version": "1.0",
  "record_id": {
    "value": "rec_123",
    "namespace": "provider"
  },
  "source": {
    "url": "https://shop.example/products/runner",
    "observed_at": "2026-09-30T12:04:05Z"
  },
  "product_group": {
    "id": "grp_456",
    "title": "Example Runner",
    "brand": "Example"
  },
  "variants": [
    {
      "id": "var_789",
      "group_id": "grp_456",
      "options": {"color": "black", "size": "9"},
      "identifiers": {
        "sku": "RUN-BLK-9",
        "gtin": "00012345678905"
      },
      "offers": [
        {
          "id": "off_001",
          "variant_id": "var_789",
          "seller": "Example Shop",
          "price": {"amount": 129.0, "currency": "USD"},
          "availability": "in_stock",
          "observed_at": "2026-09-30T12:04:05Z"
        }
      ]
    }
  ],
  "provenance": {
    "method": "source_observation",
    "processed_at": "2026-09-30T12:04:08Z"
  },
  "warnings": []
}
```

This is an illustrative canonical shape, not a vendor schema. The important properties are explicit relationships, typed money, namespaced identifiers, and separate source and processing timestamps.

## Keep identifier namespaces explicit

Identifiers answer different identity questions. Store the value, its namespace, the issuer or source, and the scope in which it is unique.

| Identifier | Usually owned by | What it answers | Safe use |
| --- | --- | --- | --- |
| Provider or database ID | API provider or merchant platform | Which record does this system store? | Joins inside that provider’s dataset |
| Source URL | Storefront or marketplace | Where was this record observed? | Traceability and re-fetching, with redirect history |
| SKU | Merchant or seller | Which sellable item does this merchant manage? | Merchant-scoped inventory and operations |
| GTIN | Brand owner under GS1 rules | Which trade item is this? | Cross-seller matching when valid and available |
| MPN | Manufacturer | Which model or part is this? | Manufacturer-level matching with brand context |
| Offer ID | Merchant, feed, or marketplace | Which seller/channel offer is this? | Offer-level updates and deduplication |
| Group or parent ID | Catalog or normalization layer | Which variants belong together? | Variant grouping and shared attributes |

A SKU can be reused by two sellers. A URL can change. A provider ID can be meaningful only inside one tenant. A GTIN identifies a trade item and is not a substitute for a store SKU. [GS1’s GTIN definition](https://support.gs1.org/support/solutions/articles/43000734283-what-is-a-global-trade-item-number-gtin-) and [Google’s identifier guidance](https://support.google.com/merchants/answer/160161?hl=en) are useful guardrails: preserve manufacturer-assigned identifiers and never invent a missing value.

Do not join records on title, URL, or a bare SKU across merchants. Keep each identifier in a typed namespace and make the matching decision explicit. A good API returns the original values alongside any normalized value so you can audit a merge.

## Read the API contract before writing code

The response shape is only one part of the integration. Ask for the following behavior in the contract and test fixtures.

| Contract area | What to demand | Why it changes your implementation |
| --- | --- | --- |
| Authentication and scope | Header or token scheme, scopes, key rotation, tenant and environment boundaries | Determines secret storage, least privilege, and deployment separation |
| Schema and types | OpenAPI or JSON Schema, required fields, enums, units, currency, time zone, and compatibility rules | Prevents silent parsing and unit errors |
| Nulls and omission | Meaning of `null`, missing fields, empty arrays, empty strings, and disabled features | Lets you distinguish “not observed” from “not applicable” or “failed” |
| Pagination | Cursor or page token, stable ordering, page size, continuation expiry, and duplicate behavior | Prevents dropped or repeated records in large results |
| Asynchronous jobs | Accepted response, execution ID, states, polling or callback rules, cancellation, result retention, and partial results | Separates submission from completion and gives workers a safe state machine |
| Errors | HTTP status, machine-readable code, request ID, item-level errors, and retryability | Makes failures observable and retry logic safe |
| Rate limits | Quotas by key, tenant, or route; burst and concurrency rules; limit headers; `Retry-After` | Lets you throttle before work fails and budget capacity |
| Versioning | Version location, backward-compatibility policy, deprecation window, and schema-change notice | Keeps generated clients and stored records usable over time |
| Idempotency | Idempotency key support, retention, deduplication scope, and replay result | Prevents duplicate jobs and duplicate charges after a timeout |
| Cost | Unit of billing, treatment of failed or empty records, refresh cost, and enrichment cost | Gives you cost per usable record rather than cost per request |

For pagination, prefer a cursor or page token tied to a stable snapshot. An offset can shift when a catalog changes between calls. For asynchronous work, model states such as `queued`, `running`, `completed`, `completed_with_errors`, `failed`, and `expired`. Store the execution ID and request ID with every result.

HTTP semantics help set sensible defaults. `429 Too Many Requests` indicates rate limiting, and the `Retry-After` header can communicate when a client should try again. Read the [HTTP semantics](https://www.rfc-editor.org/rfc/rfc9110.html) and [429 guidance](https://datatracker.ietf.org/doc/html/rfc6585#section-4), then use the provider’s documented policy for the final retry decision.

A timeout does not prove that a POST failed. Unless the API documents idempotency keys or another deduplication mechanism, treat a POST retry as potentially unsafe. If idempotency is supported, send a stable key derived from your logical job, persist it, and confirm whether a replay returns the original result or creates a new execution.

### Contract questions to answer before integration

1. Can the current schema generate a client without hand-written field guesses?
2. Which fields are required for a usable record, and which are optional by category or source?
3. How are money, units, locale, time zone, and availability values represented?
4. Can a response contain a valid record and item-level failures at the same time?
5. How do you retrieve a large result, and what happens if a page token expires?
6. Which status codes and error codes are safe to retry?
7. How do you correlate a request, execution, source URL, and stored record?
8. What changes require a new API version, and how are deprecations announced?
9. What is billable when a job returns no usable record or only a partial result?

Catalog’s [public API page](https://api.getcatalog.ai/) shows a concrete extraction interface with `POST /v2/extract`, `x-api-key` authentication, URL input, country selection, and explicit enrichment, review, and image-tag flags. That level of explicitness is useful for downstream builders because a feature flag changes the meaning of a missing field. Treat batch support, rate limits, latency targets, freshness, uptime, and accuracy as contract questions rather than assumptions from a sample request.

## Freshness has two clocks

A record can arrive quickly and still describe an old page. It can also take time to process a source change and eventually return a current value. Track these clocks separately:

- **Source age:** how long since the value was observed at the source.
- **Processing duration:** how long the provider spent fetching, parsing, normalizing, and enriching.
- **Output lag:** how long between a source change and the first usable API result that contains it.
- **Serving age:** how long since the API stored or published the result you are reading.

Use timestamps at the field or offer level when a value changes independently. A record-level `updated_at` cannot tell you whether a price, image, or availability value is current. A source-reported update time also has provider-specific semantics. For example, Shopify exposes a product `updatedAt` field, but a platform timestamp can change for inventory or administrative reasons. Keep the provider timestamp and your own observation timestamp instead of treating one as universal truth.

A simple measurement set is:

```text
source_age = api_read_time - source_observed_at
processing_duration = output_ready_at - fetch_started_at
output_lag = output_ready_at - controlled_source_change_at
```

Measure price and availability on a shorter acceptable-age window than stable descriptions or dimensions. If you cannot create a controlled source change, report observed source age and processing duration separately. Do not turn a sample response duration into a freshness promise. Catalog’s [product data quality guidance](https://www.getcatalog.ai/blog/product-data-quality) has adjacent advice on freshness lag and field-level quality checks.

## Separate source facts, normalization, and enrichment

A normalized value can preserve the source fact while changing its representation. An enriched value adds a classification, attribute, relationship, or description that was not directly present in the source. Those layers need different trust and review rules.

| Layer | Example | Minimum provenance |
| --- | --- | --- |
| Source-observed | The page says `water resistant` and shows `$129.00` | Source URL, observed time, raw or captured evidence |
| Normalized | `water resistant` maps to `water_resistance: true`; `$129.00` becomes amount `12900` in USD cents | Source field, transformation rule or unit, processor version |
| Enriched or inferred | A category model assigns `trail_running`; an AI system proposes a material | Method or model, production time, evidence, confidence, and review state |

Keep source and enriched values addressable separately. A downstream agent may accept an inferred category for discovery while requiring source evidence for a safety, compatibility, or regulated claim. Catalog’s [product data enrichment guide](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) covers the broader enrichment workflow; the contract question here is whether each value tells you how it was produced.

Null behavior needs the same discipline. A documented `null` might mean “source did not provide this value.” In another API, it might mean an option was disabled. An omitted field might mean the schema version does not support it, while an empty array might mean an observed collection is empty. An error state can look identical if the API does not expose per-field or per-item status.

Require a documented distinction among at least these states:

- **Not observed:** the source did not expose the field.
- **Not applicable:** the field does not apply to the record.
- **Disabled:** the request omitted or disabled the feature.
- **Unsupported:** the source or provider cannot produce the field.
- **Failed:** processing attempted the field and did not complete.
- **Empty:** the source explicitly returned an empty collection or value.

Never treat `null` as a safe default for zero, false, or an empty list. Preserve the status so consumers can choose whether to hide, retry, or review the field.

## Evaluate a product data API with a reproducible scorecard

A demo proves that one URL works. A benchmark should show how an API behaves across the catalog you intend to operate.

Start with a representative set of 100 to 300 URLs or identifiers, adjusted to your budget and catalog size. Stratify the set by source platform, category, country and language, simple and multi-variant products, seller count, and unavailable or out-of-stock cases. This range is a practical starting point, not an external standard.

### Build the test

1. **Define success.** Write the required fields for each category and what counts as a usable record. Mark price, currency, availability, and identity fields as hard gates if a downstream workflow depends on them.
2. **Capture ground truth.** Manually record the source value and timestamp for the fields you will use. Capture each variant and offer that matters, not only the parent title.
3. **Run the same configuration.** Use the same input set, region, locale, flags, output version, concurrency, and retry policy for every candidate.
4. **Repeat after a controlled change.** Change a test price or availability value where you control the source, then measure when the correct field appears.
5. **Retain raw evidence.** Store request IDs, response bodies, status codes, job states, page tokens, timestamps, and billable units. Redact secrets.
6. **Report slices.** Publish results by platform, category, market, variant complexity, and outcome. A single average hides the failures your production catalog will expose.

### Score the dimensions

| Dimension | Measure | Decision signal |
| --- | --- | --- |
| Coverage | Eligible inputs that produce a usable record, split by source and category | Shows where the API works and where it returns unsupported or empty results |
| Accuracy | Exact or normalized correctness for price, currency, brand, specs, image, and availability | Separates plausible text from values safe to use |
| Completeness | Required-field and category-attribute coverage per record | Shows whether records can power the intended workflow |
| Identity and variants | Stable group and variant IDs, identifier preservation, parent links, option values, and variant-specific offer fields | Catches merges, splits, and parent-level data incorrectly copied to variants |
| Freshness | Source change to correct output, plus source age and serving age by field | Sets refresh cadence from observed behavior |
| Enrichment | Precision and coverage on labeled inferred values, with evidence and confidence | Shows whether enrichment adds usable facts or review work |
| Submit and end-to-end latency | p50, p95, and p99 from submit to completion, segmented by batch and source | Exposes tail behavior that an average conceals |
| Reliability | HTTP errors, job completion, timeouts, schema validation, retry outcomes, and request-ID availability | Shows whether the pipeline can operate and debug failures |
| Partial failures | Per-input status, error code, retry scope, and duplicate behavior in mixed-result jobs | Determines whether one bad URL blocks a whole batch |
| Cost | Total spend divided by usable records and by correct usable records, including refreshes, enrichment, and retries | Connects price to data that actually reaches production |

Use hard gates before a weighted score. If a shopping agent cannot identify a variant or trust its currency and availability, a strong description score does not compensate. For the remaining dimensions, report rates and distributions with the test conditions beside them.

A small set of formulas keeps the benchmark reproducible:

```text
usable_record_rate = usable_records / eligible_inputs
required_field_accuracy = correct_required_fields / labeled_required_fields
correct_record_rate = records passing all hard gates / eligible_inputs
cost_per_correct_record = total_cost / correct_records
```

Report p50 and tail percentiles for latency rather than an average alone. [Service-level objective guidance](https://sre.google/sre-book/service-level-objectives/) explains why a high percentile captures the slow requests that shape user experience. The same logic applies to extraction and async completion.

## Choose the right product-data layer

The right choice depends on source authority, source count, and how much operational behavior you want to own. When a structured layer is the need, Catalog is our recommended fit for a product-data workflow because it focuses on normalized records, synchronization, distribution to AI surfaces, and outcome measurement.

| Option | Best fit | What you own |
| --- | --- | --- |
| **Catalog** | You need a structured product-data layer across heterogeneous product sources and AI shopping surfaces | Your source policy, required fields, acceptance gates, and downstream use of the records |
| First-party API or feed | You own the catalog or have an authorized merchant integration | Source credentials, platform-specific semantics, and feed or webhook operations |
| Build and maintain extraction | You have a narrow source set and want full control of parsers and storage | Fetching, parser changes, identity resolution, freshness, retries, and data quality |

The [Catalog API](https://api.getcatalog.ai/) shows the pattern plainly: a versioned extraction route that accepts product URLs and explicit options, then returns machine-ready product data. The value is the layer around extraction. Your application can keep identity and provenance with the record, apply the scorecard above, and publish the accepted data to AI commerce workflows.

Use [product data quality](https://www.getcatalog.ai/blog/product-data-quality) for operating field-level checks, [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) for distribution concerns, and [trusted data sources](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce) for the broader source and agent architecture. The focus here is making the API contract and returned record testable.

## FAQ

### Is a product data API the same as a product catalog API?

A product catalog API usually exposes one merchant’s own catalog and may support creating or updating products. A product data API can normalize records from several sources, including public product pages, and often emphasizes read access, identity resolution, provenance, and cross-source consistency. The names overlap, so compare the input sources and response semantics rather than the endpoint label.

### Should price live on the product, variant, or offer?

Put price on the lowest level where it can change independently. A single canonical price can live on a variant. A seller-, market-, currency-, or fulfillment-specific price belongs on an offer. Keep the currency and observation time with the amount, and avoid copying an offer price to every parent record without the seller and market context.

### What does a successful HTTP response prove?

It proves transport-level success. It does not prove that every input produced a usable record, that a price is current, or that an asynchronous job has completed. Track service status and data status separately, including per-input failures inside a successful batch response.

### How fresh should product data be?

Set the age window from the decision the data supports. Price, availability, inventory, delivery, and promotions usually need tighter windows than descriptions, dimensions, or stable specifications. Measure source age, processing duration, and source-change-to-output lag separately so a fast response does not hide stale data.

### Can enriched attributes be treated as source truth?

Only when the provider gives you evidence and your own validation accepts the field for that use. Keep source-observed, normalized, and enriched values separate. Store the method, production time, confidence, and review state for inferred values, then apply stricter gates to compatibility, safety, and regulated claims.

### How large should an evaluation set be?

Begin with a stratified set large enough to include your major platforms, categories, markets, variant patterns, and unavailable cases. One hundred to 300 inputs is a practical first pass for many teams. Expand the set when a long tail, high failure cost, or new source segment changes the decision.

If you need a structured product-data layer that your developers and AI commerce workflows can build on, [see how Catalog works](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/product-data-api
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Manufacturer part number: How to use MPNs in ecommerce

*October 2, 2026 · Catalog Team · Product Data · 14 min read*

> Learn what a manufacturer part number is, how it differs from SKUs and GTINs, where to find it, and how to map it into feeds and product schema.

A product record can contain several numbers that look interchangeable. They are not. A merchant SKU, manufacturer part number, GTIN, model number, and channel item ID each answer a different identity question. Mixing them can split one product across listings, attach the wrong variant to an order, or make a feed fail validation.

This guide explains how MPNs work in ecommerce, how to find and validate one, and how to keep the same manufacturer-assigned value aligned across your catalog, product pages, feeds, marketplaces, and structured data.

## What is a manufacturer part number (MPN)?

A manufacturer part number, or MPN, is a code the manufacturer assigns to identify a particular product or part in its catalog. It can contain letters, numbers, and punctuation, and formats vary by manufacturer. An MPN is meaningful with its manufacturer or brand, so the pair `brand + MPN` is the reliable product identity for matching.

An MPN usually identifies an orderable product configuration. A different connector, voltage, color, capacity, or revision can have a different MPN. Some manufacturers reuse one MPN across apparel sizes or other variations, so your product model should follow the manufacturer’s own catalog rather than an assumption about variants.

An MPN identifies a product type. It is not a serial number for one physical unit, a lot number, or a code that a retailer should invent. It can help a buyer find a replacement part, help a distributor join records, and help a shopping channel distinguish products from the same brand. It does not replace the product title, specifications, or variant relationship.

Google defines MPN as identifying a specific product among the products from the same manufacturer. Its Merchant Center guidance says to use the manufacturer-assigned value, avoid guesses, and submit the correct value for each variant when one exists. [Google’s MPN requirements](https://support.google.com/merchants/answer/6324482?hl=en) are a useful baseline even when another destination has its own rules.

## MPN vs. SKU vs. GTIN

The fields can contain similar-looking strings. Their owners and scopes are different.

| Identifier | Assigned by | Scope | Typical ecommerce use |
| --- | --- | --- | --- |
| **MPN** | Manufacturer | The manufacturer’s catalog, in combination with its brand | Parts lookup, product matching, feeds, marketplaces, and technical catalogs |
| **SKU** | Merchant or seller | One seller’s inventory and operating systems | Stock, fulfillment, purchasing, reporting, and internal updates |
| **GTIN** | Brand owner through the GS1 system | A trade item that can be priced, ordered, or invoiced across trading partners | Barcode scanning, product feeds, marketplace matching, and retail exchange |
| **Model number** | Usually the manufacturer | A product family or model naming system | Product naming, customer support, and manufacturer lookup |
| **Channel item ID** | Destination or merchant | One feed or channel account | Row-level updates and offer management |

A [SKU is a merchant-specific identifier](https://www.getcatalog.ai/blog/what-is-a-sku). A GTIN is a global trade-item identifier. [GS1 describes GTIN](https://www.gs1.org/standards/id-keys/gtin) as a number a company can use to uniquely identify its trade items. An MPN belongs to the manufacturer and is interpreted with the brand. A model number may describe a family, while the full MPN can identify the exact orderable version.

A store SKU can happen to match an MPN. Keep the fields separate anyway. If you manufacture a private-label product, the same code may be the value you use internally and the manufacturer-assigned part number. Record both roles and their source instead of relying on a naming coincidence. Google specifically warns merchants not to put ordinary store SKUs into MPN, GTIN, or brand fields.

### A concrete identity map

Google’s product-identifier example uses a green small T-shirt with these values:

| Field | Google’s example |
| --- | --- |
| Merchant item ID | `9876-S-GRN` |
| Brand | `Google` |
| GTIN | `9504000059422` |
| MPN | `00638HAY` |
| Variant | Green, small |

The item ID is the channel row key. The MPN identifies the product within Google’s brand catalog. The GTIN identifies the trade item. The color and size explain which variant the row represents. The example comes from [Google’s unique product identifier guidance](https://support.google.com/merchants/answer/160161?hl=en); the roles apply to any catalog that keeps its identity fields distinct.

## Where to find an MPN

Start with a source controlled by the manufacturer. Use a reseller listing as a lead only when you can confirm it against manufacturer documentation.

1. **Inspect the product and packaging.** Look for a label, plate, box, barcode panel, or printed specification. An MPN may be next to terms such as `part number`, `model`, `P/N`, or `item number`. Do not assume every number on a label is the MPN. A serial number and a lot code identify a unit or production run.
2. **Search the manufacturer’s catalog.** Open the product page, ordering table, technical drawing, manual, or data sheet. Use the full orderable string, including suffixes that encode size, package, voltage, finish, or revision.
3. **Ask the supplier for the manufacturer record.** Request the brand, exact MPN, product description, variant details, and source document together. A supplier SKU or distributor stock code is useful for procurement, yet it is not automatically the manufacturer’s part number.
4. **Reconcile the value before importing it.** Confirm that the brand, product family, variant, pack quantity, and condition match the item you sell. Store the source URL or document, retrieval date, and reviewer with the value.

Do not manufacture a value to fill a blank. If you are the product manufacturer and the product has no assigned MPN, a destination may provide a narrow path for a self-assigned identifier. Google describes that exception for a manufacturer who is the only seller, and it still requires a unique value paired with the store or product brand. That exception does not turn a merchant SKU into an MPN for a product made by someone else.

## How MPNs work in feeds and marketplaces

An MPN is one field in a destination record. It does not replace the row ID, brand, GTIN, title, variant, or offer data. Map each field from your canonical product record to the destination’s schema.

| Destination | MPN field or workflow | What to do |
| --- | --- | --- |
| Google Merchant Center | `mpn`, alongside `brand`, `gtin`, and `id` | Send the manufacturer-assigned MPN when available. Google documents a 1 to 70 character, non-repeated string, recommends ASCII, and requires it for products without a manufacturer-assigned GTIN unless the product has no associated MPN or is custom-made. |
| eBay | Category-specific product identifier workflow | Product identifiers are required in most categories. Use the identifier that exactly matches the item and choose “Does not apply” when the product has no identifier or you are unsure. |
| Other marketplaces and retailers | Destination-specific identifier field | Check the category contract, then map the verified MPN with the manufacturer or brand field. Do not copy a channel’s seller SKU into the MPN field. |

Google can disapprove an item with an incorrect MPN. Its guidance also covers edge cases that frequently cause feed errors:

- A compatible or refurbished product should use the MPN from the company that actually built that product, not the OEM’s MPN to imply compatibility.
- A manufacturer-created bundle uses the bundle MPN. A merchant-created bundle uses the main product’s MPN when the destination’s bundle rules call for it.
- A manufacturer-created multipack uses the multipack MPN. A merchant-created multipack uses the individual product’s MPN under Google’s documented rule.
- A product variant needs its own MPN when the manufacturer assigned one. Google notes an apparel-size exception because sizes often share an MPN.

[eBay’s product-identifier guidance](https://www.ebay.com/sellercenter/listings/product-identifiers) also stresses exact catalog matches. Category requirements change, so treat this table as a mapping pattern rather than a universal marketplace rule.

For a broader operating model, see our guide to [product feed management](https://www.getcatalog.ai/blog/product-feed-management). A feed is a destination output. Your canonical record should remain the place where the verified MPN, its source, and its product scope are governed.

## Store MPN as a governed identity field

The safest product model keeps MPN, SKU, GTIN, brand, and variant relationships separate. It also records why the value can be trusted.

```json
{
  "product_id": "9876-S-GRN",
  "brand": "Google",
  "mpn": "00638HAY",
  "gtin": "9504000059422",
  "sku": "STORE-GREEN-S",
  "variant": {
    "color": "green",
    "size": "S"
  },
  "mpn_provenance": {
    "source_type": "manufacturer_catalog",
    "source_ref": "supplier-record-2026-09",
    "status": "verified",
    "verified_at": "2026-09-30"
  }
}
```

The identifier values above use Google’s published example for the brand, MPN, and GTIN. `STORE-GREEN-S` and the provenance fields are illustrative additions. Use your own approved source values in production.

Keep the raw MPN as text. Do not cast it to a number, strip leading zeros, or remove punctuation because another system prefers a normalized format. If you need search normalization, store a separate comparison key and retain the original value for feeds, pages, and audits.

A useful MPN field policy includes:

- **Source and provenance:** manufacturer page, product label, datasheet, or supplier record, plus retrieval date and reviewer.
- **Scope:** parent product, exact variant, bundle, or multipack. Avoid a value that silently applies to every child.
- **Raw value:** the exact manufacturer string, including meaningful zeros, case, and separators.
- **Status:** verified, pending review, conflicting, missing, or not applicable.
- **Relationships:** brand, manufacturer, product ID, variant ID, GTIN, and merchant SKU.
- **Destination mappings:** the feed field, schema property, or marketplace field that receives the value.

![A canonical product record maps brand, MPN, GTIN, and merchant SKU to commerce destinations.](https://www.getcatalog.ai/images/blog/mpn-product-record.svg)

This separation is the foundation for [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication). Catalog helps teams structure product data, map fields to destination formats, publish live normalized product objects, and keep updates synchronized across AI shopping surfaces and other channels.

## Add MPN to product structured data

Schema.org represents an MPN with `Product.mpn`, whose value is text. The same `Product` object can contain `brand`, merchant-specific `sku`, and a GTIN property such as `gtin13`. [Schema.org’s Product definition](https://schema.org/Product) distinguishes `mpn` as the manufacturer part number and `sku` as the merchant-specific identifier.

A JSON-LD record can look like this when the values are visible and approved on the product page:

```json
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Google T-shirt, green, small",
  "brand": {
    "@type": "Brand",
    "name": "Google"
  },
  "sku": "STORE-GREEN-S",
  "mpn": "00638HAY",
  "gtin13": "9504000059422"
}
```

Structured data does not require an MPN for every product rich result, and adding one does not guarantee a rich result or a ranking. Add it when you have a verified value. Keep the MPN, SKU, GTIN, brand, title, variant, price, and availability consistent with the page a shopper sees and with the feed submitted to the destination. Google says structured markup must match the landing-page values and can support Merchant Center updates, while regular product-data updates remain necessary. See [Google’s product structured-data documentation](https://developers.google.com/search/docs/appearance/structured-data/product) and its guidance on [structured data for Merchant Center](https://support.google.com/merchants/answer/6069143?hl=en).

Our [product schema glossary](https://www.getcatalog.ai/glossary/product-schema) explains the larger markup model. The practical rule is simple: emit one approved identity model into every output, then test the rendered page and feed for drift.

## Common MPN errors

Most MPN failures come from treating a field as a label instead of an identity relationship.

### Putting a store SKU in the MPN field

A seller’s SKU may be useful for your warehouse and order system. It does not identify the manufacturer’s product. Keep it in the item ID or SKU field and leave MPN blank when you cannot verify the manufacturer value.

### Guessing or copying a similar product

A near-match can differ in voltage, connector, material, capacity, or revision. Do not copy a number from a neighboring product, an old listing, or a search result. Resolve the conflict against the manufacturer record.

### Assigning the OEM value to a compatible product

A third-party replacement can fit an OEM product without being made by the OEM. Use the third-party manufacturer’s brand and MPN. Describe compatibility separately.

### Reusing one value across a variant, bundle, or pack

A color, size, capacity, bundle, or multipack can represent a different orderable item. Apply the manufacturer’s scope. Keep parent and child relationships explicit.

### Mutating the code during normalization

Leading zeros, punctuation, and suffixes can carry meaning. Keep MPNs as text and preserve the raw value. A comparison key may support search, yet it should never overwrite the source string.

### Letting outputs disagree

A page can show one MPN, the feed can send another, and structured data can omit both. Use the same approved record to generate each output. Monitor feed diagnostics, page markup, and marketplace warnings after catalog or template changes.

## MPN validation checklist

Run this checklist for each new or changed product record:

1. **Source:** Is the value from the manufacturer, its catalog, packaging, manual, or a supplier record that cites one of those sources?
2. **Brand:** Does the brand or manufacturer match the company that assigned the MPN?
3. **Product:** Does the description and technical specification match the item you sell?
4. **Variant:** Does the value apply to this exact color, size, capacity, voltage, finish, condition, pack, or bundle?
5. **Exactness:** Did ingestion preserve the complete string, leading zeros, case, and punctuation?
6. **Role:** Are MPN, SKU, GTIN, model number, serial number, and channel item ID stored in their own fields?
7. **Destination:** Does each feed or marketplace accept the value and its current category-specific format?
8. **Page:** Does the product page display the same approved identity, when you choose to display it?
9. **Structured data:** If `Product.mpn` is emitted, does it match the visible page and the feed?
10. **Absence:** If no MPN exists, is the field blank or marked according to the destination’s no-identifier rules rather than filled with a guess?

For a wider quality framework, use our guide to [product data quality](https://www.getcatalog.ai/blog/product-data-quality). Identifier QA works best as part of the same validation pipeline as price, availability, taxonomy, attributes, media, and variant relationships.

## Frequently asked questions

### Is an MPN the same as a model number?

Sometimes a manufacturer uses “model number” and MPN for the same string. A model name can also describe a broader family. Use the full manufacturer-assigned part number for the orderable product, and keep the model or family value in its own field when the source distinguishes them.

### Where can I find a product’s MPN?

Check the manufacturer’s product page, catalog, datasheet, manual, packaging, or product label. Then confirm the brand and exact variant. A supplier or marketplace listing can help you locate the record, yet the manufacturer source should resolve uncertainty.

### Does every product have an MPN?

No. Custom-made, handmade, vintage, and some private-label products may not have one. Google says not to submit an MPN when no associated value exists. Use the destination’s identifier-exists or no-identifier process instead of inventing a code.

### Can a merchant create an MPN?

A merchant that is also the manufacturer may assign a value for its own product where the destination permits it. Google documents a narrow case for a manufacturer that is the only seller of a product without an assigned MPN. A retailer or distributor should not create an MPN for another company’s product.

### Is an MPN required in structured data?

No. `Product.mpn` is a supported Schema.org property, yet it is not a universal requirement for product rich results. Add it when the value is verified, and keep it aligned with the visible product and feed data.

### What should I enter for an MPN on Amazon or eBay?

Use the manufacturer’s part number when the category workflow asks for it. Do not substitute your store SKU. eBay publishes category-specific identifier guidance and allows “Does not apply” when the item has no identifier or you are unsure. Amazon requirements vary by category and listing flow, so follow the current field instructions for the destination rather than applying one platform-wide rule.

## Keep the identity layer consistent

An MPN is small data with a large joining role. When the manufacturer value, brand, variant, SKU, GTIN, feed row, product page, and schema all agree, every downstream system has a clearer product to match and update.

Catalog gives ecommerce teams a product data layer for that work. We structure product records, preserve provenance, map fields to feeds and structured data, keep live normalized product data synchronized, and publish it to AI shopping surfaces. [Explore Catalog’s product data layer](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/manufacturer-part-number
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Ecommerce site search: how to improve product discovery and choose a platform

*October 2, 2026 · Catalog Team · Product Discovery · 14 min*

> Improve ecommerce site search with practical UX, relevance, product-data, metrics, and platform guidance for faster product discovery and better conversion.

Your search box is often the shortest path between a shopper and a product. It is also where catalog gaps become visible. A missing attribute, stale stock value, or unfamiliar synonym can turn a useful query into irrelevant results or a blank page.

A good ecommerce site search system connects product data, query understanding, retrieval, ranking, results UX, and measurement. The work is to fix the failures that matter most and evaluate a platform with your own queries.

## What ecommerce site search does

Ecommerce site search is the product-discovery experience inside your storefront. A shopper enters a word, product ID, description, or need. The system interprets the query, finds matching products, orders them, and gives the shopper ways to refine the result.

The visible search field is only one part of the system:

| Layer | Job | Typical failure |
| --- | --- | --- |
| Product data | Describes products, variants, attributes, identifiers, price, and availability | The product is missing a searchable field or has conflicting values |
| Query understanding | Normalizes terms, detects intent, and handles spelling, synonyms, and constraints | “Sneakers” and “trainers” behave like unrelated terms |
| Retrieval | Finds a candidate set using exact, lexical, semantic, or hybrid matching | A relevant product never enters the candidate set |
| Ranking | Orders candidates by relevance and safe business signals | A promoted or unavailable item outranks an exact match |
| Results experience | Presents products, suggestions, filters, sorting, and recovery paths | The shopper cannot tell what matched or how to narrow the list |
| Measurement | Connects queries to results, clicks, carts, and orders | The team cannot distinguish a relevance problem from a data problem |

Catalog works upstream of the search engine. We structure product data into live, normalized, machine-readable records with the attributes, relationships, identifiers, and commercial signals that discovery systems need. That data layer can support storefront search as well as AI shopping surfaces when the real bottleneck is incomplete or stale product information.


### Site search is different from SEO and search merchandising

**Ecommerce SEO** helps external search engines discover and rank pages. **Ecommerce site search** helps a shopper find products inside your storefront. **Search merchandising** shapes those results with boosts, pins, redirects, banners, and synonyms. Use the [search merchandising rule framework](https://www.getcatalog.ai/blog/search-merchandising) to govern those controls, but remember that rules cannot compensate for missing color, material, or availability data.

## Start with the query types your shoppers use

A single ranking strategy should not treat every query as the same. Build a query set from your logs and label each query by the shopper’s expected result.

| Query type | Example | The result should prioritize | Data or behavior required |
| --- | --- | --- | --- |
| Known product or SKU | `Air Max 90`, `filter X100` | The exact product, compatible variant, and current availability | Stable identifiers, aliases, variant relationships, and exact matching |
| Product category | `running shoes`, `desk lamps` | A relevant assortment with useful filters and sensible defaults | Taxonomy, product type, category-specific attributes, and inventory |
| Attribute or specification | `black linen shirt`, `32 GB laptop` | Products that satisfy the stated constraints | Normalized color, material, size, capacity, dimensions, and other typed fields |
| Use case or problem | `gift for a new homeowner`, `shoes for plantar fasciitis` | Products connected to a need, use case, or guided path | Use-case fields, curated collections, synonyms, content, or a category fallback |
| Compatibility | `case for iPhone 15`, `ink for LaserJet 4100` | Products that fit the named item or standard | Compatibility IDs, model aliases, and explicit relationships |
| Misspelled or zero-result | `waterprof jacket`, an unavailable SKU | A correction, synonym, related category, or useful fallback | Spelling tolerance, synonym governance, and a recovery experience |

Baymard’s 2026 ecommerce search benchmark found that 56% of sites failed to adequately support users’ search needs. Its research treats product type, feature, symptom, compatibility, and other patterns as separate usability problems. [Read the query-type research](https://baymard.com/research-articles/ecommerce-search-query-types) before choosing a test set.

Write down acceptable top results and constraints for each label. “Filter X100” must not return an incompatible filter. “Red wool coat under $200” should not be broadened silently to avoid an empty result.

### Decide when semantic matching helps

Semantic or natural-language matching helps use-case queries such as “a compact lamp for a small bedside table.” It is less forgiving with hard constraints such as model number, size, voltage, ingredient, price ceiling, or compatibility.

Use a hybrid approach when you need both. Keep exact and structured matching for IDs and constraints. Use semantic signals to expand concepts, expose interpreted filters so shoppers can correct them, and fall back cleanly when the catalog cannot support the request.

## Fix product data before tuning the ranker

Search cannot rank a fact that the product record does not contain. Before changing boosts or adding an AI layer, audit the fields that drive retrieval and filters.

### Make fields complete by category

Every category needs its own required attributes. A furniture record may need width, depth, height, material, assembly, and room. A laptop needs screen size, processor, memory, storage, ports, and operating system. Beauty may need ingredients, skin type, shade, finish, and volume.

Title and description alone are not enough. Define which attributes are searchable, filterable, sortable, or explanatory, then measure coverage by category.

### Normalize terms, units, and values

A search system should understand that `navy`, `navy blue`, and `midnight` may refer to one color family. It should also understand equivalent units and abbreviations where the category allows them. Keep the canonical value in the product record and map customer language through a controlled vocabulary.

Do not hide data cleanup inside an ungoverned synonym list. When “trainers” maps to “sneakers,” record the relationship, scope, and owner. Keep mappings category-specific when needed.

### Preserve identifiers and variant relationships

SKU, GTIN, MPN, product ID, and variant ID are retrieval fields. Keep them stable and searchable. Connect size, color, pack, and configuration variants to the parent product so a query can land on a purchasable option.

If only one size is available, show the family with that variant clearly. Do not send shoppers to a card they cannot buy.

### Keep price and availability fresh

Price, promotion, stock, delivery promise, and regional eligibility change faster than descriptive copy. Set a freshness expectation, monitor source-to-index lag, and remove or label unavailable results according to intent.

An out-of-stock item can be useful for a specific product query if you offer a notification or substitute. It should not dominate a broad query when in-stock alternatives exist.

Catalog’s guide to [product data quality](https://www.getcatalog.ai/blog/product-data-quality) goes deeper on completeness, consistency, validity, uniqueness, and freshness. These dimensions power search, filters, feeds, and AI commerce.

## Build a search experience that helps shoppers recover

Relevance is more than a score. The shopper needs to understand what happened and have a clear next move.

### Make the search field obvious and usable

Place search where shoppers expect it, keep the query visible on the results page, and make the field usable with keyboard, screen reader, and touch. On mobile, provide an explicit submit control. Label the form and suggestions so assistive technology can announce them correctly.

The [W3C search technique](https://www.w3.org/WAI/WCAG21/Techniques/general/G161) recommends an accessible search form and calls out spelling, stemming, and synonyms as ways to increase access to relevant information. Accessibility and relevance reinforce each other when shoppers have more than one way to express a need.

### Use autocomplete to teach the catalog’s language

Autocomplete should help shoppers form a better query, not only reduce typing. Show a small mix of query suggestions, product matches, categories, and brands when those scopes are clear. Make each suggestion selectable with keyboard and touch.

Baymard’s benchmark found that only 19% of sites get all of its autocomplete implementation details right. [Its autocomplete research](https://baymard.com/research-articles/autocomplete-design) covers keyboard behavior, suggestion scope, and the difference between echoing text and guiding a query.

### Handle spelling, synonyms, and symbols without hiding the change

Support common misspellings, abbreviations, plural forms, regional language, and symbols used in your catalog. Treat “wifi” and “Wi-Fi,” or “10 inch” and “10 in,” as deliberate mappings where valid. Show a “Did you mean” correction when uncertain, and preserve the original query.

Review synonym performance by query and category. A broad synonym can create false positives. A narrow synonym can leave a zero-result page untouched. Give the team an approval, owner, scope, and expiry path for each important mapping.

### Make filters reflect the result set

Filters and facets should expose attributes that help a shopper decide. Labels and values should match product data, preserve active selections, show sensible counts, and avoid dead ends.

A search for “black running shoes” may need filters for size, width, activity, waterproofing, brand, price, and availability. The right facets depend on query and category, so do not show every catalog field as a filter.

Filters are a data and UX system. Use Catalog’s [ecommerce filters guide](https://www.getcatalog.ai/blog/ecommerce-filters) for facet design, attribute quality, and faceted-navigation decisions.

### Design a useful zero-results page

Zero results are a diagnostic signal. Check for a typo, synonym gap, missing attribute, stale inventory, an overly strict combination, or a product you do not carry.

Give the shopper a path forward:

- show a spelling or terminology correction;
- remove one constraint at a time and explain which one changed;
- offer a related category or collection;
- show a support or contact path for high-intent product requests;
- let the shopper clear filters without losing the original query.

Track repeated zero-result queries. If shoppers search for “waterproof commuter backpack” while your catalog says “weather-resistant,” fix vocabulary and product attributes before changing vendors.

## Measure search as a product journey

Instrument the path from query entry to product outcome. Capture the query, result count, response time, selected suggestion, filters, result clicks, product views, carts, checkouts, and orders within your privacy rules.

Use a dashboard that connects quality signals to business outcomes:

| Metric | What it tells you | How to use it |
| --- | --- | --- |
| No-result rate | How often a query returns no products | Segment by query type, spelling, category, and stock state to find the cause |
| Refinement rate | How often shoppers change a query or filter | High refinement can signal broad results, weak ranking, or unclear facets |
| Result click-through rate | Whether the result set earns a product click | Compare by query class and result position, not only as one site average |
| Search-assisted add-to-cart or conversion | Whether search sessions reach a commercial outcome | Define the attribution window and compare with non-search journeys |
| Suggestion selection rate | Whether autocomplete helps shoppers commit to a useful query | Review selected suggestions and downstream product outcomes |
| Filter exit or dead-end rate | Whether a facet choice leaves shoppers stuck | Check attribute values, counts, and inventory freshness |
| Latency | How quickly the experience responds | Track p50 and p95 by device and query type, including autocomplete |

Review a fixed test set after every major data, ranking, or interface change. Review the long tail too, because head terms can hide failures that produce support tickets and abandoned sessions.

## Choose a platform by team ownership and trade-offs

A platform decision determines who owns relevance, data synchronization, operations, and the shopper experience. Compare options against your catalog and query logs, not a vendor’s prepared demo.

| Approach | Fits best when | Strengths | Trade-offs |
| --- | --- | --- | --- |
| Native commerce search | The catalog and traffic are modest, and the commerce team needs a low-operations default | Fast setup, close platform integration, familiar administration | Less control over ranking, analytics, query interpretation, and complex catalogs |
| Hosted search SaaS or API | Search is a core product surface and a team can own integration and tuning | Mature retrieval, typo and synonym controls, analytics, and scaling | Recurring cost, index synchronization work, and a need for search expertise |
| Custom search service | You have unusual data, strict control requirements, or substantial engineering capacity | Full control over schema, retrieval, ranking, and experimentation | You own relevance quality, uptime, indexing, observability, and long-term maintenance |
| Broader discovery suite | You want search, recommendations, merchandising, and personalization under one operating model | Shared controls and cross-surface analytics | Larger implementation scope, broader contract, and more dependencies |

### Use a vendor-neutral test plan

Before choosing, assemble 60 to 100 representative queries across known products, categories, attributes, use cases, compatibility, misspellings, and zero-result cases. Test each platform for:

1. **Retrieval and relevance:** Do expected products enter the result set and appear in a sensible order?
2. **Constraint handling:** Do size, price, compatibility, and availability constraints hold?
3. **Typo and vocabulary coverage:** Can the team manage spelling, synonyms, abbreviations, and category-specific language?
4. **Facets and variants:** Are filter counts, variant relationships, and unavailable options accurate?
5. **Merchandising control:** Can a merchandiser apply a narrow rule with a relevance floor, preview it, and set an expiry?
6. **Analytics:** Can you connect query, result, click, cart, conversion, and no-result events?
7. **Integration and freshness:** How does data enter the index, how quickly do changes propagate, and how are failures surfaced?
8. **Operating cost:** Include license, implementation, engineering, data cleanup, observability, and tuning.

Ask each vendor to replay the queries with the same product snapshot. Record wrong and missing results, classify each failure as data, retrieval, ranking, UX, or integration, and compare the diagnosis rather than one relevance score.

## A practical improvement loop

Run the work in this order so each change has a clear owner and measurable effect:

1. **Baseline real behavior.** Rank a query set by volume, no-result rate, refinement rate, and commercial value.
2. **Repair the record.** Fill required attributes, normalize values, connect variants, and refresh price and availability.
3. **Improve retrieval.** Add identifier matching, spelling tolerance, approved synonyms, and supported semantic expansion.
4. **Tune ranking.** Set relevance as the floor, then use bounded availability, delivery, popularity, margin, or campaign signals. Give each rule an owner and expiry.
5. **Improve recovery and repeat.** Fix autocomplete, filters, mobile submission, query persistence, and zero-result paths, then review the fixed set, long-tail logs, and outcomes after each release.

Ranking cannot solve an absent attribute. A synonym cannot solve stale inventory. A polished zero-results page cannot solve a missing compatibility relationship.

## Ecommerce site search FAQ

### Is ecommerce site search the same as ecommerce SEO?

No. SEO helps external search engines discover and rank pages. Site search retrieves products and content inside your storefront using your catalog, index, rules, and results experience.

### How do search and filters work together?

Search creates a candidate set from the query. Filters and facets narrow it using structured attributes such as size, color, price, compatibility, or availability. Good filters need complete, normalized data and accurate counts.

### Should every ecommerce site use semantic or AI search?

Use the retrieval method that fits your query mix and data. Exact matching is essential for identifiers and hard constraints; semantic matching can help with use-case language. A hybrid system with visible constraints is safer than one fuzzy model for every query.

### When should a team replace its search platform?

Consider a change when the current system cannot meet quality, freshness, analytics, or control requirements defined with real queries. First rule out missing fields, broken synchronization, and weak instrumentation. Change platforms to remove a structural limitation, not to hide a data problem.

Search gets better when the product record, retrieval logic, interface, and measurement tell the same story. If missing or stale product facts are holding back that work, [see Catalog’s product data layer](https://www.getcatalog.ai/) for AI shopping and the discovery systems that depend on it.

---

Canonical: https://www.getcatalog.ai/blog/ecommerce-site-search
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Google Merchant Center suspension: how to diagnose and fix it

*October 2, 2026 · Catalog Team · Product Data · 14 min*

> Understand Merchant Center warnings, product disapprovals, and suspensions, then follow a website and feed audit workflow before requesting review.

A Google Merchant Center notice can stop product visibility at the moment you need it most. The fastest route back is a controlled diagnosis: identify the scope of the notice, reconcile your website with your product data, fix the underlying source, and request review only when the evidence is ready.

It separates product disapprovals, account warnings, and account suspensions, then shows what to check on your site, in your feed, and in Merchant Center.

## Start by identifying the scope

“Suspended” is often used for several different Merchant Center states. The distinction determines what is affected and what you should fix first.

| Status | What it affects | What you will usually see | First move |
| --- | --- | --- | --- |
| Product warning | Individual products or offers | The products may continue to show, with limited performance | Open the product issue and correct the field or page mismatch before it becomes a disapproval |
| Product disapproval | Individual products or offers | Those products stop showing across Google | Fix the specific product data, landing page, or policy issue, then follow the product-level review flow |
| Account warning | The account and its product data | Products may continue to show with limited visibility during a warning period | Audit the whole site and catalog against the account-level policy named in the notice |
| Account suspension | The account and its product data | Products are disabled from appearing across Google | Fix every account-level issue, verify the live site and feed, then request an account review |

Google describes product-level issues as isolated to the affected product. Account-level issues apply to all products. A warning can lead to a disapproval or suspension if it remains unresolved, and some egregious issues can lead to immediate suspension. Read [Google’s current issue guidance](https://support.google.com/merchants/answer/12153802?hl=en) for the status and navigation labels shown in your account.

![Google Merchant Center Help page showing product-level issues, warnings, and disapprovals](https://www.getcatalog.ai/images/blog/google-merchant-center-issues.svg)

Do not treat a product disapproval as proof that the entire account is suspended. Conversely, do not fix one flagged SKU and assume an account-level notice is resolved. First establish whether the notice is product-level, account-level, country-specific, or linked to another account.

## Capture the exact issue before changing anything

Start with the notice Google gave you, not a generic checklist from a forum. Save a copy of the email and record the following from the account:

1. **The policy or data-quality name.** Examples include Misrepresentation, price mismatch, unavailable offers, or a product data specification issue.
2. **The scope.** Record whether the issue affects a product, a country, a destination, or the account. Products targeting multiple countries can have different issues in each country.
3. **The examples.** Download the affected-product list from the issue details page when it is available. Keep product IDs, URLs, and the exact message.
4. **The dates and status.** Note when the warning or suspension started, the warning-period deadline, and whether a review button or cool-down date is shown.
5. **The connected systems.** Record the data source, ecommerce platform, linked accounts, and any third-party app that can change product data.

In Merchant Center, account-level issues appear in the banner at the top of the account. You can also go to **Products**, open **Needs attention**, and choose **View setup and policy issues**. Product-level issues are listed in **Needs attention** for the affected product. Labels move as Google updates the interface, so use the notice and the in-product path together.

## The causes that deserve a full audit

Google’s examples are not an exhaustive suspension checklist. Use the notice to choose the relevant branch, then audit related promises that could create the same signal.

### Misrepresentation and missing business information

Misrepresentation is a trust problem. Google may assess your listings, website, account information, and third-party sources together. Common triggers include:

- A legal business name, address, phone number, or email that is missing or inconsistent across the site and Merchant Center.
- A hard-to-find contact page, placeholder text, broken form, or shipping, return, refund, privacy, or payment terms that are missing or contradictory.
- A product claim, discount, delivery promise, or subscription condition that the site cannot support.
- Checkout, account, or payment flows that fail, redirect unexpectedly, or do not make the total cost clear.

Review [Google’s Misrepresentation policy](https://support.google.com/merchants/answer/6150127?hl=en) for the specific policy language. Its examples are fact-specific. Do not assume that adding a footer link alone fixes a store whose product claims or checkout terms remain misleading.

### Price and availability mismatches

Compare the offer Google receives with the page a shopper lands on. Check the same variant, currency, sale state, and customer location. A mismatch can arise when:

- the feed has an old sale price while the product page has the regular price;
- the feed says `in_stock` while the selected variant is unavailable;
- a regional page shows a different currency or price;
- taxes, minimum order values, or required fees appear only later in checkout; or
- a cached feed, structured-data block, or app output disagrees with the visible page.

Google calls out price and availability mismatches as a cause of preemptive item disapprovals. Product-level and account-level consequences depend on the issue and the account, so fix the data rather than guessing at the enforcement outcome.

### Shipping, returns, and checkout

The product offer includes the terms needed to complete a purchase. Check that shipping rates, delivery windows, destinations, handling time, return windows, refund method, and return-shipping fees are clear and consistent. Check both policy pages and the actual checkout calculation.

Country settings matter. Make sure the shipping and tax settings you submit at the account or item level match what the shopper sees for the same country and product.

### Restricted products, unsupported offers, and unreliable claims

Review the Shopping policy named in the notice for restricted, regulated, counterfeit, dangerous, or unsupported products. Also check claims in titles, descriptions, images, promotions, and structured data. A permissible product can still create a policy problem when its advertised result, affiliation, or availability is inaccurate.

Do not turn another merchant’s checklist into a universal rule. Product category, destination, country, and the facts of the offer all matter.

### Data-quality and specification errors

For each affected item, inspect the required fields for its category and destination. Start with:

`id`, `title`, `description`, `link`, `image_link`, `brand`, `gtin` or `mpn` when applicable, `price`, `availability`, `condition`, variant fields, category, and `shipping` or `tax` settings where applicable.

Look for invalid identifiers, duplicate variant IDs, malformed URLs, unsupported values, missing images, incorrect categories, stale data, and a product page that redirects to a generic collection. Use [Google’s product data specification](https://support.google.com/merchants/answer/7052112?hl=en) for the requirements that apply to your product type and target country.

### Attempts to bypass review

Do not reduce the catalog, alter a page temporarily, or create another account to get around a review. Google’s [bypassed account review guidance](https://support.google.com/merchants/answer/10151285?hl=en) specifically warns against manipulating product data or site content to evade checks. A smaller feed can hide the symptom while leaving the account-level problem in place.

## Run a synchronized website and feed audit

Audit the storefront and the data source as one system. A clean CSV does not make an unavailable product compliant, and a polished product page does not correct a stale feed.

### 1. Check identity and transparency on the website

Use an incognito session and the same country settings that the affected offer targets. Check that:

- the legal business name and physical address are visible and match Merchant Center;
- phone and email details work and match the account or payment profile;
- About, Contact, Shipping, Returns or Refunds, Privacy, Terms, and payment information pages are reachable from the site navigation or footer;
- policy pages state actual timelines, eligibility, fees, exclusions, and the refund method;
- product pages, cart, and checkout contain no placeholder copy, dead links, browser errors, or unexpected redirects; and
- the store uses HTTPS and the checkout can complete for the target country.

Capture the URL and result for each check. A reviewer needs to see the live page, not a plan to publish one later.

### 2. Test the product promise on the landing page

Sample every product in the issue list, then sample products from the same source or category. For each variant, record:

| Check | Website value | Feed or Merchant Center value | Result |
| --- | --- | --- | --- |
| Product ID and variant | SKU or variant ID shown or encoded in the page | `id`, `item_group_id`, or variant fields | Match |
| Price and currency | Visible price and checkout total | `price`, `sale_price`, currency | Match for the target location |
| Availability | Selected variant and purchase control | `availability`, inventory state | Match |
| Product identity | Brand, title, condition, key attributes | Corresponding feed fields | Same product and variant |
| URL and image | Canonical product URL and reachable image | `link`, `image_link` | Crawlable and specific |
| Delivery and returns | Shipping, timing, fees, return terms | Account or item-level settings | Consistent |

Treat the customer-facing page as the operational source of truth for the promise. If the page is wrong, fix the commerce system that produced it, then regenerate the feed. If the feed is wrong, correct the mapping or transformation instead of editing hundreds of rows by hand.

### 3. Inspect the feed and crawl path

Download the current data source or API payload, not yesterday’s export. Check for:

- duplicate `id` values or variant relationships that split the same product;
- stale price, sale price, availability, shipping, or tax values;
- missing or invented GTINs, MPNs, or brand values;
- category mappings and condition values that follow the current specification;
- image and product URLs that return an error, redirect to a generic page, or require a blocked session;
- country and currency variants that point to the wrong landing page; and
- robots or server rules that block Googlebot or Googlebot-image.

For a high-risk issue, crawl the same URLs outside your application and test the page as an unauthenticated shopper. Compare what the browser renders with the values in structured data and the feed. A source record can be accurate while a template, cache, app, or regional rule publishes a different value.

## Fix the source, then verify the new state

Make the smallest complete fix that removes the underlying cause. That may mean correcting business details, changing a policy page, repairing checkout, updating inventory logic, remapping a field, or removing an offer that is genuinely non-compliant.

Then:

1. Publish site and policy changes to the live URLs.
2. Update the source catalog or ecommerce system that owns the field, then regenerate or refresh the Merchant Center data source.
3. Check the processed data and affected-product examples again.
4. Crawl representative landing pages and confirm that price, availability, identity, and policies still match. Keep a short change log with the issue, owner, timestamp, and evidence.

Do not remove products solely to make the issue list smaller. Remove an offer when it violates a policy or cannot be fulfilled. Otherwise, fix the offer and keep the catalog complete. This is especially important for a bypassed-account-review notice.

This is a product-data governance problem as much as a channel problem. Catalog can give teams one normalized, live product data layer for the storefront, Merchant Center, marketplaces, and AI shopping surfaces. Read our guides to [product data quality](https://www.getcatalog.ai/blog/product-data-quality), [product feed management](https://www.getcatalog.ai/blog/product-feed-management), and [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) for the operating model behind that control loop. Catalog does not override Google policy decisions or reinstate an account.

## Request a review only when the evidence is ready

Use the review action attached to the issue. Do not send a vague appeal while the site still shows old information.

Before you submit, confirm that:

- every issue named in the account banner has a completed fix;
- the live website, feed, structured data, checkout, and policy pages agree;
- identity verification is complete if Merchant Center requests it;
- the data source is not empty and contains the products you intend to sell;
- affected countries and destinations are covered; and
- you have saved the affected-product list and your change evidence.

For a fixed issue, select **I fixed the issue** and then **Request review** when that option is available. If you believe Google made an error, select **I disagree with the issue** and provide a precise reason and supporting documentation. The interface may show **Review and fix**, **Fix**, or **Request review** depending on the issue and integration. [Google’s review instructions](https://support.google.com/merchants/answer/13585221?hl=en) describe the current choices.

If you use the Google & YouTube app on Shopify, Google’s [Shopify-specific warning and suspension guidance](https://support.google.com/merchants/answer/13693195?hl=en) shows the integration path. The underlying audit still applies to your live site, account, and data source.

Keep the explanation factual:

> We corrected the account issue identified as [policy or issue]. We updated [specific pages, fields, or settings] on [date], refreshed the data source, and checked [sample or affected-product set]. The business details, product prices, availability, shipping, and returns now match across the live site and Merchant Center. Please review the account for [country or destination].

Use that structure only when it is true. An appeal cannot substitute for a live fix.

Google says a review can take up to seven days. Some flows limit review or appeal actions and can impose a cool-down period after an unsuccessful attempt. The exact controls depend on the issue and account. Wait for the result, monitor the notice, and use the cool-down period to gather new evidence instead of resubmitting the same explanation.

## Prevent a repeat suspension

After reinstatement, treat the notice as a control failure. Put an owner and a check behind each field that can change the customer promise.

| Control | Owner and check |
| --- | --- |
| Price and availability freshness | Ecommerce or inventory owner monitors source-to-feed lag and alerts on stale or conflicting values |
| Policy regression | Operations checks shipping, returns, refunds, privacy, contact, and checkout after site or payment changes |
| Feed validation | Catalog or channel owner validates identifiers, variants, URLs, images, categories, and required fields before upload |
| Crawl monitoring | Technical owner tests representative product pages, redirects, robots rules, server responses, and regional variants |
| Issue response | One operator owns the Merchant Center queue, records root causes, and closes the loop with merchandising and engineering |

Run automated checks for fields that change hourly, such as price and stock. Review policy pages and checkout after releases. Sample high-revenue, high-return, and recently changed products weekly. Review broader category completeness on a regular cadence.

## FAQ

### Is a product disapproval the same as a Merchant Center suspension?

No. A product disapproval normally affects the listed offer. An account suspension affects the account’s product data and disables products from appearing across Google. Check the scope in the account banner and **Needs attention** before choosing a fix.

### Can I create a new Merchant Center account?

Do not create a replacement account to evade a suspension. Google says bypassing review or manipulating product data can violate its Abuse of Network policy, and a new account does not fix the business, website, or feed problem. Resolve the named issue in the affected account and use its review flow.

### How long does a suspension review take?

Google’s current review guidance says a review can take up to seven days. That is guidance, not a reinstatement guarantee. More checks, a cool-down period, or an integration-specific workflow can change what you see.

### What if the notice does not explain the problem?

Open the account-level issue banner and **Products → Needs attention → View setup and policy issues**. Download affected products, inspect the email and account message archive, and audit identity, policies, checkout, price, availability, and crawlability together. If the in-product path remains unclear, use Google’s support flow rather than guessing at repeated appeals.

### Should I remove all products before requesting review?

No. Remove offers that are genuinely non-compliant or cannot be fulfilled. Do not hide products, shrink the feed, or change data only to pass a review. Fix the source data and keep the products that meet the policy requirements.

When one normalized catalog feeds every channel, a correction can flow to the storefront and Merchant Center together instead of creating another mismatch. [See how Catalog works](https://www.getcatalog.ai/) when you are ready to make that product-data layer operational.

---

Canonical: https://www.getcatalog.ai/blog/google-merchant-center-suspension
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# PIM integration: architecture, data flows, and best practices

*October 2, 2026 · Catalog Team · Product Data · 18 min read*

> Learn how PIM integration connects ERP, DAM, ecommerce, feeds, marketplaces, analytics, and AI shopping surfaces with a durable architecture.

PIM integration is the work that makes product information usable outside the PIM. It connects product content with the operational systems, selling channels, and measurement tools around it.

The hard part is rarely the connector. It is deciding which system owns each field, keeping identifiers stable, translating different schemas, and preventing stale data from reaching a shopper or shopping agent. The practical work is choosing the systems to connect, designing a resilient architecture, and deciding where a product data layer such as Catalog fits.

## What PIM integration means in ecommerce

A [product information management (PIM) system](https://www.getcatalog.ai/glossary/pim-system) centralizes, enriches, validates, and governs market-ready product content. PIM integration connects that content to the rest of the commerce stack through APIs, events, files, or middleware.

A production PIM integration usually has five concerns. They can live in separate services, but they need to work as one controlled data path:

1. **Ingests** product facts and assets from approved source systems.
2. **Maps** different field names, types, units, taxonomies, and variant models into a shared product model.
3. **Enforces** ownership, approval, provenance, and quality rules, or hands off to the system that does.
4. **Hands off** the right representation to each storefront, feed, marketplace, or AI shopping surface.
5. **Reconciles** the result and reports freshness, errors, rejects, and downstream outcomes.

That is more than moving a CSV from one application to another. A PIM can be a source of enriched product content while an ERP owns commercial data, a warehouse system owns stock by location, a DAM owns image files, and an order management system owns orders. A reliable integration keeps those boundaries explicit.

The [PIM glossary](https://www.getcatalog.ai/glossary/pim) explains the category. The integration question is what comes before and after the PIM, and how each handoff stays trustworthy.

You will also see narrower terms for the same work. **PIM ERP integration** joins operational item data to market-ready content. **PIM DAM integration** joins structured attributes to approved media and rights. **PIM ecommerce integration** publishes that governed record to a storefront or CMS. **PIM system integration** is the broader program that connects all of these flows.

Keep the related jobs separate:

- **Integration** establishes a connection, contract, and flow between systems.
- **Synchronization** keeps records aligned as they change. The [data synchronization glossary](https://www.getcatalog.ai/glossary/data-synchronization) covers cadence and direction in more detail.
- **Enrichment** adds or improves product content, with provenance and review when a value is inferred.
- **Validation** checks whether a record meets your rules and a destination's requirements. See [product data quality](https://www.getcatalog.ai/blog/product-data-quality) for the quality layer around that work.
- **Migration** moves a set of records from one system to another, usually as a project.
- **Syndication** adapts and publishes approved records to channels. [Product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) is the downstream publishing problem.

A connection can move incomplete or incorrect data. Integration creates the path. Governance, quality gates, and monitoring determine whether the path is useful.

## The systems a PIM integration should connect

Start with data ownership rather than a list of connectors. The exact stack varies, but the responsibilities below are common.

| System | Data it usually owns | How it connects to product data |
| --- | --- | --- |
| Planning, PLM, or merchandising | Assortment decisions, product lifecycle, specifications, launch dates, and buying plans | Sends product concepts and lifecycle state upstream; it does not publish the sellable record by itself |
| ERP | Item master, suppliers, cost, finance, procurement, and sometimes price or inventory summaries | Supplies stable identifiers and operational facts; receives only the fields it is designed to own |
| DAM | Approved images, video, documents, renditions, rights, and expiry dates | Links assets to product or variant IDs; does not replace structured product attributes |
| PIM | Descriptions, taxonomy, attributes, variants, localization, enrichment, approvals, and channel content | Governs market-ready product information and distributes it to destinations |
| Commerce platform or CMS | Product pages, collections, merchandising presentation, cart, and checkout experience | Receives product content and sends back URLs, product state, and sometimes price or availability |
| WMS | Stock by warehouse, location, lot, and fulfillment operation | Sends availability signals; it does not own product copy or category attributes |
| OMS | Orders, allocation, routing, fulfillment status, cancellations, and returns | Uses product and offer identifiers; it should not become a second PIM |
| Feeds and marketplaces | Destination-specific schemas, listing requirements, offers, and channel diagnostics | Receive mapped product and offer records, then return acceptance or error states |
| Analytics and data warehouse | Product views, searches, carts, purchases, channel performance, and historical events | Uses the same product and variant IDs to measure what happened after publication |
| AI shopping surfaces | Machine-readable product records, price, availability, attributes, policies, and relationships | Receive structured outputs through supported feeds or APIs and use them for discovery or recommendations |

This division prevents a common mistake: asking a PIM to calculate inventory, route orders, or replace demand planning. PIM integration joins systems. It does not erase their jobs.

### Where Catalog fits

Catalog is a product data layer for AI commerce. We can consume permitted data from a PIM, ERP, ecommerce platform, DAM, supplier feed, or other approved source, then normalize and structure it into machine-readable product objects. We keep the data synchronized, publish it to AI shopping surfaces, and measure outcomes.

Catalog is not an ERP, WMS, OMS, planning system, or traditional PIM. It does not calculate replenishment, pick orders, allocate stock, or run internal catalog approvals. A brand can keep its existing PIM for enrichment, localization, and governance while using Catalog as the parallel layer for AI-ready distribution. Our [PIM versus Catalog comparison](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) explains that boundary. If the PIM is not the bottleneck, this avoids turning an AI-commerce project into a replacement program for the whole commerce stack.

## The core PIM data flows

Think about the integration as a set of flows with different owners and update speeds.

### 1. Product and lifecycle data flows in

Planning, PLM, supplier files, and ERP records introduce products and their identifiers. A new outdoor jacket might arrive with a style number, supplier, cost, planned launch date, color codes, and technical specifications. The integration should preserve the source and status of every value.

Do not treat every source field as equally authoritative. A planning system can say that a product is planned for launch. The commerce platform should not publish it until the product has approved content, media, price, and availability.

### 2. Content and assets meet in the product record

The PIM or product data layer joins structured facts with the right DAM assets. A variant should point to the image for that color and configuration, with rights and expiry conditions intact. Asset URLs should remain stable or be refreshed when a rendition changes.

A DAM stores files and the metadata around their use. A PIM stores the product story and relationships. Our guide to [PIM versus DAM](https://www.getcatalog.ai/blog/pim-vs-dam) covers that boundary in more detail.

### 3. Operational state flows in separately

Price, inventory, fulfillment eligibility, and tax or shipping state change faster than product copy. Pull them from the system that owns them, then join them to the product record by a stable sellable-item ID.

For example, a WMS can report that `JKT-001-NAVY-M` is available in two fulfillment nodes. The PIM can provide the jacket's material, fit, and care instructions. The commerce platform can combine both to render a purchasable page. A product data layer can expose the same joined state to a shopping agent without becoming the warehouse or checkout system.

### 4. Product records flow out to destinations

The downstream representation depends on the destination:

- **Commerce platform:** complete product content, variant relationships, media, URLs, and the fields needed to render the storefront.
- **Feeds:** destination-specific titles, categories, identifiers, prices, availability, shipping, and return fields. Our guide to [product feed management](https://www.getcatalog.ai/blog/product-feed-management) explains why the normalized record should be the source for every feed.
- **Marketplaces:** channel taxonomy, required attributes, offer data, seller information, and listing status.
- **Search and recommendations:** normalized attributes, synonyms, relationships, and current availability.
- **AI shopping surfaces:** typed product objects with stable IDs, factual descriptions, variants, images, price, availability, and policy context.

Current specifications show why one export rarely fits every endpoint. Google Merchant Center documents product attributes, variant identifiers, price, availability, shipping, and returns, and warns that missing or conflicting data can limit eligibility or cause disapprovals. OpenAI's product-feed specification requires a stable item ID and core fields such as title, description, URL, brand, image, availability, and price for discovery. Use the [Google product data specification](https://support.google.com/merchants/answer/7052112) and [OpenAI product-feed specification](https://developers.openai.com/commerce/specs/file-upload/products) as destination contracts, rather than assuming a valid PIM record is automatically valid everywhere.

![OpenAI's product-feed reference lists the fields used for product discovery in ChatGPT.](https://www.getcatalog.ai/images/blog/pim-integration-openai-product-feed-spec.svg)

### 5. Analytics flows back to the team

Product IDs need to survive every handoff. The identifier in the PIM should map to the commerce product, feed item, marketplace listing, search document, and analytics item. That makes it possible to connect a data change with a product view, add-to-cart event, purchase, rejection, or AI referral.

Google Analytics' ecommerce guidance uses an `items` array with fields such as `item_id`, `item_name`, and `item_variant` to measure product interactions. The [GA4 ecommerce documentation](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce) is a useful reference when defining the analytics contract. If the feed uses one ID and analytics uses another, the team loses the feedback loop needed to improve the catalog.

## An integration architecture that survives growth

A durable architecture separates the product model from the transport and from the destination adapters.

### Layer 1: source connectors and ingestion

Connect each system with the method it supports. REST or GraphQL APIs work well for queryable records. Webhooks or events can announce changes. CSV, XML, JSON, or TSV files still make sense for supplier onboarding, bulk imports, and full snapshots.

Keep the raw payload, source identifier, capture time, and source system. A raw record makes failures reproducible and gives the team a way to replay an import after correcting a mapping.

### Layer 2: identity and a canonical product model

Create one stable identity model before writing channel mappings. It should define:

- product, variant, bundle, accessory, replacement, and component relationships;
- SKU, GTIN, MPN, seller, and canonical URL rules;
- allowed values, units, locale, currency, and decimal precision;
- effective dates for price, availability, and promotions;
- asset references, rights, provenance, confidence, and approval state.

A canonical model does not mean every destination receives identical content. It means every output starts from the same well-defined facts.

### Layer 3: normalization, enrichment, and quality gates

Normalize spelling, units, categories, identifiers, and variant values before a record reaches an output adapter. Enrichment can add missing attributes or channel copy, but generated or inferred values need provenance and review rules.

Run quality gates before publication. Useful checks include:

- required field completeness by destination;
- duplicate or reused identifiers;
- parent-child and variant consistency;
- price and availability freshness;
- image reachability, format, rights, and variant match;
- category and attribute vocabulary validity;
- policy, shipping, and returns coverage;
- unsupported claims or prohibited values.

Reject the record with a reason that a person can act on. A generic `sync failed` message is an operations queue with no owner.

### Layer 4: orchestration and transport

Choose the transport by data behavior, not by habit.

| Data behavior | Good default | Why |
| --- | --- | --- |
| Price, availability, or eligibility changes frequently | Event or API update, with a scheduled reconciliation | Reduces stale offers while recovering from missed events |
| Product copy, taxonomy, and media changes occasionally | Event or incremental API sync | Moves approved changes without re-exporting the entire catalog |
| Initial migration or large supplier file | Batch import and full snapshot | Handles volume and gives the team a repeatable baseline |
| Destination supports only files | Stable file name, predictable cadence, and delivery monitoring | Prevents accidental gaps and makes rollback possible |
| AI or marketplace endpoint accepts partial upserts | Idempotent updates keyed by stable item ID | Allows one product to change without rewriting unrelated records |

Use idempotency keys, retries with limits, dead-letter handling, versioned contracts, and a replay path. A successful HTTP response only says that a request was accepted. It does not prove that the downstream catalog is correct.

### Layer 5: destination adapters

Keep one adapter per destination family. The commerce adapter can preserve rich content and storefront relationships. A marketplace adapter can map a channel taxonomy and required attributes. An AI adapter can publish typed product objects and policy context.

This is where a product data layer reduces brittle point-to-point work. With direct connections, every new source needs custom logic for every destination. With a shared model and adapters, each source maps into the model once and each destination reads from a controlled output. The exact savings depend on the stack, but the architecture changes the work from a growing web of special cases into a set of reusable contracts.

If a stack has *n* sources and *m* destinations, direct point-to-point work can approach *n × m* mappings. A shared layer aims for *n* inbound mappings plus *m* outbound adapters. Real stacks still need exceptions, but the integration surface stays understandable as channels grow.

### Layer 6: observability and feedback

Track the pipeline as a product operation, not only as an engineering job. At minimum, report:

- source and destination freshness;
- records processed, accepted, rejected, retried, and dead-lettered;
- field-level completeness and validation failure rates;
- identifier and variant join rates;
- feed and marketplace diagnostics;
- product views, carts, orders, and revenue by product ID;
- AI-surface coverage, referrals, and assisted conversions where available.

Assign an owner and a response path to each alert. A dashboard without an incident process only documents the problem.

## How to implement PIM integration

A focused rollout is safer than connecting every application at once.

### 1. Map the current system and ownership

Inventory sources, destinations, formats, credentials, update cadence, and failure handling. For every important field, record the authoritative system, transformation, consumer, and named owner. Include fields that are often forgotten, such as variant relationships, shipping restrictions, return policy, image rights, and effective dates.

### 2. Pick one product slice and one destination

Start with one category or a manageable group of SKUs. Choose a destination that exposes real risk, such as a commerce storefront or a marketplace feed. Prove the complete path from source to publication to analytics before expanding.

### 3. Define identity before mapping prose

Agree on how a product, variant, bundle, and offer are identified. Never use a display title as an identifier. Preserve leading zeros in GTINs and keep IDs stable when a title, price, image, or category changes.

### 4. Write data contracts

Document field names, types, allowed values, cardinality, units, locale, null behavior, ownership, and update expectations. Include example payloads and rejection reasons. Version the contract when a field changes instead of silently changing the meaning of an existing field.

### 5. Build quality gates before broad enrichment

Validate the minimum useful record first. Enrichment is easier to control when identity, variants, price, availability, and media are already reliable. Route ambiguous matches and unsupported claims to review instead of auto-publishing them.

### 6. Add destination adapters and run in parallel

Publish to a test or limited channel while the existing workflow remains active. Compare record counts, identifiers, price and stock, media, variant behavior, and downstream diagnostics. Reconcile differences before switching the source of publication.

### 7. Measure outcomes and expand by evidence

Use data-quality metrics for the pipeline and commercial metrics for the destination. Look for fewer rejects, fresher availability, higher attribute completeness, better product discovery, and cleaner analytics joins. Expand to the next channel only when the first path has an owner and a recovery procedure.

## Common PIM integration failure modes

| Failure mode | What it looks like | Durable fix |
| --- | --- | --- |
| Two systems write the same field | Price, title, or status flips back after every sync | Assign one owner, make other systems read-only for that field, and log the winner |
| Product and variant IDs are mixed | Images, stock, or orders attach to the wrong size or color | Model parent and sellable variant separately, then test every relationship |
| Mapping changes names without meaning | `waterproof`, `water resistant`, and `water-repellent` become one value | Define controlled vocabularies and preserve the source value and transformation |
| A batch feed becomes the live truth | A product is shown as available after it sells out | Use event or API updates for volatile fields and run reconciliation snapshots |
| DAM links are treated as permanent | A listing shows a broken or expired image | Check reachability, rights, rendition, and variant association before publish |
| Middleware reports success too early | The request succeeded, but the marketplace rejects the record later | Consume destination diagnostics and tie each reject to a product and field |
| Point-to-point logic grows unchecked | One new channel requires changes in several integrations | Normalize once, use versioned destination adapters, and retire duplicate mappings |
| Analytics identifiers drift | Product views cannot be joined to feed items or orders | Define one ID crosswalk and test it in every event and export |
| AI is added as a final export | Agents see titles and prices but miss fit, compatibility, policies, or variants | Design an AI output contract with factual context, stable IDs, freshness, and measurement |
| The PIM becomes an operational system | Teams ask it to route orders, calculate stock, or make replenishment decisions | Keep PIM focused on product content and integrate the operational system that owns each decision |

## Frequently asked questions

### Does PIM integration replace an ERP?

No. An ERP usually owns operational, supplier, financial, and procurement data. PIM integration brings the product facts needed for market-ready content into the right workflow. Define whether price, cost, and inventory are owned by the ERP, commerce platform, WMS, or another system in your own stack.

### Does a PIM replace a WMS or OMS?

No. A WMS manages warehouse stock and fulfillment operations. An OMS manages orders, allocation, routing, and returns. The PIM supplies the product and variant context those systems reference. Catalog also stays outside those transaction and fulfillment jobs.

### Should the PIM connect directly to marketplaces?

It can, when the PIM has the channel model, connector, diagnostics, and operational ownership you need. A feed or product data layer can sit between them when several destinations need different schemas, freshness rules, or AI-specific outputs. Choose the design that gives the team one canonical model and visible failures.

### Is an API better than a file for PIM integration?

Neither is always better. APIs or events suit volatile values and incremental changes. Files suit bulk onboarding, migrations, and endpoints that require scheduled snapshots. Most durable integrations use both, with reconciliation to catch missed events and drift.

### Should PIM integration be one-way or two-way?

Choose direction by field and decision ownership. Product copy and approved attributes often flow one way from the PIM to commerce and channels. Orders and fulfillment state flow back from commerce or OMS. Inventory may flow from a WMS to an offer service, while feed diagnostics flow back to the team that owns the mapping. A two-way connection is useful only when both directions have explicit contracts and conflict rules.

### Can Catalog work with an existing PIM?

Yes. Catalog can sit beside the PIM, ingest its approved product information, join it with current commercial signals and approved assets, then publish structured data to AI shopping surfaces. Your PIM can remain the internal system for enrichment, localization, and approvals.

### How do we measure a PIM integration?

Measure the pipeline and the business outcome. Start with freshness, completeness, validation failure rate, variant join rate, feed acceptance, and time to publish. Then connect stable product IDs to product discovery, add-to-cart, purchase, returns, and AI referrals. A fast sync that publishes wrong data is not a successful integration.

### What is the first AI-shopping integration to build?

Start with a complete product object for one category and a supported surface. Include stable item and variant IDs, factual titles and descriptions, relevant attributes, image URLs, price, availability, seller context, and policy fields. Test the output against the destination's schema, then monitor freshness and downstream behavior.

## Make product data usable everywhere

PIM integration works when every system has a clear job and every handoff has an owner, contract, quality gate, and recovery path. Keep operational systems operational. Keep PIM focused on governed product content. Give commerce channels and AI shopping surfaces the structured data they can actually use.

If your existing stack contains good product information but AI surfaces still see partial, stale, or hard-to-interpret records, Catalog can become the parallel product data layer. [See what AI is actually doing for you](https://www.getcatalog.ai/audit) and identify the next integration worth fixing.

---

Canonical: https://www.getcatalog.ai/blog/pim-integration
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product data management software for ecommerce buyers

*October 2, 2026 · Catalog Team · Product Data · 13 min*

> Compare product data management software for ecommerce, PIM, MDM, DAM, feeds, engineering PDM, and AI commerce readiness with a buyer checklist.

When product facts live in an ERP, spreadsheets, a storefront, and supplier files, each sales channel gets a different version of the truth. That creates broken variants, stale availability, missing identifiers, and questions your team cannot answer.

Product data management software gives commerce teams a controlled way to collect, structure, improve, and distribute those facts. The right choice depends on where your data problem sits. This guide separates ecommerce product data management from engineering PDM, compares adjacent systems, and gives you a practical evaluation checklist for stores, marketplaces, and AI shopping surfaces in agentic commerce.

## What product data management software means in ecommerce

In ecommerce, product data management software is the operational layer that turns scattered product facts into trusted, channel-ready records. It connects source systems, resolves product identity, models attributes and variants, applies quality rules, and delivers the right representation to each destination.

A useful record covers more than a title and a description. It gives each stock-keeping unit (SKU) and manufacturer part number (MPN) a stable identity:

| Record area | Typical fields | Why it matters |
| --- | --- | --- |
| Identity | SKU, GTIN, MPN, brand, product ID, canonical URL | Matches the right item and prevents duplicate records |
| Product content | Title, description, bullets, claims, category | Explains the product to shoppers and software |
| Attributes | Color, size, material, dimensions, ingredients, compatibility | Supports filters, comparisons, and use-case matching |
| Variants and relationships | Parent ID, variant ID, bundles, accessories, replacements | Keeps sellable versions and related products distinct |
| Commercial state | Price, currency, sale price, availability, inventory, condition | Represents what a shopper can buy now |
| Logistics and policy | Shipping, returns, warranty, restrictions, package data | Sets expectations and supports channel requirements |
| Media and provenance | Images, video, source, owner, confidence, last updated | Makes the record usable and traceable |

![Illustration of a storefront connected to a structured product record](https://www.getcatalog.ai/images/blog/product-data-management-layer.svg)

The software should preserve a canonical product model while allowing channel-specific outputs. A marketplace may need a particular category and attribute vocabulary. A product detail page may need richer copy and media. An AI shopping surface may need a typed record with a stable item ID, variant relationships, seller context, price, and current availability.

This is why a product feed is not the same thing as a product-data system. A feed is a destination-specific output. A storefront is a customer-facing presentation. A product information management (PIM) system is one possible way to govern product content. The [ecommerce product-data guide](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) explains how these layers work together.

## Product data management is not always engineering PDM

The phrase product data management has two established meanings. Engineering product data management (PDM) software manages product-development data such as computer-aided design (CAD) files, drawings, bills of materials, revisions, access permissions, and engineering change records. It supports design and manufacturing control.

Commerce product data management software manages the information used to market, sell, and distribute a product. That includes descriptions, attributes, media, variants, identifiers, offers, localization, channel mappings, and buyer-facing policies.

These systems can connect. An engineering system may own a technical dimension or material specification. A commerce system may transform that approved fact into a retailer attribute, product-page field, and feed value. They solve different operational jobs.

| If your team needs to manage... | Start with... | The commerce buyer should still ask... |
| --- | --- | --- |
| CAD files, drawings, BOMs, revisions, and engineering changes | Engineering PDM or PLM | How will approved specifications reach commercial product records? |
| Titles, attributes, variants, descriptions, media, and channel content | PIM or product-data management software | Which sources own inventory, price, assets, and technical facts? |
| Both product development and multichannel selling | Connected engineering and commerce systems | Where is each field transformed, approved, and published? |

A search result that says “PDM software” may therefore describe a design repository rather than a commerce catalog. Define the records your buying team needs before comparing vendors.

## Who needs product data management software?

A small catalog with one storefront can often use the product tools inside its commerce platform. A dedicated system earns its place when product complexity creates recurring operational work.

You are a strong candidate when several of these conditions apply:

- The same SKU appears with different titles, specs, images, or availability across your storefront, marketplaces, retailer portals, and feeds.
- Product teams maintain attributes in spreadsheets and copy them into several systems.
- Parent products and variants have inconsistent IDs, options, images, or inventory states.
- Launches wait on missing specs, translations, approvals, or media rights.
- Each destination has a different schema, taxonomy, character limit, or required field.
- Merchandising needs richer content while operations needs current price and stock.
- Your team cannot trace a channel value back to an owner and source, or a Google and AI-shopping correction requires manual edits in several places.

SKU count alone is a poor buying threshold. A retailer with 2,000 products across 10 regions can have more governance work than a single-market brand with 50,000 simple products. Channel count, variant depth, localization, update frequency, and the cost of incorrect data are better signals.

## Capabilities to put in the buying scorecard

Feature lists look similar across this category. A useful scorecard ties each capability to the work your team needs to complete.

### 1. Ingestion and source ownership

Require a clear path from enterprise resource planning (ERP), supplier files, manufacturer pages, PIM, digital asset management (DAM), storefront, reviews, and internal databases into the product record. The system should retain source location, retrieval time, and field ownership. It should accept APIs and structured files without forcing every team to maintain another manual import.

Ask vendors to show how a conflict is handled. If the ERP owns inventory, the DAM owns approved images, and a supplier document owns dimensions, the system should preserve those boundaries instead of silently selecting one value.

### 2. Identity, variants, and relationships

Product identity is the foundation of every update. The platform should support stable IDs, SKU, GTIN, MPN, brand, canonical URLs, parent-child relationships, bundles, accessories, replacement products, and multiple seller offers where relevant.

GS1 defines a Global Trade Item Number (GTIN) as a globally unique identifier for a trade item. A scorecard should therefore include identifier format, uniqueness, and ownership, alongside the ability to preserve leading zeros and distinguish a variant from its parent. The [GS1 GTIN standard](https://www.gs1.org/standards/id-keys/gtin) provides the identifier context.

For each representative variant, require a separate price, availability, URL, image relationship, and channel representation. A product page can show one family with options while a feed still needs one row per sellable item.

### 3. Schema, taxonomy, and typed attributes

A platform should support a shared core schema plus category extensions. Apparel may need fit and fabric. Electronics may need ports and compatibility. Beauty may need ingredients and warnings.

Look for typed values, controlled vocabularies, units, locale rules, conditional fields, and destination mappings. Free text belongs in descriptions. Fields used for filtering, comparison, eligibility, or automated decisions should have a defined type and accepted values.

### 4. Enrichment with evidence and review

Enrichment can fill missing attributes, classify products, improve titles, create channel copy, connect related products, and add image metadata. Automation is useful when every derived value has a source, confidence, and review path.

The system should distinguish a manufacturer-confirmed material from an inferred style tag, and a specification from a review summary. Require change history and reviewer ownership for values that affect a purchase decision, safety, compliance, or fit.

### 5. Quality and governance

A mature workflow catches errors before they spread. Score the platform on:

- required-field completeness by category, locale, and destination;
- identifier format and uniqueness;
- variant and relationship consistency;
- accepted values, units, currency, and locale;
- price, sale-price, availability, and inventory logic;
- image URLs and variant-image matching;
- category and attribute compatibility;
- claims, restrictions, warnings, and policy fields;
- approval status, permissions, and audit history.

You also need an exception queue. A quality score without a way to assign, resolve, and reprocess errors leaves the work in a spreadsheet. Use the [product data quality guide](https://www.getcatalog.ai/blog/product-data-quality) for a deeper operating model.

### 6. Publishing, feeds, and APIs

The system should map one canonical record to channel-specific schemas, then deliver through feeds, APIs, webhooks, or scheduled files. Ask for retries, partial updates, destination-level validation, delivery logs, and rollback or replay behavior.

A feed-management tool can be excellent at mapping and delivery while leaving source governance elsewhere. That is a valid architecture when the handoff is explicit. The [product data syndication guide](https://www.getcatalog.ai/blog/product-data-syndication) covers channel contracts and delivery in more detail.

### 7. Freshness and observability

A clean record from last quarter is not a reliable offer today. Score update latency for price, inventory, availability, shipping, and policy changes separately from the cadence for descriptions and attributes.

Require timestamps, freshness status, source health, failed jobs, affected destinations, and a view of what changed. A useful system shows the path from source change to published value, including any channel rejection or stale output.

### 8. Integration and ownership

Map the system boundaries before you buy. ERP usually owns operational and transactional data. DAM manages files and rights. A commerce platform renders the storefront and often owns the live offer. PIM manages commercial product content. A feed system handles destination delivery. An AI-ready product-data layer can normalize and expose the record to machine-facing surfaces.

The platform must have an owner after implementation. Include migration, taxonomy design, mapping, localization, approvals, monitoring, API limits, support, and total operating cost in the scorecard. The [product data integration guide](https://www.getcatalog.ai/blog/product-data-integration) is useful when drawing this architecture.

## How the adjacent categories fit

The right product data management software is the system that owns your unresolved problem. These categories overlap, yet their primary jobs differ.

| System or layer | Primary job | Good fit | What it does not solve by itself |
| --- | --- | --- | --- |
| **Catalog’s AI-ready product-data layer** | Normalize, enrich, sync, and expose live structured product data to AI shopping surfaces | A governed catalog that needs a machine-readable, measurable parallel storefront | Deep internal PIM workflows, ERP transactions, or engineering change control |
| **PIM** | Govern market-ready product content and distribute it across channels | Complex attributes, localization, approvals, and merchandising operations | Engineering files, transactions, or every real-time channel state |
| **Product catalog management** | Organize assortment, hierarchy, variants, collections, and relationships | Storefront and merchandising workflows | It is a capability, not always a separate source of truth |
| **Master data management (MDM)** | Govern master data across domains, entities, and business processes | Enterprise data ownership and cross-domain consistency | Commerce-ready copy, channel mappings, and media operations without additional work |
| **DAM** | Store, organize, approve, and distribute digital assets | Image, video, document rights, renditions, and usage control | Product identity, attributes, offers, and variant logic |
| **Feed management or syndication** | Map and deliver data to marketplaces, retailers, ads, and other destinations | Destination-specific formatting, delivery, and monitoring | Upstream governance, enrichment, and source resolution |
| **Engineering PDM or product lifecycle management (PLM)** | Control design data, revisions, BOMs, and engineering changes | Product development and manufacturing teams | Market-ready product content and commerce distribution |

Catalog belongs in the first row when the core gap is AI commerce. A traditional PIM is the better first investment when internal catalog operations are the bottleneck. Many larger teams keep both. The PIM remains the operational system for enrichment and governance, while Catalog provides the live AI-commerce layer. See the [PIM and Catalog comparison](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) for that architecture.

## A practical evaluation process

Use a representative buying exercise instead of a generic feature checklist.

1. **Map the source of truth.** List every system that owns a field, from GTIN and technical specs to price, inventory, media, shipping, and returns. Record update frequency and an accountable owner.
2. **Select difficult records.** Include products with variants, bundles, missing attributes, multiple locales, conflicting sources, regulated claims, and fast-changing offers. A simple SKU hides the work you are buying for.
3. **Define destination contracts.** Write down the fields, types, taxonomies, URLs, image rules, and freshness expectations for your storefront, Google Merchant Center, major marketplaces, retail partners, and AI surfaces.
4. **Score five workflows.** The vendor should demonstrate ingest and identity resolution, enrichment with evidence, quality exceptions and approval, destination publishing, and a correction that propagates to every affected output.
5. **Measure the operating load.** Include implementation time, migration, mapping, training, API usage, localization, support, monitoring, and the people required to keep the system healthy. A low license price can still create a large manual workload.
6. **Set outcome measures.** Track completeness, error rate, correction time, freshness, rejected records, channel coverage, launch time, and support or return issues tied to incorrect information. For AI surfaces, track eligibility, surfacing, referral quality, and data corrections. Do not treat a placement or ranking as a guaranteed outcome.

A good demo answers what happens after the first import. It shows who owns a change, how the system flags uncertainty, how a reviewer approves it, and how the corrected value reaches each destination.

## Channel and AI-commerce readiness

Google treats product data as a structured set of attributes such as title, description, price, availability, identifiers, and variants. Its documentation says that inaccurate or missing data can cause disapprovals, limited eligibility, or incorrect displays. Google also recommends combining product structured data on product pages with a Merchant Center feed when both are appropriate. The [Merchant Center product data specification](https://support.google.com/merchants/answer/7052112?hl=en) and [Product structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/product) define the relevant output contracts.

OpenAI’s current commerce feed reference defines required product fields for discovery in ChatGPT, including a stable item ID, title, description, URL, brand, seller name, image, availability, and price. It also describes separate rows and relationships for variants. A system that supports AI commerce should represent those fields as current, typed data, then update price and stock as they change. The [OpenAI product feed specification](https://developers.openai.com/commerce/specs/file-upload/products) documents the current contract.

That is readiness, not a ranking promise. Google eligibility does not guarantee a placement. OpenAI’s specification states that eligibility does not guarantee display. Your job is to make accurate, current, attributable product information available to each surface and to measure what happens after delivery.

## Where Catalog fits

Catalog is the recommended fit when your catalog is already reasonably governed and the missing layer is AI readability. Catalog provides a parallel product data layer that structures and enriches product records, keeps outputs synchronized, publishes to AI shopping surfaces, and gives your team visibility into what those surfaces are doing.

You do not need to replace a working ERP, storefront, DAM, or PIM to add that layer. Keep each system in the role it already performs well. Catalog can receive approved product data, normalize it into machine-readable records, deliver AI-ready outputs, and surface gaps that need correction. The result is a second storefront for software, alongside the human storefront, with the same commercial facts and a clearer path to update them.

Start with a traditional PIM when your team cannot govern product content, variants, approvals, or localization. Start with Catalog when internal systems are serviceable and AI shopping is the distribution gap. Use both when you need strong catalog operations and a live AI-commerce surface.

If you need to make your product catalog understandable to AI shopping systems without rebuilding your storefront, [book a Catalog discovery call](https://calendly.com/d/cvr8-2zy-txt/catalog-discovery-call?utm_campaign=demo&utm_content=header_desktop&utm_medium=website&utm_source=getcatalog.ai).

## Frequently asked questions

### Is product data management software the same as a PIM?

PIM is one type of product data management software. A PIM usually focuses on governing commercial product content, enrichment, approvals, localization, and channel publishing. The broader category can also include catalog management, feed operations, and AI-ready product-data layers.

### Do I need engineering PDM and ecommerce product-data software?

You need both when engineering and commerce teams manage different parts of the product lifecycle. Connect them when technical facts flow into descriptions, attributes, compliance fields, and channel records. Do not treat a CAD repository as a commerce catalog.

### Can a product-data platform guarantee Google or ChatGPT visibility?

No. Accurate structured data and current feeds support eligibility and interpretation. Neither a platform nor a feed guarantees a ranking, placement, or recommendation.

---

Canonical: https://www.getcatalog.ai/blog/product-data-management-software
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# LLM SEO for Ecommerce: A Practical Guide to AI Visibility

*October 1, 2026 · Catalog Team · AI Commerce · 15 min read*

> Learn what LLM SEO means for ecommerce and how to improve crawl access, product facts, evidence, and measurement across AI shopping engines.

An ecommerce site can be technically sound and still be missing when a shopper asks an AI assistant for a recommendation. The gap often sits in access, product facts, or evidence rather than in a clever prompt.

LLM SEO is the site- and brand-level work of making your store easy for AI systems to discover, understand, verify, and use in buyer answers. This guide separates that work from using an LLM as an SEO tool, then gives you a cross-engine workflow you can put into your existing SEO and merchandising processes.

## What LLM SEO means for ecommerce

LLM SEO is the practice of improving a website and brand so large language model-powered experiences can retrieve, interpret, and accurately use its information. For an ecommerce team, the unit that matters is often a product and its variant, not only a page or a keyword.

A useful outcome is specific: when a shopper asks for a product with a set of constraints, an assistant can find your site, understand which item fits, describe it correctly, and link to a page with a current offer. Visibility does not mean inclusion is guaranteed. It means you have removed avoidable reasons for being absent, misunderstood, or described with stale facts.

The name is still used in two ways. Some people mean optimizing a site for AI-assisted discovery. Others mean using an LLM to perform SEO work. Those are different jobs:

| Term | What it optimizes | Typical work |
| --- | --- | --- |
| Traditional SEO | Crawlable pages that can be indexed, ranked, and clicked | Technical SEO, information architecture, useful content, links, and page experience |
| LLM SEO | A site and brand that can be retrieved, understood, verified, and used in AI answers or recommendations | Crawler access, clear product facts, original evidence, consistent sources, and answer measurement |
| Using an LLM for SEO | The team's workflow | Keyword research, briefs, audits, summaries, code assistance, and draft editing |
| GEO | Visibility in generative systems that synthesize, cite, compare, or recommend information | A broader outcome and practice that overlaps with LLM SEO; see Catalog's [GEO definition](https://www.getcatalog.ai/glossary/generative-engine-optimization) |
| AEO | Content and data that answer a question directly | A narrower answer-focused objective; see Catalog's [AEO definition](https://www.getcatalog.ai/glossary/answer-engine-optimization) |

The boundaries are practical rather than official categories. Google describes AEO and GEO as terms used for work on AI search, while its own recommendation is to keep doing SEO. Treat LLM SEO as an extension of a mature SEO program, with more attention to product truth and how answers are measured.

Using an LLM to write a product description can save time. It does not make that product crawlable, give it a trustworthy price, or earn a recommendation. The first is an internal production method. The second is a property of the site, the data, and the sources an AI system can access.

![Workflow from product facts to AI answers](https://www.getcatalog.ai/images/blog/llm-seo-workflow.svg)

## The SEO foundations that carry over

Google's [generative AI guidance](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) says the core Search and quality systems still underpin AI Overviews and AI Mode. Those foundations also make a site easier for other retrieval systems to use:

- **Crawlable, indexable pages.** A product or category page needs a stable URL, an accessible response, and a clear canonical. An AI system cannot use a page it cannot reach or a page that exposes no product information.
- **Clear site architecture.** Link categories, collections, products, policies, and supporting guides together. Use navigation and XML sitemaps to reveal the pages that matter. Avoid creating a separate thin page for every phrasing of a question.
- **Helpful, original content.** Explain products and buying decisions with information that comes from your experience, data, testing, or customers. A rephrased manufacturer paragraph gives a system little reason to choose your page.
- **Good page experience.** Keep pages usable on phones, fast enough to load, and free of overlays that hide the main information. Make important facts available in the initial page response when feasible instead of relying on a crawler to execute every client-side interaction.
- **Accurate visible content and markup.** Structured data can clarify products and offers and support eligibility for Search features. It should describe what the shopper can see and buy. Markup is a supporting signal, not a substitute for a complete product page.

These are shared foundations, not a second technical stack. Start with the same audit you would run for organic search. Add checks for the AI crawlers and answer outcomes that matter to your business.

## A cross-engine LLM SEO workflow

### 1. Map buyer questions before changing copy

Start with the questions that lead to a product decision. Pull them from Search Console queries, site search, customer-service tickets, sales calls, reviews, return reasons, and merchandising briefs. Group them by the information a buyer needs:

| Question group | Example | Information the answer needs |
| --- | --- | --- |
| Category discovery | “What is a good carry-on for a week-long business trip?” | Category, use case, constraints, and meaningful alternatives |
| Fit and compatibility | “Which filter fits the 2024 Model X purifier?” | Model numbers, compatibility relationships, dimensions, and exclusions |
| Comparison | “Compare these two trail shoes for wet, rocky routes.” | Materials, performance attributes, trade-offs, and evidence |
| Trust and proof | “Is this sunscreen suitable for sensitive skin?” | Ingredients, testing or certification, warnings, reviews, and limitations |
| Purchase and policy | “Which one ships to Canada and can be returned within 30 days?” | Price, stock, destination, shipping, returns, and warranty |
| Brand evaluation | “Is this brand a good choice for repairable luggage?” | Company claims, repair policy, warranty, independent coverage, and customer experience |

Create a fixed prompt set for the main categories and brands you care about. Twenty-five well-chosen prompts are more useful than a long list of variations that no shopper asks. Map each prompt to the page or product record that should supply the answer, then list the facts that must be present there.

This keeps the work at the site and brand level. You are improving the information architecture and the underlying product records instead of stuffing prompts into pages.

### 2. Remove access blockers across the engines you serve

Run an access pass before rewriting content. Check a representative sample of category pages, product detail pages, policies, and guides for:

- accidental `noindex` directives, restrictive `robots.txt` rules, incorrect canonicals, login walls, and geofencing;
- `200` responses for the intended public pages, including when requests pass through your CDN, WAF, or bot-management layer;
- stable product URLs in XML sitemaps and crawlable internal links;
- product names, prices, availability, and key attributes in the rendered page content;
- JavaScript interactions that hide the product record until a user clicks, selects a variant, or starts a session;
- staging, duplicate, filtered, and expired campaign URLs that create noise or conflicting facts.

Crawler access is a policy choice. The bot names published by OpenAI illustrate why “allow AI” is too broad to be a useful instruction. [OpenAI's crawler documentation](https://developers.openai.com/api/docs/bots) separates:

- **OAI-SearchBot**, which is used to surface websites in ChatGPT search. Opting out means a site will not appear in ChatGPT search answers, although it may still appear as a navigational link.
- **GPTBot**, which crawls content that may be used to train OpenAI's generative AI foundation models. Its control is independent from OAI-SearchBot.
- **ChatGPT-User**, which can fetch a page after a user action. It is not an automatic web crawler or the control for ChatGPT search, and robots.txt rules may not apply to that user-initiated request.

Decide which uses your business permits for each section of the site. Allowing OAI-SearchBot does not mean you must allow GPTBot. The same distinction will not map perfectly to every provider, so document each engine's control and test the actual response from your infrastructure. Review access logs for bot names, status codes, response sizes, and repeated blocks rather than relying on a robots.txt file alone.

### 3. Keep product facts consistent across pages, feeds, and markup

An assistant needs a product record it can compare. Build that record from a source of truth, then distribute it to the surfaces where buyers and systems find you. At minimum, cover:

| Fact family | Examples | Consistency check |
| --- | --- | --- |
| Identity | Product name, brand, SKU, GTIN or MPN, canonical URL | The same identifier resolves to the same item everywhere |
| Decision attributes | Material, dimensions, fit, use case, compatibility, ingredients, capacity, color, size | Values use stable units and accepted category terms |
| Variant relationships | Size, color, pack, bundle, refill, model, and parent-child relationships | A shopper can tell what changes and which offer applies |
| Offer state | Price, currency, sale terms, availability, condition, shipping, returns, warranty | The page, feed, and checkout agree at the same time |
| Proof and provenance | Reviews, ratings, certifications, manuals, tests, source, owner, and update time | Claims have a source and a person or system responsible for freshness |

For Google, [product data guidance](https://developers.google.com/search/docs/specialty/ecommerce/share-your-product-data-with-google) explains how structured data and Merchant Center feeds serve complementary purposes. Structured data helps Google read product pages. A feed gives Google a direct commerce record, can help it discover products that crawling misses, and gives you more control over update timing. Google also explains how [merchant listing markup](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing) can represent price, availability, shipping, and returns for a purchasable product. Follow those requirements for Google, then map the same source facts to other channels.

Do not let a feed become a second product database. When a price, stock state, variant, or return policy changes, update the canonical record and regenerate the page output, structured data, and feeds. Validate the outputs on a schedule that matches how quickly each fact changes. Inventory may need near-real-time updates. A long-lived material specification may need review when the product changes.

Catalog fits at this product data layer. It can normalize and enrich live product facts, expose machine-readable product objects, keep downstream outputs synchronized, and help teams observe what AI systems do with those facts. That makes Catalog useful alongside a storefront, PIM, CMS, Merchant Center, marketplaces, and an SEO program. It does not replace those systems or force an assistant to recommend a product.

### 4. Publish original evidence a buyer can use

Clear attributes make a product legible. Evidence gives an assistant and a buyer a reason to trust the claims.

Replace broad claims with specific, supportable facts:

- Instead of “the best lightweight pack,” publish the measured weight, capacity, load guidance, materials, and the conditions under which you tested it.
- Instead of “fits most devices,” list compatible models, dimensions, exclusions, and the date the compatibility list was reviewed.
- Instead of “gentle for sensitive skin,” publish the ingredient list, use instructions, relevant testing or certification, warnings, and limits of the claim.
- Instead of hiding a return promise in a footer, state the window, exclusions, process, and regions in a page that the product links to.

Put important evidence in visible prose and in structured fields where a field exists. Keep the source, unit, date, and owner with the fact in your internal product model. Link to manuals, test methods, certifications, and policies when they help a buyer make a decision.

Google recommends [valuable, non-commodity content](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide), including first-hand perspectives that add information beyond a summary. For ecommerce, that can come from fit testing, support patterns, return analysis, repair records, independent reviews, retailer consistency, or a documented product comparison. Do not manufacture reviews, inflate claims, or create a network of artificial mentions. A brand is easier to trust when its own site and credible outside sources describe the same product in compatible terms.

Use an LLM as an assistant for organizing evidence, finding contradictions, or proposing a first draft. Apply human review to every claim, including titles, metadata, alt text, and structured data. [Google's AI-content guidance](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) warns that scaled pages without added value can violate spam policies and that generated text needs fact-checking.

### 5. Measure retrieval, answers, and revenue together

A rank tracker cannot tell you whether an assistant chose the right variant or repeated an obsolete price. Measure the full path with the same prompt set you created in step one.

| Layer | What to record | Useful signal |
| --- | --- | --- |
| Access | Index status, response code, crawler requests, blocked paths, and render output | The intended page and facts are available to the intended systems |
| Retrieval | Prompt, engine, model or mode, locale, date, cited URLs, and result type | Your page or product enters the candidate set |
| Answer quality | Brand and product mentions, correct variant, factual accuracy, citation, and competitor context | The system describes the right product for the question |
| Owned traffic | Search Console performance, organic visits, AI referrals, landing pages, and UTM values | AI-assisted discovery reaches the site |
| Commerce outcome | Product views, add-to-cart, checkout, conversion, revenue, and assisted conversions | Visibility contributes to a business result |

Run the prompts across the engines your buyers use, such as Google AI features, ChatGPT, Gemini, Claude, or Perplexity. Keep the wording, location, language, and account state consistent enough to compare runs. Record the full response and cited links, not just a screenshot or a yes/no mention. Repeat the set after meaningful product-data or content changes and watch patterns across several runs because model outputs vary.

Google provides a [Generative AI performance report](https://support.google.com/webmasters/answer/16984139?hl=en) in Search Console for eligible AI features. OpenAI's [publisher FAQ](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq) says publishers that allow OAI-SearchBot can track ChatGPT referral traffic, with `utm_source=chatgpt.com` included in referral URLs. Use those first-party signals alongside your own prompt and conversion records. Catalog's [AI visibility guide](https://www.getcatalog.ai/blog/ai-visibility-ecommerce) goes deeper on measuring mentions, citations, and product-level outcomes without turning this workflow into a dashboard exercise.

A useful operating rhythm is simple:

1. **Baseline:** capture buyer prompts, access checks, product facts, and current answer quality.
2. **Fix:** resolve the highest-impact block, usually a missing fact, conflicting offer, or inaccessible page.
3. **Re-run:** test the same prompts and verify the source page, variant, and offer.
4. **Prioritize:** promote fixes that improve factual accuracy and buyer outcomes across more than one engine.

## Myths and limits

| Myth | What is true |
| --- | --- |
| “An `llms.txt` file or special AI markup guarantees visibility.” | Google says it does not use `llms.txt` or other special AI files for Search. Other services may choose to read such files, but there is no universal requirement or guarantee. Use supported structured data for the surfaces that document it. |
| “Every page should be broken into tiny chunks.” | Google says there is no required content chunking pattern or ideal page length. Organize pages for buyers and make each important answer clear in context. |
| “Rewrite product copy for AI and leave the rest alone.” | Copy cannot fix blocked pages, stale price and inventory, weak variant relationships, or unsupported claims. |
| “Product schema guarantees a citation or recommendation.” | Structured data can improve machine understanding and eligibility for some Search features. It does not force an AI system to retrieve, cite, or recommend a product. |
| “Allowing an AI crawler guarantees inclusion.” | Access is a prerequisite for some retrieval paths. Relevance, data quality, evidence, competition, engine behavior, and user context still decide what appears. |
| “One answer proves that LLM SEO worked.” | Answers vary. Use a fixed prompt set, several observations, accurate citations, and business outcomes before changing priorities. |

## FAQ

### Does LLM SEO replace traditional SEO?

No. Crawlability, indexing, useful content, internal linking, page experience, and trustworthy authority remain the base. LLM SEO adds site- and brand-level work for retrieval, product interpretation, evidence, and answer measurement.

### Should an ecommerce brand allow GPTBot?

That depends on your publishing and training policy. GPTBot is the OpenAI crawler used for content that may be used to train foundation models. OAI-SearchBot controls inclusion in ChatGPT search. OpenAI documents them as independent controls, so decide deliberately instead of treating all AI crawlers as one setting.

### Do I need `llms.txt` for LLM SEO?

No universal file is required. Google says `llms.txt` does not affect visibility in Google Search. If another service supports the file, you can evaluate it as an optional distribution aid, without treating it as a ranking or recommendation lever.

### What should an ecommerce team fix first?

Fix access and product truth first. Make key pages crawlable, then reconcile identity, variants, price, availability, policies, and structured data across the page and feeds. Add or improve copy after the facts are reliable.

### How often should we measure AI visibility?

Keep a stable prompt set and repeat it on a schedule that fits the business. Monthly checks can suit stable categories. Weekly checks are useful around launches, promotions, inventory changes, and major site releases. Monitor high-change product facts more often than you run full prompt tests.

LLM SEO becomes manageable when it is treated as an operating system for product truth rather than a collection of AI tricks. Map real buyer questions, open the right access paths, keep the same facts synchronized everywhere, publish evidence that earns trust, and measure what assistants say alongside what shoppers do.

If your product information is spread across a storefront, PIM, feeds, and channel tools, [see Catalog's product-data layer](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/llm-seo-ecommerce
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product taxonomy: A practical guide for ecommerce teams

*October 1, 2026 · Catalog Team · Product Data · 16 min read*

> Build a governed product taxonomy that keeps categories, attributes, filters, feeds, and machine-readable records consistent across commerce channels.

Product data usually breaks at handoffs. A supplier calls an item a “top,” your storefront calls it a “shirt,” and a shopping channel expects a predefined category. A governed product taxonomy gives catalog owners a shared language for categories and attributes, then maps that language to every downstream surface. The practical path is to design that model, keep it current, and validate every product against it.

## What is a product taxonomy?

An ecommerce product taxonomy is a governed hierarchy of product categories, with rules for the attributes and values that describe each category. The hierarchy answers **what kind of product is this?** The attributes answer **what does it have, and what is true about it?**

A compact example:

```text
Home & Garden
└── Lighting
    └── Lamps
        └── Table Lamps
```

A product assigned to the `Table Lamps` leaf might have this record:

| Field | Example value |
| --- | --- |
| `category_id` | `home.lighting.table-lamp` |
| `category_path` | `Home & Garden > Lighting > Lamps > Table Lamps` |
| `material` | `ceramic` |
| `shade_color` | `blue` |
| `bulb_type` | `LED` |
| `dimmable` | `true` |
| `shade_diameter` | `9 in` |

The category is stable product identity. `Material`, `shade_color`, and `dimmable` are structured facts. Their values should use controlled labels and typed units so `blue`, `Blue`, and `navy-blue` do not become three unrelated filter values.

A taxonomy includes more than a tree. Define a stable ID for every node, a preferred label, synonyms, inclusion and exclusion rules, required attributes, allowed values, and mappings to outside vocabularies. Keep the canonical category separate from a storefront collection, campaign tag, or supplier label.

Keep parent-level facts on the parent product and variant-level facts such as size or color on each sellable variant. Give each product one primary canonical leaf unless your business has a documented reason to support multiple classifications. Derive additional placements from that assignment instead of asking every channel to invent its own category.

## Taxonomy is not navigation, facets, or a channel standard

These terms often appear together in a catalog project. They solve different problems.

| Concept | What it does | How it relates to taxonomy |
| --- | --- | --- |
| **Product taxonomy** | Defines the governed hierarchy and the rules for classifying products. | The canonical classification model. |
| **Storefront navigation** | Gives shoppers menus, breadcrumbs, landing pages, and collection links. | A customer-facing view of selected categories. It can be shallower, reordered, or renamed without changing canonical IDs. |
| **Attribute** | Stores a product fact such as material, capacity, fit, or compatibility. | Describes products inside a category. Attributes can apply across categories, while category-specific attributes keep filters relevant. |
| **Facet or filter** | Lets a shopper narrow a result set by a field and value. | A search or browse interface built from attributes, category context, inventory, and business rules. A facet is not a new category. |
| **Merchant product type** | Expresses a merchant’s own hierarchy, such as `Women > Tops > Shirts`. | A useful internal or channel field. In Google Merchant Center, `[product_type]` accepts the merchant’s chosen values. |
| **External standard** | Provides a predefined vocabulary for a marketplace, platform, or trading network. | A mapping target. Google product categories, Shopify’s Standard Product Taxonomy, and GS1 GPC should not replace the canonical model by default. |

Use a category for a durable difference in **what a product is**. Use an attribute for a difference in **what a product has, does, or suits**. “Table lamps” can be a category. “Dimmable” is an attribute. “Blue” is an attribute value. “Bedroom lighting” might be a navigation collection or use-case facet rather than a second product category.

## Why taxonomy affects more than the menu

Taxonomy is discovery infrastructure. It gives each downstream system context for interpreting product facts.

| Surface | What taxonomy contributes | Operational result |
| --- | --- | --- |
| **Filters and facets** | A category-specific attribute schema and controlled values. | Shoppers see relevant filters, such as `bulb type` for lamps, without empty or unrelated options. |
| **On-site search** | Category labels, synonyms, hierarchy, and normalized attributes. | A query such as “blue ceramic table lamp” can combine a product type with facts instead of relying on one exact title match. |
| **Recommendations** | Product families and comparable attribute sets. | Candidate products stay within a meaningful category before behavior, price, inventory, or merchandising rules rank them. |
| **Feeds and marketplaces** | A canonical source for channel category fields and category-dependent requirements. | One approved product record can be transformed into several channel contracts without manual recategorization. |
| **Machine-readable product records** | Stable IDs, typed fields, category context, and mappings. | Search engines, APIs, and shopping agents can interpret a product without inferring every fact from prose. |

Taxonomy is one signal in each system. It does not determine search ranking or recommendation order by itself. Availability, price, behavior, text relevance, margin, and channel rules still matter. Taxonomy makes those systems operate on a consistent product set.

Taxonomy cannot rescue missing facts. If `material` is empty or stored as free text, a filter, feed, or machine-readable object still has an incomplete record. Product attributes need their own definitions, value sets, and quality checks. Catalog’s [product attributes guide](https://www.getcatalog.ai/blog/product-attributes-guide) covers that layer in more detail.

## Map one canonical category to every channel

Start with one canonical record. Map it outward. Do not map a supplier label directly to Google, Shopify, a marketplace, and an AI endpoint independently.

Assume the canonical model contains:

```text
category_id: apparel.clothing.shirts
category_path: Apparel > Clothing > Shirts
attributes:
  color: black
  fabric: cotton
  fit: regular
  sleeve_length: short
```

The same record can produce different, valid outputs:

| Destination | Channel output from the canonical record | Why the mapping is separate |
| --- | --- | --- |
| **Storefront navigation** | `Clothing > Shirts` | The menu is optimized for how shoppers browse. It may use shorter labels and omit operational branches. |
| **Storefront search and filters** | Category `shirts`; facets for `color`, `fabric`, `fit`, and `sleeve length` | Filters come from attributes and category rules, not from every node in the tree. |
| **Google Merchant Center** | `google_product_category`: Google’s predefined `Apparel & Accessories > Clothing > Shirts & Tops` (ID `212`) when it is the best match; `product_type`: `Women > Tops > Shirts` for the merchant’s own hierarchy | Google’s product category is predefined. Google’s `[product_type]` is merchant-defined. Google can categorize products automatically, and the category field can override that classification in specific cases. See the [Google category documentation](https://support.google.com/merchants/answer/6324436?hl=en) and [product type documentation](https://support.google.com/merchants/answer/6324406?hl=en). |
| **Shopify** | Product category: the matching node in Shopify’s Standard Product Taxonomy, such as `Apparel & Accessories > Clothing > Clothing Tops > Shirts`; category metafields for size, neckline, sleeve length, fabric, and color | Shopify’s standard category unlocks category metafields and supports filtering and channel workflows. Shopify’s category path is its own vocabulary, even when it maps closely to Google. See [Shopify product categories](https://help.shopify.com/en/manual/products/details/product-category) and [category metafields](https://help.shopify.com/en/manual/custom-data/metafields/category-metafields). |
| **GS1 GPC or a trading partner feed** | The approved GPC brick code plus the attributes required by that brick | GS1 GPC is a shared classification language for trading partners. It has its own Segment, Family, Class, Brick, and attribute structure. It is not a storefront menu. See [how GPC works](https://www.gs1.org/standards/gpc/how-gpc-works). |
| **API or AI shopping surface** | A typed object containing `category_id`, `category_path`, normalized attributes, variant relationships, identifiers, price, availability, and provenance | A machine-readable record needs explicit fields and freshness. It should not depend on one channel’s labels or on a model guessing the category from copy. |

Google accepts either a predefined category ID or its full path for `google_product_category`, not both. If no Google category fits, use the merchant-defined `product_type` field. Keep those rules in the mapping layer and test them when Google changes its taxonomy. Shopify’s category metafields are tied to the Standard Product Taxonomy and can support product data, filters, variant options, analytics, and channel workflows. Treat an unassigned `uncategorized` product as a validation failure in your own pipeline.

## How to build a product taxonomy

A useful taxonomy comes from product facts and shopper language. It does not start with a list of department names.

### 1. Define jobs and owners

List the surfaces the taxonomy must support: storefront browse, site search, recommendations, Google Merchant Center, marketplaces, retailer feeds, reporting, and machine-readable APIs. Give each surface an owner. Name one taxonomy owner who can resolve conflicts across merchandising, product data, search, and channel operations.

Write the decision rule before writing categories. For example: “Classify by the product’s primary function. Keep color, material, use case, and audience as attributes unless the channel or shopper journey requires a separate branch.”

### 2. Audit products and shopper language

Export active products, variants, titles, descriptions, supplier categories, existing tags, attributes, identifiers, and channel errors. Add site-search queries, zero-result queries, filter usage, returns, and customer-service terms. Look for duplicate product-type names and categories that mix incompatible products.

Start with a representative sample from every department. Include long-tail, bundle, replacement-part, and new-product records. A taxonomy that only fits best sellers will fail when the catalog expands.

### 3. Set category boundaries

Create a small draft tree and write an inclusion rule and an exclusion rule for every leaf. “Table lamps include complete portable lamps intended to illuminate a surface. Exclude bulbs, shades sold alone, and floor lamps.” This makes ambiguous assignments reviewable.

Choose depth when a new branch changes the shopper’s decision, required attributes, or a channel requirement. Do not create branches for every adjective in a title. Put color, size, material, finish, and most use cases in attributes unless evidence shows they need a separate browse path.

### 4. Define the attribute schema

Attach attributes to the categories where they are meaningful. For each one, record its data type, unit, allowed values, synonym rules, whether it is required, and whether it belongs on the parent product or a variant.

Normalize values before they reach filters or feeds. Store `0.75 lb` and `12 oz` in a canonical unit, then format them for a channel. Keep display labels separate from machine values when “graphite” is a brand-facing label for a normalized color value.

### 5. Assign stable IDs and aliases

Use immutable IDs for categories and attributes. Store preferred labels, historical labels, supplier aliases, search synonyms, and localized labels separately. This lets a label change without breaking URLs, feed mappings, analytics, or downstream joins.

Record the source and confidence for automated classifications. A low-confidence assignment should enter a review queue, not silently become canonical truth.

### 6. Map external taxonomies

Create a versioned mapping table with at least these columns:

| Column | Purpose |
| --- | --- |
| `canonical_category_id` | Stable internal leaf. |
| `external_system` | Google, Shopify, GS1, marketplace, or other destination. |
| `external_category_id` | Preferred machine key where the channel provides one. |
| `external_path` | Human-readable path for review. |
| `mapping_status` | Approved, pending review, deprecated, or no-match. |
| `effective_version` | Taxonomy release or mapping version. |
| `owner` | Person or team responsible for the mapping. |

One canonical leaf may map to different external leaves. A channel may have no exact match, in which case keep the closest approved parent and preserve the merchant-defined type or additional attributes the channel accepts. “No match” is a review state, not permission to use a random catch-all.

### 7. Validate before publishing

Run checks for missing category IDs, invalid parent-child relationships, duplicate leaves, unsupported values, missing required attributes, stale mappings, broken variant inheritance, and channel-specific formatting. Sample the output with a category specialist and a channel operator.

Publish only records that pass the checks for their eligible channels. Keep a rejection reason and remediation owner for every failed record. A clean source taxonomy and a clean channel export are separate quality gates.

Catalog can help with the normalization, enrichment, classification, and channel transformation around this workflow. Its [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) and [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) workflows can sit beside a PIM, commerce platform, ERP, or another source of truth. Catalog does not have to replace the system that owns your canonical product record.

## Govern the taxonomy as a product-data system

Taxonomy work is ongoing. New products, acquisitions, suppliers, markets, and channel changes create new classification decisions.

Use a lightweight change process:

1. A merchandiser, supplier, data steward, or channel owner submits a proposed category, attribute, value, or mapping change with examples.
2. The taxonomy owner checks the proposal against existing definitions, shopper language, required attributes, and external taxonomies.
3. A category subject-matter expert reviews edge cases and inclusion or exclusion rules.
4. The owner publishes a versioned change with an effective date, migration plan, and impact list.
5. Data operations reclassifies affected products, reruns channel validation, and monitors exceptions.
6. Search and merchandising owners review zero-result queries, filter usage, and category performance after the change.

Keep IDs stable. Deprecate a node with a replacement and a migration window. Keep a change log that records the reason, owner, old and new values, affected products, external mappings, and rollback path. Review exception queues monthly and the full tree at least quarterly, with an additional review before a new department or channel launch.

Useful measures include:

- approved canonical leaf coverage across active products;
- catch-all, unmapped, and `uncategorized` rate;
- required-attribute completeness by category;
- invalid-value and stale-mapping rate;
- percentage of eligible products with an approved channel mapping;
- feed rejection rate caused by category or missing category attributes;
- zero-result searches and empty filter values;
- recommendation coverage for each major category.

Set targets by catalog and channel. A single global score hides the products and categories that need attention.

## Catch-all and unmapped products need a queue

`Other`, `Miscellaneous`, `Uncategorized`, a blank category, and a supplier’s “general” label are useful intake states. They are poor end states.

Separate four cases:

- **Missing source data:** the product record needs a title, specification, image, or identifier before classification is possible.
- **Ambiguous evidence:** two categories fit, so a subject-matter expert must apply the inclusion rules.
- **New product concept:** the catalog has a real gap that may justify a new leaf or attribute.
- **No external match:** the canonical category is valid, but a particular channel has no equivalent node.

Track each case with an owner, reason, age, and next action. Do not count a product as covered simply because it was placed in `Other`.

A practical validation report should show, by category and channel:

| Check | Pass condition |
| --- | --- |
| Canonical assignment | Every eligible product has an approved category ID or an explicit review status. |
| Leaf validity | The assigned leaf exists, has the correct parent, and is not deprecated. |
| Attribute fit | Category-required attributes exist and use allowed values and units. |
| Variant integrity | Variant-level values belong to the right parent and do not leak across products. |
| Mapping validity | The external ID or path exists in the version used for the feed. |
| Catch-all aging | No unresolved `Other` or `Uncategorized` record exceeds the team’s review window. |
| Output quality | Channel exports pass schema, policy, and freshness checks. |

Use automated classification to prioritize work, with evidence and confidence attached. Human review remains necessary for ambiguous products, new concepts, bundles, regulated categories, and mappings that change channel requirements.

## Frequently asked questions

### What is an example of a product taxonomy?

For a lamp catalog, `Home & Garden > Lighting > Lamps > Table Lamps` can be a canonical path. The leaf can define attributes such as material, shade color, bulb type, dimmability, and dimensions. A storefront may show a shorter `Lighting > Table Lamps` path while feeds use their own category vocabularies.

### Is a product category the same as a product taxonomy?

No. A product category is one node or leaf. A product taxonomy is the complete hierarchy plus its IDs, definitions, attributes, values, and governance rules.

### Does Google require a Google product category for every product?

Google Merchant Center automatically assigns a product category from its evolving taxonomy. The `google_product_category` attribute is an optional override for specific cases, including category-specific requirements and campaign organization. When you provide it, use one predefined Google category as an ID or full path. Use `[product_type]` for your own hierarchy. Read Google’s current [category requirements](https://support.google.com/merchants/answer/6324436?hl=en) before publishing a feed.

### What is the difference between Google product category and product type?

`google_product_category` is Google’s predefined classification. `[product_type]` is the merchant’s chosen categorization, such as `Women > Tops > Shirts`, and can support bidding and reporting. They can both be sent from one canonical mapping, but they are different fields with different rules.

### What is Shopify’s product taxonomy?

Shopify’s Standard Product Taxonomy is Shopify’s predefined hierarchy of product categories, attributes, and attribute values. Assigning a category can unlock category metafields for fields such as size, color, fabric, or neckline. Shopify uses the category for product organization, filtering, channel workflows, and, in some cases, tax calculation. An unassigned product can remain `uncategorized`.

### Does a Shopify product category replace Google product category?

No. Shopify can map a Google Product Category when the value matches Google’s English taxonomy or its ID, but the two systems retain separate fields and release cycles. Keep a deliberate mapping and validate both outputs. A Shopify category alone does not remove Google feed requirements.

### Is GS1 GPC the same as Google or Shopify taxonomy?

No. GS1 Global Product Classification gives trading partners a shared classification language. Its structure uses Segment, Family, Class, Brick, and attributes. Google and Shopify maintain their own channel or platform taxonomies. Map GPC when a trading partner or data-synchronization workflow needs it, and keep customer-facing navigation in the canonical or storefront model.

### Should every product have one category?

Every eligible product should have one approved primary canonical category in the model, with documented rules for bundles, kits, services, and products that span categories. A product can appear in several storefront collections or have secondary relationships without creating several competing canonical truths.

## Keep the canonical model usable everywhere

A taxonomy earns its place when it reduces translation work. One governed category and attribute model should feed the storefront, search index, recommendation candidates, channel exports, and machine-readable product records. Each destination can still receive the vocabulary and fields it requires.

Catalog helps brands structure, enrich, normalize, and syndicate product data for AI commerce, publish machine-readable facts to AI shopping surfaces, keep those records live, and measure how products are surfaced. If your records are hard to classify, incomplete at the attribute level, or inconsistent from one destination to the next, [talk to Catalog](https://www.getcatalog.ai/) about building a live, normalized product data layer beside your existing source systems.

---

Canonical: https://www.getcatalog.ai/blog/product-taxonomy
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product data integration for ecommerce: A practical guide

*September 23, 2026 · Catalog Team · Product Data · 12 min*

> Learn how to connect supplier, PIM, ERP, and commerce data, map fields, validate product records, and keep prices, inventory, and variants current.

Product information rarely lives in one system. Supplier spreadsheets, enterprise resource planning (ERP) records, product information management (PIM) content, digital assets, and ecommerce platforms each hold part of the product truth. Product data integration connects those systems so teams can reuse a reliable product record instead of rebuilding a catalog for every storefront and channel.

The hard part is deciding who owns each attribute, translating schemas, validating variants and commercial state, and monitoring what arrives. A practical workflow covers the integration methods, a worked example, and the point where Catalog fits when AI shopping surfaces need live, machine-readable product data.

## What product data integration means

Product data integration connects product-data sources and destinations, translates their schemas, and moves validated records between them. In ecommerce, the flow usually looks like this:

**Supplier file or API → normalized product record → mapping and validation → storefront, marketplace, feed, or AI shopping surface**

A record can include SKU and GTIN, title and material, variant relationships, images, price, currency, availability, shipping, and return policies. The integration decides how each value is named, formatted, validated, and delivered.

That makes integration more than a connector. A production workflow also needs:

- **Ownership:** one authoritative writer for each important attribute.
- **Mapping:** rules that translate source fields into a shared product model and destination schemas.
- **Quality gates:** checks for missing fields, invalid values, duplicates, bad images, and broken variant relationships.
- **Delivery:** an API, file, feed, event, or connector that sends the record to its destination.
- **Observability:** freshness, acceptance, rejection, retry, and drift signals with a named owner.

The destination matters. A storefront needs a complete product page. A marketplace may require a category taxonomy and identifiers. An AI shopping surface needs typed product objects that explain what a product is, who it suits, and how it differs from alternatives.

## Integration is not the same as extraction, PIM, or syndication

These terms describe different stages or responsibilities. Keeping them separate prevents a feed export or one-time import from becoming an accidental source of truth.

| Term | Main job | Relationship to integration |
| --- | --- | --- |
| **Product data extraction** | Collect data from pages, files, databases, or APIs | Supplies input. It does not establish ownership, normalize fields, or deliver a usable record by itself. See [product data extraction](https://www.getcatalog.ai/blog/product-data-extraction). |
| **PIM or catalog management** | Govern approved product content, attributes, taxonomy, and workflows | May provide the canonical record. Integration still connects it to suppliers, commerce systems, and destinations. |
| **Feed management** | Build, transform, and monitor destination-specific feeds | Uses integrated records to produce channel outputs. See [product feed management](https://www.getcatalog.ai/blog/product-feed-management). |
| **Product data syndication** | Distribute product information to retailers, marketplaces, partners, and shopping surfaces | Usually the outbound distribution stage. See [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication). |
| **Data synchronization** | Keep values aligned as records change | Describes recurring updates. Integration also includes initial loading, mapping, validation, and ownership. |
| **Data migration** | Move a dataset from one system to another, often once | Can be an initial step, but does not keep future launches and updates moving. |


## The end-to-end product data integration workflow

A reliable integration turns a catalog connection into a repeatable operating process. Use these steps before importing a large file or building mappings.

### 1. Inventory sources, destinations, and field owners

List every system that reads or writes product information: supplier portals, spreadsheets, PIM systems, ERP, digital asset management (DAM), ecommerce platform, warehouse system, marketplaces, retail partners, ad feeds, and AI shopping destinations.

Assign ownership at the attribute level. A common arrangement is:

| Product data | Possible owner | Rule to define |
| --- | --- | --- |
| SKU, cost, and purchasing status | ERP or supplier | Preserve the source identifier and status. |
| Title, description, taxonomy, and attributes | PIM or catalog | Publish approved values and source locale. |
| Price and currency | ERP or ecommerce platform | Define which value wins in each market. |
| Inventory and availability | Warehouse, ERP, or commerce platform | Treat the value as time-sensitive. |
| Images and video | DAM or PIM | Pass the approved asset and variant relationship. |

Ownership must be unambiguous. If an ERP and storefront can both write price, a later update can undo a valid change without anyone knowing why. Make downstream copies read-only or define reconciliation before launch.

### 2. Choose a transport method that matches the source

The method depends on source access, catalog size, update risk, and the destination contract. Most catalogs combine a bulk load with incremental updates.

| Method | Best fit | Constraints to plan for |
| --- | --- | --- |
| **API or connector** | A system with a supported API and recurring updates | Rate limits, permissions, pagination, versions, and partial failures. |
| **Scheduled file or feed** | Suppliers publishing CSV, TSV, XML, JSON, or files over secure file transfer | Delimiter, encoding, schema, and freshness errors can affect a delivery. |
| **Event or webhook** | A source that emits product or inventory changes | Events can be missed, duplicated, or arrive out of order. Keep retries and reconciliation. |
| **Manual import** | A small catalog, pilot, or controlled migration | Hard to audit, monitor, or keep current as the catalog grows. |

Do not assume a supplier or destination supports a connector or two-way sync. Confirm access, permissions, pagination, rate limits, file schedule, and response semantics.

### 3. Match identifiers and model variants

Preserve a stable identifier from each source, then create a deterministic cross-system key. SKU, GTIN, manufacturer part number (MPN), product ID, and variant ID can all help match records, but they serve different purposes. A GTIN identifies a trade item where one exists. An internal SKU may identify the exact sellable variant.

Model parent products and variants explicitly. A navy medium jacket should retain its parent ID, color, size, price, image, and availability. A two-pack or bundle needs its own relationship and component list. Keep the original source ID so a changed supplier name updates an existing product instead of creating a duplicate.

### 4. Map schemas, values, units, and taxonomies

A mapping translates one field model into another and defines transformations and accepted values. Write it as a data contract instead of burying it in a script.

Common transformations include:

- Convert weight and dimensions to canonical units, then format them per destination.
- Map `Blue/Navy`, `dark blue`, and `navy` to one controlled color value where they are equivalent.
- Convert supplier status codes such as `Y` and `N` into accepted availability values.
- Map internal categories to a channel taxonomy without replacing the internal category.
- Convert locale, currency, date, and decimal formats explicitly.
- Preserve source and effective timestamps so a late update cannot overwrite a newer value.

For each mapping, store the source field, destination field, transformation, requiredness, and owner. Test empty values, unknown categories, multiple locales, and products with several variants.

### 5. Validate before you publish

Validation should stop bad records before they reach a storefront or channel. Check both data shape and product meaning:

- required fields, data types, unique identifiers, prices with currency, valid URLs, accepted image formats, dates, units, locales, and parent-child references;
- titles and descriptions that agree with the landing page, complete category attributes, correct variant images and availability, current price and stock, and exclusions for discontinued or restricted products.

Google’s [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) identifies missing identifiers, incorrect variant attributes, poor images, and feed-to-website conflicts as causes of disapprovals, limited eligibility, or display issues. Treat those checks as part of the integration even when Google is only one destination.

Keep rejected records with their reason, source version, and owner.

### 6. Load the catalog, then add incremental updates

Use a controlled bulk load for the first import. Compare record counts, identifier coverage, variant counts, image availability, and representative product pages before enabling downstream publishing. Then use incremental updates where the source can identify changes.

| Data | Update pattern | Reason |
| --- | --- | --- |
| Price, availability, and inventory | Event-driven or frequent scheduled updates | An old value can create a bad offer or failed order. |
| Content and attributes | After approval, then scheduled or event-based | These changes need review and rarely need minute-level delivery. |
| Images and rich media | After DAM approval and URL checks | The asset must be present and match the variant. |
| Taxonomy and mappings | On taxonomy change and before launches | Destination rules change independently of copy. |

Run full reconciliation on a schedule too. Incremental updates keep the catalog fresh. A complete comparison catches missed events, deleted products, and drift.

### 7. Monitor freshness, acceptance, and drift

A successful request does not prove a usable product. Google says a successful Merchant API insertion means Merchant Center accepted data for processing, not that the product is approved to show. Its [upload guidance](https://support.google.com/merchants/answer/11586438?hl=en) recommends the Merchant API for many feeds or frequent product changes.

Track:

- source fetch success, latency, and last-seen timestamp;
- records created, updated, deleted, skipped, and quarantined;
- validation failures and destination acceptance, warnings, rejections, and eligibility;
- age of price, inventory, content, and media values.

Alert on shopper-facing failures. A green job status is not enough if the last successful price update is two days old.

## Worked example: supplier jacket data to channel-ready records

Imagine a supplier sends this row:

```text
supplier_sku,upc,name,colour,size,rrp,stock_status,image_url,weight_kg,material
JKT-001-NV-M,0614141123452,Commuter Jacket,Blue/Navy,M,148.00,Y,https://supplier.example/jkt-001-nv-m.jpg,0.72,Recycled nylon
```

The integration should create a canonical variant record before producing channel outputs:

```json
{
  "product_id": "JKT-001",
  "variant_id": "JKT-001-NV-M",
  "sku": "JKT-001-NV-M",
  "gtin": "0614141123452",
  "title": "Waterproof commuter jacket, navy, medium",
  "attributes": {"color": "navy", "size": "M", "material": "recycled nylon", "weight_g": 720},
  "price": {"amount": 148.00, "currency": "USD"},
  "availability": "in_stock",
  "image_url": "https://supplier.example/jkt-001-nv-m.jpg",
  "source": "supplier-42"
}
```

The rules are explicit: `supplier_sku` becomes the stable SKU, `upc` is preserved as the GTIN after an identifier check, `Blue/Navy` becomes `navy`, `rrp` gets an explicit currency, `Y` becomes `in_stock`, and `weight_kg` becomes `weight_g`. The variant remains connected to parent product `JKT-001`.

That record can map separately to a storefront, a Google product feed, and a live product data layer for AI shopping. If the image URL is broken, the price has no currency, the SKU is already in use, or the parent relationship is missing, quarantine the row. Do not publish a plausible-looking substitute.

## Common failure modes and the controls that prevent them

| Failure | Symptom | Control |
| --- | --- | --- |
| Conflicting sources | Storefront and feed show different prices or copy | Assign one owner per attribute and retain timestamps. |
| Duplicate identifiers | A new variant overwrites another item or creates two listings | Preserve source IDs and validate uniqueness. |
| Flattened variants | A product shows the wrong image, price, or stock | Store parent, variant, and option relationships separately. |
| Stale commercial state | A channel advertises an unavailable item or old price | Give price and availability their own cadence and alerts. |
| Transport mistaken for acceptance | The API returns success while the channel suppresses the product | Read destination diagnostics and track eligibility. |
| Silent schema changes | A supplier adds, removes, or renames a column | Version contracts, test files, and alert on unknown fields. |

A tool can move records quickly and still spread a bad source value quickly. Make the data contract, validation rules, and escalation path as visible as the connection itself.

## How to evaluate product data integration software

Choose a system based on the product problem you need to solve.

| Option | Best fit | What to check |
| --- | --- | --- |
| **Catalog** | A live product data layer for machine-readable records and AI shopping surfaces | Source coverage, field ownership, variant handling, freshness controls, destination outputs, and measurement. Catalog sits beside the storefront, PIM, and ERP. |
| **Feed management platform** | Channel feeds when the source catalog is already trusted | Mapping depth, destination rules, diagnostics, and handling of source gaps. |
| **General iPaaS or ETL platform** | Broad workflows across operational systems, analytics, and warehouses | How much product modeling, taxonomy, validation, and monitoring your team must build. |
| **Custom integration** | A few strict contracts with an engineering owner | API changes, retries, security, tests, alerting, and maintenance. |

Catalog is the recommended fit when the integration goal includes AI commerce. We structure product data, keep records synchronized, publish machine-readable product context to AI shopping surfaces, and help teams measure what those surfaces do with the catalog. We are not a replacement for an ERP’s purchasing workflow or a warehouse’s inventory system. We work alongside the systems that own those facts.

During evaluation, ask:

- Can it ingest the APIs, files, and feeds your suppliers actually provide?
- Can you assign field-level ownership and keep timestamps, locale, and provenance?
- Does it model variants, bundles, packs, accessories, and regional offers?
- Can you test mappings, quarantine bad records, and replay failed updates?
- Does it support bulk loads, incremental updates, full reconciliation, retries, and destination diagnostics?
- Can you monitor freshness separately for price, inventory, content, media, and policy data?

## FAQ

### Is ETL the same as an API?

No. An API is an interface for requesting or sending data. ETL is a workflow pattern that extracts, transforms, and loads data. An integration may use an API for extraction and loading, a file for bulk transfer, or an event to trigger a transformation.

### Is product data integration the same as data synchronization?

No. Integration establishes the connection, model, mapping, validation, and delivery path. Synchronization applies recurring changes after that path exists. A synchronized copy without ownership and validation can keep the wrong value current.

### How often should product data be integrated?

Use the shortest cadence that matches business risk and source capability. Price, availability, and inventory need event-driven or frequent scheduled updates when they change quickly. Product content, attributes, taxonomy, and media can follow approval workflows. Pair incremental updates with scheduled reconciliation.

## Give AI shopping surfaces a product record they can trust

If your storefront is easy for people to read but thin for machines, Catalog can sit alongside your existing systems and turn product facts into live, normalized, machine-readable records for AI commerce. [Book a Catalog discovery call](https://calendly.com/d/cvr8-2zy-txt/catalog-discovery-call?utm_campaign=article&utm_content=product_data_integration&utm_medium=website&utm_source=getcatalog.ai).

---

Canonical: https://www.getcatalog.ai/blog/product-data-integration
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Multi-touch attribution for ecommerce: models, setup, and limits

*September 21, 2026 · Catalog Team · AI Commerce · 16 min*

> Learn how multi-touch attribution splits ecommerce conversion credit, how to choose and implement models, and how to measure AI-assisted discovery honestly.

Ecommerce shoppers rarely discover, compare, and buy in one session. A product can appear in search, get discussed by an AI assistant, return through an email, and convert after a paid reminder. A single-touch report compresses that path into one source. Multi-touch attribution gives the path more detail, while still leaving important questions about missing data and causality. This guide explains the models, an implementation plan, and the product-data foundations that make the output usable.

## What multi-touch attribution measures

Multi-touch attribution (sometimes written as multi touch attribution, or MTA) assigns fractional or proportional conversion credit to multiple eligible touchpoints before a conversion. A touchpoint can be an ad click, organic visit, email click, referral, product-page visit, or another interaction your measurement system can observe.

The output is an allocation. It is not a record of which channel caused the purchase. [Nielsen's guide to multi-touch attribution](https://www.nielsen.com/insights/2019/methods-models-a-guide-to-multi-touch-attribution/) describes the method as assigning fractional credit to touchpoints that influenced a key performance event. The distinction matters when a team turns the report into a budget decision.

Every MTA result depends on five choices:

1. **Conversion event:** The outcome being credited, such as a purchase, subscription, qualified lead, or product trial.
2. **Eligible touchpoints:** The channels, campaigns, views, clicks, and owned interactions that can receive credit.
3. **Identity rule:** How sessions, devices, logged-in users, and orders are connected to one journey.
4. **Lookback window:** How far before the conversion a touchpoint remains eligible.
5. **Attribution model:** The rule or algorithm that divides credit among the eligible touches.

Change any one of these inputs and the channel report can change. MTA does not discover a single timeless answer. It produces a consistent view of observed journeys under an explicit set of assumptions.

### A worked ecommerce journey

Consider a $160 order with four observed touches:

| Day | Touchpoint | What happened | Linear credit | Position-based credit* |
| --- | --- | --- | ---: | ---: |
| 0 | AI assistant referral | A shopper clicks a product link from ChatGPT | $40 | $64 |
| 2 | Organic search | The shopper returns through a non-branded product-guide query | $40 | $16 |
| 5 | Paid social | A retargeting ad sends the shopper back to the product page | $40 | $16 |
| 7 | Email | A product email leads to checkout and purchase | $40 | $64 |

\*This example uses a 40% first-touch, 20% middle-touch, 40% last-touch rule. It is an illustration, not a universal weighting.

Linear attribution gives each touch 25% of the order. Position-based attribution gives more weight to the first and last touches. Both approaches allocate the full $160. Neither proves that ChatGPT, organic search, paid social, or email created the order on its own.

If the assistant opens a webview that drops the referrer, the first touch may appear as `(direct) / (none)` or disappear from the tracked journey. The same linear model then divides the visible path among three touches. The model did not decide the assistant was unimportant. The source signal never arrived.


## Single-touch, multi-touch, and marketing mix modeling

Single-touch models are easy to explain and cheap to operate. MTA is more detailed. Marketing mix modeling (MMM) answers a different question at a different level.

| Approach | How it assigns or estimates credit | Useful for | Main limit |
| --- | --- | --- | --- |
| First-touch | Gives all credit to the first recorded touch | Comparing discovery campaigns and top-of-funnel entry points | Ignores the work that turns interest into a sale |
| Last-touch | Gives all credit to the last eligible touch, often the final click | Fast channel reporting and short purchase paths | Favors channels that close demand, including branded search and retargeting |
| Multi-touch | Splits credit across multiple observed touches using rules or a data-driven model | Comparing the roles of discovery, consideration, and conversion channels | Depends on observable paths, identity matching, and model assumptions |
| Marketing mix modeling | Uses aggregate spend, exposure, and outcome data over time to estimate channel contribution | Budget planning across online and offline media when user-level paths are incomplete | Does not explain an individual shopper's journey and needs enough historical variation |

Use the approach that matches the decision. MTA can help decide which campaigns deserve more or less investment within an observable digital journey. MMM can provide a broader view when impressions, offline media, retail activity, or privacy limits make user-level tracking incomplete. Incrementality tests are the stronger tool when the question is whether removing or adding a channel changes outcomes.

## Common multi-touch attribution models

Rules-based models are transparent. They are also opinions encoded as formulas. Data-driven models estimate weights from observed converting and non-converting paths, which can be more responsive to the business and harder to inspect.

| Model | Logic | When it helps | Trade-off |
| --- | --- | --- | --- |
| Linear | Splits credit equally across every eligible touch | Establishing a neutral baseline when no stage has a defensible weight | Treats a brief reminder and a high-intent product visit as equally important |
| Time-decay | Gives more credit to touches closer to the conversion | Longer consideration cycles where recent interactions tend to matter more | Can understate early discovery and brand-building work |
| Position-based (U-shaped) | Gives extra weight to the first and last touch and shares the rest across the middle | Journeys where discovery and conversion are both important | The chosen percentages are arbitrary unless validated |
| W-shaped or custom | Reserves weights for milestones such as first touch, lead, opportunity, and close | B2B or commerce journeys with clearly defined stages | Adds complexity and can create false precision when stages are inconsistent |
| Algorithmic or data-driven | Estimates contribution from patterns across converting and non-converting paths | Teams with enough clean journey data and a specific optimization question | Sensitive to data quality, selection bias, and the model's training rules |

Google Analytics currently supports data-driven attribution and last-click variants in its reporting settings for paid and organic channels. Google says first-click, linear, time-decay, and position-based models were removed from its attribution reports in November 2023. Those models remain useful industry concepts, but do not describe them as current GA4 reporting choices. See [Google's attribution settings](https://support.google.com/analytics/answer/10597962?hl=en) and its [current model guidance](https://support.google.com/analytics/answer/16291112?hl=en) when documenting a GA4 setup.

Google's data-driven model uses property-specific data to estimate the contribution of interactions. That is more grounded than assigning a fixed share to every touch, but it is still an estimate of allocated credit. It is not causal proof or a universal ranking of channels.

## How to implement multi-touch attribution

The software comes after the measurement design. Start with the questions the business needs to answer and make the path auditable.

### 1. Define the conversion and the decision

Choose one primary outcome for the first implementation. For most ecommerce teams, that is a completed purchase with order ID, revenue, currency, and item-level details. You may also track subscription starts, lead submissions, or checkout starts, but keep those events separate from purchase reporting.

Write down the decision the report should support. Examples include:

- Should discovery content receive more budget?
- Does a paid campaign create incremental demand or capture existing demand?
- Which product categories need more qualified traffic?
- Do assistant referrals reach products that convert or only pages that attract browsing?

The question determines the required touchpoints and the right level of detail.

### 2. Map identities, events, and product relationships

Create a data map before selecting a model. At minimum, define how these fields connect:

- user or consented customer identifier, where permitted;
- session and event timestamps;
- source, medium, campaign, content, and landing page;
- referrer or referring application when available;
- order ID, revenue, currency, refunds, and discounts;
- product ID, variant ID, SKU, quantity, and item revenue.

Do not treat an order ID as a user identity. An order can join the conversion to the transaction, while a consented user or session key joins eligible interactions to that transaction. Cross-device and anonymous paths will remain incomplete when the required signal is unavailable.

### 3. Instrument the touchpoints you control

Use consistent campaign parameters for email, SMS, affiliate, influencer, QR, PDF, and partner links. Preserve those parameters through redirects. Keep naming conventions stable, and prevent internal links from overwriting the original campaign source.

For events, capture the page type and the product or variant involved. A product-page visit tells a different story from a blog visit, even when both came from the same source. Exclude or clean payment gateways, authentication providers, checkout return URLs, and self-referrals before assigning revenue to a channel.

Known AI assistant referrals deserve their own channel rule when the source is visible. ChatGPT, Perplexity, Gemini, Claude, and Copilot can appear as referrals or as a recognized AI Assistant channel depending on how the click arrives. Their visible sessions are useful evidence, not a complete count of AI-assisted demand.

### 4. Set eligible channels and the lookback window

A 30-day window can make sense for a fast-moving product. A considered purchase may need 60 or 90 days. Use the actual decision cycle, then keep the window stable while comparing periods. If you change it, annotate the report because the eligible path has changed.

In GA4, the key event lookback window determines how far back a touch can receive credit. Current settings allow different windows for acquisition key events and other key events. [Google's settings reference](https://support.google.com/analytics/answer/10597962?hl=en) documents the available options and the fact that the window applies across attribution models.

### 5. Start with a simple baseline model

Use linear attribution as a transparent baseline when the team has no evidence for a weighting scheme. Compare it with last-touch and, where available, data-driven output. A large change between models is a finding. It shows that the budget decision depends on an assumption about where value sits in the journey.

Do not switch models every week to produce a favorable channel ranking. Keep a primary model for operating decisions and use alternatives as sensitivity checks.

### 6. Reconcile before interpreting

Compare the attribution dataset with the source of truth for orders and revenue. Check:

- purchase counts by day and order ID;
- total revenue, currency, tax, shipping, discounts, and refunds;
- duplicate events and missing transactions;
- item IDs and variants in ecommerce events;
- consent rates and known identity gaps;
- checkout, payment, and cross-domain referrals;
- campaign tags, referrer coverage, and Direct growth;
- changes to the site, consent banner, feed, or analytics implementation.

If the report cannot reconcile to orders, fix the data before debating the model. A sophisticated allocation over broken inputs only makes the error harder to see.

### 7. Report allocation with coverage and confidence

Report allocated conversions or revenue with the model name, lookback window, eligible channels, and observable-path coverage. Call the result “allocated revenue” or “influenced revenue.” Reserve “caused” for an experiment or another design that can estimate incremental impact.

At product level, include item ID, variant, landing page, channel, and outcome. This makes it possible to see whether a channel is sending shoppers to the right products, rather than only whether it sent sessions to the domain.

## How to measure AI-assisted discovery without false precision

AI-assisted shopping adds a source problem to an existing attribution problem. A shopper can ask an assistant to compare products, click a recommendation, and arrive on a product detail page. An app, webview, copied link, privacy setting, or redirect may remove the referrer. GA4 then has no way to reconstruct the missing source after the fact.

Catalog's guide to [referral traffic in Google Analytics](https://www.getcatalog.ai/blog/referral-traffic-google-analytics) explains the practical split:

- **Visible AI referrals:** A detectable source or recognized AI Assistant channel. These are the measurable floor.
- **Unknown-source or Direct sessions:** A mixed bucket that includes typed URLs, bookmarks, untagged campaigns, private apps, copied links, and some assistant clicks.
- **Likely assistant-influenced Direct:** A test segment based on landing page, new-user behavior, engagement, timing, and supporting visibility evidence. It is an estimate, not a source label.

Do not label every Direct product-page session as AI traffic. Start with a baseline and investigate a narrow segment, such as new users whose first session lands on a product, category, comparison, or buying-guide page, excludes account and support pages, and includes meaningful engagement or a purchase. Then cross-check against:

- known AI referrals in the same period;
- product and prompt visibility in answer engines;
- branded and product-name searches;
- paid, email, affiliate, influencer, and SMS calendars;
- product launches, promotions, PR, and marketplace activity;
- device and browser patterns;
- server logs when they preserve referrer information.

Catalog's guide to [dark traffic in agentic commerce](https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic) recommends reporting a range rather than a single invented number. Use three layers:

| Layer | What to report | What it means |
| --- | --- | --- |
| Known AI floor | Visible AI sessions, purchases, and revenue | Confirmed by the source data that reached analytics |
| Likely dark estimate | Direct product-page activity above a tested baseline | A defensible hypothesis after competing explanations are removed |
| Influence signals | Visibility, citations, branded search, and product-level movement | Evidence that may align with AI discovery without identifying a click |

In an MTA report, include only observed AI touchpoints in the path. Keep likely hidden influence as a separate estimate or diagnostic layer. Folding the estimate into allocated revenue without labeling it turns uncertainty into fake precision.

## Why product-data quality changes attribution quality

Attribution follows identity. If the same product appears as three URLs, two variant IDs, and a stale feed record, the journey and the outcome can split across records. If an assistant links to a non-canonical page or an unavailable variant, a visible referral may still produce a poor commerce outcome.

Use a product-data layer that keeps the following facts aligned across the product page, feeds, analytics events, marketplaces, and AI shopping surfaces:

| Product-data requirement | Discovery role | Measurement role |
| --- | --- | --- |
| Stable product and variant IDs | Lets systems recognize the item and its sellable versions | Joins page events, item events, orders, and revenue |
| Canonical product URL | Gives assistants and shoppers one reliable destination | Groups landing pages and avoids splitting one product across URLs |
| Clear parent-child variant relationships | Helps match size, color, pack, and configuration requests | Prevents product and variant revenue from being mixed |
| Current price, currency, and availability | Keeps recommendations commercially valid | Adds context when traffic converts, abandons, or returns |
| Consistent taxonomy and attributes | Makes products comparable by use case and constraints | Enables channel and category cuts that mean the same thing over time |
| Provenance and update state | Gives systems confidence that facts are current | Helps explain changes in recommendations and conversion rates |

Catalog is the product data layer for AI commerce. It helps brands structure product data, keep facts current, and publish machine-readable product objects to AI shopping surfaces without replacing the existing storefront. Catalog is not an attribution platform and does not assign fractional conversion credit. Your analytics stack or warehouse still owns touchpoint collection, model logic, and revenue reporting.

The connection is operational. Better product identity makes the downstream path easier to read. Better price, availability, variant, and attribute data helps assistants recommend the right offer. [AI visibility for ecommerce](https://www.getcatalog.ai/blog/ai-visibility-ecommerce) and Catalog's guide to [trusted data sources](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce) cover the discovery side. MTA shows what can be learned after a shopper reaches the site.

## What multi-touch attribution cannot tell you

MTA is useful when its limits are visible. Plan for these failure modes:

### Missing touchpoints

Ad impressions, private-app clicks, offline conversations, untagged links, and assistant interactions may never enter the path. A model cannot allocate credit to a signal it did not receive.

### Identity and consent gaps

Cookie restrictions, consent choices, browser privacy controls, and device changes break or limit journey stitching. Do not use fingerprinting or other methods that violate a user's privacy to make the path look complete.

### Correlation mistaken for causation

People who see an ad or visit a product page may already be more likely to buy. A model can assign that interaction credit because it appears on converting paths. It cannot isolate the incremental effect without a suitable control or experiment.

### Modeled events and delayed updates

Google Analytics can model key events that are not directly observable because of privacy or technical limits. [Google's documentation on modeled key events](https://support.google.com/analytics/answer/10710245?hl=en) explains that modeled data is estimated from patterns between observed and unobserved events, and that reports can be updated after a conversion. Treat modeled and observed numbers as different evidence layers when the distinction is available.

### Platform-specific views

Ad platforms often use different conversion windows, eligibility rules, and identity graphs. Their totals will not necessarily match your analytics property or order system. Reconcile definitions before comparing numbers.

### Product and revenue changes after the click

Price changes, stockouts, shipping promises, returns, promotions, and substitutions can change an order after the original discovery touch. A channel may send qualified demand to a product that could not be purchased. Include product state and item-level outcomes in the analysis.

When causal evidence matters, pair MTA with incrementality tests, holdouts, or marketing mix modeling. Use MTA to organize the observed path and experiments to test what changes when exposure changes.

## Multi-touch attribution FAQ

### What is multi-touch attribution in simple terms?

It is a method for splitting conversion credit across the eligible interactions that preceded a conversion. The model, lookback window, identity rules, and available data determine the split.

### What is the difference between last-touch and multi-touch attribution?

Last-touch gives all eligible credit to the final touch before a conversion. Multi-touch allocates credit across several touches. Last-touch is easier to operate. MTA gives more visibility into the path, but its answer depends on what the system can observe and the weighting or algorithm it uses.

### Which multi-touch model should an ecommerce team use?

Start with a transparent baseline, usually linear, then compare it with last-touch and a data-driven model when you have sufficient clean journey data. A short purchase cycle may not need a complex model. A long cycle may benefit from time-decay or a custom rule, provided the weights match a documented business question and are tested against outcomes.

### Does GA4 have a multi-touch attribution model?

GA4 currently offers data-driven attribution and last-click variants for its paid and organic channel reporting. Google removed first-click, linear, time-decay, and position-based models from its attribution reports in November 2023. You can still implement those approaches in a warehouse or another analytics system when their assumptions suit your question.

### Can multi-touch attribution prove that ChatGPT caused a sale?

No. A visible ChatGPT referral can document an observed touch. An MTA model can allocate part of an order to that touch. It cannot prove that the referral caused the purchase, and it cannot see assistant influence when the referrer is missing. Use experiments or incrementality methods for causal claims.

### Does better product data improve multi-touch attribution?

It improves the inputs that make commerce journeys interpretable. Stable IDs, canonical URLs, clear variants, current offers, and consistent taxonomy make it easier to connect AI discovery, product-page behavior, item events, and orders. Product data does not replace an attribution model.

Multi-touch attribution is most useful when it is treated as a measurement system rather than a verdict. Define the conversion, document the path you can observe, make product identity consistent, report ranges for missing AI influence, and use experiments when the business needs causal evidence. If the weak link is the product-data layer behind AI discovery, [talk to Catalog](https://www.getcatalog.ai/) about making those records structured, current, and machine-readable.

---

Canonical: https://www.getcatalog.ai/blog/multi-touch-attribution
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product feed management now has two jobs

*August 19, 2026 · Catalog Team · Product Data · 15 min read*

> Learn how product feed management works, which fields matter, how feeds differ by channel, and when to use feed tools or an AI product data layer.

Product feed management used to mean getting clean product data into Google Shopping, Meta, affiliates, and marketplaces. That work still matters. The new pressure is AI shopping. Product data now has to satisfy channel rules and give AI systems enough structured context to understand, compare, and recommend products. We see feed management moving from file formatting into live product data operations.

## What product feed management means

Product feed management is the work of collecting product data, turning it into a structured feed, adapting it for each destination, and keeping it accurate as products change.

A product feed is usually a CSV, TSV, XML, JSON, or API-based data source. Each row or object represents a product or variant. Each column or field describes a product fact, such as title, brand, price, availability, category, image, size, color, GTIN, shipping, or return policy.

Good feed management does five jobs:

1. **Collects** product data from the ecommerce platform, PIM, ERP, DAM, supplier files, and product pages.
2. **Normalizes** names, categories, attributes, units, variants, and identifiers.
3. **Maps** the normalized record to each channel's required fields.
4. **Optimizes** fields that affect discovery, matching, ad performance, and recommendations.
5. **Syncs** changes so price, stock, and product status stay current.

That last step is where many feeds fail. A valid file that goes stale creates disapprovals, wasted ad spend, bad recommendations, and broken shopper trust.

The center of the workflow is no longer the export file. It is the normalized product record. Once that record is clean, a feed becomes one output among many: Google Merchant Center, Meta catalogs, marketplaces, affiliate networks, your onsite search index, structured data, and AI shopping surfaces.

## The old job was channel compliance. The new job adds product context

Traditional feed management answers a narrow question: does this channel accept the feed?

That means the feed has the right format, field names, values, image URLs, prices, and required identifiers. Google Merchant Center, for example, has a detailed [product data specification](https://support.google.com/merchants/answer/7052112) that governs how product data is formatted. Meta has its own [catalog feed fields](https://developers.facebook.com/documentation/ads-commerce/commerce-platform/catalog/fields). Each marketplace adds another layer of rules.

AI shopping adds a second question: does the feed help software understand why this product fits a shopper's request?

OpenAI now publishes [product feed documentation](https://developers.openai.com/commerce/specs/file-upload/products) for ChatGPT shopping. Its stable schema includes eligibility flags, core product fields, price, availability, target countries, and richer recommended data such as variants, reviews, Q&A, related products, return policy, and performance signals. It also supports a Google-compatible feed path for selected integrations, with core fields such as `id`, `title`, `description`, `link`, `image_link`, `availability`, `price`, and `brand` on every row in that path.

That changes the bar. A thin feed can satisfy a channel's required fields and still fail the AI shopping job. AI systems need product facts that map to natural-language buying constraints: fit, material, compatibility, use case, dimensions, ingredients, bundle contents, policy details, and proof.

## The fields that matter most

Every channel has its own schema. The same product-data layers show up again and again.

| Layer | Fields | Why it matters |
| --- | --- | --- |
| Identity | `id`, SKU, GTIN, MPN, brand, title, canonical URL | Lets channels identify the product and match it to the right offer |
| Description | description, category, product type, key attributes | Helps systems understand what the product is and when it fits |
| Media | main image, additional images, video, image quality | Drives approval, visual comparison, and shopper trust |
| Commercial state | price, sale price, currency, availability, inventory, expiration date | Prevents stale offers and mismatched price or stock claims |
| Variant logic | item group ID, color, size, material, pack size, bundle relationships | Keeps variants grouped without confusing separate products |
| Policy and fulfillment | shipping, returns, pickup, country, tax, restrictions | Helps channels display complete offers and avoid policy issues |
| Performance and proof | reviews, ratings, popularity, return rate, Q&A | Gives AI shopping and comparison surfaces more evidence |

Most feed problems start in weak source data. The export step only exposes them. If the PIM has inconsistent colors, missing GTINs, duplicate SKUs, poor variant grouping, and thin descriptions, a feed tool can remap fields. It cannot create a trustworthy product record without enrichment rules and validation.

## A simple product feed example

A minimal product feed row might look like this:

```csv
id,title,description,link,image_link,availability,price,brand,gtin,condition,google_product_category,color,size,item_group_id
JKT-001-NAVY-M,"Women's Waterproof Commuter Jacket - Navy - M","Waterproof recycled nylon commuter jacket with taped seams, packable hood, reflective trim, and relaxed fit.",https://example.com/products/waterproof-commuter-jacket,https://example.com/images/jkt-001-navy.jpg,in_stock,148.00 USD,Northline,00012345678905,new,"Apparel & Accessories > Clothing > Outerwear",Navy,M,JKT-001
```

That row does more than describe a jacket. It gives machines a stable product ID, variant grouping, commercial state, category context, and specific attributes. A buyer can ask for a waterproof commuter jacket for rainy weather, and software has concrete fields to match against.

A weak version of the same feed would use a title like `Jacket`, a generic description, no GTIN, no item group ID, no material, and inconsistent color names across variants. That feed may still upload. It will perform worse because the product is harder to match, compare, and trust.

## How feed management works in practice

A mature feed workflow has clear owners for source quality, transformation, delivery, and monitoring.

### 1. Define the source of truth

Start by deciding which system owns each type of product data.

Common sources include:

- ecommerce platform for live price, inventory, and product URLs;
- PIM or PXM for approved product content;
- ERP for inventory and fulfillment data;
- DAM for images and video;
- supplier files for specifications;
- reviews platform for ratings and Q&A;
- custom enrichment layer for AI-ready attributes.

The key is to avoid silent conflicts. If price lives in three systems, one feed will eventually publish the wrong value. If color comes from supplier files, Shopify option names, and merchandising spreadsheets, variants will drift.

### 2. Normalize before mapping

Normalization turns messy product data into predictable values.

Typical rules include:

- convert units into one system;
- standardize color, size, and material values;
- remove duplicate products;
- group variants under stable parent IDs;
- map internal categories to channel taxonomies;
- strip unsupported HTML from descriptions;
- validate image URLs;
- enforce accepted availability values.

This is the part many teams underbuild. They map messy fields directly into Google or Meta and then fix errors one by one. That works for a small catalog. It breaks when every channel needs a slightly different version of the same product truth.

### 3. Map to each channel

A channel map translates the normalized record into the destination schema.

Google may need `image_link`. Meta and marketplace catalogs bring their own field names, value rules, and required formats. One marketplace may require bullet points. Another may reject values over a character limit. AI shopping feeds may require richer variant, eligibility, geography, or review fields.

Treat one channel's feed as an output, not the master record. A Google-compatible feed is useful, and OpenAI supports one compatibility path for certain registered feeds. The master should be your own product data model.

### 4. Enrich the attributes that drive matching

Feed optimization often gets reduced to better titles. Titles matter. The deeper advantage is attribute coverage.

For apparel, that might mean fit, material, closure, weather use case, inseam, rise, care instructions, and occasion. For furniture, it might mean dimensions, weight, material, assembly, room, style, and finish. For electronics, it might mean compatibility, ports, power, warranty, included components, and certification.

Those fields let product feeds answer real shopping prompts:

- “waterproof jacket for bike commuting”
- “oak dining table for a small apartment”
- “USB-C monitor compatible with MacBook Pro”
- “fragrance-free moisturizer for sensitive skin”

A feed with only title, description, price, and image gives AI systems less to work with. A feed with structured, category-specific attributes gives the product a clearer shape.

### 5. Sync and monitor changes

Feed management is live operations. Products launch, variants sell out, prices change, images are replaced, policies shift, and channel schemas evolve.

Set a sync cadence based on risk:

| Feed data | Suggested cadence | Reason |
| --- | --- | --- |
| Price and availability | Near real time or frequent scheduled updates | Prevents mismatches and bad offers |
| Product content and attributes | Scheduled daily or after approval workflow | Keeps discovery data current without bypassing review |
| Images | After DAM approval and URL validation | Avoids broken or low-quality media |
| Category mappings | On taxonomy change or new-category launch | Prevents wrong placement and disapprovals |
| AI shopping attributes | After enrichment and quality scoring | Keeps recommendations tied to trustworthy facts |

The operational goal is simple: shoppers should only see offers your site can honor.

## Product feed management software, PIMs, and product data layers

These tools overlap. They solve different problems.

| System | Primary job | Best fit | Limitation |
| --- | --- | --- | --- |
| Feed management software | Transform and syndicate product feeds to channels | Google Shopping, Meta, marketplaces, affiliates, retail media | Depends on source data quality |
| PIM or PXM | Govern product content across teams | Product copy, approvals, localization, channel content | Can still hold thin or inconsistent data |
| ERP | Manage inventory, finance, fulfillment | Stock, cost, warehouse, order data | Usually too operational for discovery |
| DAM | Manage media assets | Images, videos, rights, creative workflows | Leaves product attributes to another system |
| AI product data layer | Create live, machine-readable product records for AI commerce | AI shopping visibility, structured product context, recommendation readiness | Works best when connected to existing systems of record |

Feed tools are the right choice when your source data is already strong and the main job is channel mapping. Productsup, Feedonomics, Channable, DataFeedWatch, GoDataFeed, Lengow, and Rithum all sit in that traditional feed-management category, with different mixes of managed service, rules, marketplace support, and enterprise workflow.

Our view is that AI commerce needs another layer. We built Catalog for the product-data problem underneath AI shopping: live, normalized, machine-readable product records that can be understood by systems like ChatGPT, Gemini, Claude, Perplexity, and future shopping agents. That complements feed management. It gives AI surfaces richer product facts than a thin channel feed or human-facing PDP can provide by itself.

## Product feed management for AI shopping

AI shopping changes feed management in four ways.

First, **natural-language matching becomes the product of the feed**. A shopping assistant interprets constraints instead of only matching exact terms. “Best travel stroller for a tall parent” asks for product type, use case, dimensions, handlebar height, reviews, portability, and price range.

Second, **third-party context matters**. OpenAI's [shopping help page](https://help.openai.com/en/articles/11128490-shopping-with-chatgpt-search) says merchant listings can use merchant and product metadata from third-party providers or directly from merchants. Your own feed is one input in a broader product understanding system. If reviews, retailer listings, and product pages disagree, confidence falls.

Third, **freshness becomes more visible**. OpenAI notes on the same page that price and shipping updates may have some delay before they appear in ChatGPT shopping. That makes feed freshness and consistent source data even more important. If your feed, site, and merchant integrations disagree, the assistant has to reconcile conflicting facts.

Fourth, **richer fields become useful, not decorative**. Q&A, reviews, related products, return policy, region, variants, and category-specific attributes help an AI system answer comparison questions. They also help it avoid choosing the wrong SKU when a shopper asks for a bundle, refill, accessory, or substitute.

For most brands, AI feed management starts with the same foundation as Google and Meta: stable IDs, accurate product URLs, images, price, availability, brand, title, and description. The difference is what comes next. AI-ready feeds need product facts that explain fit, usage, constraints, and trust.

## Common product feed management mistakes

### Treating the feed as the source of truth

The feed should reflect the product record. Fixes should live upstream whenever possible. When feed rules pile up without source cleanup, the system becomes brittle. One channel looks right. Another stays broken.

### Optimizing titles before fixing missing attributes

Title rules can improve performance. They cannot replace missing product facts. If a mattress feed lacks firmness, size, materials, certifications, and trial policy, a cleaner title only solves a small part of the problem.

### Ignoring variants

Variants should be grouped clearly and separated only when they are truly different products. Weak variant logic causes duplicated listings, wrong images, incorrect sizes, and confused recommendations.

### Letting price and availability drift

Price and stock mismatches are among the fastest ways to lose channel trust. They also create a poor AI shopping experience. Feed updates need to move as fast as the commercial state changes.

### Using one generic schema for every category

A generic feed can meet basic requirements. It rarely wins on matching. Each category has its own decision-making attributes. The feed model should reflect that.

### Measuring upload success instead of product usefulness

A successful upload only proves that a channel processed the file. It does not prove product completeness, competitiveness, eligibility, or AI recommendation readiness. Track error rate, field coverage, variant quality, stale-offer rate, and visibility by product group.

## A practical feed-quality scorecard

Use a scorecard before adding another channel. It keeps the work focused on product truth instead of export volume.

| Question | Strong answer |
| --- | --- |
| Are IDs stable across systems? | SKU, product ID, item group ID, and canonical URL stay consistent over time |
| Are required fields complete? | Every active product has title, description, URL, image, price, availability, brand, and identifiers where available |
| Are variants clear? | Parent-child relationships, sizes, colors, bundles, and packs are explicit |
| Are category attributes filled? | Each category has the fields shoppers use to narrow choices |
| Are commercial fields fresh? | Price, stock, sale dates, shipping, and returns sync at the right cadence |
| Are images usable? | URLs resolve, images match the variant, and quality meets channel requirements |
| Are channel errors monitored? | Disapprovals, warnings, and rejected rows feed back into upstream fixes |
| Is the feed AI-ready? | Product records answer natural-language questions without relying on vague copy |

A feed that passes this scorecard is easier to syndicate, easier to optimize, and easier for AI shopping systems to reason over.

## When to use Catalog

Use a traditional feed management platform when your main need is channel syndication: building Google, Meta, affiliate, or marketplace feeds from data you already trust.

Use Catalog when the deeper problem is product understanding for AI commerce.

That usually means:

- your products need richer structured attributes than the storefront exposes;
- your PDPs read well to humans and stay thin for machines;
- variants, bundles, sizes, or product relationships are hard for AI systems to parse;
- you want AI shopping surfaces to understand products by use case, constraints, and proof;
- you need a live product data layer that sits beside the existing storefront without rebuilding it.

We are focused on the part that will matter more as shopping shifts into AI interfaces: turning product catalogs into live, normalized product data that machines can trust.

If you want to see how your catalog reads to AI systems, [run a Catalog audit](https://www.getcatalog.ai/audit).

## FAQ

### What is product feed management?

Product feed management is the process of collecting, normalizing, optimizing, syndicating, and syncing product data across sales, advertising, marketplace, and AI shopping channels.

### What is the difference between a product feed and a product catalog?

A product catalog is the broader set of products and product information a business owns. A product feed is a structured export or data source built from that catalog for a specific destination. A single catalog can produce many feeds.

### What is the difference between product feed management and product data syndication?

Product feed management includes the upstream work of cleaning, mapping, optimizing, and monitoring feed data. [Product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) is the distribution step, sending product data to channels in the format they require.

### How often should product feeds update?

Price and availability should update as often as they change. For fast-moving catalogs, that means near real time or frequent scheduled updates. Product content can usually follow an approval workflow, then publish on a daily or event-based cadence.

### Do AI shopping systems use product feeds?

Yes. OpenAI publishes product feed documentation for ChatGPT shopping. AI systems may also use product pages, structured metadata, third-party providers, reviews, and other public product context.

### Does a Google Shopping feed make products AI-ready?

It is a useful starting point. A Google-compatible feed covers many core fields. AI shopping needs richer product context: variants, use cases, category-specific attributes, reviews, Q&A, policies, and related-product relationships.

---

Canonical: https://www.getcatalog.ai/blog/product-feed-management
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# What is a SKU? Meaning, examples, and how to create one

*August 18, 2026 · Catalog Team · Product Data · 15 min read*

> Learn what a SKU is, see real SKU examples, compare SKU vs UPC and barcode, and build a SKU system that works for ecommerce and AI shopping.

A SKU looks like a simple product code. In practice, it becomes one of the main ways a business counts stock, separates variants, connects sales channels, and gives software a stable handle for each sellable item. A good SKU system keeps inventory work clean today and makes product data easier for search, feeds, and AI shopping systems to read tomorrow.

## What is a SKU?

SKU stands for stock keeping unit. A SKU is a unique internal code a business assigns to a product or product variant so it can track, sell, replenish, pick, pack, report on, and publish that item.

The word is usually pronounced "skew," though some teams say the letters S-K-U. People also say "SKU number," even when the code includes letters.

A SKU is internal to your business. Two retailers can sell the same water bottle and give it different SKUs. A UPC or GTIN, by contrast, is meant to identify the trade item across companies through a standards system such as GS1's [GTIN standard](https://www.gs1.org/standards/id-keys/gtin).

The most important rule is granularity. If a variant is stocked, priced, picked, shipped, returned, or reported separately, it usually needs its own SKU.

| Product | Variant | Example SKU |
| --- | --- | --- |
| Cotton crewneck T-shirt | Black, medium | TEE-CRW-BLK-M |
| Cotton crewneck T-shirt | Black, large | TEE-CRW-BLK-L |
| Cotton crewneck T-shirt | White, medium | TEE-CRW-WHT-M |
| Ceramic table lamp | Blue, US plug | LMP-CER-BLU-US |
| Ceramic table lamp | Blue, EU plug | LMP-CER-BLU-EU |

That separation matters because the black medium T-shirt and black large T-shirt can have different stock levels, return rates, reorder points, and demand patterns.

## What a SKU does

A SKU gives teams and systems a shared product identity. The code may appear on shelf labels, pick lists, packing slips, point-of-sale systems, ecommerce platforms, product feeds, analytics reports, and internal databases.

| Job | How the SKU helps |
| --- | --- |
| Inventory tracking | Counts stock by exact item or variant |
| Replenishment | Shows which item needs to be reordered |
| Fulfillment | Helps warehouse teams pick and pack the right product |
| Sales reporting | Separates demand by color, size, pack, region, or model |
| Returns | Connects returned units to the right variant and reason codes |
| Channel publishing | Maps one product record into marketplaces, feeds, and ads |
| Product data quality | Gives each record a stable key for enrichment, validation, and syncing |

We treat SKU as one identity field inside a larger product data layer. The SKU is useful. It cannot carry the whole truth about a product. The complete record also needs brand, title, GTIN, MPN, variant relationships, price, availability, attributes, images, policies, and provenance.

That wider context is what helps a product show up correctly in product feeds, structured data, search results, recommendations, and AI shopping surfaces. Our work on [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) starts with stable identifiers, then adds the attributes and relationships machines need to understand what a product actually is.

## SKU example: how to read one

A useful SKU is short enough for people to work with and structured enough for systems to parse consistently.

Take this example:

**LMP-ARC-BR-110V**

| Segment | Meaning |
| --- | --- |
| LMP | Category: lamp |
| ARC | Product family or style: arc lamp |
| BR | Finish: brass |
| 110V | Electrical version: US voltage |

This SKU tells an operations team enough to recognize the item without opening the full record. It does not try to include every product fact. The product record should store the full title, material, dimensions, bulb type, price, availability, images, shipping class, and compatibility fields.

That distinction prevents a common mistake. A SKU should identify the item. It should not become a compressed product description.

## SKU vs UPC, barcode, GTIN, MPN, and serial number

SKU confusion usually comes from mixing internal identifiers, global identifiers, and scannable labels. They work together. They answer different questions.

| Term | What it means | Who controls it | Best use |
| --- | --- | --- | --- |
| SKU | Internal stock keeping unit for one product or variant | The seller, retailer, distributor, or brand | Inventory, fulfillment, reporting, internal product records |
| UPC | A common barcode identifier in North America, based on GTIN-12 | GS1 through licensed company prefixes | Retail scanning and cross-seller product identification |
| GTIN | Global Trade Item Number, the broader global identifier family | GS1 | Product matching across retailers, marketplaces, ads, and data partners |
| Barcode | A machine-scannable representation of a code | Depends on the code encoded | Fast scanning at checkout, warehouse, or receiving |
| MPN | Manufacturer part number | The manufacturer | Manufacturer-specific product or replacement part identification |
| Model number | A model, family, or design identifier | The manufacturer or brand | Grouping related items, especially electronics, appliances, parts, and equipment |
| Serial number | Unique identifier for one physical unit | The manufacturer, brand, or service system | Warranty, service, fraud prevention, repair, and traceability |
| Item group ID | A shared parent identifier for variants in some feeds | The merchant or platform | Grouping color, size, material, pack, or pattern variants |

Schema.org defines `sku` as a merchant-specific identifier in its [Product vocabulary](https://schema.org/Product). Google product structured data also supports product identifiers such as SKU, GTIN, MPN, and brand through its [Product documentation](https://developers.google.com/search/docs/appearance/structured-data/product). For merchant feeds, Google's [product data spec](https://support.google.com/merchants/answer/7052112?hl=en) separates an item's `id` from fields such as `gtin`, `mpn`, `brand`, and `item_group_id`.

The operating rule is simple. Use SKUs for your own product operations. Use GTINs or UPCs when a channel needs standardized product matching. Use serial numbers when you need to track one physical unit after it leaves inventory.

## How SKUs work with product variants

Variants are where SKU systems usually break.

A parent product is the product family shoppers understand, such as "cotton crewneck T-shirt." A variant is the exact option a shopper can buy, such as "black, medium." Ecommerce teams often need both:

- **Parent product ID:** groups related variants together.
- **Variant SKU:** identifies the exact item stocked and sold.
- **GTIN or UPC:** identifies the trade item when a global identifier exists.
- **Channel IDs:** map the same record into specific marketplaces, feeds, and ads platforms.

Google's [variant guidance](https://developers.google.com/search/docs/appearance/structured-data/product-variants) uses variant relationships so search systems can understand which offers belong together. The same logic applies inside a merchant's own catalog. If every size and color is treated as an unrelated standalone product, systems lose the relationship. If every variant shares one SKU, operations lose the difference.

For ecommerce, these cases need special care:

| Case | Recommended SKU treatment |
| --- | --- |
| Size or color variants | Give each stocked variant its own SKU and connect all variants to one parent product |
| Regional versions | Use separate SKUs when voltage, compliance, plug, language, packaging, or assortment differs |
| Multipacks | Use a separate SKU when the pack is sold, priced, picked, or replenished as a distinct item |
| Bundles and kits | Use a bundle SKU for the sellable bundle, while preserving the component SKUs underneath |
| Replacement parts | Use SKUs that map cleanly to MPNs, compatibility data, and fitment rules |
| Custom products | Use a base SKU plus structured configuration data, or generate a unique SKU for each build when operations require it |

Good variant structure makes product data more useful for people and machines. It helps warehouse teams ship the right unit, analytics teams read demand correctly, and AI shopping systems tell the difference between similar products.

## Where SKUs fit in a product data layer

A SKU is one field in the product identity layer. It should connect to every downstream system that needs to know which item it is dealing with.

A practical product data layer keeps the SKU beside the other identifiers, attributes, and channel IDs that describe the same item.

| Product data layer | What the SKU connects |
| --- | --- |
| Product record | Parent product, variant attributes, title, brand, images, price, and availability |
| Operations | ERP records, inventory counts, replenishment rules, pick lists, and returns |
| Commerce channels | Storefront pages, marketplaces, retail media, ads, and product feeds |
| Machine-readable data | Structured data, API objects, feed IDs, and AI shopping surfaces |

This is where many teams outgrow a simple spreadsheet. A SKU may be clean in the ecommerce platform, different in the ERP, missing from a marketplace export, and duplicated in an old feed. The result is product data drift. Inventory, pages, ads, feeds, analytics, and AI systems stop referring to the same item with the same facts.

We help brands solve that identity problem at the product data layer. We normalize product records, enrich missing attributes, resolve variants, and publish machine-readable data so the same product facts can support storefronts, [product feeds](https://www.getcatalog.ai/glossary/product-feed), [structured data](https://www.getcatalog.ai/glossary/structured-data), APIs, and AI shopping systems.

## How to create SKU numbers

A strong SKU system is documented before it is generated. Use these rules before creating codes in bulk.

### 1. Define what deserves its own SKU

Start with the operational question: what do you stock separately?

Create separate SKUs for items that differ in inventory, price, fulfillment, supplier, reorder logic, shipping rules, compliance, warranty, or returns handling. Do not create separate SKUs only because marketing copy changes.

### 2. Choose a short set of code segments

Most SKU systems use a few stable segments. Common choices include:

- category or department;
- product family or style;
- material, color, size, flavor, shade, scent, or finish;
- pack count or bundle type;
- region, voltage, language, or compliance version;
- supplier or collection when it is operationally useful.

Keep the structure short. A SKU such as **TEE-CRW-BLK-M** is easier to use than **APPAREL-TSHIRT-CREWNECK-COTTON-BLACK-MEDIUM-CORE-2026**.

### 3. Use controlled abbreviations

Create a code list for common values.

| Attribute | Better code examples | Avoid |
| --- | --- | --- |
| Color | BLK, WHT, NVY, GRN | B, DARKBLUE, GREENISH |
| Size | XS, S, M, L, XL | 1, 2, 3 if teams also use numeric size labels |
| Region | US, EU, UK, CA | INTL when region-specific rules matter |
| Pack | 1PK, 2PK, 6PK | MULTI if pack count affects inventory |
| Voltage | 110V, 220V | US if voltage and market can diverge |

Avoid characters that cause scanning, typing, or spreadsheet issues. Hyphens are easier to read than spaces. All caps are easier to scan. Avoid ambiguous pairs such as O and 0, I and 1, or S and 5 when teams read codes aloud.

### 4. Keep SKUs stable

A SKU should not change because the product goes on sale, moves to a new campaign, or gets a new homepage description. Price, stock status, season, and promotion belong in fields that can update without changing the identifier.

When a product is discontinued, retire the SKU. Do not reuse it for a new product. Reuse breaks reporting history and can cause returns, warranty claims, and marketplace records to point to the wrong item.

### 5. Separate the SKU from external identifiers

Do not rely on UPCs, GTINs, or supplier part numbers as your only SKU system unless they match how you operate. You may sell a bundle made from multiple GTIN-bearing products. You may need separate regional SKUs for the same design. You may also sell private-label items where you control both internal and external identifiers.

A cleaner model stores all relevant identifiers together:

| Field | Example |
| --- | --- |
| Internal variant ID | var_482019 |
| SKU | LMP-ARC-BR-110V |
| GTIN | 00815587001234 |
| MPN | ARC-BR-110 |
| Parent product ID | LMP-ARC |
| Channel ID | google-us-482019 |

This gives every system the identifier it needs without forcing one code to do every job.

### 6. Document ownership

SKU rules fail when no one owns them. Document who creates SKUs, which system is the source of truth, which fields are encoded, which fields are separate attributes, how retired SKUs are handled, and how channel-specific aliases are mapped.

For a small catalog, that may be a one-page rulebook. For a large catalog, it should be part of product data governance and [product data quality](https://www.getcatalog.ai/blog/product-data-quality) workflows.

## SKU examples by product type

Different categories need different SKU patterns. The right structure reflects operational differences, not a universal template.

| Category | Example SKU | What the SKU captures |
| --- | --- | --- |
| Apparel | TEE-CRW-BLK-M | Product type, style, color, size |
| Footwear | SHOE-RUN-NVY-10M | Product type, style, color, size and width |
| Beauty | LIP-MAT-RSE-3ML | Product type, finish, shade, size |
| Furniture | CHR-OAK-NAT-SET2 | Product type, material, finish, pack |
| Lighting | LMP-ARC-BR-110V | Product type, style, finish, electrical version |
| Food | COF-BLD1-WB-12OZ | Product type, blend, grind or whole bean, size |
| Replacement parts | FLT-HVAC-M8-2PK | Part type, compatibility or model, pack |
| Bundle | KIT-BED-QN-WHT-4PC | Kit type, size, color, component count |

The best SKU is the shortest code that reliably separates the item for the way the business sells and operates.

## Common SKU mistakes

### Reusing a SKU after a product is retired

Reusing SKUs corrupts history. Old sales, returns, inventory counts, support tickets, and channel records can attach to the new product. Retire old SKUs and create new ones for new products.

### Encoding volatile facts

Do not put price, stock level, sale status, campaign name, or warehouse location into the SKU. Those facts change too often. Store them as separate fields.

### Using one SKU for multiple stocked variants

One SKU for every size or color may feel simpler. It hides stockouts and demand differences. If variants are stocked separately, they need separate SKUs.

### Treating the SKU as the only identifier

A SKU does not replace GTIN, MPN, parent product ID, serial number, channel ID, or internal database ID. Those identifiers answer different questions.

### Hiding product attributes inside the SKU only

A SKU such as **TEE-CRW-BLK-M** is useful because humans can read it. Search systems, filters, product feeds, and AI shopping systems still need color and size stored as structured attributes. Do not expect software to infer the whole product record from a code.

### Letting channels invent their own codes

Marketplaces, ads systems, retail partners, and fulfillment tools may create destination-specific IDs. Keep those aliases mapped to the canonical SKU and product record. Otherwise each channel becomes a separate product truth.

## SKU FAQ

### Is SKU the same as a barcode?

No. A SKU is the internal code. A barcode is a scannable representation of a code. A barcode can encode a SKU for internal warehouse use, or it can encode a UPC or GTIN for retail scanning.

### Is SKU the same as UPC?

No. A SKU is created by the merchant or business for internal use. A UPC is a standardized product identifier used in retail scanning and product matching. The same product can have one UPC and different SKUs at different retailers.

### How do I find the SKU of a product?

Look in the ecommerce platform, inventory system, POS, ERP, product feed, shelf label, pick list, packing slip, or product record. On consumer product packaging, the visible barcode is often a UPC or GTIN rather than the merchant's internal SKU.

### Can two products have the same SKU?

Inside one business, no. A SKU should identify one sellable product or variant. Across different businesses, yes. SKUs are internal, so two sellers can use the same code for different products.

### How long should a SKU be?

Most teams do best with short SKUs that are easy to read, type, scan, and print. A practical range is often 8 to 16 characters excluding separators. Clarity matters more than a fixed length.

### Should SKUs be visible to customers?

They can be, especially for B2B, replacement parts, wholesale, support, and reordering use cases. Consumer brands may hide SKUs from the main product page while still using them in structured data, feeds, support systems, and packing workflows.

### Do digital products need SKUs?

They can. A digital product, subscription, license, plan, or service package may need an internal product code for pricing, billing, reporting, fulfillment, entitlement, or support. It may not need physical inventory logic. It still benefits from clear product identity.

A SKU problem is often a product data problem. If your products, variants, feeds, and AI shopping surfaces need one source of truth, [book a demo](https://calendly.com/d/cvr8-2zy-txt/catalog-discovery-call?utm_source=getcatalog.ai&utm_medium=website&utm_campaign=blog&utm_content=what_is_a_sku) to see how we structure, enrich, and publish product data for AI commerce.

---

Canonical: https://www.getcatalog.ai/blog/what-is-a-sku
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Omnichannel vs. multichannel: what changes for product data

*August 13, 2026 · Catalog Team · Product Data · 11 min*

> Compare omnichannel vs. multichannel commerce, the operational tradeoffs, and what each model needs from product feeds, inventory, and structured data.

Omnichannel vs. multichannel is not really a debate about how many places a brand sells. Both strategies use more than one channel. The difference is whether those channels operate separately or share the data needed to create one continuous product and customer experience.

Multichannel commerce means your products appear across several independent channels, such as an owned storefront, Amazon, Google Shopping, retail partners, email, SMS, and social commerce. Each channel can have its own goals, data requirements, campaigns, and reporting.

Omnichannel commerce means those channels are connected. The same product, price, inventory, variant, policy, order, and customer context can move across channels so the shopper does not experience each touchpoint as a restart.

For merchants, the difference shows up in the product-data layer. A multichannel setup can work with clean channel exports and disciplined manual operations. An omnichannel setup needs synchronized product data, inventory, pricing, policies, fulfillment rules, and machine-readable product facts that stay current wherever products are discovered, compared, recommended, and bought.

That matters because inconsistent product information is not a small content problem. In Salsify's 2025 consumer research, [54% of surveyed shoppers said they abandoned an online sale because product information was inconsistent across websites](https://www.salsify.com/hubfs/2025/Salsify%202025%20Consumer%20Research%20Report.pdf). Omnichannel only works when the product story stays consistent across every surface that uses it.

## Omnichannel vs. multichannel at a glance

| Factor | Multichannel | Omnichannel |
| --- | --- | --- |
| Main goal | Reach customers in more places | Make every touchpoint work as one connected journey |
| Channel setup | Channels operate independently | Channels share data and context |
| Customer experience | A shopper may need to restart on each channel | A shopper can move across channels without losing context |
| Product-data pattern | Product data is exported, adapted, and managed by channel | Product data is synchronized from a trusted layer into every destination |
| Team model | Channel teams optimize their own performance | Channel, product, merchandising, operations, and data teams align around one customer and product view |
| Best fit | Testing new channels, early expansion, simpler catalogs, limited resources | Mature commerce operations, store plus ecommerce workflows, marketplace scale, personalization, AI shopping readiness |
| Main risk | Data drift, repeated manual work, inconsistent product information | Integration cost, governance complexity, sync failures, inventory and fulfillment pressure |
| Catalog angle | Clean product feeds and channel mappings reduce avoidable errors | A product data layer keeps product facts ready for storefronts, marketplaces, search, retail media, and AI commerce |

The short version: multichannel is about presence. Omnichannel is about continuity.

## What is multichannel commerce?

Multichannel commerce is the practice of selling, marketing, or distributing products through more than one [distribution channel](https://www.getcatalog.ai/glossary/distribution-channel). A merchant might sell on its own ecommerce site, list selected products on [third-party marketplaces](https://www.getcatalog.ai/blog/third-party-marketplace), send products to Google Merchant Center, run Meta catalog ads, and maintain wholesale retailer pages.

In a multichannel model, each channel can still be valuable even if it is managed separately. The Amazon team can optimize Amazon listings. The paid media team can optimize Google Shopping. The ecommerce team can optimize the owned product detail page (PDP). The social team can test catalog ads. Each channel has its own playbook.

That independence is the benefit and the risk.

The benefit is speed. A merchant can launch a channel without rebuilding the whole operating model. It can test whether a marketplace, ad surface, or retail partner drives incremental demand before investing in deeper integration.

The risk is drift. A price is updated on the website but not in the feed. A variant relationship is fixed in the PIM but not on a marketplace. A new image is approved for the owned storefront but not distributed to retailer partners. A product is out of stock in one system but still appears available somewhere else.

Multichannel works best when the product data layer gives every channel a clean starting point:

- approved product titles, descriptions, images, and attributes;
- normalized identifiers such as SKU, GTIN, brand, MPN, parent IDs, and variant IDs;
- channel-specific category and attribute mappings;
- a clear [product feed](https://www.getcatalog.ai/glossary/product-feed) or API output for each destination;
- validation rules that catch missing fields, invalid values, and stale price or availability before they reach shoppers.

A product feed can support multichannel execution, but it should not become the source of truth. It is a channel-ready output. The deeper product record needs to live somewhere teams can govern, enrich, validate, and reuse.

## What is omnichannel commerce?

Omnichannel commerce connects multiple channels into one coordinated experience. The channels still exist, but they are not treated as separate worlds. Product data, customer context, inventory, pricing, orders, returns, and fulfillment rules can travel across them.

A simple example: a shopper discovers a jacket through a social ad, checks available sizes on the brand's site, sees that the medium is available at a nearby store, saves it to a cart, receives a reminder with the same variant, buys online for store pickup, and later starts a return through customer support. In an omnichannel model, those steps are connected. The shopper, the product, the store inventory, the order, and the policy data all refer to the same underlying truth.

All omnichannel commerce is multichannel, because it uses multiple channels. Not all multichannel commerce is omnichannel, because the channels may not share context.

For product teams, omnichannel needs more than an exported catalog. It needs a product record that can support many downstream uses at once:

- the owned product page;
- marketplaces and retailer portals;
- Google Merchant Center and other shopping feeds;
- social commerce catalogs;
- store inventory and pickup workflows;
- product recommendations and onsite search;
- [structured data](https://www.getcatalog.ai/glossary/structured-data) for search engines;
- AI shopping assistants and other machine-facing discovery surfaces.

That means omnichannel is not only a marketing strategy. It is a data and operations strategy.

## The real difference for merchants: reach vs. continuity

Multichannel asks, "Where else can we sell or promote this product?"

Omnichannel asks, "How do we keep the product experience consistent when shoppers, teams, and systems move across those places?"

A merchant can be multichannel if it sells a backpack on its website, Amazon, Google Shopping, and Instagram. It becomes omnichannel only when those channels share enough data to prevent conflicting experiences.

Consider one inventory change. If the navy backpack sells out in size medium, that fact may need to update:

- the product detail page;
- the marketplace listing;
- the Google Merchant Center feed;
- local inventory surfaces;
- paid shopping campaigns;
- product recommendation systems;
- support tooling;
- AI shopping data exposed to assistants and answer engines.

If those updates happen independently, the business is multichannel. If those updates are coordinated from a trusted data layer with defined sync rules, the business is closer to omnichannel.

This is why channel expansion often exposes product data problems. Each new channel adds a new schema, taxonomy, policy, error queue, reporting view, and freshness expectation. Without a shared product data layer, every channel becomes a separate cleanup project.

## What each model requires from the product data layer

The product-data requirements are different because the operating goals are different.

### What multichannel requires

A strong multichannel setup needs a reliable product record and controlled outputs for each destination. The goal is not necessarily to make every channel share context in real time. The goal is to avoid preventable channel errors and keep each destination accurate enough to perform.

At minimum, multichannel needs:

1. **A trusted product record.** Teams need one approved version of each product's identity, attributes, copy, media, price logic, variant structure, and policy fields.
2. **Channel mappings.** Each destination has different field names, taxonomies, image rules, title limits, identifiers, and required values.
3. **Feed or API outputs.** Each channel needs a reliable way to receive product data in the right format.
4. **Validation before syndication.** Missing GTINs, invalid categories, broken image links, blank attributes, and unsupported values should be caught before export.
5. **Freshness rules.** Fast-moving fields such as price, sale price, availability, inventory, and shipping promises need more frequent updates than slow-moving product descriptions.
6. **Channel error monitoring.** Every destination will reject or warn on different issues. The product data workflow needs a way to route those errors back to the source record.

Catalog's guide to [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) covers this workflow in more depth. The important point here is that multichannel product data is already more than a spreadsheet upload. It is distribution plus translation.

### What omnichannel requires

Omnichannel requires everything multichannel requires, plus shared context across channels.

The product-data layer needs to support:

1. **Normalized product objects.** Product identities, variants, bundles, categories, specifications, media, and policy fields should be represented consistently enough for different systems to reuse.
2. **Persistent identifiers.** SKU, GTIN, MPN, brand, parent IDs, variant IDs, and channel IDs must connect the same product across systems.
3. **High-frequency price and availability sync.** Google Merchant Center says accurate and up-to-date product data matters because mismatched price or availability can cause product disapprovals or inaccurate displays. [Google's high-quality data guidance](https://support.google.com/merchants/answer/188489?hl=en) is a concrete reminder that freshness is an operational requirement, not a nice-to-have.
4. **Location-level inventory.** Store pickup, local inventory ads, and regional availability require more granular data than a simple in-stock or out-of-stock flag. Google's [local inventory specification](https://support.google.com/merchants/answer/14819809?hl=en) requires fields such as product ID, store code, and in-store availability.
5. **Structured outputs for machines.** [Merchant listing structured data](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing) can help Google understand price, availability, shipping, and returns. AI shopping systems also need product facts they can parse and compare, not only persuasive page copy.
6. **Customer, order, and fulfillment context.** Omnichannel depends on knowing what a shopper did, what they bought, where inventory sits, how returns work, and which channel should handle the next step.
7. **Governance.** Teams need clear ownership for fields, approval flows, sync timing, exceptions, and rollback paths.

This is where [product data quality](https://www.getcatalog.ai/blog/product-data-quality) becomes the foundation. A channel can only synchronize what it receives. If the source record is incomplete, inconsistent, or stale, omnichannel turns bad data into a faster-spreading problem.

## Operational tradeoffs

Omnichannel is often presented as the obvious upgrade, but the tradeoff is real. Multichannel and omnichannel solve different stages of maturity.

### Multichannel tradeoffs

Multichannel is easier to start because teams can launch one channel at a time. It is useful when a merchant is testing new demand, entering a marketplace, or proving that a product category has traction outside the owned storefront.

The cost shows up later:

- the same product fields are cleaned repeatedly by different teams;
- channel-specific fixes never make it back to the source record;
- shoppers see inconsistent prices, titles, availability, images, or policies;
- teams cannot see how channels influence one another;
- paid media, marketplace, and support teams spend time explaining issues that came from product data drift.

Multichannel can be a smart starting point. It becomes fragile when the channel count grows faster than the product data process.

### Omnichannel tradeoffs

Omnichannel can create a better customer experience, but it requires more integration and operational discipline.

The hard parts are not limited to software. Teams have to decide which system owns each field, how quickly each field updates, which exceptions block publishing, how store inventory is trusted, how channel errors are resolved, and how customer context is used without breaking privacy or compliance rules.

Fulfillment adds another layer. [McKinsey estimates](https://www.mckinsey.com/industries/retail/our-insights/retails-need-for-speed-unlocking-value-in-omnichannel-delivery) that omnichannel order fulfillment can cost roughly 10% to 20% of sales and notes that store inventory accuracy is often 70% to 90%, compared with more than 99.5% in distribution centers. Those numbers make the point clearly: omnichannel promises are only profitable when inventory, picking, fulfillment, and product data are accurate enough to support them.

The answer is not to avoid omnichannel. The answer is to build it in stages, with the data foundation first.

## Examples of synchronized product data improving execution across channels

Synchronized data is easiest to understand through the problems it prevents.

### Google Shopping and search listings

Google uses submitted product data to match products to relevant queries. Its [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) says incorrect, inaccurate, or missing information can cause disapprovals, limited eligibility, incorrect displays, or other issues.

A multichannel team might upload a feed and fix warnings in Merchant Center. An omnichannel team connects the underlying product, price, availability, shipping, returns, and structured data so the product page, feed, and search surfaces tell the same story.

The result is fewer avoidable feed errors, fewer stale prices, and cleaner eligibility for shopping and search experiences.

### Marketplaces

Marketplaces need product identifiers, category mappings, images, titles, variation structures, and policy fields that match their rules. Amazon, for example, [generally requires standardized product identifiers such as GTINs](https://sellercentral.amazon.com/gp/help/external/200317470) for most categories when creating new listings.

In a multichannel model, marketplace teams often patch those requirements inside the marketplace tool. In an omnichannel model, the source product record already knows the identifier, variant structure, category mapping, and required attributes. The channel output adapts the record, but the source remains governed.

That matters when products change. If a variant is discontinued or a pack count changes, the correction should not have to be rediscovered separately on every marketplace.

### Social commerce and retail media catalogs

Social commerce and retail media depend on structured catalogs. The channel needs product IDs, images, landing pages, availability, prices, categories, labels, and sometimes custom fields for campaigns or audiences.

A multichannel approach can run catalog ads from a feed. An omnichannel approach keeps that feed connected to the same product, inventory, and merchandising logic used elsewhere. That makes campaigns less likely to promote unavailable products, outdated prices, or poorly mapped variants.

### Store pickup and local inventory

Store pickup is a clean omnichannel example because it joins online discovery with store-level operations. A shopper does not care which system owns the product record or which inventory service feeds the store. They care whether the item is actually available where the site says it is.

That requires location-level inventory, product IDs that match across systems, store codes, update timing, and clear fulfillment rules. If those fields are weak, omnichannel creates disappointment instead of convenience.

### AI shopping assistants

AI shopping surfaces are becoming part of the channel mix because they can compare, recommend, and answer product questions before a shopper reaches a store or PDP. [Google's AI shopping experience](https://www.thinkwithgoogle.com/next/article/search-and-video/google-shopping-ai-mode-virtual-try-on-update/), for example, uses the Shopping Graph with more than 50 billion product listings and details such as prices, reviews, color options, and availability.

For merchants, that changes the product-data bar. A polished description is not enough. AI systems need machine-readable facts: what the product is, who it is for, how variants differ, whether it is available, how it compares, what policies apply, and which claims are supported.

Catalog's guide to [AI shopping assistants](https://www.getcatalog.ai/blog/ai-shopping-assistant-guide) goes deeper on that shift. In this comparison, the key point is simpler: AI commerce makes disconnected product data more visible. If a product is described one way on the PDP, another way in a feed, and not structured at all for AI systems, the channel experience will not feel omnichannel.

## How to choose between omnichannel and multichannel

Choose multichannel when you need reach before integration. That usually fits when:

- you are testing a new marketplace, ad channel, social catalog, or retailer relationship;
- your team has limited engineering or data operations capacity;
- the product catalog is small enough to manage with lighter governance;
- each channel has a distinct audience or goal;
- speed matters more than cross-channel continuity.

Move toward omnichannel when continuity becomes the constraint. That usually happens when:

- shoppers research, buy, return, and ask for support across different channels;
- stale price, availability, or policy data creates conversion and trust issues;
- store inventory or fulfillment options influence online buying;
- marketplace, feed, and ad errors repeat across channels;
- personalization depends on both product and customer context;
- AI shopping, search, and recommendation systems need better product facts.

A practical path is to evolve the data layer before promising a fully connected experience:

1. Centralize the approved product record.
2. Normalize identifiers, variants, taxonomy, attributes, media, and policy fields.
3. Define each channel's data contract.
4. Validate product records before publishing.
5. Synchronize price, availability, and inventory with tighter freshness rules.
6. Route channel errors back to the source data workflow.
7. Add customer, order, support, and fulfillment context once the product layer is reliable.
8. Expose machine-readable product facts for search, recommendations, and AI commerce.

That path lets a merchant keep the speed of multichannel while building toward the continuity of omnichannel.

## Where Catalog fits

Catalog is the product data layer for AI commerce. That means Catalog focuses on the product facts behind the channel experience: normalizing messy product information, enriching records with useful attributes, making product data machine-readable, and keeping downstream systems ready for search, recommendations, feeds, marketplaces, and AI shopping.

In a multichannel strategy, that helps teams create cleaner channel outputs with less repeated manual cleanup.

In an omnichannel strategy, it helps create the trusted product layer that every touchpoint can reuse, including AI shopping surfaces that need more than a generic product description.

The goal is not to make every merchant jump to omnichannel overnight. The goal is to make product data strong enough that every new channel becomes easier to launch, easier to govern, and easier to connect.

## FAQ

### Is omnichannel better than multichannel?

Omnichannel is not always better. It is more connected, but it also requires more data infrastructure, governance, and operational maturity. Multichannel is often better when a merchant is testing new channels or has limited resources. Omnichannel becomes better when disconnected product, inventory, price, customer, and fulfillment data starts limiting growth or damaging the customer experience.

### Is marketplace selling multichannel or omnichannel?

Marketplace selling is usually multichannel at first. A merchant adds Amazon, Walmart, eBay, TikTok Shop, or another marketplace as an additional sales channel. It becomes closer to omnichannel when marketplace listings, inventory, pricing, product content, order handling, returns, and customer support are connected to the same underlying product and operations data used by other channels.

### Do you need a PIM or CDP for omnichannel?

Most omnichannel strategies need both strong product data and strong customer data, but the exact tools vary. A [PIM](https://www.getcatalog.ai/glossary/pim) can help centralize product information. A customer data platform (CDP) can help unify customer behavior and identity. Catalog's view is that merchants also need a product data layer that can turn product records into clean, structured, channel-ready, AI-readable outputs.

### What product data should sync first?

Start with the product facts most likely to create customer, channel, or revenue problems when they are wrong: product IDs, variant relationships, titles, images, price, sale price, availability, inventory, shipping, returns, category, and required channel attributes. Then improve richer fields such as use cases, compatibility, materials, dimensions, care instructions, reviews, and AI-facing product context.

---

Canonical: https://www.getcatalog.ai/blog/omnichannel-vs-multichannel
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Conversational commerce: what it is, examples, and how brands should prepare

*July 28, 2026 · Catalog Team · AI Commerce · 16 min*

> Learn what conversational commerce is, how AI shopping assistants change it, and what product data brands need for chat-led buying.

Conversational commerce is ecommerce that happens through a two-way conversation. A shopper asks for help in natural language, the brand or shopping surface responds with product guidance, and the interaction can move toward comparison, checkout, order support, or a human handoff.

The idea is not new. Brands have used live chat, SMS, WhatsApp, Messenger, and voice assistants for years. What changed is the quality of the interface. AI shopping assistants can now interpret messy shopper requests, ask clarifying questions, compare products, and explain recommendations in plain language.

That makes conversational commerce more important than a chat widget. It is becoming a product discovery layer. If a shopper asks, "Which waterproof carry-on fits a 15-inch laptop and can arrive before Friday?" the answer depends on product attributes, price, availability, shipping data, reviews, and policies. The conversation is the interface. Product data is the infrastructure.

## What is conversational commerce?

Conversational commerce is the use of chat, messaging, voice, or AI assistants to help shoppers discover, evaluate, buy, and get support for products through conversation.

A practical definition is this: conversational commerce turns a shopping journey into an interactive dialogue.

That dialogue can happen on a brand's own site, inside a messaging app, through a marketplace assistant, in a voice interface, or in an external AI shopping surface. [Salesforce](https://www.salesforce.com/commerce/conversational-commerce/) describes the category around messaging apps, chatbots, and voice assistants that make interactions and transactions smoother. [IBM](https://www.ibm.com/think/topics/conversational-commerce) frames it as ecommerce supported by conversation tools such as chatbots, voice assistants, and real-time messaging.

For ecommerce teams, the important part is not the label. It is the behavior: shoppers increasingly expect to ask specific questions and get specific answers.

Instead of browsing a category page and applying filters one by one, a shopper may ask:

- "Which of these running shoes is best for wide feet and wet pavement?"
- "Do you have a low-profile sofa under 84 inches that ships in two weeks?"
- "Is this serum safe for sensitive skin and fragrance-free?"
- "Can I reorder the replacement filter that fits the machine I bought last year?"
- "Which carry-on has the best reviews for durability and still fits overhead bins?"

Those questions are commercial intent in sentence form. Conversational commerce is the system that turns those sentences into product decisions.

## Why conversational commerce matters again

Early conversational commerce was often support-led. A chatbot answered frequently asked questions. A live agent helped with sizing. A text campaign recovered abandoned carts. Those use cases still matter, but they are no longer the full story.

AI shopping assistants are pulling conversational behavior into the discovery layer. A shopper can ask an external assistant for product ideas, compare options in a marketplace, then land directly on a product detail page. Catalog's guide to [AI shopping assistants](https://www.getcatalog.ai/blog/ai-shopping-assistant-guide) covers that shift in more detail.

Google and OpenAI are also turning product data into conversational inputs. Google's Merchant Center documentation on [conversational attributes](https://support.google.com/merchants/answer/17085370?hl=en) says those details help AI systems and conversational agents understand product nuances. [OpenAI's merchant documentation](https://chatgpt.com/merchants/) describes product results that can include images, pricing, and key details in ChatGPT shopping experiences.

That is why conversational commerce should be on the roadmap for ecommerce, merchandising, and product data teams. The next version of product discovery will not always look like a search box and a product grid. It may look like a shopper asking a full question and expecting the system to know enough about the catalog to answer.

## How conversational commerce works

Every platform is different, but most conversational commerce flows have the same basic shape.

1. **The shopper states a goal.** The request may include a category, budget, use case, style, size, delivery window, problem, or constraint.
2. **The system interprets intent.** A chatbot, assistant, search layer, or human agent turns the request into requirements the commerce stack can act on.
3. **Product and customer data are retrieved.** The system checks product attributes, variants, price, stock, shipping, policies, reviews, order history, or customer context.
4. **The assistant responds.** It may answer a question, recommend products, compare options, ask a clarifying question, or route the shopper to the right product page.
5. **The journey moves forward.** The shopper may add to cart, start checkout, request a human agent, track an order, return an item, or save the recommendation for later.

The weak point is usually step three. If product data is incomplete, stale, inconsistent, or locked in disconnected systems, the assistant has to guess. That creates vague answers, wrong recommendations, unnecessary handoffs, and shopper distrust.

A conversational interface is only as useful as the facts behind it.

## Common types of conversational commerce

Conversational commerce includes several overlapping channels.

| Type | Where it happens | Common use cases |
| --- | --- | --- |
| Live chat | Brand website or app | Product questions, sizing help, order support, returns, sales handoff |
| AI chatbot | Brand website, app, or support surface | Guided discovery, FAQs, comparisons, triage, product recommendations |
| Messaging app commerce | WhatsApp, Messenger, WeChat, Instagram DMs, RCS, SMS | Promotions, product help, cart recovery, order updates, customer service |
| Voice commerce | Smart speakers, phone assistants, voice search | Reorders, local product queries, hands-free support, simple purchase flows |
| Marketplace assistant | Amazon, retail marketplaces, commerce platforms | Catalog search, product comparisons, review summaries, marketplace-specific support |
| External AI shopping assistant | ChatGPT, Perplexity, Gemini, Copilot, and other AI surfaces | Product research, shortlisting, comparison, click-through to product pages |
| Human-assisted concierge | High-consideration retail, luxury, B2B, complex categories | Personal shopping, complex fit, custom quotes, relationship-driven buying |

A brand does not need to launch every channel at once. The right starting point depends on where shoppers already ask questions and where better answers would change revenue.

## Conversational commerce examples across the buying journey

The easiest way to understand conversational commerce is to map it to real shopping moments.

### Product discovery

A shopper says, "I need a wedding guest dress for an outdoor September ceremony, under $250, in a petite size." A conversational assistant can translate that into category, season, occasion, price, size, color, material, stock, and shipping requirements.

Traditional filters can support some of that. A conversation can capture the whole intent at once.

### Product comparison

A shopper asks, "What is the difference between these two espresso machines?" The assistant can compare dimensions, boiler type, grinder compatibility, warranty, price, reviews, and who each product is best for.

This is where structured [product attributes](https://www.getcatalog.ai/blog/product-attributes-guide) matter. If the comparison facts are not stored consistently, the assistant cannot compare them reliably.

### Fit, compatibility, and confidence questions

Many shoppers do not need a generic recommendation. They need confidence that a product fits their situation.

Examples include:

- apparel fit, inseam, stretch, and care instructions;
- electronics compatibility, ports, battery life, and warranty;
- furniture dimensions, room fit, assembly, and delivery constraints;
- beauty ingredients, allergens, shade, coverage, and skin type;
- replacement parts, model numbers, and version compatibility.

These are high-intent questions. If the answer is missing, the shopper may leave, contact support, or choose a competitor with clearer data.

### Cart recovery and checkout help

A shopper abandons a cart because shipping timing is unclear. A conversational message can answer the question, confirm availability, apply an eligible offer, or route the shopper back to checkout.

This use case works best when the assistant can see real price, promotion, inventory, shipping, and policy data. Otherwise, the message becomes generic and the shopper still has to investigate.

### Post-purchase support

After purchase, conversational commerce can support order status, returns, exchanges, warranty questions, setup, replenishment, and reorders. For many brands, support is the first place conversational commerce becomes measurable because the team can track resolution rate, handoffs, and customer satisfaction.

The long-term opportunity is connecting support signals back into product data. If shoppers repeatedly ask whether a jacket is warm enough for winter, the product record may need better warmth, lining, temperature, or use-case attributes.

## Conversational commerce vs. chatbots, social commerce, AI shopping assistants, and agentic commerce

The terms overlap, but they are not interchangeable.

| Term | What it mainly means | How it relates to conversational commerce |
| --- | --- | --- |
| Live chat | A human or agent answers questions in a chat window | One channel for conversational commerce |
| Chatbot | Software that automates answers or workflows in chat | A tool that can power conversational commerce, but not all chatbots are commerce-ready |
| Conversational marketing | Messaging used to capture, qualify, and nurture leads | Often lead-generation focused; conversational commerce continues into product selection and purchase |
| Social commerce | Selling through social platforms and creator-driven discovery | Can become conversational when buying happens through DMs or platform messaging |
| AI shopping assistant | An AI system that helps shoppers find, compare, and choose products | A modern form of conversational commerce focused on product discovery and decision support |
| Agentic commerce | AI agents acting on behalf of buyers across research, comparison, and sometimes purchase | A broader model where the conversation may be only one interface for a multi-step agent workflow |

A simple rule: conversational commerce describes the interface and interaction model. [Agentic commerce](https://www.getcatalog.ai/blog/what-is-agentic-commerce) describes a more autonomous buying model where an AI agent may take multiple steps on the shopper's behalf. The two are connected, but they are not the same thing.

## Why product data decides whether conversational commerce works

Most conversational commerce content focuses on channels: WhatsApp, live chat, SMS, chatbots, and voice assistants. Channels matter, but they do not solve the underlying product understanding problem.

A shopping assistant needs enough product data to answer a specific buying question. A vague product title and a lifestyle image are not enough.

The most important data areas are:

| Product data area | Why it matters in conversation | Examples |
| --- | --- | --- |
| Product identity | Prevents duplicate, mismatched, or stale recommendations | Product ID, SKU, GTIN, MPN, brand, canonical URL |
| Category and taxonomy | Helps the assistant know what kind of product it is reasoning about | Product type, category path, collection, use case |
| Attributes and specs | Converts shopper language into matchable facts | Size, material, fit, dimensions, ingredients, compatibility, capacity |
| Variants and relationships | Keeps recommendations at the right sellable level | Parent product, color/size variants, bundles, refills, replacement parts |
| Commercial data | Prevents recommendations that cannot be purchased | Price, sale price, stock, delivery window, regional availability |
| Policies and logistics | Answers purchase-confidence questions | Shipping, returns, warranty, assembly, restrictions, hazardous material rules |
| Reviews and proof | Supports recommendation explanations | Ratings, review themes, certifications, expert notes, provenance |
| Machine-readable distribution | Makes product facts accessible to systems beyond the page | Structured data, Merchant Center feeds, APIs, partner feeds, sitemaps |

Google's [product structured data](https://developers.google.com/search/docs/appearance/structured-data/product) guidance shows how page markup can expose product facts such as price, availability, ratings, and shipping information. Google's [Merchant Center product data specification](https://support.google.com/merchants/answer/7052112?hl=en) makes the same point from a feed perspective: accurate product data helps products match the right queries and appear correctly.

For conversational commerce, this becomes even more important because the queries are more specific. A shopper is not only searching for "sofa." They may ask for "a stain-resistant apartment sofa under 84 inches with removable covers that can be delivered before the end of the month."

If those facts are missing or inconsistent, the assistant cannot answer with confidence.

## What an assistant-ready product record looks like

A weak product record might say:

> "Lightweight commuter jacket. Black. Water resistant."

That is understandable to a human, but it gives an assistant very little to use.

An assistant-ready product record is more explicit:

> "Women's waterproof commuter jacket with recycled nylon shell, taped seams, packable hood, two-way zipper, reflective trim, relaxed fit, sizes XS-XL, colors black/navy/olive, in stock, ships in two business days, machine washable, 30-day returns."

The second record can answer many more questions:

- Is it waterproof or just water resistant?
- Does it work for commuting in low light?
- Is it available in my size?
- Can it arrive before my trip?
- Is the hood removable or packable?
- Can I return it if the fit is wrong?

This is why [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) is becoming a growth workflow. Enrichment turns raw product content into complete, normalized, machine-readable facts that assistants can retrieve and compare.

## How to prepare your catalog for conversational commerce

You do not need a perfect catalog before testing conversational commerce. But you do need a clear plan for the products and questions that matter most.

### 1. Audit the questions shoppers already ask

Start with support tickets, onsite search logs, live chat transcripts, product reviews, returns reasons, and paid search queries. Look for repeated questions such as:

- size and fit;
- compatibility;
- delivery timing;
- materials or ingredients;
- setup and assembly;
- warranty and returns;
- comparison against another product;
- whether an item works for a specific use case.

These questions are your conversational commerce roadmap. They show where better product data can reduce friction.

### 2. Prioritize products where better answers can move revenue

Do not enrich every SKU equally on day one. Start with products that have commercial importance and high question volume.

Good candidates include best sellers, high-margin products, high-return products, complex products, products with strong reviews, and categories where shoppers need help before buying.

### 3. Build category-specific attribute models

A beauty product, laptop, sofa, industrial part, and grocery item do not need the same fields. Build attribute models around shopper questions and category rules.

For apparel, fit and material may be essential. For furniture, dimensions and delivery constraints matter. For electronics, compatibility and warranty are critical. For replacement parts, identifiers and model relationships may decide whether the recommendation is safe.

### 4. Normalize variants, identifiers, and relationships

Conversational systems can fail when the catalog does not clearly separate products, variants, bundles, accessories, refills, and replacement parts.

Clean records should define:

- parent product and child variants;
- SKU, GTIN, MPN, or other identifiers where available;
- color, size, pack, finish, or configuration;
- bundle components;
- compatible accessories and replacement parts;
- canonical product URLs.

This reduces duplicate recommendations and prevents the assistant from comparing the wrong sellable item.

### 5. Keep price, inventory, shipping, and policies fresh

Conversational commerce creates a trust problem when dynamic facts are wrong. A shopper will not forgive an assistant that recommends an out-of-stock product, quotes an outdated price, or promises a delivery window the brand cannot meet.

Use a [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) workflow to keep product pages, feeds, marketplaces, and AI-facing surfaces aligned. The goal is not only consistency for humans. It is consistency for every system that may answer on the brand's behalf.

### 6. Expose product facts in machine-readable formats

Product pages still matter, but conversational systems also rely on structured inputs.

Useful distribution layers include:

- product structured data on the page;
- Merchant Center feeds and marketplace feeds;
- clean product APIs;
- accurate sitemaps and canonical URLs;
- consistent metadata across retail media, affiliate, and marketplace listings.

For teams building AI shopping experiences, a product API can be the cleanest interface: live product objects, variant-level price and stock, normalized specs, images, and the product data agents need to build reliable shopping experiences.

### 7. Test conversations against real product records

Do not only test whether the assistant sounds good. Test whether it answers hard product questions correctly.

Use prompts such as:

- "Which of these is best for a petite shopper?"
- "What can arrive before Friday?"
- "Which option is compatible with model X?"
- "What is the return policy if it does not fit?"
- "Why would I choose this product over the cheaper one?"

When the assistant cannot answer, label the cause. Was the attribute missing? Was the variant relationship unclear? Was inventory stale? Was the policy not machine-readable? Those failures become the next enrichment backlog.

## Benefits and risks of conversational commerce

Conversational commerce can improve the buying journey, but only when it is implemented with the right data and guardrails.

### Benefits

- **Lower discovery friction.** Shoppers can describe what they need instead of translating a need into filters.
- **Higher-context recommendations.** Assistants can use use case, constraints, budget, timing, and preferences in one interaction.
- **Better support efficiency.** Common questions can be answered faster, while complex cases can route to humans with context.
- **More useful customer feedback.** Conversation logs reveal missing product facts, confusing policies, and common objections.
- **New distribution surfaces.** Product answers can appear in AI assistants, messaging apps, and agentic shopping flows beyond the brand site.

### Risks

- **Wrong recommendations.** Thin or stale data can lead to confident but incorrect product suggestions.
- **Hallucinated product claims.** AI systems may infer details the product record does not prove.
- **Disconnected channels.** A chatbot, feed, product page, and support system may all show different facts.
- **Privacy and consent problems.** Messaging and personalization workflows need clear permission, data handling, and opt-out rules.
- **Bad human handoffs.** Shoppers get frustrated if automation cannot transfer context to a person.
- **Measurement gaps.** AI-assisted visits can show up as ordinary referral or direct traffic, making the channel hard to size.

The lesson is simple: do not treat conversational commerce as a front-end experiment only. Treat it as a data, systems, and customer experience project.

## How to measure conversational commerce

Measurement should cover both the conversation itself and the commerce outcome.

Useful metrics include:

| Metric | What it tells you |
| --- | --- |
| Conversation-to-product-view rate | Whether conversations route shoppers to relevant products |
| Product recommendation click-through rate | Whether recommended products earn engagement |
| Add-to-cart and conversion rate | Whether the assistant helps shoppers act |
| Assisted revenue | Revenue connected to sessions that included conversational help |
| Average order value | Whether guided shopping changes basket size |
| Resolution rate | How often the assistant answers without human help |
| Human handoff rate | Where automation still needs support |
| Customer satisfaction | Whether the experience feels helpful, not just efficient |
| Unanswered intent rate | Which questions expose product-data gaps |
| AI referral and deep product-page traffic | Whether external assistants are sending qualified visits |

For external AI surfaces, watch visible referrers from ChatGPT, Perplexity, Gemini, Copilot, and similar tools. Also monitor the pattern Catalog covers in [dark agentic commerce traffic](https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic): high-intent product-detail-page sessions that may not carry a clean AI referrer.

Do not assume every direct product-page visit came from AI. Use it as a hypothesis. Look for changes in landing page depth, product-page conversion, branded vs. non-branded demand, and visibility in AI shopping assistants.

## A practical conversational commerce checklist

Use this checklist before launching or expanding a conversational commerce program.

- List the top shopper questions by category.
- Identify which products or categories matter most commercially.
- Define required product attributes for those categories.
- Normalize variants, identifiers, bundles, and compatibility relationships.
- Keep price, availability, shipping, and returns synchronized.
- Add structured data and feed fields where relevant.
- Expose product data through APIs when partners or AI experiences need clean access.
- Test assistants against real product records, not demo data.
- Build a human handoff path with conversation context.
- Track unanswered intents and turn them into product-data improvements.
- Measure assisted revenue, conversion quality, and AI referral patterns.

If your product data team owns this checklist, conversational commerce becomes more than a support channel. It becomes a product discovery strategy.

## The takeaway

Conversational commerce is the shift from shoppers browsing silently to shoppers asking for help directly. AI makes that shift bigger because assistants can interpret intent, compare products, and explain recommendations at scale.

But the assistant is not the strategy by itself. The strategy is making your products easy for humans and machines to understand.

Brands that prepare now will not only have better chat experiences. They will have catalogs that are more visible, more recommendable, and more useful across AI shopping surfaces, messaging channels, and agent-led buying journeys.

## FAQ

### What is conversational commerce?

Conversational commerce is ecommerce through two-way conversation. It uses chat, messaging apps, voice assistants, human agents, or AI shopping assistants to help shoppers discover, compare, buy, and get support for products.

### What is an example of conversational commerce?

A shopper asking an onsite assistant, "Which waterproof jacket is best for commuting and available in size medium?" is a conversational commerce example. So is a WhatsApp product recommendation, a voice reorder, an Instagram DM checkout flow, or an AI shopping assistant comparing products before sending the shopper to a product page.

### Is conversational commerce the same as a chatbot?

No. A chatbot is one tool that can support conversational commerce. Conversational commerce is the broader shopping model where the customer journey happens through dialogue. It may involve AI chatbots, live agents, messaging apps, voice assistants, marketplace assistants, or external AI shopping tools.

### Is conversational commerce AI?

Not always. Live chat and SMS commerce can be conversational without AI. But AI is making conversational commerce more powerful because assistants can interpret longer requests, ask follow-up questions, retrieve product data, compare options, and explain recommendations.

### How is conversational commerce different from agentic commerce?

Conversational commerce describes a shopping interaction through dialogue. Agentic commerce describes AI agents that can take more steps on behalf of the buyer, such as researching, comparing, checking constraints, and moving toward purchase. Many agentic commerce experiences will use a conversational interface, but agentic commerce is broader than chat.

### What product data does conversational commerce need?

Conversational commerce needs complete and current product facts: product identifiers, categories, attributes, variants, price, stock, shipping, returns, warranty, reviews, structured data, feeds, and APIs. The more specific the shopper question, the more important complete product data becomes.

---

Canonical: https://www.getcatalog.ai/blog/conversational-commerce-guide
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product experience management: what PXM means and how it fits the product data stack

*July 27, 2026 · Catalog Team · Product Data · 11 min*

> Learn what product experience management means, how PXM differs from PIM, enrichment, and syndication, and how AI commerce changes the workflow.

Product experience management is the discipline of turning product data, content, media, and channel rules into a consistent product experience everywhere a product is discovered, compared, recommended, and bought.

The short version: product experience management (PXM) makes sure every channel has the product information it needs, in the format it expects, with enough context for shoppers and software to trust it.

That sounds close to [product information management](https://www.getcatalog.ai/glossary/pim), and the two are connected. But they are not the same job. A [PIM system](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) helps centralize and govern product information. PXM is the broader operating model that turns that information into channel-ready experiences across storefronts, marketplaces, retailer pages, feeds, search, social commerce, and AI shopping surfaces.

For modern ecommerce teams, the distinction matters. A product record can look complete inside an internal system and still fail on the channels where customers actually decide what to buy.

## What product experience management means

Product experience management is the work of managing how products appear and perform across customer-facing and machine-facing channels.

A strong PXM workflow answers practical questions:

- Is the product information complete enough for the channel?
- Are attributes, variants, prices, availability, and media consistent?
- Does each destination get the right version of the product record?
- Can shoppers compare the product without guessing?
- Can search engines, marketplaces, recommendation systems, and AI shopping tools understand the product facts?
- Can the team see when product content is rejected, stale, incomplete, or underperforming?

PXM is not just prettier product pages. It includes the operational work behind those pages: product facts, category structure, content, assets, rules, approvals, syndication, validation, and feedback.

It is also not the same as a product manager's work on product strategy or feature development. In ecommerce, PXM usually refers to the product content and product data experience around the items a brand sells.

## PXM vs PIM, enrichment, DAM, syndication, and feeds

PXM overlaps with several product-data terms. The cleanest way to separate them is to ask what job each one owns.

| Term | What it owns | How it relates to PXM |
| --- | --- | --- |
| PXM | The end-to-end product experience across channels | The umbrella operating model for channel-ready product information and content |
| [PIM](https://www.getcatalog.ai/glossary/pim) | Centralized product information, governance, and internal workflow | Often the source of truth PXM depends on |
| Product data enrichment | Filling, normalizing, improving, and validating product records | Makes the source data strong enough for PXM to use |
| DAM | Digital assets such as photos, videos, 3D files, manuals, and brand files | Supplies the media layer of the product experience |
| [Product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) | Mapping, transforming, and distributing product data to each destination | Delivers PXM outputs into channels |
| [Data feed](https://www.getcatalog.ai/glossary/data-feed) | A file or stream of structured product records for one or more destinations | One delivery format, not the whole PXM workflow |

The terms often blur because software vendors package several of these jobs together. A PXM platform might include PIM, DAM, workflow, enrichment, syndication, and analytics. A PIM vendor might add PXM features. A feed tool might handle parts of syndication and channel validation.

For planning purposes, keep the distinction simple: PIM organizes the source information. Enrichment improves it. Syndication sends it. PXM owns the customer and channel outcome.

## What PXM actually manages

A product experience is built from many smaller data and content decisions. PXM brings those decisions into one repeatable workflow.

Common PXM inputs include:

- product titles, descriptions, bullets, and merchandising copy;
- structured [product attributes](https://www.getcatalog.ai/blog/product-attributes-guide) such as color, material, dimensions, compatibility, ingredients, care instructions, and technical specs;
- product identifiers such as SKU, GTIN, UPC, MPN, brand, and canonical URL;
- category, taxonomy, collection, and use-case data;
- variant relationships such as size, color, pack, bundle, and configuration;
- photos, videos, swatches, manuals, certificates, alt text, and asset usage rules;
- price, sale price, currency, availability, condition, inventory, shipping, returns, warranty, and policy data;
- localization and regional rules;
- channel-specific mappings, limits, required fields, image rules, and accepted values;
- analytics, rejection data, content quality scores, and performance feedback.

The output is not one universal product page. It is a set of channel-ready product experiences built from the same trusted product record.

A marketplace may need a strict category, accepted attribute values, and a compliant main image. A retailer may need a supplier-specific template. A brand site may need richer storytelling and comparison content. A search engine may need [structured data](https://www.getcatalog.ai/glossary/structured-data). An AI shopping system may need clear product facts, current availability, and enough context to compare the product against alternatives.

PXM is the work of keeping those versions aligned without turning every channel into a separate manual project.

## Why PXM matters now

PXM matters because commerce teams no longer control a single product experience.

A product can appear on a brand site, a retailer page, a marketplace listing, Google Shopping, paid social catalogs, affiliate feeds, reseller portals, internal search indexes, recommendation systems, and AI shopping assistants. Each destination has a different data contract.

Google Merchant Center's [product data specification](https://support.google.com/merchants/answer/7052112?hl=en) is a good example. Product data is not just a title and image. It includes required, conditional, and optional attributes across basic product data, price and availability, categories, identifiers, descriptions, tax, shipping, and more. If required data is missing, a product may not be eligible to serve in ads or free listings.

Search has a similar machine-readable layer. Google Search Central's [product structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/product) explains how product markup can support richer search experiences with product information such as price, availability, ratings, shipping, returns, and variants. Schema.org's [`Product`](https://schema.org/Product) vocabulary includes fields for facts such as brand, GTIN, SKU, MPN, color, material, size, weight, offers, and more.

Those examples point to the same reality: product experiences are made from structured facts as much as from copy and images.

AI shopping raises the bar again. [AI shopping assistants](https://www.getcatalog.ai/blog/ai-shopping-assistant-guide) do not only display products. They summarize, compare, filter, and recommend. If a product's most important facts are missing, stale, vague, or trapped in prose, AI systems have less reliable material to work with.

## The product data foundation behind PXM

PXM becomes easier when the product data underneath it is complete, normalized, and current. The exact fields vary by category, but most teams need six foundations.

### 1. Stable identifiers and variant relationships

Identifiers tell systems which product they are looking at. That includes SKU, GTIN, UPC, MPN, brand, product ID, parent product ID, variant ID, and canonical URL.

Variant relationships are just as important. A shirt with five sizes and four colors is not twenty unrelated products. A marketplace, storefront, search engine, or AI shopping system needs to know how each variant relates to the parent product and which facts change by option.

### 2. Rich attributes and specifications

Attributes turn product copy into reusable facts. Material, color, size, capacity, dimensions, compatibility, ingredients, finish, fit, care instructions, certifications, and use cases help products show up in filters, comparisons, recommendations, and channel feeds.

A generic product record might say a bag is "great for travel." A stronger PXM-ready record says the bag is carry-on compliant, weighs 2.4 pounds, has a 38-liter capacity, includes a padded 16-inch laptop sleeve, and uses water-resistant recycled nylon.

The second version is easier for people to trust and easier for software to compare.

### 3. Taxonomy and merchandising context

Taxonomy tells systems where a product belongs. Product type, category, subcategory, collection, occasion, audience, style, season, and use case all affect discovery.

Weak taxonomy creates avoidable downstream work. If source data does not distinguish between hiking backpacks, laptop backpacks, and fashion backpacks, every channel has to infer the difference later.

### 4. Media and asset metadata

PXM includes images and rich media, but the important part is not only having assets. It is knowing what each asset shows and where it can be used.

A strong media layer tracks main images, alternate images, lifestyle shots, swatches, videos, manuals, certificates, image roles, alt text, usage rights, and destination-specific rules. That prevents a retailer, marketplace, or product page from showing the wrong image or rejecting an asset that does not meet its requirements.

### 5. Price, availability, and policies

Price and availability are freshness fields. They change faster than evergreen product content, and bad freshness creates immediate customer problems.

PXM needs a reliable way to keep sale price, currency, inventory, condition, shipping, returns, warranties, restrictions, regional availability, and fulfillment details current across destinations.

### 6. Structured and AI-facing product facts

The strongest product records are built for both humans and machines. That means keeping facts in predictable fields, not only inside paragraphs.

Structured product data helps search engines, feeds, recommendation systems, and AI shopping tools parse what a product is, who it is for, and how it compares. For AI commerce, this is where [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) becomes strategic: raw catalog records have to become live, machine-readable product objects.

## A practical PXM workflow

A PXM workflow should be repeatable. It should not depend on someone exporting a spreadsheet, cleaning it by hand, and hoping each channel accepts it.

1. **Centralize the source record.** Decide which system owns approved product information. This may be a PIM, ecommerce platform, ERP-backed catalog, product data layer, or a combination of systems with clear ownership.
2. **Normalize the data model.** Standardize field names, units, values, taxonomy, variants, identifiers, and media references. Resolve conflicts such as `navy`, `navy blue`, and `midnight` before they reach channels.
3. **Enrich missing or weak fields.** Add attributes, specs, descriptions, taxonomy, image metadata, compatibility, policies, and AI-readable context where the source record is thin.
4. **Map each destination.** Define which source fields feed each channel, which values need transformation, which fields are required, and which products are eligible.
5. **Review and approve changes.** Give merchandising, product, ecommerce, legal, localization, or supplier teams a clear way to approve the fields they own.
6. **Publish or syndicate.** Send product data through the right delivery method: storefront CMS, marketplace connector, retailer portal, product feed, API, or data exchange.
7. **Validate acceptance and display.** Track rejections, warnings, missing fields, bad images, broken variants, price mismatches, and display issues after publishing.
8. **Monitor and improve.** Use feedback from channels, search, merchandising, support, returns, and AI visibility to improve the product record over time.

This is why PXM is less about a single content launch and more about operating discipline. Products change, channels change, and customer expectations change. The workflow has to keep up.

## Where PXM workflows break

Most PXM problems come from a few predictable failure points.

**The record is complete internally but not channel-ready.** A product can be approved in a PIM and still miss a retailer's required attribute, a marketplace's accepted value, or a feed's image rule.

**Spreadsheet drift becomes normal.** Teams export a file, patch it for one destination, and create a second source of truth without meaning to. The next sync overwrites the fix or reintroduces old errors.

**Attributes are too thin for discovery.** Products can be live but hard to find, filter, compare, or recommend because the important facts are missing or inconsistent.

**Media rules are unmanaged.** Teams track asset URLs but not image roles, destination rules, rights, alt text, or which visual belongs to which variant.

**Price and availability lag behind.** Static content workflows break down when inventory, promotions, regional availability, or fulfillment promises change quickly.

**Ownership is unclear.** If no one owns a field, the field decays. Supplier data, merchandising copy, compliance warnings, shipping details, and AI-facing enrichments all need clear owners.

**AI-facing data is vague.** AI shopping systems need explicit product facts. "Premium," "durable," and "great for travel" are not enough unless the record also includes materials, dimensions, capacity, compatibility, warranty, reviews, constraints, or other concrete facts.

## What to look for in PXM software

PXM software can mean different things depending on the vendor. Before comparing feature lists, define which job you need the system to do.

Use this checklist:

- **Source of truth:** Does the system own product information, or does it sit downstream from another source?
- **Data model:** Can it handle your categories, attributes, variants, identifiers, localization, and policies without forcing awkward workarounds?
- **Enrichment:** Can teams fill missing fields, normalize values, generate or review content, and validate completeness by category?
- **Media:** Does it connect to a DAM or manage product assets, roles, variant relationships, and usage rules?
- **Workflow:** Can the right teams review, approve, localize, and audit product content changes?
- **Channel mapping:** Can it translate one product record into the fields, accepted values, and formats each destination needs?
- **Validation:** Does it catch required-field gaps, rejected products, bad images, stale prices, and channel warnings?
- **Analytics:** Can it connect product data quality to channel acceptance, search visibility, conversion, returns, content completeness, or AI visibility?
- **Freshness:** How quickly do product updates reach the places where buyers see them?
- **AI readiness:** Does it produce structured, machine-readable product data that AI shopping systems can parse, compare, and keep current?

The right answer depends on the bottleneck.

If your biggest problem is internal product-data governance, a traditional PIM or full PXM suite may be the right foundation. If your biggest problem is distribution, a syndication or feed-management tool may matter most. If your biggest problem is making product data usable for AI commerce, you may need a live product data layer alongside the systems you already have.

## Where Catalog fits in the PXM landscape

Catalog is not a one-for-one replacement for every PIM or PXM deployment.

If a brand needs deep internal workflows for supplier onboarding, localization, DAM approvals, retailer templates, and enterprise governance, a traditional PIM or PXM suite can still be the right center of the stack.

Catalog fits when the missing layer is AI-ready product data.

Catalog helps brands structure, enrich, and publish product information so AI shopping surfaces can understand what they sell. Developers can use the resulting live, normalized product objects in AI-commerce applications without maintaining brittle scraping pipelines.

That makes Catalog complementary to many PIM/PXM setups. The PIM can remain the internal source of truth. Catalog can sit beside it as the product data layer for AI commerce: structured facts, current product objects, and visibility into how products appear across AI shopping surfaces.

The simplest decision rule is this:

- If your product information is scattered and ungoverned, fix the source of truth first.
- If your product content is complete but not channel-ready, improve enrichment and syndication.
- If your catalog is not legible to AI shopping systems, add an AI-commerce product data layer.

PXM is the operating model that connects those decisions. The goal is not to buy the broadest platform. The goal is to make every product understandable, accurate, and useful wherever a buyer or machine evaluates it.

## Frequently asked questions about product experience management

### Is PXM the same as PIM?

No. PIM centralizes and governs product information. PXM uses that product information, plus content, media, channel rules, enrichment, syndication, and feedback, to create consistent product experiences across channels.

### What is PXM software?

PXM software helps teams manage product content and product data for customer-facing channels. Depending on the platform, it may include PIM, DAM, enrichment, workflow, channel mapping, syndication, validation, analytics, and AI-ready product data outputs.

### Who owns product experience management?

PXM is usually shared across ecommerce, merchandising, catalog operations, product data, content, digital marketing, and IT. The best owner is the team accountable for product data quality and channel performance, with clear field-level ownership across the business.

### Does PXM matter for AI shopping?

Yes. AI shopping systems need product facts they can parse, compare, and keep current. PXM helps turn product content into structured, channel-ready product data so AI systems have clearer information about attributes, variants, use cases, price, availability, and policies.

### Does every brand need a PXM platform?

Not always. Smaller teams may start with a clean ecommerce catalog, strong attributes, and reliable feeds. Larger or more complex teams usually need stronger PIM, enrichment, DAM, syndication, workflow, and analytics. The important question is not whether the software is called PXM; it is whether the workflow keeps product experiences accurate across every important channel.

---

Canonical: https://www.getcatalog.ai/blog/product-experience-management
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product attributes: examples, types, and why they matter

*July 24, 2026 · Catalog Team · Product Data · 15 min read*

> Learn what product attributes are, see ecommerce examples, and understand how consistent attributes improve search, filters, feeds, and AI readability.

Product attributes are the structured facts that describe a product. They tell shoppers, storefronts, search systems, feeds, marketplaces, application programming interfaces (APIs), and AI shopping tools what the product is and how it should be understood.

For a t-shirt, product attributes might include size, color, material, fit, sleeve length, care instructions, price, availability, SKU (stock keeping unit), and [GTIN (global trade item number)](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number). For a laptop, they might include processor, memory, screen size, storage, ports, battery life, warranty, operating system, weight, and compatible accessories.

Good attributes make a product easier to find, filter, compare, recommend, and buy. Weak attributes create the opposite problem: products disappear from filters, feed validation gets harder, search systems miss relevant matches, and AI shopping tools have less reliable data to work with.

## What are product attributes?

Product attributes are the specific properties, characteristics, or facts attached to a product record. They can describe what a product is, what it is made of, how it works, how it is sold, how it ships, and how it relates to other products.

Put simply, product attributes are the reusable facts that describe a product in a structured way.

In ecommerce, attributes usually live inside a broader [product catalog](https://www.getcatalog.ai/glossary/product-catalog). That catalog may include product titles, descriptions, images, categories, variants, prices, inventory, policies, identifiers, and channel-specific fields. Attributes are the field-level details that make each record usable.

Common attributes of a product include:

* product name
* brand
* SKU, GTIN, UPC (universal product code), MPN (manufacturer part number), or other identifiers
* category and product type
* size, color, material, dimensions, and weight
* ingredients, compatibility, technical specifications, and care instructions
* variants such as size, color, pack size, or configuration
* price, sale price, availability, and condition
* shipping, warranty, return, and compliance details
* images, swatches, alt text, and other media metadata.

A product can have dozens or hundreds of attributes. The right set depends on the category, the customer journey, and the channels where the product appears.

## Product attributes vs features, benefits, variants, taxonomy, and specs

Product attributes overlap with other ecommerce terms, but they are not all the same thing.

| Term | What it means | Example |
| --- | --- | --- |
| Product attribute | A structured fact or property attached to a product | `color: navy`, `material: merino wool`, `availability: in_stock` |
| Product feature | A capability or characteristic the product offers | Waterproof shell, magnetic closure, 30-hour battery |
| Product benefit | The value the customer gets from a feature or attribute | Stays dry in rain, easier one-handed use, fewer charges during travel |
| Product specification | A precise technical or measurable detail | 13.3-inch display, 16 GB RAM, 18 in x 24 in frame |
| Product variant | A sellable version of the product that differs by option | Small navy shirt, large black shirt, 256 GB phone |
| Product taxonomy | The category structure used to organize products | Apparel > Shirts > T-shirts |

The same fact can play more than one role. `Water-resistant` can be an attribute. It can also support a feature claim. The benefit is what that fact means for the buyer: the jacket can handle light rain during a commute.

The practical rule is simple: attributes should be stored as reusable product facts. Features and benefits can then be written from those facts without guessing.

## Common types of product attributes

The classic split is tangible and intangible attributes. Tangible attributes are physical details such as size, color, material, and weight. Intangible attributes are non-physical details such as brand reputation, quality, style, warranty, sustainability claims, or perceived value.

That distinction is useful, but ecommerce teams usually need a more operational view.

### Identity attributes

Identity attributes tell systems which product or variant they are looking at.

Examples include SKU, GTIN, UPC, MPN, brand, product ID, handle, canonical URL, parent product ID, and variant ID.

These fields matter for deduplication, feed updates, inventory matching, reviews, analytics, and cross-channel reporting.

### Descriptive attributes

Descriptive attributes explain what the product is and how it should be presented.

Examples include product title, short description, long description, bullet points, style, use case, collection, audience, and key selling points.

These fields help shoppers understand the product and help search systems match it to relevant queries.

### Physical attributes

Physical attributes describe measurable or visible qualities.

Examples include size, dimensions, weight, color, material, pattern, finish, shape, volume, capacity, ingredients, scent, and country of origin.

These are often the most important attributes for product filters and comparison tables.

### Technical and functional attributes

Technical and functional attributes describe how the product works.

Examples include wattage, voltage, screen resolution, battery life, processor, operating system, compatibility, waterproof rating, care instructions, assembly requirements, and included accessories.

These matter most when shoppers need to confirm fit, compatibility, safety, or performance before buying.

### Commercial attributes

Commercial attributes describe how the product is sold.

Examples include price, sale price, currency, availability, condition, minimum order quantity, subscription eligibility, promotion flags, bundle options, and regional availability.

These fields change more often than most product attributes, so they need stronger freshness checks.

### Logistics and policy attributes

Logistics and policy attributes reduce uncertainty around fulfillment and post-purchase expectations.

Examples include shipping weight, package dimensions, delivery window, return policy, warranty, restrictions, compliance warnings, hazardous materials flags, and installation requirements.

These fields can affect conversion, channel eligibility, and support volume.

### Media and digital attributes

Media attributes describe the product assets attached to the record.

Examples include main image, alternate images, lifestyle images, videos, 3D assets, image angle, image role, swatch image, alt text, manuals, spec sheets, and certificates.

They help both shoppers and systems understand what each asset shows.

### Merchandising and discovery attributes

Merchandising attributes help teams and systems place products in the right shopping context.

Examples include product type, collection, season, occasion, use case, customer segment, style tags, search synonyms, filter groups, recommendation tags, and ranking rules.

These fields make products easier to browse, promote, and recommend.

### Derived and behavioral attributes

Derived attributes are calculated or inferred from other data.

Examples include bestseller status, review summary, margin band, return-risk score, popularity score, AI-generated summary, or compatibility confidence.

Derived attributes can be useful, but they should be labeled carefully. A system should know the difference between a supplier-confirmed material and an inferred style tag.

## Product attribute examples by category

A universal product attributes list is only a starting point. The most useful attributes are category-specific.

| Category | Useful product attribute examples |
| --- | --- |
| Apparel | Size, fit, color, material, fabric weight, pattern, inseam, rise, sleeve length, care instructions, gender, season, model measurements |
| Furniture | Dimensions, material, finish, weight capacity, assembly requirements, room, style, cushion fill, care instructions, delivery constraints |
| Electronics | Brand, model, processor, memory, storage, screen size, ports, battery life, operating system, compatibility, warranty, included accessories |
| Beauty | Shade, finish, ingredients, skin type, coverage, volume, SPF, allergens, usage instructions, cruelty-free or vegan claims, warnings |
| Grocery | Ingredients, nutrition facts, allergens, pack size, flavor, weight, storage instructions, certifications, origin, expiration or best-by details |
| Industrial parts | MPN, dimensions, material, tolerance, compatibility, load rating, voltage, certifications, replacement part relationships, safety requirements |
| Software or digital products | Platform, version, license type, integrations, supported file types, user limits, API access, security features, deployment model |

The pattern is the same across categories: the best attributes answer the questions a shopper or system needs before it can confidently select the product.

The product attributes examples above are not a complete checklist. They show how the attribute model changes by category, buyer question, and destination.

For simple products, that may mean a short set of clear fields. For technical, expensive, regulated, or compatibility-dependent products, the required attribute set is much deeper.

## Why product attributes matter for ecommerce discovery

Attributes are not just product-page details. They power the systems that decide where a product appears.

### Search and filtering

Onsite search, filters, and faceted navigation depend on structured attributes. If a shopper filters for `black`, `linen`, `wide fit`, or `fits iPhone 16`, the product record needs those facts in fields the system can use.

If the same color appears as `navy`, `navy blue`, and `midnight`, the filter may split one logical option into several. If material is buried inside an image or a long paragraph, the product may not match a material filter at all.

### Comparison and recommendations

Comparison pages and recommendation systems need attributes that are consistent across similar products. A laptop recommendation system cannot compare battery life reliably if one record stores `18 hours`, another stores `all day`, and another has no battery field.

Structured attributes give search and recommendation systems cleaner inputs. They also make merchandising rules easier to manage.

### Product feeds and channel eligibility

Product attributes also determine whether products can be accepted and shown correctly by external channels.

[Google Merchant Center's product data specification](https://support.google.com/merchants/answer/7052112?hl=en) says Google uses submitted product data to match products to the right queries. It also says accurate and correctly formatted product data is essential for ads and free listings, and that incorrect, inaccurate, or missing information can cause disapprovals, limited eligibility, incorrect displays, or other issues.

That is why attributes should be managed before [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication), not patched after a feed fails. Required fields, identifiers, category mappings, price, availability, image URLs, and policy fields all need to be valid for the destination that consumes them.

### Structured data and search appearance

Machine-readable website markup is another attribute layer. [Google Search Central's product structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/product) explains that product structured data can help product information appear in richer ways across Google Search, Google Images, and Google Lens, including price, availability, ratings, and shipping information.

[Schema.org's `Product` type](https://schema.org/Product) includes specific properties for facts such as brand, category, color, GTIN, material, model, MPN, product ID, SKU, size, weight, width, and more. Those specific fields are usually easier for systems to use than a generic property/value dump.

If your team is turning product facts into website markup, Catalog's glossary covers [structured data](https://www.getcatalog.ai/glossary/structured-data) and [schema markup](https://www.getcatalog.ai/glossary/schema-markup) in ecommerce.

## Why consistency matters

Attributes become valuable when they are consistent enough to reuse.

A person can usually tell that `XL`, `Extra Large`, and `X-Large` mean the same thing. A filter, feed mapper, analytics report, or AI system may treat them as different values unless the data is normalized.

Consistency matters across four layers.

### Attribute names

Use one field name for the same concept. Do not split the same idea across `material`, `fabric`, `composition`, and `materials used` unless each field has a distinct job.

### Attribute values

Use controlled values where consistency affects discovery or reporting. Colors, sizes, materials, conditions, product types, and compatibility values should not drift across teams and channels.

### Units and formats

Use standard units and formats. Dimensions, weight, volume, voltage, dates, prices, currency, and identifiers should follow rules that can be validated.

### Ownership and source of truth

Every important field needs an owner. Supplier data may be the source for dimensions. An enterprise resource planning (ERP) system may own inventory. A product information management (PIM) system or product data layer may own approved attributes. A compliance system may own warnings. If ownership is unclear, channel drift becomes normal.

Catalog's guide to [product data quality](https://www.getcatalog.ai/blog/product-data-quality) covers these dimensions in more detail: accuracy, completeness, consistency, timeliness, validity, uniqueness, and usefulness.

## How to define and manage product attributes

A strong product attribute workflow is simple to describe and hard to maintain manually. The goal is to make attributes complete, normalized, validated, and current before they reach shoppers or downstream systems.

### 1. Define attributes by category

Do not use one generic required-field list for the whole catalog. Category decides what complete means.

A cookware product may need material, capacity, dimensions, heat tolerance, induction compatibility, care instructions, included pieces, and warranty. A beauty product may need ingredients, shade, finish, skin type, usage instructions, allergens, certifications, and warnings.

Start with the categories that matter most to revenue, search, support, returns, marketplace eligibility, or AI-shopping visibility.

### 2. Separate core and category-specific attributes

Some attributes apply to almost every product: product name, brand, identifier, category, price, availability, image, and URL.

Other attributes apply only to certain product types. [IBM's Product Master documentation](https://www.ibm.com/docs/en/product-master/12.0.0?topic=overview-product-attributes) describes this split as core attributes and extension attributes. Core attributes are common across products, while extension attributes are specific to product types or categories.

This is a useful model for ecommerce teams. Keep a shared core record, then extend it by category.

### 3. Use controlled values where systems need structure

Free text is useful for descriptions. It is risky for fields that power filters, feeds, taxonomy, and recommendations.

Use controlled values for high-impact fields such as color, size, material, product type, condition, gender, age group, compatibility, and certification status. Keep synonyms and display labels if needed, but store a normalized value underneath.

### 4. Enrich missing attributes from trusted sources

Many catalogs are not wrong. They are thin.

[Product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) fills gaps in product records by extracting, normalizing, and validating missing details from trusted inputs such as supplier specs, product pages, manufacturer sheets, images, reviews, or internal systems.

Be careful with inferred values. It may be safe to infer that a linen dress belongs in apparel. It is not safe to invent exact fabric composition, compatibility, or safety claims without evidence.

### 5. Validate before publishing or syndicating

Validation should happen before attributes reach a product page, feed, marketplace, API, or AI-facing surface.

Useful checks include:

* required-field completeness by category and destination
* accepted values for controlled fields
* unit and format validation
* duplicate SKU or variant detection
* image and URL checks
* price and availability freshness
* compatibility between category and attributes
* channel-specific feed and structured data rules.

Validation turns attribute management from cleanup into quality control.

### 6. Monitor live behavior

Downstream systems often reveal attribute problems. Review feed warnings, structured data errors, zero-result searches, weak filter usage, high-return products, support questions, marketplace rejections, and AI-shopping prompts where products are missing or described incorrectly.

Those signals tell you which attributes need better coverage, normalization, or ownership.

## Product attributes and AI commerce

AI commerce raises the standard for product attributes because AI systems need product facts they can parse, compare, and trust.

A human shopper can read a product page and infer that a chair is stackable, wipe-clean, and good for a small kitchen. A shopping agent or recommendation model needs those details stated clearly in the product record: product type, material, dimensions, color, stackability, care, use case, price, availability, and variant options.

That does not mean every product record should be longer. It means the important facts should be specific, structured, current, and traceable.

Catalog is built around this version of the problem. It returns live, normalized product objects with structured fields, variant-level price and stock, and optional enrichment. For teams building AI shopping, search, comparison, or recommendation systems, the value is not just having more text. It is having product attributes in predictable fields that software can use without brittle scraping or silent guesses.

In AI shopping, adjectives are less useful than facts. Brands with clear, current product attributes are easier for machines and shoppers to understand.

## FAQ

### What are examples of product attributes?

Examples of product attributes include name, brand, SKU, GTIN, category, size, color, material, dimensions, weight, ingredients, compatibility, care instructions, price, availability, condition, shipping details, warranty, and product images. The best attribute list depends on the category. Apparel needs fit and fabric. Electronics need technical specifications. Beauty products need shade, ingredients, and usage details.

### What is the difference between product attributes and product features?

Product attributes are structured facts about a product. Product features are notable capabilities or characteristics that the customer may care about. For example, `material: recycled nylon` is an attribute. `made with recycled materials` is a feature claim. `lower-impact material choice` is a benefit. Strong feature and benefit copy should be grounded in accurate attributes.

### How many product attributes should a product have?

A product should have enough attributes to make it findable, comparable, valid for its channels, and clear to the buyer. There is no universal number. A simple candle may need a short set of fields. A laptop, supplement, appliance, or replacement part may need dozens of technical, compatibility, compliance, and commercial attributes.

### How are product attributes used in product feeds?

Product feeds use attributes to send product information to channels such as Google Merchant Center, marketplaces, retailers, social commerce catalogs, and affiliate partners. Common feed attributes include ID, title, description, link, image link, brand, GTIN, price, availability, condition, product type, shipping, and category-specific fields. If required attributes are missing or formatted incorrectly, the channel may reject, limit, or display the product incorrectly.

### Do product attributes matter for AI shopping?

Yes. AI shopping systems need precise product facts to classify, compare, and recommend products. Clear attributes such as category, material, size, compatibility, price, availability, variants, policies, and use cases reduce ambiguity. They also help AI systems answer more specific shopping questions without guessing from thin product descriptions.

---

Canonical: https://www.getcatalog.ai/blog/product-attributes-guide
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Inventory management process: 7 steps and checklist

*July 22, 2026 · Catalog Team · Product Data · 24 min read*

> A practical guide to the inventory management process, with seven steps, role-based checkpoints, a worked SKU example, KPIs, and an implementation checklist.

The inventory management process is the repeatable way a business plans, buys, receives, stores, sells, fulfills, counts, and replenishes stock. It connects demand planning to the physical unit and then connects that unit to every customer promise made across the business.

A useful process makes every handoff explicit. Someone owns the decision, the next team knows which inputs to trust, a checkpoint releases the work, and the output becomes the next step's input. Counts, stockouts, returns, and channel errors then feed the next planning cycle.

This guide lays out the seven-step workflow, shows one SKU moving through it, and gives you the checkpoints, tools, metrics, and implementation checklist needed to run it.

## What is the inventory management process?

The inventory management process is the end-to-end operating system for deciding what stock to carry, where to hold it, how to track it, when to sell it, and when to replenish it. It connects merchandising, demand planning, purchasing, suppliers, warehouses, stores, finance, ecommerce, marketplace operations, and customer support.

Inventory management is broader than inventory control. Inventory control keeps records accurate, tracks location and condition, and controls stock movement. Inventory management includes those controls plus forecasting, purchasing, replenishment policy, supplier coordination, channel allocation, fulfillment decisions, and performance review.

A product record gives each unit a stable identity. It can include a SKU, variant, [GTIN](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number), supplier code, unit of measure, price, dimensions, and availability rules. A [product catalog](https://www.getcatalog.ai/glossary/product-catalog) describes what is being sold; the inventory record describes how many units exist, where they are, and what can be promised. Both records have to agree for the process to work across systems.

## Inventory management process map

Use the map below as a starting operating model. The accountable role owns the handoff, even when other teams perform part of the work. SKU means stock keeping unit. GTIN means Global Trade Item Number.

| Step | Accountable role | Inputs | Release checkpoint | Output | Failure signal |
| --- | --- | --- | --- | --- | --- |
| 1. Forecast demand and set policy | Inventory planner with merchandising and finance | Sales history, seasonality, campaigns, lead times, returns, margin, channel demand | Forecast exceptions and service priorities reviewed | Reorder points, safety stock, buy plan, channel rules | Stockouts, overstocks, emergency buys |
| 2. Set up item and supplier records | Product operations or merchandising | SKU, variant, GTIN, supplier unit, case pack, dimensions, cost, attributes | Item record approved for buying and selling | Trusted item master and channel-ready product record | Duplicate SKUs, broken variants, wrong pack size |
| 3. Purchase, receive, and inspect | Purchasing with warehouse and quality | Purchase order, advance shipment notice, barcode, quantity, lot or serial data | Ordered, received, accepted, and held units reconciled | Sellable stock, quality holds, receipt variance | Shortages, damaged goods shipped, early availability |
| 4. Store, locate, and track | Warehouse and inventory control | Bin or store location, status, on-hand, reserved, damaged, in-transit quantities | Units scanned into the right location and status | Accurate physical and system inventory | Pick errors, lost stock, phantom availability |
| 5. Publish sellable availability | Ecommerce or channel operations | On-hand, reservations, holds, safety stock, allocations, price, variant status | Availability and required channel fields validated | Current promises on storefronts, marketplaces, feeds, and APIs | Overselling, suppressed listings, stale promises |
| 6. Fulfill orders and update stock | Order management and fulfillment | Orders, allocation, picks, shipments, cancellations, returns | Reservation, shipment, and exception statuses recorded | Customer shipment and updated stock status | Backorders, cancellations, double-selling |
| 7. Audit, reconcile, and improve | Inventory control with operations leadership | Cycle counts, shrink, returns, supplier variances, forecast error, channel warnings | Variances have a cause, correction, and owner | Corrected records and revised policy | The same exception repeats next cycle |

Inventory is a loop rather than a one-way line. The last step should change the first step's assumptions. A receiving variance can change a supplier rule, a stockout can change the forecast, and a channel rejection can change the item setup or publication rule.

## The seven steps in the inventory management process

### 1. Forecast demand and set inventory policy

Start with the demand you expect to serve. Use sales velocity, seasonal patterns, promotions, supplier lead times, return behavior, marketplace demand, wholesale orders, store demand, and planned launches. Treat stockouts as a warning when reading sales history. A product that was unavailable could have more demand than its sales report shows.

The forecast becomes an operating policy with explicit decisions:

- Which products and locations need the tightest monitoring?
- What reorder point triggers a purchase or production order?
- How much safety stock should each product and location carry?
- Which products can tolerate a stockout, and which customer promises cannot?
- How should scarce units be allocated across stores, ecommerce, marketplaces, and wholesale?
- How much cash and storage capacity can slow-moving stock consume?

A simple starting formula is:

`Reorder point = expected demand during supplier lead time + safety stock`

Track inventory position separately from physical on-hand:

`Inventory position = on-hand + on-order - reserved`

The planner can then compare the inventory position with the reorder point without treating units already promised to customers as available.

**Checkpoint**

- **Owner:** Inventory planner.
- **Inputs:** Demand history, lead time, campaign calendar, returns, margin, and service priorities.
- **Check:** Review exceptions such as demand acceleration, supplier delay, high returns, or a new promotion.
- **Output:** Approved reorder points, safety stock, order quantities, and channel priorities.

### 2. Prepare product, supplier, and variant records

Before inventory can move cleanly, the business needs a single definition of each stocked item. A stocked color, size, pack, bundle, or configuration usually needs its own SKU when it is bought, priced, picked, shipped, returned, or reported separately. A GTIN can identify a trade item across companies, while a SKU is an internal identifier. The [SKU guide](https://www.getcatalog.ai/blog/what-is-a-sku) explains the distinction in more detail.

The item record should include the fields the next teams actually need:

- SKU, variant relationship, GTIN or other approved identifier, and supplier item number
- Unit of measure, case pack, inner pack, and conversion rules
- Dimensions, weight, handling instructions, and storage constraints
- Cost, price, tax category, and currency where applicable
- Category, attributes, compatibility, expiry, lot, or serial requirements
- Channel rules for availability, fulfillment, and publication

Common failures begin before the first unit arrives. A supplier may send cases while the commerce system expects individual units. A color variant may be created as a new parent product. A duplicate identifier may connect stock to the wrong listing. The item setup checkpoint should catch these problems before purchasing or receiving.

Strong [product data quality](https://www.getcatalog.ai/blog/product-data-quality) means that the fields are accurate, complete, consistent, timely, valid, unique, and useful to the systems that depend on them. That standard applies to the operational fields above as well as to shopper-facing product content.

**Checkpoint**

- **Owner:** Product operations or merchandising.
- **Inputs:** Supplier specification, item master, variant rules, identifiers, pack data, and required channel fields.
- **Check:** Confirm that one SKU maps to the right sellable unit and that unit, pack, variant, and identifier relationships are unambiguous.
- **Output:** Approved item master record that purchasing, receiving, fulfillment, and channels can use.

### 3. Purchase, receive, and inspect inventory

Turn the plan into a purchase order, manufacturing order, transfer order, or supplier commitment. Receiving then verifies that the right goods arrived in the right quantity and condition.

Receiving should capture:

- Purchase order, supplier, and shipment reference
- SKU, barcode, GTIN, lot, serial, or expiry data where relevant
- Quantity ordered, shipped, received, accepted, and rejected
- Case-pack or unit-of-measure differences
- Damage, substitution, quality hold, and compliance status
- Putaway location and status
- Landed cost or invoice variance when finance needs it

Do not make stock sellable because a truck arrived. The goods may need inspection, labeling, kitting, quarantine, or a location assignment. Use explicit statuses such as inbound, quality hold, available, damaged, and rejected so the next system can distinguish physical presence from a customer promise.

**Checkpoint**

- **Owner:** Receiving lead, with purchasing and quality support.
- **Inputs:** Purchase order, advance shipment notice, barcode scan, count, and inspection result.
- **Check:** Reconcile ordered, received, accepted, and held quantities. Record the reason for every variance.
- **Output:** Sellable inventory in a known location plus documented holds, rejects, and supplier discrepancies.

### 4. Store, locate, and track inventory

Inventory has to be physically findable and digitally trustworthy. Track the location and status of each unit or lot across warehouses, stores, third-party logistics providers, and in-transit movements. At minimum, distinguish on-hand, reserved, available, damaged, returned, quarantined, and in-transit quantities.

The gap between the system record and the physical count is a central operational risk. A study of nearly 370,000 retail inventory records across 37 stores found that 65% were inaccurate, and identified auditing practices as one factor that can reduce inaccuracy. [The study](https://ideas.repec.org/a/inm/ormnsc/v54y2008i4p627-641.html) is older, but the control lesson still applies: a forecast and reorder rule cannot fix a count that nobody trusts.

Cycle counting is the practical control. Count high-value, high-velocity, high-variance, or high-risk SKUs more often instead of waiting for one annual count. Use the variance to investigate receiving, putaway, picking, returns, shrink, and manual adjustments. RFID, barcodes, mobile scanning, warehouse management systems, and perpetual inventory systems can reduce manual work when they fit the operation. McKinsey reports demonstrated RFID improvements of more than 25% in inventory accuracy, along with reductions in inventory-related labor hours. [Its research](https://www.mckinsey.com/industries/retail/our-insights/rfids-renaissance-in-retail) describes the results as observed benefits, not a guarantee for every retailer.

**Checkpoint**

- **Owner:** Warehouse lead or inventory-control lead.
- **Inputs:** Scan events, bin map, transfer records, stock statuses, and count results.
- **Check:** Confirm that system quantity, location, and status match the physical unit before publishing or allocating it.
- **Output:** A traceable inventory record that can support the next availability and fulfillment decision.

### 5. Calculate and publish sellable availability

Availability is not the same as on-hand. A common exposed quantity is on-hand minus reservations, damaged or quarantined units, safety stock, and channel holds. The exact rule depends on the business, but it must be defined once and applied consistently.

Publish that quantity, along with the product and variant facts needed to interpret it, anywhere a customer or downstream system makes a decision:

- Ecommerce product pages and search
- Store pickup and local delivery
- Marketplaces and partner catalogs
- Shopping ads and product feeds
- Internal sales and support tools
- APIs and AI shopping surfaces

Omnichannel operations add locations, channels, and allocation decisions to the process. McKinsey notes that customers expect real-time visibility into inventory and that cross-channel systems need to share availability and delivery-time information. [Its omnichannel research](https://www.mckinsey.com/industries/retail/our-insights/into-the-fast-lane-how-to-master-the-omnichannel-supply-chain) also recommends channel-level forecasting and cross-channel inventory pools.

Channel validation matters as much as update speed. Google Merchant Center warns that incorrect, inaccurate, or missing product information can cause disapprovals, limited eligibility, or incorrect product displays. [Its product-data specification](https://support.google.com/merchants/answer/7052112) lists wrong identifiers, missing variant attributes, and conflicts between a feed and a website among the common causes.

A [product data feed](https://www.getcatalog.ai/glossary/data-feed) or [syndication workflow](https://www.getcatalog.ai/blog/product-data-syndication) should therefore carry the approved product, price, variant, and availability values with a freshness rule that matches the risk. High-velocity stock and price changes need faster updates than slow-moving descriptive attributes.

**Checkpoint**

- **Owner:** Ecommerce or channel operations.
- **Inputs:** On-hand, reservations, holds, safety stock, allocation rules, product and price records, and channel requirements.
- **Check:** Recalculate sellable quantity, validate required fields, and measure the time from a source change to each channel.
- **Output:** A current, channel-specific availability promise with a recorded freshness timestamp.

### 6. Fulfill orders and update stock immediately

Fulfillment turns availability into a customer commitment. The basic sequence is order capture, reservation, allocation, pick, pack, ship, order-status update, inventory decrement, and downstream availability update.

The sequence needs clear status transitions. A canceled order may release a reservation. A returned unit may need inspection before it becomes available. A damaged unit should leave sellable stock even if it remains physically present. A partial shipment should decrement only the units that shipped.

Allocation should respect location, channel priority, safety stock, promised delivery time, and substitutions. When the last unit sells on one channel, reserve or decrement it before other channels continue showing it. The key metric combines shipment completion with whether the process reserved the right unit and updated every dependent record quickly enough.

**Checkpoint**

- **Owner:** Order-management lead and fulfillment lead.
- **Inputs:** Order lines, available inventory by location, allocation rules, pick and ship events, cancellations, and returns.
- **Check:** Confirm the reservation, pick, shipment, and exception statuses before releasing the order and changing availability.
- **Output:** Shipped order, correct remaining stock, and classified returns or exceptions.

### 7. Audit, reconcile, and improve

The final step turns the workflow back into planning. Review counts, shrink, damaged goods, returns, supplier variances, forecast error, stockouts, overstock, backorders, channel warnings, and slow updates. Correct the record and assign a root cause rather than making an unexplained adjustment.

A useful review asks which part of the process failed:

- Did the forecast miss demand, or did the product go unavailable during the period?
- Did the supplier ship short, or did receiving record the wrong unit?
- Did a return remain in a hold status, or did it re-enter sellable stock too early?
- Did the source record change, or did a feed or API fail to publish it?
- Did allocation follow policy when inventory was scarce?

ECR Retail Loss reports that a 2025 follow-up study of 11 stores found inventory audits led to an 11% increase in store-wide sales over the following two months in matched stores, with gains concentrated on items whose system records overstated actual stock. [The report](https://ecrloss.com/fixing-broken-inventory-inventory-records-increases-sales-by-eleven-percent/) supports targeted auditing as a revenue control alongside compliance.

**Checkpoint**

- **Owner:** Inventory control lead with operations leadership.
- **Inputs:** Physical counts, transaction history, supplier and channel exceptions, and KPI trends.
- **Check:** Correct the record, document the cause, assign an owner, and change the policy or workflow when the cause is systemic.
- **Output:** A clean starting point for the next forecast and a lower repeat-exception rate.

## Worked example: one SKU through the process

Suppose a retailer sells a waterproof trail boot in black, size 9. The internal SKU is `TRL-BOOT-BLK-09`. The GTIN, supplier code, and variant relationship are already approved in the item master.

The inventory planner forecasts 8 units per day. Supplier lead time is 14 days, and the policy holds 24 units as safety stock.

`Reorder point = (8 units x 14 days) + 24 safety-stock units = 136 units`

At the weekly review, the warehouse has 150 units on hand, 18 already reserved for orders, and no units on order. Inventory position is therefore 132 units, below the 136-unit reorder point. The planner places a purchase order for 160 units.

| Point in the loop | Role | Input and checkpoint | Output |
| --- | --- | --- | --- |
| Forecast | Inventory planner | 8 units per day, 14-day lead time, 24 safety-stock units; inventory position is 132 | Approved PO for 160 units |
| Receive | Receiving and quality | PO expects 160; scan and inspection accept 156 and place 4 damaged units on hold | 156 units available for putaway, 4 units quarantined |
| Publish | Channel operations | System now holds 306 units, with 18 reserved; subtract 24 safety-stock units | 264 units exposed, allocated as 220 to the website and 44 to a marketplace |
| Fulfill | Order management and warehouse | A website order captures 6 units; reserve, pick, ship, and then decrement | 300 units remain on hand, with 18 other units still reserved |
| Reconcile | Inventory control | Cycle count finds 299 units while the system says 300 | Adjust the record to 299 and investigate the missing unit before the next review |

The example shows why each handoff matters. A receiving error changes the available quantity. A stale channel value creates a false promise. A missing shipment update leaves the system overstated. A count variance changes the next reorder decision.

## Operational checkpoints for every handoff

The process map gives each step an owner and output. Use this smaller handoff review to make the controls visible in daily operations.

| Handoff | Evidence to retain | Leading signal |
| --- | --- | --- |
| Demand plan to buy plan | Forecast version, exceptions, lead-time assumption, approval | Forecast error, stockout risk, days of supply |
| Item setup to purchasing | Approved SKU, variant, identifier, unit, and case-pack record | Setup completion, duplicate identifier rate |
| Purchase order to receiving | PO, shipment notice, ordered and received quantities, variance reason | PO-to-receipt variance, quality-hold rate |
| Receiving to storage | Scan, putaway location, status, and time accepted | Putaway time, unlocated inventory |
| Storage to availability | On-hand, reserved, held, safety-stock, and allocation calculation | Inventory record accuracy, availability freshness lag |
| Availability to listing | Feed or API response, channel validation, warning status | Rejection rate, listing warning rate |
| Order to shipment | Reservation, allocation, pick, ship, cancel, and return events | Fill rate, cancellation rate, decrement lag |
| Count to policy | Count result, variance cause, correction, and assigned owner | Cycle-count variance, repeat-exception rate |

A checkpoint should change behavior. If the same SKU, supplier, location, or channel appears in the report every week, assign a corrective action and change the rule that allowed the failure.

## Common failure points and corrective checks

IHL Group's 2026 Inventory Distortion Study estimates that out-of-stocks and overstocks together cost global retail $1.7 trillion in 2026. It attributes 65.6% of the total to out-of-stocks and 34.4% to overstocks. [The research summary](https://www.ihlservices.com/news/ihl-research-findings/) gives the scale of the problem, while the process below identifies where to intervene.

| Symptom | Likely break | Corrective check |
| --- | --- | --- |
| A product sells after the last unit is gone | Reservation or availability update is late | Measure source-to-channel freshness and reserve before publication |
| A size or color shows the wrong stock | Parent-child variant or identifier mapping is wrong | Approve the variant relationship and test each sellable SKU |
| Receiving or shipping uses the wrong quantity | Unit, case-pack, or conversion rule differs by system | Compare supplier units with the item master before the PO is released |
| A listing is suppressed or rejected | Required attributes, identifier, price, or availability conflict | Keep a channel validation report with an owner and response time |
| A spreadsheet becomes the live source of truth | Manual copies drift from the system of record | Use spreadsheets for analysis and exceptions, then write approved changes to the source system |
| Physical stock does not match the record | Mispick, shrink, damage, return, transfer, or manual adjustment was missed | Run risk-based cycle counts and document every variance |
| A return becomes sellable too soon | Inspection and status transitions are unclear | Separate returned, inspected, sellable, damaged, and quarantined states |
| The forecast misses a channel's demand | Marketplace, store, wholesale, or promotion data is absent | Include channel demand and stockout periods in the planning review |

Spreadsheet errors are a known control risk. The Institute of Chartered Accountants in England and Wales cites research finding that as many as 90% of spreadsheets contain a mistake. [Its review guidance](https://www.icaew.com/technical/technology/excel-community/excel-community-articles/2022/how-to-review-a-spreadsheet-part-1) explains why low cell-level error rates can become material across large workbooks.

## Inventory management techniques and tools

Choose techniques and systems after defining the process. A WMS can improve receiving and picking, but it cannot set a sensible safety-stock policy. A product-data system can improve item records and distribution, but it cannot count physical units or allocate an order.

| Technique or tool | What it means | Where it helps |
| --- | --- | --- |
| ABC analysis | Group inventory by business value so the most important SKUs receive tighter control | Prioritizing counts, safety stock, and planning attention |
| Safety stock | Extra inventory held to absorb demand or supply variation | Protecting service levels for important products |
| Reorder point | The inventory position that triggers replenishment | Turning policy into a repeatable buy signal |
| Economic order quantity (EOQ) | A model that balances ordering and holding costs | Setting order quantities for stable-demand items |
| Just-in-time (JIT) | Stock arrives close to the time it is needed | Reducing holding cost when supply and demand are reliable |
| FIFO and FEFO | First in, first out and first expired, first out | Managing dated, perishable, lot-controlled, or aged stock |
| Cycle counting | Regular partial counts instead of one annual full count | Finding record errors while they can still be corrected |
| Warehouse management system (WMS) | Software for receiving, putaway, picking, packing, and location control | Running warehouse execution |
| Enterprise resource planning (ERP) | Software for finance, purchasing, inventory valuation, procurement, and master data | Connecting inventory to financial and purchasing controls |
| Order management system (OMS) | Software for routing, allocation, fulfillment status, cancellations, and returns | Coordinating orders across locations and channels |
| PIM or product-data layer | A system for product attributes, variants, identifiers, enrichment, and distribution | Keeping product records usable across channels |
| Feeds and APIs | Scheduled or programmatic paths for sharing approved data | Publishing inventory, prices, and product facts to downstream systems |

## Inventory management KPIs to track

Use metrics that expose both stock outcomes and the handoff that produced them. Pair a lagging result with a leading signal so the team can act before the customer promise fails.

| KPI | What it tells you | Pair it with |
| --- | --- | --- |
| Stockout rate | How often products are unavailable when demand exists | Availability freshness, forecast exception rate |
| Overstock or aged inventory | How much stock is not moving at the planned pace | Days of supply, sell-through by age bucket |
| Sell-through rate | How quickly received inventory becomes sales | Campaign calendar, receipt timing |
| Inventory turnover | How efficiently inventory investment becomes revenue | Margin, purchase frequency, aged stock |
| Days inventory on hand | How long current stock lasts at the current sales pace | Lead time, reorder point, safety stock |
| Inventory record accuracy | How closely system counts match physical counts | Cycle-count variance, count completion |
| Cycle-count variance | Where and how often records diverge | Location, SKU, process cause |
| Order fill rate | How often orders ship complete from available stock | Allocation failures, backorders |
| Backorder or cancellation rate | How often a promise fails after order capture | Reservation timing, channel freshness |
| Return-to-restock time | How quickly returned units receive the correct status | Inspection queue, damage rate |
| Availability freshness lag | How long a stock or price change takes to reach a channel | Feed or API errors, source event time |
| Channel rejection or warning rate | How often product, price, or inventory data fails validation | Missing fields, identifier and variant errors |

A high cancellation rate can come from a warehouse count problem, an allocation rule, a channel-sync delay, or an item setup mistake. Trace each KPI back to the handoff instead of treating the dashboard as the diagnosis.

## How to implement the inventory management process

Start with one location, one channel, or one product group. Document the process before buying another tool. Then use this checklist to make it operational:

1. **Define scope and ownership.** Name the accountable owner for planning, item setup, purchasing, receiving, storage, availability, fulfillment, and reconciliation. Document the source system and status names for each handoff.
2. **Establish the item master.** Standardize SKUs, variants, identifiers, units, case packs, dimensions, costs, and required channel fields. Block buying or publication when a required relationship is missing.
3. **Set the inventory policy.** Define the demand window, lead-time assumption, safety-stock method, reorder point, order quantity, channel priority, and treatment of damaged, returned, and quarantined stock.
4. **Choose the system of record.** Decide which system owns purchasing, physical quantity, reservations, orders, product facts, and channel publication. Do not let an unmanaged spreadsheet become a second source of truth.
5. **Set freshness service levels.** Match update frequency to risk. High-velocity products, reservations, prices, marketplaces, and pickup promises need faster updates than slow-moving descriptive fields.
6. **Design exception paths.** For each failure signal, define the threshold, owner, response time, evidence, and escalation. A report without an action owner is only an observation.
7. **Run risk-based cycle counts.** Use value, velocity, variance, perishability, and customer impact to set count frequency. Record the cause and correction with each count.
8. **Review the handoff KPIs.** Hold a short operational review for freshness lag, receipt variance, record accuracy, fill rate, cancellations, returns, and channel warnings. Connect every change to a step in the map.
9. **Close the loop.** Change the forecast, item rule, supplier requirement, allocation rule, or feed mapping when a root cause repeats. Re-run the example SKU or a comparable item through the process after each major change.

## FAQ

### What are the main steps in the inventory management process?

The seven steps are forecasting and policy, item and supplier setup, purchasing and receiving, storage and tracking, sellable-availability publication, order fulfillment, and audit or reconciliation. The process is a loop, so count variances, returns, stockouts, and channel errors should change the next planning cycle.

### What is the difference between inventory management and inventory control?

Inventory control is the discipline of keeping stock records accurate, locating units, managing status, counting inventory, and preventing loss or misplacement. Inventory management is broader. It includes those controls plus forecasting, purchasing, replenishment, allocation, fulfillment, and performance improvement.

### Where does product data fit into inventory management?

Product data defines the item that inventory is attached to. SKU, variant, identifier, unit, pack, dimensions, price, and availability rules affect receiving, storage, fulfillment, and channel publication. A physically present unit can still be mislisted or mispromised when its product record is wrong.

### How often should inventory data be updated?

Update it as often as the risk of a bad promise requires. High-velocity products, reservations, prices, marketplaces, store pickup, and other customer-facing availability usually need near-real-time or event-driven updates. Slower descriptive fields can use scheduled batches when the channel allows it.

### Who owns the inventory management process?

One operations leader should be accountable for the end-to-end process, with named owners for each handoff. Planning, merchandising, purchasing, warehouse, ecommerce, fulfillment, finance, and customer operations can share the work, but each transition needs one person responsible for the checkpoint and metric.

## Where Catalog fits

We fit in the product-data layer around the inventory process. Catalog can structure product, variant, price, stock, and attribute data, keep approved values synchronized, and make those records usable by downstream channels, including AI shopping surfaces.

We are not a warehouse management system, ERP, order management system, replenishment planner, or physical inventory source of truth. We do not replace forecasting, receiving, cycle counts, reservation, allocation, or fulfillment. Those systems and teams still run the operational process.

If your warehouse and planning workflows are in place but product and availability facts are difficult to keep consistent across channels, [see how Catalog handles structured product data](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/inventory-management-process
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Ecommerce filters: how to improve product discovery with better data and UX

*July 22, 2026 · Catalog Team · Product Data · 15 min*

> A practical guide to ecommerce filters, faceted navigation, filter UX, product attribute quality, and SEO crawl control.

Ecommerce filters help shoppers turn a large product list into a smaller set of products that match their needs. A shopper can filter by size, color, price, availability, rating, delivery speed, compatibility, material, or any other attribute that affects the buying decision.

Good filters feel simple from the outside. Under the surface, they depend on two systems working together: clean product data and clear user experience. If attributes are missing, duplicated, or inconsistently labeled, the filter UI cannot show the right choices. If the UI hides active filters, returns empty results, or uses language shoppers do not understand, complete data still will not help people find the right product.

That makes ecommerce filters more than a sidebar on a category page. They are a product discovery system. They influence how shoppers browse, how merchandisers guide demand, how search engines crawl category pages, and how much value a store gets from its product catalog.

## What are ecommerce filters?

Ecommerce filters are controls that narrow a product list by selected product attributes. Instead of scanning every item in a category, shoppers choose the criteria that matter to them and see only matching products.

Common ecommerce filters include:

- Price
- Brand
- Size
- Color
- Material
- Rating
- Availability
- Delivery or pickup options
- Product type
- Use case, occasion, or style
- Category-specific specifications, such as storage size for laptops or width for furniture

[Baymard](https://baymard.com/learn/ecommerce-filter-ui) defines an ecommerce filter as a UI mechanism that lets shoppers narrow a product catalog by selecting specific attributes such as price, size, color, brand, or customer rating. [Nielsen Norman Group](https://www.nngroup.com/articles/filters-vs-facets/) describes a filter as anything that analyzes a set of content and excludes items that do not meet a criterion.

Filters are often discussed with facets, faceted navigation, search, and sorting. They are related, but they do different jobs.

| Term | What it does | Ecommerce example |
| --- | --- | --- |
| Search | Finds products that match a query | Searching for "running shoes" |
| Filter | Narrows a product set by criteria | Showing only size 10 shoes under $150 |
| Facet | One attribute dimension used for filtering | Size, price, color, brand, or activity |
| Faceted navigation | Lets users combine multiple facets | Nike + black + trail running + waterproof |
| Sorting | Reorders the current product set | Lowest price, highest rated, newest |

A strong product discovery experience usually uses all of these together. Search gets the shopper to a starting set. Filters help them remove irrelevant products. Sorting helps them prioritize the relevant products that remain.

When people talk about ecommerce faceted search or ecommerce filters UX, they are usually talking about this combined system: the data, controls, and page behavior that let shoppers narrow a large catalog without losing context.

## Why ecommerce filters matter for product discovery

Filters matter because most ecommerce catalogs are too large to browse manually. Even a category with 80 products can feel unmanageable when the products differ by size, material, compatibility, price, or availability. Filters reduce the work needed to find a product that fits the shopper's situation.

They also make products discoverable. If a shopper wants a washable wool rug, a stainless steel water bottle, or a laptop with 32 GB of RAM, those products need filterable attributes. Without them, the products may exist in the catalog but stay invisible to the buyer.

[Baymard's filtering examples page](https://baymard.com/ecommerce-design-examples/filtering-options) says 34% of tested ecommerce sites have poor filtering implementation. The same page reports that sites with mediocre product-list usability saw 67% to 90% abandonment for users trying to find the same types of products, while sites with a slightly optimized toolset saw 17% to 33% abandonment.

Those numbers point to a practical truth: filters affect revenue because they affect product finding. The filter experience is often the bridge between a category page and a product detail page. If that bridge is unclear, shoppers may assume the store does not carry what they need.

Filters also create useful merchandising signals. Filter usage can show which attributes shoppers care about, where products are missing important data, which categories create zero-result dead ends, and which product dimensions deserve more prominent merchandising.

## The product data behind useful filters

A filter is only as useful as the product data behind it. The UI can show a clean checkbox list, but the results will still be bad if the underlying attributes are incomplete, stale, or inconsistent.

A useful filter needs five kinds of product data quality.

### 1. Attribute completeness

Every product that should qualify for a filter needs the relevant attribute filled in. If half of the shirts have a `fit` value and half do not, the `fit` filter becomes unreliable. A shopper who selects "relaxed fit" may miss products that match but were never tagged.

Attribute completeness is especially important for category-specific filters. A general apparel category may need size, color, brand, material, fit, and gender. A laptop category may need processor, memory, storage, screen size, operating system, graphics card, and battery life. A furniture category may need dimensions, material, room, assembly, delivery method, and finish.

### 2. Value normalization

Filter values need consistent names. If product data contains `navy`, `dark blue`, `blue navy`, and `midnight`, shoppers may see a messy color filter or get incomplete results when they choose one option.

Normalization turns those messy values into a controlled set. The goal is not to flatten useful detail. It is to make sure the value shown to shoppers maps cleanly to the products they expect.

### 3. Category specificity

Generic filters rarely work across every category. Price, availability, brand, and rating may apply broadly, but the attributes that actually help someone buy are category-specific.

A home improvement store should not use the same filters for drill bits, refrigerators, paint, and patio furniture. A fashion retailer should not use the same filter priority for shoes, dresses, jewelry, and coats. Each category needs filters that match how buyers compare products in that category.

### 4. Customer-language labels

Internal taxonomy labels are often too technical for shoppers. A product team may use `upper material`, `closure type`, `lifecycle status`, or `program eligibility`. A shopper may look for "leather," "zip," "new arrival," or "pickup today."

Use the words customers use in site search, reviews, support tickets, and product questions. This is where [ecommerce product data](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) and UX research meet. The attribute may be technical in the database, but the label should be clear in the product list.

### 5. Freshness

Filters need to reflect current inventory, pricing, variants, and fulfillment promises. "In stock," "pickup today," "on sale," and "ships by Friday" are only useful if they stay synced with operational data.

This is why [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) should not be a one-time cleanup project. It should feed a reliable, updated product catalog that can support storefront search, filters, recommendations, ads, feeds, and AI shopping surfaces.

## Ecommerce filter types to consider

There is no universal list of filters every ecommerce site should copy. The right set depends on the catalog, category, customer intent, and product data maturity. A good starting point is to group filters by the job they do.

| Filter type | Use it for | Examples |
| --- | --- | --- |
| Universal filters | Common buying criteria across many categories | Price, brand, rating, availability |
| Variant filters | Product options shoppers often know before they browse | Size, color, width, fit, finish |
| Category-specific specifications | Technical or category-specific comparison criteria | RAM, screen size, capacity, material, dimensions, compatibility |
| Thematic filters | Exploratory shopping or gift/occasion intent | Wedding guest, back to school, work from home, outdoor, minimalist |
| Merchandising filters | Business-led or time-sensitive product groups | Sale, new arrival, bestseller, limited stock, bundle eligible |
| Fulfillment filters | Availability and convenience criteria | In stock, pickup today, fast shipping, local delivery |
| Visual filters | Attributes where words alone are not enough | Color swatches, shape chips, room-style images, fit guides |

The main rule is simple: make important product differences filterable. If shoppers compare products by an attribute, and the catalog has enough products for that attribute to matter, it is a filter candidate.

The inverse is also true. Do not add filters just because the data exists. A filter that almost nobody uses, contains unclear values, or creates tiny result sets can add noise. Start with product-finding tasks, then choose filters that help shoppers complete those tasks faster.

## Ecommerce filters best practices for better UX

The best filter UX helps shoppers understand three things at all times:

1. What can I narrow by?
2. What have I already selected?
3. What will happen if I add or remove a filter?

These practices support that goal.

### Allow multi-select inside a filter group

Shoppers often want more than one value within the same filter group. Someone may want black or gray sneakers, medium or large shirts, or Bosch or Makita tools.

Use OR logic within a filter group and AND logic across filter groups. For example:

- Color: black OR gray
- Brand: Nike OR Adidas
- Size: 10
- Final result: products that match one selected color AND one selected brand AND size 10

[Baymard says 14% of benchmarked sites](https://baymard.com/learn/ecommerce-filter-ui) do not let users select multiple filter options. That forces shoppers into false either-or choices and can hide products they would have considered.

### Show result counts before users click

Counts help shoppers predict the effect of a filter. "Blue (34)" is more useful than "Blue" because it tells the shopper whether the filter will create a useful result set.

Counts are also a guardrail against over-filtering. If selecting one more option would reduce the list from 28 products to 1, the shopper can make that choice knowingly.

### Keep applied filters visible and removable

Applied filters should be visible near the product list, not only inside a hidden panel. Use filter chips, a summary row, or another clear overview that lets shoppers remove one filter at a time or clear everything.

[Baymard says 20% of ecommerce sites](https://baymard.com/learn/ecommerce-filter-ui) fail to keep applied filters visible. This creates orientation problems. Shoppers may forget why the product list looks narrow, assume inventory is limited, or struggle to broaden the results.

### Match filter behavior to the device

Desktop and mobile filters do not need identical behavior.

On desktop, instant updates can work well when results update quickly and the shopper can still see the product list. A persistent left sidebar is familiar, but a horizontal filter bar can work for simple categories when space is limited.

On mobile, a drawer or bottom sheet often works better because there is not enough room for a full sidebar. Use a clear "Show results" button with an updated count, keep the filter trigger easy to find, and show active filters above the product list after the drawer closes.

### Persist filter state

If a shopper filters a category, opens a product, and taps back, the same filters should still be applied. Losing state forces the shopper to rebuild their search and makes the store feel unreliable.

The safest approach is to reflect filter state in the URL or app state in a way that survives product-page navigation. This also makes filtered views easier to share, debug, and analyze.

### Order filters by importance

Do not default to alphabetical order if it hides the most useful filters. The best order depends on the category and shopper task.

For apparel, size and fit may belong near the top. For electronics, compatibility and specifications may matter more. For grocery, dietary needs, brand, and availability may matter most. Use behavior data, search terms, customer questions, and merchandising priorities to choose the order.

### Make long filter groups manageable

Long lists need help. If a brand filter contains 180 brands, do not make shoppers scroll through all of them in a tiny panel.

Use search within the filter group, show the most common options first, provide a "show more" control, and keep selected values visible. For visual attributes, such as color or shape, use accessible swatches or image chips with text labels.

These choices sit alongside [search merchandising](https://www.getcatalog.ai/blog/search-merchandising) and [site merchandising](https://www.getcatalog.ai/blog/site-merchandising). Filters are not isolated controls. They are part of how the store guides demand toward the right products.

## Faceted navigation SEO: what to index and what to block

Faceted navigation can create SEO problems when every filter combination becomes a crawlable URL. A store with category, size, color, brand, price, rating, and sort parameters can generate thousands or millions of URL combinations from one category page.

[Google Search Central warns that URL-parameter-based faceted navigation can create effectively infinite URL spaces](https://developers.google.com/search/docs/crawling-indexing/crawling-managing-faceted-navigation). The two risks Google calls out are overcrawling and slower discovery crawls. If crawlers spend time on low-value filtered URLs, they have less time for useful category pages, product pages, and new content.

The SEO question is not "Should filtered pages exist?" It is "Which filtered pages deserve to be crawlable and indexable?"

Index a filtered page only when it has durable search value. For example, a page for "women's waterproof hiking boots" may be useful if people search for that exact product set, the page has stable inventory, and the content is meaningfully different from the parent category. A URL for `?color=navy&sort=price_desc&page=7` usually should not be indexed.

A practical faceted-navigation SEO plan should include:

- A clear rule for which facets can create indexable landing pages.
- Canonical handling for near-duplicate filtered pages.
- Robots.txt or crawl rules for low-value parameter combinations when appropriate.
- Noindex rules only where they fit the crawl/indexation strategy.
- Consistent parameter order so the same filter set does not create duplicate URLs.
- Internal links to durable category and subcategory pages, not every possible filter state.
- Monitoring for crawl spikes, duplicate titles, duplicate descriptions, and index bloat.

Filters are for shoppers first. Search engines should be able to crawl the pages that matter, but they should not be invited into every temporary product-list state.

## Common ecommerce filter mistakes

Most filtering problems come from a gap between product data, UX, and crawl rules. These are the mistakes to catch first.

### 1. Building filters from incomplete product attributes

If important products are missing the attribute, the filter hides them. Before launching a filter, check attribute coverage across the category. A filter should not go live just because some products have the data.

### 2. Reusing the same filters across every category

Generic filters make categories feel shallow. They also make specialized products harder to compare. Build a core set of shared filters, then add category-specific filters where they affect buying decisions.

### 3. Using labels shoppers do not understand

Unclear labels make shoppers skip useful filters. [Baymard says unclear industry-specific filter labels affect 25% of desktop sites and 40% of mobile stores](https://baymard.com/learn/ecommerce-filter-ui). Translate internal attribute names into plain customer language.

### 4. Hiding active filters

When active filters disappear inside a collapsed panel or mobile drawer, shoppers lose context. Keep a visible summary near the results.

### 5. Creating zero-result dead ends

Do not let shoppers select a combination that silently produces no products. Show counts, disable impossible options, or provide a clear recovery path that suggests which filter to remove.

### 6. Forcing single-select where multi-select is expected

Radio-button behavior works for mutually exclusive choices. It does not work for brands, colors, sizes, materials, or use cases where shoppers are open to several values.

### 7. Making every filter combination indexable

Faceted URLs can create crawl waste, duplicate pages, and thin indexable states. Define indexable combinations intentionally.

### 8. Treating filters as a one-time project

Catalogs change. New products introduce new attributes. Merchandising priorities shift. Shoppers use different language over time. Filters need maintenance, not just launch QA.

## How to audit and improve ecommerce filters

A filter audit should look at the full system: shopper tasks, product attributes, UI behavior, and crawl rules.

### 1. Start with product-finding tasks

Pick the categories and journeys that matter most. For each one, write down the tasks shoppers try to complete:

- Find a product in the right size and color.
- Compare products by compatibility.
- Find products available for pickup today.
- Narrow a broad category by use case.
- Find a gift by recipient, occasion, or budget.

These tasks tell you which filters matter.

### 2. Map required attributes by category

For each high-priority category, list the attributes that affect buying decisions. Then mark which ones already exist in the product catalog, which ones are missing, and which ones exist but need cleanup.

This is where a [product catalog](https://www.getcatalog.ai/glossary/product-catalog) becomes operational infrastructure. The same attributes that support filters can also support recommendations, feeds, product pages, marketplace listings, AI shopping answers, and [structured data](https://www.getcatalog.ai/glossary/structured-data).

### 3. Measure attribute coverage and consistency

For every proposed filter, check:

- What percentage of eligible products have this attribute?
- How many distinct values exist?
- Are there duplicate or near-duplicate values?
- Are values formatted consistently?
- Are values clear enough to show to shoppers?
- Does the attribute update when inventory, variants, or product facts change?

Do this before UI work. It is faster to fix data before it becomes a broken customer-facing filter.

### 4. Review filter behavior data

Useful metrics include:

- Filter usage rate by category.
- Most-used and least-used filters.
- Zero-result events.
- Product-list exits after filtering.
- Filter combinations that often precede product-page views.
- Filters that shoppers remove immediately after applying.
- Mobile filter open rate and apply rate.

No single metric proves filter quality. Look for patterns that show confusion, dead ends, or demand for attributes that are missing from the current experience.

### 5. Run task-based usability tests

Ask people to find specific products using the category page. Watch for hesitation, wrong turns, repeated filter opening, missed active filters, and moments where shoppers say the store does not have something it actually has.

A small number of well-chosen tasks can reveal issues analytics will not explain on its own.

### 6. Prioritize fixes by discovery impact

Fix the filters that affect important categories, high-margin products, frequent searches, and common zero-result paths first. You do not need to perfect every filter at once.

High-impact fixes often include:

- Completing missing attributes for top categories.
- Normalizing messy values.
- Renaming unclear labels.
- Adding result counts.
- Showing applied filters more clearly.
- Disabling impossible options.
- Creating crawl rules for low-value faceted URLs.

### 7. Keep filters synced with product operations

Filters should change when the catalog changes. New attributes, new categories, new variants, and new fulfillment promises all need a path into the filter system.

Catalog helps teams turn messy product data into live, normalized product objects. Better product discovery starts with product data that is complete enough for both people and machines to use.

## FAQ

### What is the difference between filters and facets?

A filter narrows a product list by one criterion, such as size or price. A facet is one attribute dimension within a larger faceted navigation system. In ecommerce, faceted navigation lets shoppers combine multiple filters, such as brand, size, color, material, and availability.

### What filters should an ecommerce site have?

Most ecommerce sites should consider price, availability, brand, rating, size, color, and category-specific product attributes. The exact set should depend on the category. A laptop category needs different filters than a dress, sofa, grocery, or replacement-part category.

### Should ecommerce filters update instantly?

On desktop, instant updates can work well when results update quickly and the shopper can still see what changed. On mobile, a deliberate "Show results" button is often clearer because shoppers may want to select several filters inside a drawer before applying them.

### Are ecommerce filters bad for SEO?

Ecommerce filters are not bad for SEO by themselves. The risk comes from letting every filter combination create a crawlable or indexable URL. Index filtered pages only when they satisfy real search demand, and control low-value parameter combinations so search engines can focus on useful category and product pages.

## The best filters are a data system and a UX system

Ecommerce filters work when shoppers can express what they want and the catalog can answer accurately. That requires clean attributes, useful labels, clear interaction patterns, and careful crawl rules.

If the product data is incomplete, filters hide relevant products. If the UX is unclear, shoppers cannot use the data. If faceted URLs are unmanaged, search engines waste time on low-value combinations.

Treat filters as part of the product discovery layer. The payoff is a store where products are easier to find, easier to compare, and easier for both shoppers and machines to understand.

---

Canonical: https://www.getcatalog.ai/blog/ecommerce-filters
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# What is a third-party marketplace?

*July 21, 2026 · Catalog Team · Product Data · 14 min read*

> Learn what a third-party marketplace is, how 3P selling works, examples like Amazon and Walmart, and what product data merchants need.

A third-party marketplace is an ecommerce platform where independent sellers list and sell products on a marketplace they do not own. The marketplace provides the audience, search and browse experience, checkout, payment flow, and rules of the channel. The seller manages the product offer: what gets listed, how it is described, how it is priced, where inventory sits, and how orders are fulfilled.

The term third party marketplace is often shortened to 3P marketplace. You will see the model on broad retail marketplaces like Amazon Marketplace, Walmart Marketplace, and eBay; niche marketplaces like Etsy; and newer social or creator-led shopping channels like TikTok Shop.

For merchants, the model is attractive because it can put products in front of shoppers who already trust the platform. It is also operationally demanding. Each marketplace has its own listing rules, product data fields, category structure, shipping expectations, fee model, and performance standards. Strong marketplace teams treat expansion as a product data and operations problem, not just a new place to upload SKUs.

## How a third-party marketplace works

A third-party marketplace has three main participants:

- **The marketplace operator** owns the platform, traffic, checkout, customer policies, seller rules, and often the advertising tools. Amazon, Walmart, eBay, and Etsy are common examples.
- **The third-party seller** lists products on the platform. The seller may be a brand, retailer, distributor, reseller, manufacturer, or individual merchant.
- **The customer** discovers the product through marketplace search, category pages, recommendations, ads, or external search, then buys through the marketplace experience.

The basic workflow looks like this:

1. The seller creates or matches a product listing.
2. The marketplace validates the listing against its category, identifier, image, policy, and product data rules.
3. The product becomes discoverable through marketplace search, browse, ads, recommendations, or external search engines.
4. The customer buys through the marketplace checkout.
5. The seller or a marketplace fulfillment program ships the order.
6. The marketplace tracks service quality through delivery performance, returns, reviews, response time, and policy compliance.

This is why a marketplace listing is more than a product page. It is a structured data object attached to price, availability, fulfillment, seller performance, reviews, advertising, and marketplace policy.

## Third-party marketplace examples

A third-party marketplace can be broad, niche, retailer-owned, B2B, social, or hybrid. The exact seller rules vary by platform, but the pattern is the same: independent sellers use another platform's commerce infrastructure to reach buyers.

| Marketplace type | Examples | How sellers use it |
| --- | --- | --- |
| Broad retail marketplace | [Amazon Marketplace](https://sell.amazon.com/sell), [Walmart Marketplace](https://marketplace.walmart.com/), eBay | Reach large, general-purpose shopping audiences across many categories. |
| Niche marketplace | Etsy, Reverb, Chairish | Reach shoppers with a category-specific intent, such as handmade goods, instruments, or furniture. |
| Retailer marketplace | Target Plus, Macy's Marketplace, Best Buy Marketplace | Sell through a retailer's digital shelf while following that retailer's seller and catalog requirements. |
| Social commerce marketplace | TikTok Shop, Facebook Marketplace | Connect product discovery to social content, creators, communities, and in-app checkout flows. |
| B2B or industry marketplace | Alibaba, Faire, industry-specific wholesale marketplaces | Sell to business buyers, distributors, retailers, or procurement teams. |

Amazon is the clearest example because it combines first-party retail, where Amazon buys and sells inventory itself, with third-party selling, where independent merchants sell through Amazon's marketplace. Walmart uses a similar marketplace model alongside its owned retail business. eBay is also a third-party marketplace, though it is built more around seller listings and auctions/fixed-price listings than retailer-owned inventory.

## Third-party marketplace vs first-party retail vs owned ecommerce

Marketplace language can get confusing because the same retailer can operate several models at once. The cleanest way to compare them is by asking who owns inventory, who controls the offer, and who owns the customer relationship.

| Model | Who sells to the customer? | Who usually owns inventory? | Who controls product data and pricing? | Best fit |
| --- | --- | --- | --- | --- |
| First-party retail, or 1P | The retailer | The retailer after buying from the brand/vendor | Retailer has more control; vendor supplies product information | Brands that want wholesale distribution through a retail partner. |
| Third-party marketplace, or 3P | The independent seller sells through the marketplace | The seller, unless using a marketplace fulfillment program | Seller controls the offer, but must follow marketplace data and policy rules | Merchants that want reach without giving up all channel control. |
| Owned ecommerce | The brand or retailer sells on its own site | The brand or retailer | The site owner controls the full product experience | Merchants that want direct customer data, brand control, and margin control. |

In first-party retail, a retailer buys products from a brand, sets retail terms, and sells to shoppers. In a third-party marketplace, the marketplace is the commerce platform, but the seller is still responsible for the offer. In owned ecommerce, the merchant controls the storefront, checkout, customer data, content, analytics, and policies.

Most mature merchants use more than one model. They may run a direct-to-consumer site, sell wholesale to retailers, and operate 3P marketplace listings for selected products or regions.

## Benefits of selling through third-party marketplaces

Third-party marketplaces are popular because they compress a lot of distribution infrastructure into one channel.

### Access to existing demand

Large marketplaces already have buyers, search behavior, category pages, ads, and trust. Walmart says more than 255 million customers and members shop Walmart online and in-store each week, and that Walmart U.S. Marketplace revenue grew 45% in FY24. Sellers still need to earn visibility, but they do not have to build all of their traffic from scratch.

### Faster channel expansion

A marketplace can be faster to test than launching a new regional ecommerce site, building local fulfillment from zero, or negotiating a wholesale relationship with every retailer. Sellers can start with a subset of products, learn from marketplace performance, then expand.

### Built-in commerce infrastructure

Marketplaces often provide seller dashboards, payment processing, fraud controls, buyer messaging, reviews, advertising, fulfillment programs, returns flows, and API access. For example, Walmart promotes tools for pricing, catalog management, shipping, returns, brand management, Seller Center, APIs, and advertising.

### Channel diversification

A merchant that depends only on its own site is exposed to changes in paid search costs, organic visibility, conversion rates, and customer acquisition. Marketplaces add another route to demand. They can also help merchants test which products, bundles, or price points work outside the owned storefront.

### Customer trust

Shoppers may be more comfortable buying from a known marketplace than from a brand they have never visited. The platform's reviews, checkout, buyer protection, and shipping promises can reduce friction, especially for a new brand or new market.

## Tradeoffs and risks

A third-party marketplace can increase reach, but it also reduces control. The tradeoffs matter before you commit a large catalog.

### Fees and margin pressure

Marketplaces usually charge referral fees, selling-plan fees, payment fees, advertising costs, fulfillment costs, storage costs, or some combination of these. The topline revenue may look strong while contribution margin is thinner than owned ecommerce.

### More competition on the same shelf

Marketplace shoppers compare similar products quickly. Price, reviews, shipping speed, images, attributes, and listing quality all influence who wins the click or the buy box equivalent.

### Less customer relationship control

The marketplace owns much of the transaction experience. Sellers may have limited access to customer data, limited retargeting options, and limited control over post-purchase communication.

### Channel rules can change

A marketplace can change category requirements, ad formats, fulfillment policies, return expectations, fee structures, or enforcement rules. Sellers need processes to detect and respond to those changes.

### Brand and quality risk

Third-party marketplaces can create brand-control problems, especially when unauthorized sellers, stale product data, counterfeit listings, gray-market inventory, or price undercutting appear. That is not a reason to avoid marketplaces. It is a reason to plan governance before the channel scales.

### Operational complexity

Every added channel creates more work around inventory, pricing, product content, orders, returns, and support. Without connected systems, teams fall back to spreadsheets and manual uploads. That creates slow updates and data errors.

## Product data requirements for marketplace success

Marketplace success depends on clean, complete, channel-ready product data. Ads, discounts, and reviews cannot compensate for listings that are missing identifiers, mapped to the wrong category, showing stale availability, or using inconsistent variant data.

A marketplace-ready [product catalog](https://www.getcatalog.ai/glossary/product-catalog) should cover at least these data types:

| Data type | Why it matters |
| --- | --- |
| Product identifiers | [GTIN](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number), UPC, EAN, ISBN, MPN, SKU, ASIN, or marketplace-specific IDs help platforms match products to catalogs, prevent duplicates, and verify the exact item. |
| Titles and descriptions | Marketplaces use them for search relevance, browsing, and shopper comprehension. They must be specific without keyword stuffing. |
| Category and taxonomy mapping | Each marketplace organizes products differently. A product that is mapped to the wrong category may lose visibility or fail validation. |
| Images and rich media | Images must meet platform guidelines and show the exact product, variants, packaging, and use cases when relevant. |
| Attributes and specifications | Size, color, material, dimensions, compatibility, ingredients, certifications, and other fields drive filters, comparison, compliance, and conversion. |
| Variants | Parent/child relationships, size/color options, bundles, multipacks, and item group IDs need to stay consistent. |
| Price and promotions | Price must match the channel, currency, checkout, landing page, and promotion rules. |
| Availability and inventory | Stock status should update quickly enough to avoid overselling, cancellations, or hidden listings. |
| Fulfillment and shipping | Handling time, shipping speed, package dimensions, origin, restrictions, and service levels affect discoverability and buyer expectations. |
| Returns and policies | Return windows, warranties, restrictions, and customer-service terms influence trust and marketplace compliance. |
| Compliance fields | Country of origin, hazardous-material fields, age restrictions, regulatory claims, and category-specific disclosures may be required. |

The requirements are not theoretical. Google's [Merchant Center product data specification](https://support.google.com/merchants/answer/7052112?hl=en) says Google uses submitted product data to match products to the right queries, and that inaccurate or incorrectly formatted product data can cause disapprovals, limited eligibility, incorrect displays, or other issues. It specifically calls out problems like incorrect product category or GTIN values, missing variant attributes, low-quality images, and conflicts between feed and website data.

Marketplace-specific requirements go even deeper. Walmart's item setup guide says sellers must provide required fields such as SKU, product type, product ID, and country of origin, and that missing required fields can create data errors. eBay's [product identifier guide](https://export.ebay.com/en/manage-listings/product-identifiers/) says product identifiers are required in most categories and help buyers find, compare, and confirm what they are buying. GS1 US defines a [GTIN](https://www.gs1us.org/upcs-barcodes-prefixes/what-is-a-gtin) as a GS1 identification key used to identify a trade item in an online marketplace listing or brick-and-mortar store.

The practical takeaway: before a merchant expands to third-party marketplaces, product data should be normalized once, then mapped to each channel's schema. That is the job of [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication): turning one reliable product source into channel-specific feeds, listings, and updates.

## How to prepare your catalog for marketplace expansion

A marketplace launch goes better when the catalog is ready before the first upload. Use this checklist before adding a new marketplace channel.

### 1. Centralize the source of truth

Start with one trusted product record for each item and variant. If titles live in one spreadsheet, dimensions in another, images in a DAM, and inventory in a separate tool, marketplace teams will spend their time reconciling conflicts instead of improving listings.

### 2. Normalize product identifiers

Map internal SKUs to external identifiers such as GTIN, UPC, EAN, ISBN, MPN, ASIN, or platform-specific IDs. Keep variant-level IDs distinct. A wrong identifier can attach your offer to the wrong product, create duplicate listings, or trigger validation errors.

### 3. Map attributes by channel

Do not assume every marketplace wants the same fields in the same shape. One channel may require country of origin, another may emphasize item specifics, and another may need strict variant grouping. Build a mapping layer for each marketplace.

### 4. Enrich weak product content

Marketplace listings need enough detail for both algorithms and shoppers. [Product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) can add missing attributes, normalize titles, improve descriptions, fill specifications, and make variant data easier to use across channels.

### 5. Synchronize price and availability

Price and stock should match the marketplace listing, your source system, your owned site, checkout, and any [structured data](https://www.getcatalog.ai/glossary/structured-data) that search engines or AI systems read. [Stale inventory](https://www.getcatalog.ai/blog/inventory-management-process) creates cancellations. Stale prices create trust and compliance problems.

### 6. Validate before launch

Run feeds or listings through platform validation before a major upload. Fix missing required fields, invalid category mappings, image issues, identifier conflicts, and policy flags while the launch is still controlled.

### 7. Monitor after launch

Marketplace data is never set-and-forget. Monitor suppressed listings, feed errors, price mismatches, review patterns, return reasons, ad performance, inventory gaps, and category changes. Feed those signals back into the catalog.

### 8. Keep a channel-performance view

Track marketplace performance by product, attribute completeness, category, price, inventory status, return rate, and margin. This makes it easier to decide which products deserve more ad spend, better content, repricing, fulfillment changes, or removal from the channel.

## Where Catalog fits

Catalog helps merchants work from live, normalized product data instead of static, channel-by-channel files. That matters because every marketplace has its own schema, but the underlying product facts should not fragment.

A consistent product data layer makes it easier to:

- keep product identifiers, variants, price, stock, descriptions, images, and policies aligned;
- transform one product record into marketplace-specific formats;
- update listings when product facts change;
- reduce feed errors caused by missing or conflicting data;
- support AI shopping surfaces, marketplace channels, and owned ecommerce from the same catalog foundation.

Third-party marketplaces are distribution channels. Clean catalog data keeps those channels accurate, searchable, and scalable.

## Frequently asked questions

### What is an example of a third-party marketplace?

Amazon Marketplace is a common example. Independent sellers list products on Amazon, set their offers, and either fulfill orders themselves or use a fulfillment program. Walmart Marketplace, eBay, Etsy, Target Plus, and TikTok Shop are also examples of third-party marketplace models.

### Is Amazon a third-party marketplace?

Amazon is both a first-party retailer and a third-party marketplace. In the first-party model, Amazon buys inventory and sells it to shoppers. In the third-party model, independent sellers list and sell products through Amazon Marketplace.

### Is Walmart a third-party marketplace?

Yes. Walmart operates Walmart Marketplace, where approved third-party sellers list products on Walmart.com. Walmart also sells first-party retail inventory, so its digital shelf includes both models.

### What is the difference between a third-party marketplace and a third-party seller?

The marketplace is the platform. The third-party seller is the merchant using that platform to sell products. Amazon Marketplace is a marketplace; a brand listing products there through Seller Central is a third-party seller.

### What is the difference between 1P and 3P retail?

In 1P retail, the brand sells inventory to the retailer, and the retailer sells it to the shopper. In 3P retail, the brand or merchant sells directly to the shopper through a marketplace platform. 1P often gives the retailer more control; 3P usually gives the seller more control over the offer but more responsibility for data, operations, and performance.

### Are third-party marketplaces worth it?

They can be worth it when the channel reaches the right buyers and the unit economics work after fees, ads, fulfillment, returns, and team time. They are less attractive when margins are thin, product data is messy, inventory changes quickly, or the brand cannot maintain listing quality and customer service across channels.

---

Canonical: https://www.getcatalog.ai/blog/third-party-marketplace
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Referral traffic in Google Analytics: GA4 reporting

*July 20, 2026 · Catalog Team · AI Commerce · 16 min*

> Learn what referral traffic means in Google Analytics, find it in GA4, clean unwanted referrals, and measure AI and Direct visits with honest proof.

Referral traffic is a visit that Google Analytics can connect to another website or app. That source can be a publisher, partner, review site, marketplace, or AI assistant. GA4 shows the source when the visit arrives with usable attribution data. It cannot recover a referrer that never reaches the property.

That boundary is important for ecommerce. A shopper can click a product recommendation in ChatGPT, arrive on a product page, and appear as Direct if the app or browser drops the source. You can find referral traffic in GA4, clean misleading referrals, and separate observed AI traffic from likely under-attributed visits.

## What referral traffic means in Google Analytics

In GA4, referral traffic is a session that arrives through a non-ad link on another site or app and has a detectable source. A row such as `example.com / referral` means GA4 received enough information to identify the referring source and its medium.

The main traffic dimensions are:

| Dimension | What it tells you | Example |
| --- | --- | --- |
| **Session source / medium** | The source and medium for the session | `review-site.com / referral` |
| **Session source** | The source without the medium | `review-site.com` |
| **Session medium** | The traffic type | `referral`, `organic`, `cpc`, or `ai-assistant` |
| **Session default channel group** | GA4's rule-based channel label | Referral, Direct, Organic Search, or AI Assistant |
| **Landing page + query string** | The first page in the session | `/products/waterproof-jacket?color=navy` |
| **Page referrer** | The referring URL when GA4 receives it | `https://review-site.com/best-jackets` |

The **Traffic acquisition** report is session-scoped. It answers, “Where did this session come from?” The **User acquisition** report is user-scoped and focuses on how new users first arrived. Their rows and metrics should not be compared as if they describe the same population. [Google documents the scope difference](https://support.google.com/analytics/answer/14731736?hl=en).

GA4's **Referral** channel covers non-ad links from other sites and apps. **Direct** is the channel for a saved link or typed URL, yet the Direct bucket also receives sessions when a source is missing. GA4's own rule uses source `(direct)` with medium `(none)` or `(not set)`. [The default channel definitions](https://support.google.com/analytics/answer/9756891?hl=en) are the reference for the current grouping.

## How to find referral traffic in GA4

Use the session report first. It gives you a source, the sessions that began there, and the outcomes those sessions produced.

1. Open **Reports** in the left navigation.
2. Select **Acquisition**.
3. Open **Traffic acquisition**.
4. Set the date range and, when useful, turn on a comparison with the previous period.
5. Open the primary dimension selector and choose **Session source / medium**.
6. Search the table for `referral`, or filter to individual sources such as `review-site.com / referral`.
7. Compare **Sessions**, **Engaged sessions**, **Key events**, **Purchases**, and **Total revenue**. Add **Average purchase revenue** where available. In Explore, calculate revenue per session when you need an efficiency rate.

Use the report's dimension controls to add **Landing page + query string** or move that dimension into an Exploration. The landing page tells you whether a referral brought someone to a product detail page, category, buying guide, or a low-intent page such as an account screen.

![Illustrative current GA4 workflow from Reports to Acquisition to Traffic acquisition, with sample source and outcome rows](https://www.getcatalog.ai/images/blog/ga4-traffic-acquisition-workflow.svg)

### Build a deeper referral view in Explore

Use **Explore** when the standard report cannot answer the product question. Create a blank exploration, then add:

- **Dimensions:** Session source / medium, Session default channel group, Landing page + query string, Page referrer, Device category, and item or product dimensions that your ecommerce implementation sends.
- **Metrics:** Sessions, Engaged sessions, Engagement rate, Key events, Add-to-cart events, Purchases, Total revenue, and Average purchase revenue.
- **Filters:** A referral source, a channel group, a product-page path, or a comparison period.

Keep the source dimension and the landing page in the same view. A referral that lands on `/products/ultralight-pack` has a different commercial meaning from one that lands on `/blog/gear-guide` even when the two sessions came from the same domain.

## Referral traffic vs. Direct traffic

Referral and Direct describe what GA4 can attribute at session start. They do not describe the visitor's intent with certainty.

| GA4 row or channel | What GA4 saw | Typical cases | How to use it |
| --- | --- | --- | --- |
| `example.com / referral` | A visible off-site source and referral medium | Publisher links, partners, forums, marketplaces, and some AI clicks | Attribute the session to the visible source, then measure landing page and outcomes |
| `(direct) / (none)` | No usable source or campaign data | Typed URLs, bookmarks, untagged campaigns, private apps, copied links, privacy controls, and some AI clicks | Treat it as a mixed unknown bucket and investigate its landing pages and behavior |
| `chatgpt.com / ai-assistant` | A recognized AI referrer and GA4's AI medium | A detectable click from an AI assistant | Count it as observed AI traffic, never as the complete AI-influenced total |

The browser's [`Referer` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer) can carry the page that sent a request. [`Referrer-Policy` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) can reduce or omit that information. Apps, webviews, redirects, copied URLs, consent choices, and missing UTMs can also break the trail.

That is why a large Direct row does not prove strong brand loyalty, and a small referral row does not prove that the source created all of the demand. Read both with landing pages, campaigns, device patterns, and outcomes.

## Clean unwanted referrals before reporting performance

Some domains participate in your customer journey without being marketing sources. Common examples include:

- payment gateways and hosted checkout domains;
- authentication, password-reset, and account-management providers;
- owned subdomains when cross-domain measurement is configured incorrectly;
- support widgets or booking tools that send a customer away and back;
- domains used to complete a transaction or other website-managed interaction.

If a payment gateway starts a new session on the return to your confirmation page, GA4 may credit the purchase to the gateway. That inflates referral revenue and hides the channel that brought the customer in.

In GA4, open **Admin > Data collection and modification > Data streams**, choose the **Web** stream, select **Configure tag settings**, expand **Show all**, and open **List unwanted referrals**. Add the relevant domains and save. Google currently allows up to 50 unwanted-referral rules per web data stream. [Follow Google's unwanted-referral steps](https://support.google.com/analytics/answer/10327750?hl=en).

Also audit the sources you control:

- Tag email, SMS, affiliate, influencer, QR, PDF, and partner links with consistent UTMs.
- Confirm redirects preserve query strings and campaign parameters.
- Check that paid campaigns use the intended source and medium.
- Remove UTMs from internal links so they do not overwrite the original session source.
- Check site migrations, consent changes, and cross-domain settings after deployment.

**Proof example: checkout pollution.** A row such as `payments.example / referral` with purchases is evidence of a visible referral, not evidence that the payment provider marketed the product. Excluding that domain prevents the return visit from starting a new referral session. It does not rewrite the original acquisition data, so inspect the dates and attribution windows after the change.

## What AI assistant traffic looks like in GA4

Google added an **AI Assistant** channel in May 2026. When a recognized AI referrer is present, GA4 can set the medium to `ai-assistant`, set the campaign to `(ai-assistant)`, and place the session in the AI Assistant channel. The recognized-source list includes services such as ChatGPT, Gemini, Claude, Copilot, and Grok, and can change as Google updates its definitions. The channel excludes Google's AI Overviews and AI Mode. [Google's release note](https://support.google.com/analytics/answer/9164320?hl=en) explains the new fields.

This is a useful floor for measurement. An assistant app or webview can send a link without a referrer. A shopper can copy a URL, search the brand after reading an answer, or return later from a bookmark. GA4 then has no reliable way to label the first influence as AI. It may show Direct, Organic Search, or another last-click channel.

If the native channel misses a source you need to monitor, create a custom channel group. Put it above Referral, then match the referrer with a rule for the assistant domains you actually observe. A starting pattern might be:

```text
(chatgpt\.com|chat\.openai\.com|perplexity\.ai|gemini\.google\.com|claude\.ai|copilot\.microsoft\.com)
```

Keep the list owned and reviewed. Google notes that custom channel rules should be ordered above Referral and updated when assistant URLs change. [See Google's custom-channel example](https://support.google.com/analytics/answer/13051316?hl=en).

### Published proof of the measurement gap

- **Adobe Analytics:** Adobe reported a 1,200% increase in generative-AI traffic to US retail sites from July 2024 to February 2025, with AI-referred visitors showing stronger engagement indicators than non-AI traffic sources. [Read the Adobe analysis](https://blog.adobe.com/en/publish/2025/03/17/adobe-analytics-traffic-to-us-retail-websites-from-generative-ai-sources-jumps-1200-percent).
- **GA4 property dataset:** Search Engine Land reported a Previsible dataset of 6.77 million LLM-driven sessions across 166 GA4 properties. ChatGPT accounted for 92.4% of the trackable LLM referral traffic in that dataset, and ecommerce sessions often landed on product pages. [Read the reported dataset](https://searchengineland.com/chatgpt-ai-referral-traffic-sessions-data-481630).

These figures are market evidence, not a forecast for your property. Use them to justify building a visible-AI report before the channel is large enough to surprise you.

## Measure likely AI-influenced Direct traffic

You cannot prove that one `(direct) / (none)` session came from an assistant after the source has been lost. You can define a segment that makes the uncertainty explicit and test whether the pattern persists.

Start with sessions that meet most of these conditions:

- source and medium are `(direct) / (none)`;
- the visitor is new or has no recent session;
- the landing page is a product, category, collection, comparison, or buying-guide page;
- the landing page is not the homepage, login, account, support, careers, store locator, or checkout-return page;
- the session has meaningful engagement, an add-to-cart, checkout start, purchase, or another high-intent event.

Compare that segment with a baseline period. Choose a period before the visibility change, product launch, campaign, or AI-shopping release you are investigating. Then rule out other explanations:

- known AI Assistant sessions for the same dates;
- Search Console branded and product-name queries;
- paid, email, SMS, affiliate, influencer, PR, and promotion calendars;
- product launches, pricing changes, and marketplace activity;
- device and browser patterns;
- server logs, when available, to check whether requests carried a referrer.

Call the result **likely assistant-influenced Direct** or **Direct product-page investigation segment**. Do not call it exact AI traffic.

![Observed GA4 sources separated from likely assistant-influenced Direct signals, with inference clearly labeled](https://www.getcatalog.ai/images/blog/ga4-ai-attribution-evidence.svg)

**Inference example: product-page lift.** Suppose Direct sessions to `/products/ultralight-pack` rise above the baseline at the same time that the product begins appearing for relevant assistant prompts. If campaigns, SEO demand, and site changes do not explain the lift, the pattern is worth investigating as possible AI influence. It remains an inference until a referrer, campaign tag, or another first-party signal confirms the source.

Catalog's guide to [dark traffic in agentic commerce](https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic) uses the term **dark agentic commerce traffic** for this class of under-attributed, high-intent journey. The useful operating practice is to separate what GA4 observed from what the surrounding evidence suggests.

Retailgentic's [dark agentic commerce traffic](https://www.retailgentic.com/p/dark-agentic-commerce-traffic-dact) analysis describes the same pattern: an answer engine can create product intent while the final visit looks Direct. Treat the label as a measurement problem, not proof that every Direct visit came from AI.

## Connect referral traffic to products and outcomes

A referral report becomes useful when it connects three layers:

| Layer | Dimensions to use | Questions to answer |
| --- | --- | --- |
| **Channel** | AI Assistant, Referral, Direct, Organic Search, Paid Search, Paid Social, Email, SMS, affiliate, and influencer | Which sources start sessions, and how do they compare? |
| **Product and page** | Landing page, page type, category, canonical URL, item name, item ID, SKU, and variant | Which products and content attract each source? |
| **Outcome** | Engaged sessions, add-to-cart, checkout starts, purchases, item revenue, total revenue, calculated revenue per session, or lead events | Which visits create commercial value? |

For example, a Direct session landing on `/products/wide-fit-trail-running-shoe-blue-size-10` deserves a different interpretation from a Direct session landing on `/`. Report by page type and product group before relying on sitewide averages.

For a simple operating report, show these rows side by side:

| Product or page group | Known AI referrals | Likely assistant Direct | Organic Search | Paid and owned channels | Outcome |
| --- | ---: | ---: | ---: | ---: | --- |
| Product detail pages | Visible source/medium | Direct sessions above baseline | Product and branded queries | Campaign calendar | Add-to-cart, purchase, item revenue |
| Category pages | AI landings by category | Direct category sessions | Non-branded category queries | Promotions and sends | Product clicks and revenue |
| Buying guides | AI referrals to guides | Direct guide entries | Organic assists | Email and remarketing | Downstream product views and conversions |

Report three numbers instead of one blended “AI revenue” total:

1. **Known AI floor:** sessions and revenue from visible AI Assistant or AI referral rows.
2. **Likely dark estimate:** above-baseline Direct sessions that meet the segment rules and survive campaign and technical checks.
3. **Influence signals:** visibility, branded search, product-page behavior, and revenue movement that align with AI exposure but cannot be assigned to one click.

## Why product data still matters

GA4 tells you what reached the site. Product data helps determine whether an AI shopping system can understand a product well enough to recommend it and link to the correct page. Keep the product-data work tied to measurement by maintaining:

- canonical product URLs;
- current price, currency, and availability;
- product, category, and variant relationships;
- attributes such as size, color, material, compatibility, fit, and use case;
- stable identifiers, images, reviews, shipping, returns, and warranty details.

Consistent product records make landing-page patterns easier to interpret. Duplicate URLs, stale offers, and contradictory variants make both recommendations and downstream reporting harder to trust.

Catalog provides a product data layer for AI commerce. It structures product data, keeps it synchronized, publishes it to AI shopping surfaces, and measures what those surfaces do. It sits alongside the existing storefront and analytics setup. Use [AI visibility for ecommerce](https://www.getcatalog.ai/blog/ai-visibility-ecommerce) when the question is whether the right product appears, then use GA4 to measure what happens after the click.

## Common mistakes in referral reporting

### Treating every Direct session as AI traffic

Direct combines typed URLs, bookmarks, missing campaign data, private-app visits, and possible AI influence. Segment it and state the assumptions.

### Counting visible AI referrals as the whole channel

The AI Assistant row is a detectable floor. It excludes visits where the source was stripped or where the shopper returned through another channel.

### Leaving payment and authentication domains in the referral report

Checkout and login flows can claim sessions and purchases. Configure unwanted referrals before comparing revenue by source.

### Comparing channels without page context

AI referrals and likely dark traffic may concentrate on product pages, comparison pages, categories, or buying guides. Sitewide averages hide that difference.

### Calling an inference proof

Above-baseline Direct traffic can support an AI-influence hypothesis. It cannot establish a source that GA4 never received. Keep observed rows and modeled estimates separate.

## FAQ

### What is referral traffic in GA4?

It is a session that arrives through a non-ad link from another site or app when GA4 can identify the source. A typical row is `publisher.example / referral`. GA4 then lets you compare that session's landing page, engagement, key events, and revenue with other sources.

### Where do I find referral traffic in Google Analytics 4?

Open **Reports > Acquisition > Traffic acquisition**. Set the primary dimension to **Session source / medium**, then search for `referral` or a specific referring domain. Add landing-page and outcome metrics so the report answers more than “who sent the visit?”

### What is the difference between Traffic acquisition and User acquisition?

Traffic acquisition is session-scoped and describes where sessions began. User acquisition is user-scoped and describes how new users first arrived. A returning user can create a new Direct session, so the same person can produce different rows in the two reports.

### Is ChatGPT traffic referral traffic in GA4?

Sometimes. A recognized ChatGPT referrer can appear with medium `ai-assistant` and the AI Assistant channel. A click from an app or webview can lose the referrer and appear as Direct or another channel. The visible row is measurable AI traffic, not the full AI-influenced total.

### Why does a referral source appear as `(direct) / (none)`?

GA4 received no usable source or campaign data for that session. Common causes include copied links, private apps, redirects, privacy settings, missing UTMs, and consent choices. Check the landing page and campaign context before deciding what the session means.

### How do I stop a payment provider from taking referral credit?

Add its domain under **Admin > Data collection and modification > Data streams > Web > Configure tag settings > Show all > List unwanted referrals**. Check cross-domain measurement and the payment return flow as well. Exclusion prevents the unwanted domain from starting a new referral session; it does not reconstruct missing original attribution.

### Should I add UTMs to AI assistant links?

Use UTMs wherever your team controls the link, such as email, SMS, affiliates, influencers, QR codes, PDFs, and partner placements. You usually cannot add parameters to links generated by third-party assistants. UTMs reduce avoidable Direct traffic, yet they cannot recover a source that another app removes.

### Can GA4 recover dark AI traffic exactly?

No. GA4 can report the source data it receives. Use known AI referrals as the observed floor, then compare a carefully defined Direct segment with visibility, search, campaign, product, and server-log evidence. Label the result as likely influence rather than exact AI traffic.

## A practical reporting standard

Referral traffic in Google Analytics remains a useful source signal. It shows which outside sites and apps began sessions and what those sessions did. The report becomes more reliable when you clean unwanted referrals, distinguish session from user scope, and report by product page and outcome.

For AI commerce, keep three levels separate: observed AI referrals, likely assistant-influenced Direct sessions, and broader influence signals. That gives your team a measurement loop it can act on without inventing attribution.

If your products are hard for shopping agents to read or keep current, [see Catalog's product-data layer](https://www.getcatalog.ai/). Then use GA4 to see what AI is actually doing for you.

---

Canonical: https://www.getcatalog.ai/blog/referral-traffic-google-analytics
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product data extraction: how to turn product pages into usable commerce data

*July 16, 2026 · Catalog Team · Product Data · 13 min read*

> Learn what product data extraction is, how APIs, feeds, and scrapers collect product data, and how to normalize it for commerce systems.

Product data extraction is the process of collecting product information from sources such as product pages, marketplaces, feeds, PIM exports, databases, and APIs. In ecommerce, the goal is not a copy of a page. The goal is a usable product record: title, brand, price, availability, images, variants, specs, identifiers, reviews, URLs, and freshness signals that downstream systems can trust.

That distinction matters. A scraper can collect raw HTML. A feed can export a set of fields. An API can return selected product objects. But search, recommendations, comparison pages, marketplace submissions, pricing tools, and AI shopping agents need clean product data, not a pile of disconnected snippets.

The practical work is extraction first, then normalization, validation, enrichment, and refresh.

## Product data extraction at a glance

| Question | Short answer |
| --- | --- |
| What is product data extraction? | Collecting product information from websites, marketplaces, feeds, databases, documents, or APIs |
| Common sources | Product detail pages, category pages, marketplace listings, PIM exports, supplier files, product feeds, databases, and public APIs |
| Common fields | Title, brand, price, stock, images, category, description, specs, variants, identifiers, ratings, reviews, source URL, and last-seen timestamp |
| Common methods | API extraction, web scraping, crawling, feed ingestion, PIM export, database extraction, and AI-assisted parsing |
| Main risk | Extracted data is stale, incomplete, duplicated, inconsistent, or hard to compare across sources |
| Best output | Normalized product records with stable IDs, consistent fields, variant relationships, freshness, and confidence signals |
| Related work | Product data normalization, product data enrichment, catalog management, data quality, and syndication |

## What is product data extraction?

Product data extraction is a focused form of data extraction for commerce. It collects product facts from one or more sources and turns them into records that can be stored, transformed, analyzed, or sent to another system.

A simple extraction job might pull names, prices, and product URLs from a competitor site once a week. A more advanced pipeline might collect thousands of products across many domains, resolve variants, map attributes into a shared taxonomy, track changes over time, and feed a live product search or recommendation system.

The extracted fields depend on the use case, but most product data extraction work touches some combination of:

- **Identity:** product name, brand, SKU, GTIN, UPC, EAN, MPN, model number, product ID, parent ID, and variant ID.
- **Commercial data:** price, sale price, currency, stock status, inventory count, promotions, seller, shipping details, and return policy.
- **Product content:** descriptions, feature bullets, category, specs, materials, ingredients, sizing, compatibility, images, video, documents, ratings, and reviews.
- **Relationships:** variants, bundles, accessories, replacement parts, compatible products, alternatives, and duplicate listings.
- **Freshness and provenance:** source URL, extraction timestamp, last-seen timestamp, field confidence, and source history.

That output can become part of a [product catalog](https://www.getcatalog.ai/glossary/product-catalog), a pricing system, a search index, a marketplace feed, or an [AI-commerce data layer](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai).

## How product data extraction works

Most product data extraction pipelines follow the same basic sequence, even when the tooling changes.

1. **Choose the sources.** Decide whether data will come from public product pages, marketplace listings, partner feeds, supplier files, a [PIM system](https://www.getcatalog.ai/glossary/pim-system), an ecommerce platform, internal databases, or APIs.
2. **Define the target fields.** List the exact fields the downstream system needs. A price monitor may need price, availability, seller, URL, and timestamp. A product search app may also need images, descriptions, specs, categories, and variants.
3. **Connect, crawl, scrape, import, or query.** The extraction method depends on source access. APIs and feeds are cleaner when available. Crawlers and scrapers are useful for open-web product pages. Database extraction works when the data sits in a controlled internal system.
4. **Parse the raw output.** Raw HTML, JSON, CSV, XML, PDF, image text, and database rows have to be mapped into product fields.
5. **Normalize and validate.** Units, categories, currencies, identifiers, attributes, and variant structures need to be made consistent before the data is safe to compare or publish.
6. **Store, refresh, or send downstream.** The final records may move into a warehouse, product catalog, application database, search index, marketplace feed, analytics workflow, or API.

Teams also choose between full and partial extraction. Full extraction tries to capture all available product data from a source. Partial extraction collects only selected fields, such as price and availability, because the use case does not need everything or because the source exposes only a specific view through an API or query.

## Common product data extraction methods

There is no single best extraction method. The right choice depends on source access, field complexity, freshness needs, scale, and maintenance tolerance.

| Method | When it works well | Watchouts |
| --- | --- | --- |
| API extraction | A partner, platform, marketplace, or provider exposes structured product data | API coverage, rate limits, field definitions, authentication, and cost |
| Web scraping and crawling | Product data is public on product pages or category pages, and no cleaner source exists | Page redesigns, bot defenses, schema drift, parsing errors, and ongoing maintenance |
| Product feeds and PIM exports | Data comes from a brand, retailer, supplier, or internal product-information system | Feed freshness, missing attributes, channel-specific formats, and inconsistent field names |
| Database or warehouse extraction | The team controls the source system and can query it directly | Data ownership, permissions, schema changes, joins, and transformation work |
| AI-assisted parsing | Product facts are trapped in images, PDFs, unstructured descriptions, or messy pages | Confidence, hallucination risk, review workflow, and field-level validation |

A mature setup often uses more than one method. For example, a commerce team might use [PIM data](https://www.getcatalog.ai/glossary/pim-data) for owned products, retailer feeds for partner channels, crawlers for competitor assortment, and a managed product-data API for open-web product pages that need frequent refresh.

## Product data extraction examples

Product data extraction becomes useful when the extracted records feed a specific decision or user experience.

### Competitor price monitoring

A price-monitoring workflow extracts competitor product URLs, price, sale price, currency, seller, availability, shipping details, and timestamps. The output only works if products are matched correctly and refreshed often enough to catch changes. A weekly snapshot can support category strategy. A live pricing workflow needs fresher records and stronger validation.

For teams building this directly, Catalog's [price monitoring API](https://www.getcatalog.ai/blog/price-monitoring-api) guide covers the tradeoffs behind product matching, freshness, and ongoing collection.

### Assortment and inventory tracking

Retailers and brands use extraction to understand what competitors, marketplaces, or retailers carry. The important fields are not just product names. Category, brand, variants, size, color, stock status, rating count, and seller data can all change the conclusion.

### Catalog onboarding

Marketplaces, affiliate apps, comparison engines, and internal tools often need to onboard many products from many sources. Extraction gathers the initial product facts, but onboarding succeeds only when records are deduplicated, mapped to a shared taxonomy, and checked for required identifiers and media.

### Product search and recommendations

Search and recommendation systems need structured attributes, not only titles and descriptions. A product search engine can use category, material, fit, compatibility, size, color, price, rating, and inventory data to filter and rank results. Missing or inconsistent attributes make the experience feel broken even when extraction technically succeeded.

### Marketplace and channel operations

Extracted product data can support [marketplace listings](https://www.getcatalog.ai/blog/third-party-marketplace), retailer submissions, comparison shopping engines, and product feeds. That requires more than collection. Each channel has its own field names, accepted values, image rules, category trees, and validation errors. See Catalog's guide to [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) for the distribution side of the workflow.

### AI shopping agents and product-data apps

AI shopping agents need product information they can interpret reliably: current price, stock, variants, specs, images, return details, and source URLs. A vague extracted snippet is not enough. The more a product answer depends on live commercial details, the more important freshness, confidence, and normalized fields become.

## Why extraction quality matters

Extraction is only the collection step. Poor extraction quality creates problems later, often in places where the data team is no longer watching.

Common failure modes include:

- **Stale price or availability:** a page changed, but the downstream system still shows the old value.
- **Wrong variant mapping:** a size, color, bundle, or pack count is attached to the wrong parent product.
- **Inconsistent units:** one source says 12 oz, another says 0.75 lb, and the system treats them as unrelated values.
- **Missing identifiers:** GTINs, SKUs, MPNs, and brand names are absent, malformed, or copied from the wrong listing.
- **Duplicate products:** the same item appears under different URLs, sellers, names, or marketplace listings.
- **Schema drift:** a source changes its page markup, feed format, or field names, and the extraction pipeline keeps running with bad output.
- **Low-confidence AI parsing:** an LLM or OCR model extracts a value from an image or document, but no validation step confirms it.

These issues affect more than reporting. They can break search filters, recommend the wrong variant, publish incorrect marketplace fields, misprice competitor comparisons, or send AI agents into an answer with stale product facts.

A strong [product data quality](https://www.getcatalog.ai/blog/product-data-quality) process checks completeness, consistency, accuracy, freshness, and validity after extraction. The extraction pipeline should preserve source URL, timestamp, last-seen date, and confidence so later systems know how much to trust each field.

## Extraction vs normalization vs enrichment

Product data extraction often gets used as a catch-all term, but three jobs are different.

| Step | What it does | Example |
| --- | --- | --- |
| Extraction | Collects product facts from a source | Pull price, availability, image URL, and description from a product page |
| Normalization | Makes fields consistent and comparable | Convert sizes, currencies, category names, attribute labels, and variant structures into one format |
| Enrichment | Adds missing, derived, or improved fields | Add standardized attributes, classify a product, improve a description, or infer compatibility |

Extraction without normalization gives you raw product data. Normalization makes that data usable across sources. Enrichment makes it more complete or more useful for a specific workflow.

The distinction is useful when choosing tools. A browser extension or custom scraper may extract fields from a small set of pages. A commerce application that powers search, recommendations, or AI shopping usually needs normalized and enriched product records. Catalog's guide to [product data enrichment for AI commerce](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) goes deeper on that next layer.

## How to choose a product data extraction approach

Start with the downstream job, not the extraction tool.

### Use a lightweight scraper or manual export when sources are narrow and stable

A small scraper, no-code extraction tool, or spreadsheet export can be enough when you have a few stable sources, low freshness needs, and a limited field set. This is common for one-off research, periodic category audits, or early prototypes.

The maintenance cost rises when pages change often, the source count grows, or product variants and availability matter.

### Use feeds, PIM exports, or platform APIs when you have direct access

If a supplier, retailer, marketplace, ecommerce platform, or internal team can provide structured access, use it. Feeds and APIs usually reduce parsing work and give clearer field definitions than open-web scraping.

They still need validation. A feed can be late, incomplete, or channel-specific. A PIM export can contain fields that are clean for owned channels but not mapped to the format a marketplace, search app, or agent needs.

### Use database extraction for owned internal systems

Database or warehouse extraction works when the product data lives in systems your team controls. It gives strong access and repeatability, but it can require joins across product, inventory, pricing, content, and media tables. It also has to respect permissions, data ownership, and schema changes.

### Use a managed product-data API when you need open-web product objects

A managed product-data API is a better fit when the source set is broad, product pages change often, and downstream systems need typed product records instead of HTML. This is especially true for live price, stock, variants, images, identifiers, and freshness signals.

The tradeoff is cost and provider dependence, but the upside is lower scraper maintenance and cleaner outputs for product applications.

## Where Catalog fits

Catalog is useful when teams need product objects from the open web rather than [raw scraped pages](https://www.getcatalog.ai/blog/why-smart-ecommerce-companies-choose-catalog-ai). It can take product URLs or domains and return live product JSON with 86+ normalized fields, including product details, variants, pricing, availability, images, specs, stable IDs, and field freshness.

That makes it a fit for teams building product search, recommendations, price monitoring, catalog onboarding, comparison tools, marketplace intelligence, and AI shopping experiences. Catalog does not replace every internal PIM export or partner feed. It is strongest when the work involves open-web product data that has to be collected, normalized, refreshed, and delivered as structured product objects.

The simplest way to frame the decision: use extraction to collect product facts, but choose the extraction stack based on the quality of the records your downstream system actually needs.

## Product data extraction checklist

Use this checklist before building or buying a product data extraction workflow.

- Define the business use case and the downstream system.
- List the required product fields, including variants, identifiers, media, pricing, availability, and freshness needs.
- Decide which sources are allowed and practical to use.
- Confirm access rules, contracts, privacy constraints, robots expectations, and rate limits.
- Choose full extraction or partial extraction based on the use case.
- Decide whether each source should use an API, feed, scraper, crawler, database query, or managed provider.
- Preserve source URL, extraction time, last-seen time, and field confidence.
- Normalize categories, attributes, units, currencies, identifiers, and variant relationships.
- Deduplicate products across URLs, sellers, marketplaces, and domains.
- Validate high-risk fields such as price, stock, seller, identifiers, and dimensions.
- Monitor schema changes, source failures, missing fields, and freshness drift.
- Test the extracted records in the actual downstream experience, not only in the extraction database.

## FAQ

### Is product data extraction the same as web scraping?

No. Web scraping is one method for product data extraction. Product data extraction can also use APIs, product feeds, PIM exports, database queries, documents, and AI-assisted parsing. Scraping collects data from web pages; extraction is the broader workflow of collecting product information from any usable source.

### What product fields should you extract?

Start with the fields your downstream system needs. Common fields include title, brand, URL, price, currency, availability, images, category, description, specs, variants, identifiers, ratings, reviews, seller, source URL, and timestamp. Search and recommendation systems usually need richer attributes than a simple price-monitoring workflow.

### How often should product data be refreshed?

Refresh frequency depends on the field and use case. Price, stock, seller, and promotion data often need frequent refresh. Descriptions, images, category, and specs may change less often. A production workflow should track field-level freshness so downstream systems can treat a recent price differently from a month-old product description.

### Do you need an API or a scraper for product data extraction?

Use an API, feed, or PIM export when the source provides reliable structured access. Use a scraper or crawler when the data is available on public pages and no cleaner source exists. Use a managed product-data API when you need broad open-web coverage, live freshness, normalized fields, and less maintenance than an in-house scraper stack.

---

Canonical: https://www.getcatalog.ai/blog/product-data-extraction
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Dark traffic in agentic commerce: how to find the AI shoppers your analytics miss

*July 15, 2026 · Catalog Team · AI Commerce · 15 min*

> Learn why AI shopping assistants can turn product clicks into direct traffic, and how to estimate the gap with Google Analytics 4, logs, and visibility data.

Dark traffic is website traffic your analytics tool cannot attribute to a clear source. In ecommerce, the problem is getting harder because shoppers now discover products inside ChatGPT, Gemini, Perplexity, Claude, Copilot, and other answer engines before they ever reach your site.

A shopper can ask an assistant for "the best trail running shoe under $150 for wide feet," click a product link, and land on a product detail page. If the app or browser does not pass a referrer or tracking tag, GA4 (Google Analytics 4) may classify that session as Direct. To the business, it looks like someone typed the URL or came back from memory. In reality, an AI shopping experience may have created the demand.

That is the measurement gap behind dark agentic commerce traffic, often shortened to DACT. The goal is not to prove every Direct session came from AI. The goal is to build a defensible estimate, compare it with answer-engine visibility, and improve the product data that helps assistants recommend the right products in the first place.

## What dark traffic means

Dark traffic is traffic that arrives without enough source data for analytics software to classify it accurately. [Google Analytics describes `(direct) / (none)`](https://support.google.com/analytics/answer/15258820?hl=en) as traffic that does not have a clear referral source. That bucket includes real direct visitors, but it also includes traffic where the original source was lost.

Common causes include:

- untagged email, SMS, affiliate, influencer, or paid campaigns
- links from PDFs, documents, chat apps, or private communities
- redirects or URL shorteners that drop UTM tracking parameters (the source, medium, and campaign tags added to URLs)
- ad blockers and privacy tools that interfere with tracking
- app-to-browser handoffs where referrer data does not survive
- AI assistant clicks that arrive without a recognizable referring domain

So Direct is not a clean channel. It is partly a channel and partly an unknown-source bucket. Dark traffic is the part of that bucket where the visitor did not really come "directly" in the everyday sense, but the analytics system cannot see the path they took.

## Why agentic commerce creates a new dark traffic problem

In [agentic commerce](https://www.getcatalog.ai/blog/what-is-agentic-commerce), product discovery moves from keyword search into AI-assisted decision paths. A shopper does not only search, click, and compare. They ask an assistant to narrow choices, explain tradeoffs, compare specs, check fit, and recommend a product.

That creates a new attribution problem because analytics depends on signals that may not make it through that journey. The HTTP [`Referer` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer) is one of the signals servers use to understand where a request came from. Referrer policies can reduce or omit that information for privacy and security reasons; MDN's [`Referrer-Policy` reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) notes that `no-referrer` omits the header entirely.

AI assistants add more handoffs. A link may open inside a mobile app, a webview, a privacy-controlled browser, or a copied URL. UTM parameters may never exist, or they may be stripped before the visitor reaches the site. When that happens, GA4 cannot reconstruct the original source after the fact.

Retailgentic's [Dark Agentic Commerce Traffic](https://www.retailgentic.com/p/dark-agentic-commerce-traffic-dact) article put a useful name on this ecommerce-specific version of the issue: answer engines can send high-intent shoppers to product detail pages while the analytics system credits the visit to Direct or another last-click source.

This is not the same as bot traffic. Bot traffic has its own user-agent and behavior patterns. DACT is about human shoppers whose source data is missing.

## Why the missing traffic can matter

AI referral traffic is still small for many sites, but the quality and growth patterns are hard to ignore.

Adobe reported that AI-driven traffic to retail websites [jumped 12x between July 2024 and February 2025](https://business.adobe.com/blog/the-explosive-rise-of-generative-ai-referral-traffic). Adobe also found that retail AI referrals had lower bounce rates by February 2025, and that the conversion gap between AI and non-AI traffic narrowed sharply during the same period.

Search Engine Land reported a Visibility Labs analysis of 94 ecommerce brands where [ChatGPT referral sessions converted 31% higher than non-branded organic search](https://searchengineland.com/chatgpt-vs-non-branded-organic-search-conversions-470321), at 1.81% versus 1.39%. The same analysis found ChatGPT visits grew 1,079% during 2025, but it also kept the channel in perspective: non-branded organic was still far larger by volume.

The dark portion is harder to size. Loamly's 2026 benchmark claimed that [70.6% of observed AI traffic in its database arrived without referrer headers](https://www.loamly.ai/blog/state-of-ai-traffic-2026-benchmark-report) and was classified as Direct. Treat that kind of benchmark as a signal, not a universal constant. Your site, category, device mix, and customer journey will be different.

The practical takeaway is simpler: visible AI referrals are probably not the whole story. If answer-engine visibility is rising while Direct product-page traffic rises in the same places, there may be a hidden AI-assisted demand signal worth investigating.

## The DACT fingerprint: what to look for

You cannot label a single no-referrer session as AI-driven with certainty. You can look for a pattern that is unlikely to be explained by normal Direct traffic alone.

A useful dark agentic commerce traffic fingerprint often includes:

| Signal | What it can mean | What to check |
| --- | --- | --- |
| New Direct users landing on product detail pages | Shoppers may be arriving from a recommendation, not typing the domain | Landing page type, product category, first-session path |
| Direct sessions with unusually strong engagement | The shopper may already be pre-qualified | Engaged-session rate, add-to-cart rate, conversion rate, revenue per session |
| Direct growth on specific products or categories | An assistant may be recommending a narrow set of products | Product visibility in answer engines, category seasonality, paid campaigns |
| Known AI referrals rising, but too small to explain the movement | Visible AI clicks may be only the trackable part | Custom AI referral channel, referrer reports, direct product-page baseline |
| Branded or product-name search rising after AI visibility improves | AI may influence the purchase before the final click | Search Console brand/product queries, GA4 branded organic, product-level visibility |

The important word is "fingerprint." This is evidence for an estimate, not proof for every session. A good DACT model should produce a range and show its assumptions.

## How to estimate dark agentic commerce traffic in GA4

Start by separating traffic you can see from traffic you can only estimate.

### 1. Build a known AI referrals channel

Create a custom GA4 channel or exploration for [known AI referrers](https://www.getcatalog.ai/blog/referral-traffic-google-analytics) before you estimate the dark portion. Guides from [Yotpo](https://www.yotpo.com/blog/track-ai-referral-traffic/) and [Orbit Media](https://www.orbitmedia.com/blog/track-ai-traffic-ga4/) recommend grouping sources such as:

- `chatgpt.com` and `chat.openai.com`
- `perplexity.ai`
- `gemini.google.com`
- `claude.ai`
- `copilot.microsoft.com`
- `meta.ai`
- other AI or answer-engine domains relevant to your market

Put this group above generic Referral or Organic rules if your GA4 setup processes channel rules in order. Otherwise, visits from AI domains can be swallowed by broader buckets.

### 2. Create a normal Direct-to-product-page baseline

Pick a baseline period before the AI visibility change you want to measure. For some brands, that may be before a major AI shopping feature launched. For others, it may be before a product was picked up by answer engines or before AI referral traffic started showing in GA4.

Measure Direct sessions that land on product detail pages or other buying-intent pages:

- product detail pages
- category or collection pages
- comparison pages
- buying-guide pages

Exclude pages that naturally attract real direct traffic, such as the homepage, login pages, account pages, support pages, careers pages, and store-locator pages.

### 3. Build a likely DACT segment

A reasonable starting segment is:

- session source / medium = `(direct) / (none)`
- new users or first sessions
- landing page is a product detail page, product collection, comparison page, or buying guide
- landing page is not the homepage, blog hub, support, account, login, or careers
- session shows meaningful engagement, add-to-cart, checkout, or purchase behavior

For ecommerce, the landing page matters. A new visitor who lands directly on `/products/black-wide-fit-trail-runner-size-10` is different from a returning customer who lands on `/`.

### 4. Compare the segment with known AI visibility

Now compare the likely DACT segment with:

- known AI referrals
- non-branded organic traffic
- branded organic traffic
- paid search and paid social campaigns
- email/SMS sends
- influencer or affiliate campaigns
- answer-engine visibility for the same products and queries

If a product begins appearing in ChatGPT, Gemini, Perplexity, or Google AI answers and then Direct product-page sessions rise above baseline, that is a stronger DACT signal than Direct growth by itself.

### 5. Report a range

Do not report "AI drove 12,000 hidden sessions" as if the number is exact. Report a range such as:

- conservative estimate: Direct product-page sessions above baseline with high engagement
- likely estimate: conservative estimate plus direct product-page sessions tied to known answer-engine visibility lifts
- aggressive estimate: likely estimate plus branded/product-name search lifts that coincide with AI visibility

This keeps the analysis useful without pretending GA4 can see something it did not receive.

## Use server logs and product-page patterns to cross-check GA4

Server logs can make the estimate more trustworthy, but they do not magically reveal a missing source.

Use logs to check:

- whether the request had a referrer header at all
- whether redirects preserved query strings and UTM parameters
- whether suspicious spikes are bot or crawler traffic
- which product pages received no-referrer sessions
- whether traffic changed by device, browser, geography, or time of day
- whether checkout or add-to-cart events followed quickly after the product-page entry

Logs are especially useful for ruling things out. If a spike came from a bot, a broken redirect, an untagged email send, or a tracking-code issue, it should not be counted as DACT. If the traffic is human, no-referrer, product-level, and concentrated around products where answer-engine visibility rose, the case gets stronger.

## Measure answer-engine visibility beside traffic

Traffic reports show what reached the site. Answer-engine visibility shows what may have created the demand before the click.

Track prompts that match real buying questions, such as:

- "best [product category] for [use case]"
- "[competitor] alternatives for [need]"
- "which [product] should I buy for [constraint]"
- "compare [brand] vs [competitor]"
- "best [product category] under [price]"

For each prompt, monitor:

- whether your brand or products are mentioned
- which products are recommended
- whether the answer links to you, a retailer, a marketplace, or a third-party source
- which competitors appear above you
- which sources the model cites
- whether the cited page is a product detail page, category page, blog post, review, marketplace page, or documentation

This is where [AI visibility for ecommerce](https://www.getcatalog.ai/blog/ai-visibility-ecommerce) and [ChatGPT product visibility](https://www.getcatalog.ai/blog/how-to-make-products-show-up-in-chatgpt) connect to attribution. If your products are appearing more often in answer engines and your Direct product-page traffic rises at the same time, you have a stronger explanation for the movement.

Visibility monitoring also catches influence that never becomes a referral. A shopper may ask an assistant for recommendations, see your product, then search Google for your brand or product name and buy through branded organic. Search Engine Land noted this attribution gap in the Visibility Labs analysis: GA4 referral data can understate ChatGPT's influence when the final click comes from branded search.

## Fix what you can, estimate what you cannot

Some dark traffic can be cleaned up. Some cannot.

Fix the controllable issues first:

1. Add UTMs to owned campaigns, emails, SMS, PDFs, influencer links, affiliate links, and partner links.
2. Check that redirects preserve query strings and do not strip campaign parameters.
3. Create a known AI-referrer channel group in GA4.
4. Keep product URLs canonical and stable so assistants, shoppers, and reports point to the same destination.
5. Annotate major AI visibility changes, product launches, media hits, and campaign sends in your reporting calendar.
6. Audit Direct spikes by landing page before treating them as brand strength.

Then estimate the uncontrollable portion. You cannot force every AI app to pass a referrer. You cannot tag a link an assistant creates from a third-party source you do not control. You cannot see every influence path where a shopper asks an assistant, remembers the product, and comes back later through branded search.

That is why DACT measurement should be a model, not a single report.

## Why structured product data is part of the attribution answer

The measurement problem starts upstream. AI assistants can only recommend, compare, and link to products they can understand.

For an ecommerce brand, that means product data needs to be structured, current, and machine-readable. Useful product data includes:

- canonical product URLs
- titles and descriptions written for real product distinctions
- attributes such as material, size, color, fit, compatibility, and use case
- variant-level price, availability, and identifiers
- shipping, return, and warranty policies
- review and rating signals
- images and product specifications
- category and collection context

Better product data helps assistants choose the right product for the right query. It also creates cleaner measurement patterns. If an assistant links consistently to the canonical product detail page, the traffic is easier to analyze. If product data is fragmented across duplicate URLs, stale feeds, marketplace pages, and mismatched variants, the traffic signal gets noisier.

This is the Catalog angle. Catalog is the [product data layer for AI commerce](https://www.getcatalog.ai/): it helps brands make product data structured, current, and assistant-readable without replacing the existing storefront. That matters for DACT because visibility, recommendations, links, and attribution all depend on product-level data being clear enough for machines to use.

The brands that handle this well will not only ask, "How much AI traffic did we get?" They will ask:

- Which products did assistants understand well enough to recommend?
- Which product pages received unexplained high-intent Direct traffic?
- Which product attributes or sources caused the assistant to choose a competitor?
- Which canonical URLs should answer engines cite?
- Which product-data gaps make the traffic harder to earn or measure?

That is a stronger operating loop than waiting for GA4 to solve the problem on its own.

## Common mistakes to avoid

### Treating every Direct session as AI traffic

Direct traffic has many causes. Some of it is real direct demand. Some of it is untagged campaigns. Some of it is dark social. Some of it may be AI-assisted. A DACT model should isolate likely patterns, not relabel the whole Direct bucket.

### Looking only at visible ChatGPT referrals

ChatGPT may be the largest visible AI referrer for many sites, but Gemini, Perplexity, Claude, Copilot, Google AI Overviews, and retail-specific assistants can all influence discovery. Visible referral reports are the floor, not the ceiling.

### Ignoring branded organic influence

A shopper can discover a product in an answer engine, then search for the brand or product name in Google. That conversion may be credited to branded organic even though AI did much of the qualification.

### Forgetting mobile and app behavior

Known AI referral data can skew desktop because browser sessions preserve source data more often. Mobile app traffic can be harder to classify. Segment device and browser patterns before drawing conclusions.

### Waiting for perfect attribution

Perfect attribution is unlikely. Waiting for it means you underinvest in the product data, monitoring, and measurement habits that make AI commerce legible.

## FAQ

### Is dark traffic the same as direct traffic?

No. Direct traffic is the analytics bucket. Dark traffic is the portion of traffic inside that bucket, or sometimes inside other under-attributed buckets, where the true source was lost. Some Direct traffic is genuinely direct. Some is unattributed traffic from campaigns, apps, documents, privacy tools, or AI assistants.

### Is AI referral traffic always hidden?

No. Browser-based visits from domains such as ChatGPT, Perplexity, Claude, Gemini, or Copilot can show up as referrals when source data is passed. The hidden portion usually comes from app handoffs, privacy controls, copied links, missing UTMs, redirects, or assistant-influenced journeys that end through branded search or direct visits.

### Can GA4 measure DACT exactly?

No. GA4 can measure known AI referrers and it can segment likely dark traffic patterns, but it cannot identify an original source that was never sent. The right approach is to combine GA4 segments, server-log checks, product-page patterns, and answer-engine visibility data into a range.

### What should ecommerce teams do first?

Create a known AI-referral channel, then build a baseline for normal Direct traffic to product and category pages. After that, monitor answer-engine visibility for the same products and compare visibility changes with Direct product-page movement, add-to-cart rate, conversion rate, and branded/product-name search.

## The takeaway

Dark traffic is not new. What is new is the way AI assistants can create high-intent ecommerce demand before analytics ever sees a source.

Treat DACT as an operating signal. Separate known AI referrals. Estimate the dark portion with GA4 and logs. Monitor answer-engine visibility. Improve the structured product data that helps assistants recommend and link to the right products.

The brands that do this will have a clearer view of AI commerce than teams that treat Direct traffic as a mystery bucket and move on.

---

Canonical: https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# AI shopping assistant: what it is, how it works, and how brands should prepare

*July 14, 2026 · Catalog Team · AI Commerce · 15 min*

> A practical guide to AI shopping assistants, product data readiness, and the hidden measurement problem brands need to plan for.

An AI shopping assistant is software that helps a shopper describe what they need, compare products, and move toward a product page or purchase through a [conversational interface](https://www.getcatalog.ai/blog/conversational-commerce-guide). Instead of typing a short keyword like "running shoes," a shopper can ask for "trail running shoes under $150 for wide feet that can handle wet roads" and expect the assistant to narrow the options.

That makes the assistant useful to shoppers, but it also changes the job for brands. The assistant can only recommend products it can understand. If your product data is thin, inconsistent, out of date, or trapped inside a page layout that machines cannot parse cleanly, the assistant has less to work with.

There is a measurement problem too. AI shopping assistants and answer engines can send high-intent shoppers directly to product detail pages, but that traffic may not always arrive with a clean referrer. In analytics, some of those visits can look like [Direct traffic rather than AI-referred traffic](https://www.getcatalog.ai/blog/referral-traffic-google-analytics). Brands that only watch obvious referral reports may undercount the channel while product-level demand is already moving.

## What is an AI shopping assistant?

An AI shopping assistant is a conversational system that helps shoppers make product decisions. It can interpret a need, ask follow-up questions, retrieve product options, compare those options, and explain why a specific product fits.

There are two common types:

1. **External AI shopping assistants.** These live in answer engines, marketplaces, search experiences, or AI apps. Examples include [ChatGPT Shopping](https://chatgpt.com/shopping/), [Amazon Rufus](https://www.aboutamazon.com/news/retail/amazon-rufus), Perplexity Shopping, and AI shopping experiences inside larger platforms.
2. **Onsite AI shopping assistants.** These live on a retailer or brand's own site. They act more like a store associate: answering questions, recommending products, explaining fit, and helping shoppers navigate a catalog.

The two categories are starting to overlap. A shopper may research a product in an external assistant, click into a product detail page, then expect the brand site to continue the same level of help. This is one practical expression of broader [agentic commerce](https://www.getcatalog.ai/blog/what-is-agentic-commerce). For a brand, the common requirement is the same: the product data has to be complete, current, and readable.

## AI shopping assistant vs. chatbot vs. recommendation engine

The terms are often used loosely, but they are not the same thing.

| System | What it mainly does | What it needs from your catalog |
| --- | --- | --- |
| Basic chatbot | Answers predefined questions or routes support requests | Help content, order data, policy answers |
| Recommendation engine | Suggests products based on behavior, rules, or similarity | Product attributes, categories, behavioral data, inventory |
| AI shopping assistant | Understands a shopper's goal, compares options, explains tradeoffs, and helps the shopper act | Structured product facts, variants, price, availability, policies, reviews, use cases, and trust signals |

A basic chatbot can tell a shopper your return policy. A recommendation engine can show "similar products." An AI-powered shopping assistant should be able to handle a messier request, such as: "I need a carry-on bag for a three-day work trip, under $250, that fits most US airline bins and has a laptop sleeve."

To answer that well, the assistant needs more than a product title and image. It needs dimensions, materials, airline-fit claims, laptop compartment details, price, stock, shipping timelines, reviews, and enough confidence that those facts are current.

## How AI shopping assistants work

Different systems use different models and data sources, but most AI shopping assistants follow the same basic path.

1. **They interpret shopper intent.** The assistant turns a natural-language request into product requirements: budget, category, size, style, occasion, compatibility, urgency, brand preferences, exclusions, and constraints.
2. **They retrieve candidate products.** The system searches a product index, merchant feed, website, marketplace catalog, API, or broader web corpus for possible matches.
3. **They read product facts.** The assistant looks for structured and unstructured product information: attributes, specs, variants, price, availability, shipping, returns, images, reviews, and comparisons.
4. **They rank and explain options.** The assistant weighs which products best match the shopper's constraints and then explains the recommendation in plain language.
5. **They route the shopper.** The assistant may send the shopper to a product detail page, add the item to a cart, start checkout, or hand the shopper to an onsite experience.

The important part is step three. Assistants do not recommend products because a brand says "best" in a headline. They recommend products when the product record contains facts the assistant can map to the shopper's request.

## Examples of AI shopping assistants

AI shopping assistants now show up across several surfaces.

| Assistant type | Example | How shoppers use it |
| --- | --- | --- |
| General answer engine shopping | ChatGPT Shopping, Perplexity Shopping | Ask for product ideas, compare options, filter by need, and click through to products |
| Marketplace assistant | Amazon Rufus | Ask questions inside a marketplace catalog, compare products, and get recommendations based on marketplace product data |
| Onsite ecommerce assistant | Retailer or brand-site assistant | Ask store-specific questions, get guided product discovery, and continue toward checkout |
| Vertical shopping agent | Category-specific or commerce-platform agent | Get recommendations in a narrower category, such as fashion, beauty, grocery, furniture, or B2B purchasing |

The shopper behavior is similar across all of them: people ask in full sentences. They include constraints that do not always map to traditional filters. They expect the assistant to know the difference between similar products and to explain the match.

That is why product data becomes a growth lever. If your product record does not include the facts shoppers ask about, the assistant has to infer, skip, or choose a competitor with clearer data.

## Why product data decides whether assistants can recommend you

AI shopping assistants need a product data layer, not just a website. Your product pages still matter, but assistants also need product facts in a form they can retrieve, verify, and compare.

The highest-value product data usually falls into these buckets.

| Product data area | Why assistants need it | Examples |
| --- | --- | --- |
| Core identity | To know what the product is and avoid duplicates | Brand, title, category, SKU, GTIN, MPN, canonical URL |
| Attributes and specs | To match natural-language needs | Material, size, color, fit, dimensions, capacity, compatibility, ingredients, use case |
| Variant relationships | To avoid comparing the wrong SKU | Size/color variants, bundles, refills, multi-packs, replacement parts |
| Commercial data | To recommend products shoppers can actually buy | Price, sale price, availability, inventory, shipping timing, return policy |
| Trust signals | To decide whether a recommendation is safe to surface | Reviews, ratings, warranty, certifications, provenance, editorial or merchant proof |
| Machine-readable distribution | To make the data accessible beyond the visible page | Product structured data, merchant feeds, clean APIs, channel-specific product feeds |

Google's [product structured data guidance](https://developers.google.com/search/docs/appearance/structured-data/product) says product data can expose details such as price, availability, review ratings, and shipping information in richer search experiences. It also notes that using both page structured data and Merchant Center feeds can help Google understand and verify product data. That same logic applies more broadly to AI shopping: the clearer the product facts, the easier it is for machines to reason over them.

This is also why [product data quality](https://www.getcatalog.ai/blog/product-data-quality) matters more in AI shopping than it did in a simple keyword search workflow. Missing attributes do not just create a bad back-office record. They remove the facts an assistant needs to match a shopper's request.

A weak product record might say:

> "Commuter jacket. Lightweight. Available in black."

An assistant-ready product record is more useful:

> "Women's waterproof commuter jacket. Recycled nylon shell, relaxed fit, taped seams, packable hood, reflective trim, sizes XS-XL, colors black/navy/olive, in stock, ships in two business days."

The second version gives an assistant actual match criteria. It can answer prompts about rain, commuting, sustainability, fit, size, visibility, and availability.

## The hidden measurement problem: AI shopping visits can look like Direct traffic

AI shopping assistants do not only summarize products. They can send shoppers to product detail pages.

That creates a useful new path:

1. A shopper asks an assistant for a product recommendation.
2. The assistant compares options and names a product.
3. The shopper clicks through to the product detail page.
4. The shopper arrives with high intent because the assistant already handled part of the research.

But the visit may not always show up as an obvious AI referral.

Retailgentic calls this pattern [Dark Agentic Commerce Traffic](https://www.retailgentic.com/p/dark-agentic-commerce-traffic-dact): answer engines and AI apps sending shoppers to product pages without clean referrer data or UTM tags. When that happens, analytics tools may classify the session as Direct even though the shopper came from an AI recommendation. This is the same measurement problem behind [dark agentic commerce traffic](https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic): the assistant may create demand even when the analytics platform cannot see the source.

Retailgentic cites several datasets to argue that the undercount can be large, including a Loamly analysis of 446,405 tracked visits where 70.6% of AI-influenced traffic landed as Direct and only 29.4% carried a referrer. Treat that as a source-attributed benchmark, not a universal rule for every site. The practical point is still important: Direct product-page traffic is not always a pure "typed the URL" channel.

Visible AI referrals can also be high-intent. [Search Engine Land reported](https://searchengineland.com/chatgpt-vs-non-branded-organic-search-conversions-470321) a Visibility Labs analysis across 94 ecommerce sites where ChatGPT traffic converted at 1.81% versus 1.39% for non-branded organic search, a 31% lift. The sample still represented a small share of revenue, but it suggests that assistant-driven traffic can be closer to a qualified shopping handoff than a casual visit.

Brands should not relabel every Direct PDP session as AI traffic. Instead, use the DACT pattern as a measurement hypothesis:

- Did Direct traffic to product pages rise while visible AI referrals stayed low?
- Are those Direct PDP sessions landing deep in the catalog instead of on the homepage?
- Do they show stronger add-to-cart, checkout, or conversion behavior than ordinary Direct sessions?
- Do increases line up with product visibility inside ChatGPT, Perplexity, Gemini, Rufus, or other shopping assistants?

If the answer is yes, the assistant channel may be larger than standard referral reports suggest.

## How brands should prepare for AI shopping assistants

Preparing for AI shopping assistants is not only an SEO task. It is a product data, merchandising, analytics, and distribution task.

### 1. Pick the products you want assistants to recommend

Start with the products that matter commercially:

- best sellers;
- high-margin products;
- products with strong reviews;
- products in categories where shoppers ask complex questions;
- products that already receive non-branded discovery traffic;
- products where AI assistants already mention competitors.

Do not try to fix every SKU at once. Start where recommendation quality would actually change revenue.

### 2. Build assistant-ready product records

For each priority product, write down the shopper questions the product should be able to answer.

For apparel, that might include fit, material, occasion, season, sizing, care, color, returns, and shipping. For electronics, it might include compatibility, dimensions, battery life, inputs, warranty, and replacement parts. For beauty, it might include ingredients, skin type, allergens, usage instructions, certifications, and shade matching.

Then compare those questions against the product record. If the answer only exists in an image, a long paragraph, a PDF, or a support article, make it explicit in structured product data.

This is where [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) matters. Enrichment turns raw product content into machine-readable facts an assistant can compare.

### 3. Normalize variants, bundles, and identifiers

AI shopping assistants can make bad recommendations when variant logic is muddy.

A size variant is not the same thing as a bundle. A replacement part is not the same thing as the main product. A colorway with different availability should not be treated as a generic option if the shopper needs a specific color now.

Make sure each product record has stable identifiers and clear relationships:

- parent product;
- child variants;
- SKU;
- GTIN or MPN where available;
- color, size, pack, or configuration;
- bundle components;
- accessories and replacement parts.

Clean identifiers help assistants avoid duplicate products, stale listings, and mismatched recommendations.

### 4. Keep price, stock, shipping, and returns current

A shopping assistant loses trust quickly if it recommends unavailable products or outdated prices. Fresh commercial data matters because shoppers ask questions like:

- "What can arrive by Friday?"
- "Which option is under $100?"
- "Is this available in size 8?"
- "Can I return it if it does not fit?"

Your data layer needs to keep these facts synchronized across product pages, feeds, marketplaces, and AI-facing surfaces. A [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication) workflow helps keep the same product facts current wherever a shopper or assistant finds them.

### 5. Publish data in machine-readable formats

AI shopping readiness is strongest when product facts are available in multiple reliable forms:

- product structured data on the page;
- merchant feeds where relevant;
- clean product APIs for partners and builders;
- accurate sitemaps and canonical URLs;
- consistent product information across marketplaces, retail media, affiliates, and shopping surfaces.

For developers building AI shopping experiences, structured product data can be more useful than scraped HTML. Catalog provides full product objects, variant-level price and stock, normalized specs, images, and stable product data that agents can build on.

### 6. Add proof the assistant can trust

Assistants need more than product claims. They need signals that make a recommendation defensible.

Useful proof includes:

- verified reviews and ratings;
- return and warranty policies;
- shipping timelines;
- ingredient, material, or certification details;
- compatibility charts;
- comparison data;
- customer-fit notes;
- provenance or sourcing information;
- expert or editorial context when it is real.

Do not bury this information in vague marketing copy. Put it where the product record, page, and feeds can expose it clearly.

### 7. Measure visible AI referrals and dark PDP patterns

Track obvious AI referrals from ChatGPT, Perplexity, Gemini, Claude, Copilot, and other assistants when referrers are available. Then build a separate view for possible dark assistant traffic.

A practical baseline can include:

- Direct sessions landing directly on product detail pages;
- Direct PDP sessions with strong engagement or conversion;
- branded organic sessions landing on specific PDPs after assistant visibility improves;
- product-level lifts that coincide with AI visibility checks;
- differences between desktop web referrals and mobile/app-driven behavior.

The goal is not perfect attribution. The goal is to avoid dismissing AI shopping because the clean referral number looks small.

### 8. Monitor product-level AI visibility

Classic rankings are not enough. Brands should also test whether assistants can answer product prompts accurately.

For example:

- "What is the best waterproof commuter jacket for rainy cities?"
- "Which of these products has the safest ingredients for sensitive skin?"
- "What is a good budget alternative to [competitor product]?"
- "Which products from [brand] are in stock under $150?"

Track whether your brand appears, which product gets mentioned, what claims the assistant makes, which pages it cites or links to, and whether the answer is accurate. For deeper channel-specific preparation, start with how to improve [ChatGPT product visibility](https://www.getcatalog.ai/blog/how-to-make-products-show-up-in-chatgpt). If the assistant names the wrong product, misses a key SKU, or invents a claim, the fix may be a product data problem before it is a content problem.

## Where Catalog fits

Catalog is built for the product data layer behind AI commerce. For brands, that means turning catalog data into a cleaner, richer, AI-ready representation that assistants can read, trust, and route shoppers toward. For developers, it means using normalized product objects instead of brittle scraping or shallow search snippets.

If you are preparing for AI shopping assistants, the immediate work is not to chase every new interface. It is to make your products legible across the interfaces that already exist.

That starts with structured product facts, clean variants, current commercial data, and measurement that can see beyond obvious referral reports.

## FAQ

### Are AI shopping assistants the same as AI shopping agents?

They overlap. "AI shopping assistant" usually describes the user-facing experience that helps a shopper discover, compare, and choose products. "AI shopping agent" often implies more autonomy, such as taking actions, monitoring options, building carts, or completing parts of the purchase flow. In practice, many people use the terms interchangeably.

### Do AI shopping assistants replace ecommerce site search?

No. They change what shoppers expect from product discovery. Site search still matters, especially on your own site. But assistants can handle longer, messier, more contextual requests. The strongest commerce experiences will connect search, recommendations, product data, and conversational help instead of treating them as separate systems.

### What product data does an AI shopping assistant need?

At minimum, it needs product identity, category, attributes, specs, variants, price, availability, images, shipping, returns, and reviews or trust signals. The more specific the shopper's request, the more specific the data needs to be. A generic product title and short description are usually not enough.

### How can I tell if AI shopping assistants are sending traffic to my site?

Start with visible referral traffic from AI tools, then look for possible dark traffic patterns: Direct sessions landing deep on product pages, high-intent PDP behavior, branded organic visits to specific products, and product-level lifts that line up with improved assistant visibility. Do not treat every Direct visit as AI traffic, but do not assume AI traffic is limited to clean referrers either.

### Should brands build their own AI shopping assistant or optimize for external assistants first?

Most brands should do the product data work first. Clean product data improves onsite assistants, external answer engines, marketplaces, feeds, search, recommendations, and analytics. Once the data layer is strong, it is easier to decide whether to build an onsite assistant, partner with a platform, or focus on external AI shopping visibility.

---

Canonical: https://www.getcatalog.ai/blog/ai-shopping-assistant-guide
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product data quality: dimensions, examples, and how to audit it

*July 10, 2026 · Catalog Team · Product Data · 14 min*

> Learn what product data quality means, which dimensions matter, how to audit product records, and how to improve data for search and AI commerce.

Product data quality is the difference between a product record that merely exists and a product record that can be trusted by shoppers, teams, sales channels, search systems, and AI shopping tools.

A low-quality record might have a title, image, and price, but still fail in practice. The size chart may be missing. The material may be wrong. The same color may appear as "navy," "blue," and "midnight" in different systems. The price may be current on the PDP but stale in the feed. The GTIN may be invalid. The description may sound polished but omit the facts a shopper needs to compare products.

Good product data quality means those gaps are found before they reach the customer or the channel. The product record is accurate, complete, consistent, current, valid, unique, and useful wherever the product appears.

## What product data quality means

Product data quality is the degree to which product information is fit for its intended use.

For ecommerce teams, product data includes more than the visible copy on a product detail page. It includes:

- product titles and descriptions;
- prices, promotions, availability, and inventory signals;
- sizes, materials, ingredients, dimensions, compatibility, care instructions, and other [product attributes](https://www.getcatalog.ai/blog/product-attributes-guide);
- product categories, taxonomy, collections, and merchandising tags;
- product identifiers such as SKU, GTIN, MPN, brand, and variant IDs;
- images, videos, manuals, guides, and other digital assets;
- variant relationships, bundles, accessories, and replacement parts;
- structured data, feed fields, marketplace fields, and API fields.

That makes product data quality slightly different from generic data quality. The same classic data-quality dimensions still apply, but each one needs an ecommerce translation.

A [product catalog](https://www.getcatalog.ai/glossary/product-catalog) can be complete enough for an internal team and still be weak for a marketplace, shopping feed, or AI shopping answer. A product description can be persuasive and still be low quality if it is based on guessed attributes. A [PIM](https://www.getcatalog.ai/glossary/pim) can store data centrally and still let incomplete or invalid records reach downstream channels if the validation rules are weak.

The practical question is not "Do we have product data?" It is "Can every system and shopper that uses this product record rely on it?"

## Product data quality dimensions

Most data-quality frameworks use dimensions such as accuracy, completeness, consistency, timeliness, validity, and uniqueness. For product data, those dimensions become concrete checks against the fields that help people and systems understand a product.

| Dimension | Product-data question | Example issue |
| --- | --- | --- |
| Accuracy | Are the facts true? | A jacket is listed as waterproof when the supplier spec says water-resistant. |
| Completeness | Are required and helpful fields filled? | A furniture item has no dimensions, weight, care instructions, or delivery constraints. |
| Consistency | Do systems and channels describe the product the same way? | The same color appears as `navy`, `navy blue`, and `midnight` across the PDP, feed, and marketplace listing. |
| Timeliness | Is the information current? | A product feed still shows an old sale price or out-of-stock item as available. |
| Validity | Does the value follow the required format or accepted list? | A GTIN has the wrong number of digits, or a marketplace category value does not match the channel's taxonomy. |
| Uniqueness | Are products, variants, and identifiers deduplicated? | Two SKUs represent the same variant, splitting reviews, inventory, and reporting. |
| Usefulness | Does the record give shoppers and systems enough context? | A description says "premium everyday sneaker" but omits fit, materials, sole type, care, and use cases. |

Usefulness is the ecommerce layer on top of the standard dimensions. A record can technically pass validation and still be unhelpful. It may have a title, price, and image, but lack the attributes that make the product searchable, comparable, recommendable, or safe to buy.

## Why poor product data quality hurts commerce

Poor product data quality creates problems in four places: shopper experience, product discovery, channel eligibility, and internal operations.

### Shopper confidence

Shoppers use product information to decide whether an item fits their needs. A [2023 peer-reviewed article on product information quality](https://openresearch.surrey.ac.uk/esploro/outputs/journalArticle/Presenting-products-on-websites---the/99778164502346) found that product information quality criteria directly affect online shopping outcomes, with title readability and product attribute comparability standing out as important factors.

That tracks with the everyday ecommerce experience. If a shopper cannot compare fabric, dimensions, fit, compatibility, ingredients, or warranty details, they either hesitate, ask support, order the wrong item, or leave for a better-described product.

### Product discovery

Site search, filters, product recommendations, and [site merchandising](https://www.getcatalog.ai/blog/site-merchandising) rules depend on structured attributes. If color, size, category, product type, use case, or compatibility data is missing or inconsistent, products become harder to retrieve.

A shopper searching for "wide calf black leather boots" needs the product record to contain those facts in structured or clearly readable form. If "wide calf" only appears in a buried image, or if leather is stored as a free-text note instead of a normalized material value, the product may not appear where it should.

### Channel eligibility

External channels are even less forgiving. [Google Merchant Center's product data specification](https://support.google.com/merchants/answer/7052112?hl=en) says Google uses submitted product data to match products to the right queries. It also says accurate and correctly formatted product data is essential for ads and free listings, and that incorrect, inaccurate, or missing product information can cause disapprovals, limited eligibility, incorrect product displays, or other issues.

That is product data quality in its most practical form. A missing required field, invalid identifier, stale availability value, or mismatched landing page can stop a product from showing correctly in a shopping surface.

### Internal operations

Bad product data also creates manual work. Merchandising teams fix the same attribute in several systems. Support teams answer questions that should have been answered on the product page. Marketplace teams chase avoidable feed warnings. Data teams reconcile duplicate variants. Growth teams diagnose search issues that were actually catalog issues.

The cost compounds because product data is reused. One weak source record can create errors across product pages, shopping feeds, retailer listings, ads, APIs, and partner catalogs.

## Common product data quality problems

Product data quality problems usually look small in isolation. At catalog scale, they become hard to manage.

### Missing attributes

Missing attributes are the most common issue because every category has different requirements. Apparel needs size, fit, material, care, color, pattern, and model details. Electronics need compatibility, dimensions, power, ports, warranty, and included accessories. Beauty products may need ingredients, shade, volume, skin type, usage instructions, and warnings.

A generic required-field rule is not enough. The data model has to know what "complete" means for each category.

### Incorrect specifications

Incorrect specifications are more damaging than missing ones because they create false confidence. A wrong size, voltage, material, ingredient, compatibility claim, or pack count can lead to returns, support tickets, compliance problems, or poor reviews.

Accuracy checks should compare product fields against trusted source material, such as supplier specs, manufacturer sheets, packaging, ERP data, labelling rules, or approved internal records.

### Inconsistent naming and taxonomy

Inconsistent taxonomy makes products harder to find and group. One system may use "running shoes," another "athletic footwear," and another "trainers." One channel may require a controlled category path while another accepts free text.

The same problem appears in attributes. `XL`, `Extra Large`, and `X-Large` may look equivalent to a person, but a filter, feed, or recommendation model may treat them as different values.

### Stale price and availability

Price and availability change often, so they need a different quality process than slower-moving attributes. A product can be accurate in the morning and wrong by the afternoon.

Stale price or availability is especially risky because it affects paid traffic, marketplace eligibility, customer trust, and conversion. If an ad or shopping result says the product is available at one price and the landing page says something else, the channel may reject or limit the listing.

### Invalid identifiers and feed values

Product identifiers connect records across systems. A weak identifier strategy can create duplicate products, mismatched variants, broken reviews, bad reporting, and channel errors.

Common issues include invalid GTINs, missing brand values, reused SKUs, inconsistent variant IDs, malformed image URLs, unsupported condition values, and category values that do not match a channel taxonomy.

### Weak descriptions and media

Product data quality covers structured fields and customer-facing content. Weak descriptions, missing images, low-quality media, and thin bullet points make it harder for shoppers to understand the product.

The best product descriptions usually come from structured facts: material, fit, use case, dimensions, ingredients, compatibility, benefits, constraints, and proof. If those facts are missing, copywriters and AI tools have to guess.

For examples of copy that turns structured product facts into useful buyer-facing text, see Catalog's guide to [product description examples](https://www.getcatalog.ai/blog/product-description-examples).

## How to audit product data quality

A product data quality audit should inspect both the source record and the places where the record is used. A source field can look fine in a spreadsheet and still break on a product page, feed, marketplace, or AI shopping surface.

### 1. Choose the products and channels that matter most

Start with high-impact areas instead of trying to audit the whole catalog at once. Good first samples include:

- top-selling products;
- high-margin or strategic products;
- products with high return or support volume;
- categories with many variants;
- products with marketplace or feed warnings;
- products that are important for organic search;
- products that AI shopping or recommendation systems need to interpret.

Then choose the destinations you will test. A PDP audit, Google Merchant Center audit, marketplace audit, and API audit may all reveal different issues.

### 2. Define required fields by category and destination

Completeness should not be a single global checklist. It should vary by category and channel.

For example, a cookware product may require material, dimensions, capacity, care instructions, heat tolerance, compatibility, included parts, and warranty. A beauty product may require ingredients, shade, volume, skin type, usage directions, warnings, and certifications.

Destination rules matter too. Google, Amazon, a retail partner, and your own storefront may all require different versions of title, description, image, category, identifier, price, and availability data.

### 3. Check accuracy against the source of truth

Pick a trusted source for each field type. Supplier spec sheets may be the source for dimensions and materials. ERP data may be the source for inventory. A PIM may be the source for approved marketing attributes. A compliance system may be the source for warnings or certifications.

Do more than check whether a field is filled. Check whether it is true.

### 4. Measure completeness and attribute coverage

Track completeness at two levels:

- record completeness: the percentage of required fields filled for each product;
- category coverage: the percentage of products in a category that have the attributes needed for filters, comparisons, recommendations, feeds, and PDPs.

A product may have every globally required field and still be weak for its category. For example, a shoe without width, arch support, material, closure type, and intended use may be technically publishable but hard to compare.

### 5. Normalize values for consistency

Look for uncontrolled value drift:

- `navy`, `navy blue`, `midnight`, and `dark blue`;
- `XL`, `X-Large`, and `Extra Large`;
- `stainless`, `stainless steel`, and `SS`;
- category paths that split the same products across several groups.

Normalization improves filters, analytics, feed mapping, search relevance, and recommendation logic.

### 6. Test validity against downstream rules

A value can be accurate but still invalid for a channel. The product may really be "midnight blue," but the destination may only accept `blue`. The image may be correct, but the URL may be blocked. The category may make sense internally, but not match the marketplace taxonomy.

Validate product data against the real rules of the systems that consume it: storefront templates, structured data, shopping feeds, retailer portals, marketplaces, APIs, and ad platforms.

### 7. Check freshness for changing fields

Price, availability, inventory, promotions, delivery dates, and seasonal fields need freshness checks. Measure how long it takes for a change in the source system to reach each destination.

Freshness matters most where stale data creates a visible customer promise: price, stock, delivery, sale status, and product eligibility.

### 8. Review the customer-facing page

Automated validation can miss quality issues that shoppers notice immediately. Review a sample of product pages and ask:

- Does the title clearly identify the product?
- Are the attributes specific enough to compare against alternatives?
- Do descriptions explain the product's use cases and constraints?
- Do images show the product clearly and support the claims in the copy?
- Are variants easy to understand?
- Are compatibility, sizing, and installation details visible when relevant?
- Would a shopper need to contact support to answer a basic question?

This is where product data quality meets product content quality.

### 9. Use diagnostics and behavioral signals

Downstream systems often tell you where quality is weak. Review:

- Merchant Center, marketplace, and retailer portal warnings;
- feed rejection reasons;
- structured data errors;
- site search terms with zero results;
- product filters that return too few or too many products;
- high-return products with unclear specs;
- support questions about missing product details;
- AI shopping prompts where products are omitted or described incorrectly.

These signals help prioritize fixes that matter in the real customer journey.

## Product data quality metrics to track

Dimensions describe quality. Metrics make quality visible and manageable.

| Metric | What it measures | Why it matters |
| --- | --- | --- |
| Required-field completeness rate | Percentage of required fields filled by product, category, and channel | Shows whether records are publishable and useful for each destination. |
| Attribute coverage by category | Percentage of products with category-specific attributes | Reveals whether products can power filters, comparisons, and recommendations. |
| Accuracy pass rate | Percentage of sampled fields that match trusted source material | Finds wrong facts as well as empty fields. |
| Validation error rate | Number or percentage of records failing internal, feed, API, or marketplace rules | Shows where data is not valid for downstream use. |
| Duplicate product or variant rate | Number of duplicate records, identifiers, or variants | Prevents split inventory, reviews, reporting, and search relevance. |
| Freshness lag | Time between a source change and the update reaching each destination | Protects price, availability, inventory, and promotion accuracy. |
| Channel rejection or warning rate | Products rejected, limited, or warned by a channel | Connects data quality to distribution and revenue risk. |
| Media coverage rate | Products with required images, videos, manuals, or other assets | Shows whether shoppers have enough visual or supporting information. |
| Search and filter issue rate | Zero-result searches, low-result filters, or unexpected product matches tied to missing data | Connects product data quality to product discovery. |
| Time to fix | Time from issue detection to corrected downstream record | Measures whether quality problems are becoming easier to resolve. |

The exact metrics matter less than consistency. Pick the checks that map to your catalog, channels, and customer journey, then review them on a regular cadence.

## How to improve product data quality

Improving product data quality is not a one-time cleanup. It is a process for preventing bad data from entering the system, enriching weak records, and catching downstream issues quickly.

### Build category-specific data models

Define the attributes each category needs. Do not force every product into the same generic field list. A furniture category, electronics category, beauty category, and industrial parts category each need different required fields and validation rules.

Category-specific data models make completeness meaningful. They also give merchandising, SEO, search, and AI systems richer product facts to work with.

### Use controlled values where consistency matters

Free text is useful for descriptions, but structured attributes need controlled values. Colors, sizes, materials, product types, conditions, and compatibility values should follow a clear taxonomy.

Controlled values reduce duplicate filters, improve feed mapping, and make products easier for search and recommendation systems to interpret.

### Validate before data is syndicated

Run checks before product data reaches downstream channels. Required fields, identifier formats, image URLs, category mappings, price and availability logic, and structured data should be validated before syndication.

For more on the distribution side of this process, see Catalog's guide to [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication).

### Enrich thin records from reliable sources

Some records are accurate but too thin. Enrichment fills the gaps: missing attributes, clearer descriptions, category mapping, normalized values, better product relationships, and machine-readable fields.

The important rule is that enrichment should be grounded in trusted inputs. If an AI tool writes a description without reliable product facts, it can make the copy sound better while making the data less trustworthy. Catalog's guide to [product data enrichment for AI commerce](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) covers that workflow in more detail.

### Review customer-facing content and fields

A field-level dashboard might say a product is complete, but the page may still be hard to buy from. Review titles, descriptions, bullets, images, variant labels, and comparison attributes as part of quality control.

This is especially important for high-involvement products. The more expensive, technical, regulated, or compatibility-dependent a product is, the more product information the buyer needs.

### Assign clear ownership

Product data quality often fails when everyone assumes someone else owns it. Merchandising may own attributes. Ecommerce may own PDP presentation. Data teams may own pipelines. Marketplace teams may own feeds. Suppliers may own source specs.

A good operating model defines who owns each field, who approves changes, who monitors issues, and who fixes downstream errors.

### Monitor downstream results

Even strong source data can break downstream. Keep monitoring feed diagnostics, structured data, marketplace warnings, search logs, support tickets, returns, and product-page analytics. These signals show where your quality rules need to change.

## Product data quality for AI commerce

AI commerce raises the bar for product data quality because AI systems need precise product facts to classify, compare, and recommend items.

A human shopper may infer that "water-resistant shell" belongs in outerwear. A search system, recommendation engine, or shopping agent needs the product data to state the relevant attributes clearly: material, weather protection, fit, use case, size range, color, care, price, availability, and compatible products.

The same applies to structured data. [Google's product structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/product) explains how machine-readable product information can support product snippets and merchant listing experiences. That does not mean structured data alone guarantees visibility, but it does show the direction: commerce systems work better when product facts are clear and machine-readable.

Catalog treats product data quality as the foundation for AI commerce. Clean product records make it easier to generate accurate descriptions, map products to channels, maintain [structured data](https://www.getcatalog.ai/glossary/structured-data) and [schema markup](https://www.getcatalog.ai/glossary/schema-markup), power search, and share product facts with downstream systems.

The goal is not to make every product record longer. It is to make every product record more usable: specific enough for shoppers, structured enough for systems, current enough for channels, and trustworthy enough for teams to build on.

## FAQ

### What is the difference between product data quality and product content quality?

Product data quality covers the accuracy, completeness, consistency, validity, freshness, and usability of product information across systems and channels. Product content quality is the customer-facing layer: descriptions, bullets, images, videos, guides, and other content that helps shoppers decide.

They overlap. Strong product content usually depends on strong product data. If material, fit, compatibility, dimensions, and use cases are missing from the source record, the description will either be vague or risky.

### Who owns product data quality?

Ownership depends on the company, but it usually needs a shared model. Merchandising, ecommerce, catalog operations, data, marketplace, supplier, and product teams may each own different fields or workflows. The key is to define field ownership, approval rules, validation checks, and issue response clearly.

### How often should ecommerce teams audit product data quality?

Audit high-impact products and feeds continuously or weekly, especially for price, availability, inventory, and channel warnings. Audit broader category completeness and attribute coverage monthly or quarterly. Audit product pages whenever a category launches, a marketplace changes requirements, or search and support signals show recurring product questions.

### What is the fastest way to improve product data quality?

Start with one high-impact category and one high-impact destination. Define the required fields, validate them against source material, normalize the most important attributes, fix feed or structured data errors, and review the live product pages. Once the process works, expand it to more categories and channels.

---

Canonical: https://www.getcatalog.ai/blog/product-data-quality
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product description examples: 10 patterns to use

*July 7, 2026 · Catalog Team · Product Data · 9 min*

> See product description examples by product type, learn why each one works, and use a practical framework for better ecommerce product copy.

A good product description does more than fill space on a product detail page. It tells a shopper what the product is, why it fits their situation, which details matter, and what to do next.

The strongest descriptions usually start before anyone writes a sentence. They come from clean product data: accurate attributes, variant details, materials, dimensions, ingredients, compatibility, care instructions, use cases, and channel requirements. Without that source material, even strong copywriters end up guessing.

Below are product description examples you can adapt for different product types, followed by a framework for writing descriptions from structured product data instead of from a blank page.

## What makes a product description work

A product description works when it answers the buyer's practical questions and gives them enough confidence to act.

Strong descriptions usually include five parts:

1. **The product in plain language.** What is it?
2. **The use case.** Who is it for, and when should they use it?
3. **The most important attributes.** Size, material, ingredients, compatibility, fit, flavor, finish, capacity, or other concrete details.
4. **The benefit.** Why do those attributes matter to the shopper?
5. **The next step.** Choose a size, add to cart, compare options, subscribe, request a quote, or check compatibility.

Weak descriptions often skip the middle. They say a product is premium, versatile, essential, or high quality, but they do not explain what makes it that way. Good descriptions connect the claim to facts.

## 10 product description examples by product type

Use these examples as patterns, not scripts. The best version for your product should reflect the actual product data, your customer, and the channel where the description will appear.

### 1. Apparel product description example

**Product:** lightweight rain jacket

**Example description:**

Stay dry without packing a bulky shell. This lightweight rain jacket uses a water-resistant recycled nylon outer layer, sealed front zipper, and adjustable hood to block light rain during commutes, hikes, and travel days. The relaxed fit leaves room for a sweater, while the packable pocket folds the jacket into a compact pouch for your bag.

**Why it works:**

The copy connects features to real use cases. It does not just say "water-resistant" and "packable." It explains when those details matter: commuting, hiking, travel, layering, and carrying the jacket when the weather changes.

**Product data needed:**

- material;
- weather resistance;
- fit;
- closure type;
- packability;
- hood details;
- recommended use cases.

### 2. Beauty product description example

**Product:** fragrance-free face moisturizer

**Example description:**

A daily moisturizer for skin that does not want extra fragrance, shine, or heaviness. The lightweight cream uses ceramides, glycerin, and squalane to support the skin barrier and lock in hydration for up to 24 hours. It layers cleanly under sunscreen and makeup, and the fragrance-free formula is suitable for sensitive skin.

**Why it works:**

The description names the ingredients, explains what they do, and handles common buyer objections: fragrance, shine, heaviness, sensitive skin, and layering with other products.

**Product data needed:**

- ingredients;
- skin type;
- texture;
- finish;
- usage timing;
- claim language that legal or regulatory teams have approved.

### 3. Food and beverage product description example

**Product:** oat milk latte concentrate

**Example description:**

Make a cafe-style oat milk latte in under a minute. This shelf-stable concentrate blends cold brew coffee with creamy oat milk and a light touch of brown sugar, so you only need to pour over ice or heat with your preferred milk. Each bottle makes six 8-ounce servings and contains 40 milligrams of caffeine per serving.

**Why it works:**

The description covers flavor, preparation, serving count, caffeine, storage, and a clear use case. It gives the shopper enough information to imagine using the product and enough specifics to compare it with alternatives.

**Product data needed:**

- flavor profile;
- serving size;
- serving count;
- caffeine or nutrition data;
- allergens;
- storage instructions;
- preparation instructions.

### 4. Home goods product description example

**Product:** modular sofa

**Example description:**

Build a sofa that fits the room you have now and the room you may have next. This three-seat modular sofa includes two corner units and one armless center unit that can be rearranged into a chaise, loveseat, or open lounge setup. Performance fabric resists everyday spills, and removable cushion covers make cleanup simple.

**Why it works:**

The copy turns modularity into a buyer benefit. Instead of only listing dimensions and modules, it explains why the design matters: changing layouts, smaller rooms, spills, and easier cleaning.

**Product data needed:**

- module count;
- dimensions;
- configuration options;
- fabric type;
- care instructions;
- stain resistance;
- shipping or assembly notes.

### 5. Electronics accessory product description example

**Product:** USB-C charging hub

**Example description:**

Charge your laptop, phone, and accessories from one compact hub. The 100W USB-C port powers a laptop while two USB-C ports and one USB-A port handle smaller devices. Built-in temperature control helps prevent overheating, and the 6-foot cable gives you more reach at a desk, nightstand, or hotel outlet.

**Why it works:**

The description makes compatibility and power clear. For electronics, vague copy creates returns. Buyers need wattage, port types, cable length, safety features, and the situations where the accessory solves a problem.

**Product data needed:**

- wattage;
- port types;
- supported devices;
- cable length;
- safety certifications;
- included accessories;
- compatibility exclusions.

### 6. B2B product description example

**Product:** replacement industrial air filter

**Example description:**

A replacement MERV 13 panel filter for commercial HVAC systems that require high-efficiency particulate capture without custom sizing. The filter measures 24 x 24 x 2 inches, uses a pleated synthetic media, and is rated for up to 90 days of typical commercial use. Check your system manual before ordering to confirm size, airflow requirements, and filter depth.

**Why it works:**

B2B descriptions need precision. The buyer may be comparing specs, compliance needs, and replacement intervals. The description should reduce uncertainty, not add persuasion without facts.

**Product data needed:**

- dimensions;
- rating or standard;
- material;
- compatible systems;
- expected replacement cycle;
- compliance requirements;
- warnings or exclusions.

### 7. Marketplace listing description example

**Product:** carry-on travel backpack

**Example description:**

A carry-on backpack built for short trips and overhead bins. The 35-liter main compartment opens flat for packing, while a padded laptop sleeve fits devices up to 16 inches. Exterior compression straps keep the bag compact, and a luggage pass-through slides over a suitcase handle when you want to stack your setup.

**Why it works:**

Marketplace descriptions need fast scanning. This example leads with use case, capacity, laptop fit, packing style, and travel convenience. Those are the details shoppers filter and compare across listings.

**Product data needed:**

- capacity;
- dimensions;
- laptop size;
- compartments;
- carry-on compatibility;
- material;
- warranty;
- color variants.

### 8. Variant-rich product description example

**Product:** straight-leg denim jeans

**Example description:**

A straight-leg jean with a mid rise, structured cotton feel, and enough stretch for all-day wear. Choose the short, regular, or tall inseam for the right break at the ankle. The medium indigo wash works with sneakers, boots, or loafers, and the five-pocket construction keeps the look classic.

**Why it works:**

Variant-heavy products need copy that explains the differences without forcing shoppers to open every option. Fit, rise, stretch, wash, inseam, and styling context all help reduce returns.

**Product data needed:**

- fit;
- rise;
- inseam options;
- fabric composition;
- stretch;
- wash;
- model sizing;
- care instructions.

### 9. Sustainable consumable product description example

**Product:** laundry detergent refill tablets

**Example description:**

Skip the plastic jug without changing laundry day. Drop one concentrated detergent tablet into the washer drum for a standard load, or use two for heavily soiled laundry. The tablets are fragrance-free, septic-safe, and shipped in a recyclable paper pouch that takes up less cabinet space than a liquid bottle.

**Why it works:**

The description makes the sustainability claim practical. It explains how to use the product, how much to use, who it is suitable for, and what changes compared with the old product format.

**Product data needed:**

- dosage;
- scent;
- packaging;
- certifications;
- safety claims;
- load count;
- compatibility with washer types.

### 10. Bundle product description example

**Product:** starter kit for a smart garden

**Example description:**

Start growing herbs indoors with one box. The smart garden starter kit includes a self-watering planter, full-spectrum grow light, basil and mint seed pods, plant food, and a quick-start guide. The water reservoir lasts up to two weeks, and the adjustable light arm gives seedlings more room as they grow.

**Why it works:**

Bundle descriptions should say exactly what is included and why the set is easier than buying parts separately. This example gives the contents, the outcome, and the maintenance benefit.

**Product data needed:**

- included items;
- setup steps;
- capacity;
- plant or product compatibility;
- refill options;
- maintenance cycle;
- warranty.

## A product description framework you can reuse

The fastest way to write better product descriptions is to stop starting with copy. Start with the product record.

A clean [product catalog](https://www.getcatalog.ai/glossary/product-catalog) gives writers, merchandisers, and AI systems the facts they need. If the underlying data is thin or inconsistent, every channel has to compensate later.

Use this workflow.

### 1. Define the buyer and the job

Write down who the product is for and what problem it solves. Be specific.

Weak input: "for anyone who wants comfortable shoes."

Better input: "for retail workers who stand for 8-hour shifts and need slip-resistant black shoes."

The second version tells you which attributes matter: cushioning, grip, color, durability, fit, and work-shift comfort.

### 2. Pull the source attributes

Collect the facts before writing:

- product type;
- brand;
- material or ingredients;
- size, dimensions, capacity, or weight;
- color and variant options;
- compatibility;
- use cases;
- care instructions;
- certifications;
- warranty;
- shipping or assembly details;
- channel-specific requirements.

This is where [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) matters. Enrichment turns incomplete records into usable product content by filling in missing attributes, normalizing values, and adding context that downstream systems can use.

### 3. Translate features into buyer benefits

Do not stop at the spec. Ask why the spec matters.

| Feature | Better description angle |
| --- | --- |
| 100W charging | Powers a laptop and smaller devices from one hub |
| Removable cushion covers | Makes spills easier to clean |
| Fragrance-free formula | Reduces a common irritation concern for sensitive skin |
| MERV 13 rating | Helps buyers match the filter to a system requirement |
| 35-liter capacity | Gives enough space for a short trip while staying carry-on friendly |

Features make the description accurate. Benefits make the description useful.

### 4. Match the description to the channel

The same product may need different copy across channels.

Your owned product page can include richer brand voice, comparison tables, and FAQs. A marketplace listing may need concise bullets and exact specs. A product feed may require standardized fields. An AI shopping surface may need clear, machine-readable product facts that can be extracted and compared. Those channel choices are also a [site merchandising](https://www.getcatalog.ai/blog/site-merchandising) decision because descriptions need to support the surfaces where shoppers discover and compare products.

A [PIM](https://www.getcatalog.ai/glossary/pim), product data layer, or structured content workflow helps teams maintain those versions without rewriting from scratch every time.

### 5. QA the description before publishing

Before a description goes live, check it against the product record.

Ask:

- Are the key attributes present?
- Are variant details correct?
- Are size, capacity, ingredient, compatibility, and care details accurate?
- Does the copy explain why important features matter?
- Is the description unique enough for this product?
- Does it match the channel's formatting and field requirements?
- Would a shopper understand who this product is for?

For AI shopping and search surfaces, also check whether important product facts are available in structured fields, not only in prose. [Structured data](https://www.getcatalog.ai/glossary/structured-data) gives machines a clearer way to understand the product.

## Product description template

Use this template when you need a fast first draft.

**[Product name]** is a **[product type]** for **[buyer or use case]**. It uses **[primary materials, ingredients, or technology]** to **[main benefit]**. Key details include **[attribute 1]**, **[attribute 2]**, and **[attribute 3]**. Choose **[variant or option guidance]** if you need **[specific fit, compatibility, size, flavor, or style]**.

Example:

**The Atlas commuter jacket** is a lightweight rain shell for bike commutes, travel days, and unpredictable weather. It uses a water-resistant recycled nylon outer layer and sealed front zipper to block light rain without adding bulk. Key details include an adjustable hood, packable pocket, and relaxed fit for layering. Choose the tall size if you need extra sleeve length over a sweater or blazer.

The template is simple on purpose. Add brand voice after the facts are clear.

## Common product description mistakes

### Reusing manufacturer copy everywhere

Manufacturer copy is often accurate, but it is rarely written for your exact buyer, channel, assortment, or search strategy. Use it as source material, not final copy.

### Listing features without explaining outcomes

A shopper may not know why a material, size, ingredient, or rating matters. Connect facts to use cases.

### Writing one description for every variant

If variants differ by fit, size, color, flavor, bundle, compatibility, or capacity, the description should reflect those differences. Duplicate variant copy can create confusion and returns.

### Burying critical facts

If dimensions, ingredients, material, compatibility, or care instructions matter to the purchase decision, do not hide them below decorative copy.

### Writing only for search engines

SEO matters, but keyword-stuffed product descriptions do not help shoppers. The best descriptions use the product's natural vocabulary: product type, attributes, use cases, and comparison points.

### Ignoring AI shopping surfaces

AI shopping systems need clear facts before they can compare or recommend products. A description that sounds good to a human but hides the actual attributes can still be hard for machines to parse. Catalog's guide to [Shopify ChatGPT product visibility](https://www.getcatalog.ai/blog/shopify-chatgpt-product-visibility) covers this in the context of AI shopping discovery.

## How structured product data improves product descriptions

Product descriptions are easier to write and maintain when the product data underneath them is structured.

Structured product data helps teams:

- generate first drafts from approved attributes;
- keep copy consistent across similar products;
- adapt descriptions for retailers, marketplaces, feeds, and AI surfaces;
- avoid missing required fields;
- localize or personalize copy without changing core facts;
- update downstream descriptions when price, availability, variants, materials, or claims change.

This matters most at scale. A small catalog can manually polish every page. A large catalog cannot depend on manual rewriting for every SKU, variant, bundle, and channel. The stronger the product data layer, the easier it is to create descriptions that are accurate, useful, and ready for new shopping surfaces.

## FAQ

### What is a product description?

A product description is the copy on a product page, marketplace listing, feed, or catalog entry that explains what a product is, who it is for, which details matter, and why a shopper should consider it.

### What should a product description include?

A product description should include the product type, main use case, important attributes, buyer benefits, variant or compatibility details, proof points, and a clear next step. The exact details depend on the category.

### How long should a product description be?

Use as much copy as the buyer needs to make a decision. Simple products may need a short paragraph and a few bullets. Technical, regulated, expensive, or variant-rich products usually need more detail.

### Are product descriptions important for SEO?

Yes, but they should be written for buyers first. Search engines and AI shopping systems can understand products better when descriptions include clear product types, attributes, use cases, and related terms naturally.

### How do you write product descriptions at scale?

Start with structured product data, then create templates and channel rules that turn approved attributes into useful copy. Human review still matters, but writers should refine accurate product facts instead of rebuilding every description from scratch.

---

Canonical: https://www.getcatalog.ai/blog/product-description-examples
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product data syndication: How to keep every channel accurate

*July 6, 2026 · Catalog Team · Product Data · 10 min*

> Learn how product data syndication works, which fields matter, and how to keep product data accurate across retailers, feeds, and AI shopping.

Product data syndication is the process of preparing, transforming, distributing, and keeping product information synchronized across every place products appear. That includes your own storefront, retailers, marketplaces, ad platforms, social commerce feeds, partner catalogs, APIs, and AI shopping systems.

The hard part is not sending the data once. It is making one approved product record work across many destinations that each have different rules. A retailer may need one category taxonomy. A marketplace may require specific identifiers and image formats. A shopping feed may reject products with stale prices or missing attributes. An AI shopping surface may need clear, machine-readable facts before it can compare or recommend a product confidently.

Good syndication turns product data into a reliable distribution layer. Weak syndication turns every channel into a separate cleanup project.

## What product data syndication means

Product data syndication means distributing product information from a source system to downstream channels in the format each channel expects.

The source record might live in a product information management system, ecommerce platform, ERP, spreadsheet, product data layer, or internal catalog. The destinations might include:

- owned product detail pages;
- retail partner pages;
- [marketplaces like Amazon, Walmart, or eBay](https://www.getcatalog.ai/blog/third-party-marketplace);
- shopping and ad feeds;
- social commerce catalogs;
- distributor and reseller catalogs;
- product APIs;
- AI shopping surfaces and answer engines.

A simple export is not enough because each destination has its own data contract. One channel might call a field `color`; another might require `primary_color`, `finish`, or a controlled list of accepted values. One channel might accept a long lifestyle description; another might need a shorter feed title, a clean product type, and an approved image URL.

That is why product data syndication is both distribution and translation. It takes one product record and turns it into the right version for each downstream use.

For a broader definition of syndication across content types, see Catalog's glossary entry on [content syndication](https://www.getcatalog.ai/glossary/content-syndication). Product data syndication is the product-data-specific version of that problem.

## Product data syndication vs related terms

Syndication overlaps with several ecommerce data terms, but they are not interchangeable.

| Term | What it means | How it relates to syndication |
| --- | --- | --- |
| Product data syndication | Preparing, transforming, distributing, and syncing structured product information across commerce destinations | The full workflow covered in this guide |
| Product content syndication | Distributing product copy, images, rich media, and merchandising content to commerce channels | Often part of product data syndication, but more focused on the customer-facing product experience |
| Product feed | A channel-specific file or stream, usually containing structured product records | One output of syndication, not the whole process |
| [PIM](https://www.getcatalog.ai/glossary/pim) or [PXM](https://www.getcatalog.ai/blog/product-experience-management) | Systems for managing product information or product experiences | Often the source of truth, but still needs mapping, enrichment, validation, and delivery into channels |
| Product catalog | The organized set of products, variants, fields, media, and relationships a business maintains | The source material syndication depends on |

A clean [product catalog](https://www.getcatalog.ai/glossary/product-catalog) makes syndication easier. It does not replace the need to adapt product data for each destination.

## Why product data syndication matters

Product data errors do not stay isolated. If the source record is incomplete, every destination inherits the same gap. If the mapping is wrong, one channel can display the wrong size, reject the listing, or classify the product in the wrong category. If price and availability are stale, paid traffic can land on products shoppers cannot buy.

Syndication matters because commerce teams rarely manage one product experience anymore. A single SKU might need to appear in:

- a brand storefront;
- a retailer's product detail page;
- multiple marketplaces;
- Google Merchant Center;
- Meta, TikTok, or Pinterest catalogs;
- affiliate and partner feeds;
- an internal search index;
- AI shopping and recommendation systems.

Every destination uses product data differently. Product titles, attributes, images, taxonomy, availability, and specifications all influence whether products are accepted, discovered, compared, and recommended.

This is why syndication is a product data quality problem before it is a distribution problem. The better the underlying data, the fewer manual patches each channel needs.

## The product data that has to stay synchronized

Strong product data syndication starts with knowing which fields matter. The exact schema changes by category and channel, but most workflows need to keep these data groups accurate.

### Identifiers and variant relationships

Identifiers connect the same product across systems. That includes SKU, GTIN, MPN, brand, handle, parent-child variant relationships, size/color options, bundles, and regional product IDs.

If identifiers drift, channels cannot reliably match, update, or deduplicate products. Variants may split into separate listings, merge incorrectly, or lose the relationship between size, color, price, and availability.

### Titles, descriptions, and taxonomy

Titles and descriptions need to be clear enough for shoppers and structured enough for systems. Taxonomy connects each product to the right product type, category, subcategory, and merchandising context.

This is where many teams overfit to one channel. A title that works on the brand site may be too long, too short, too branded, or missing required attributes for a marketplace feed. Strong source attributes also make it easier to turn facts into channel-specific copy; the [product description examples](https://www.getcatalog.ai/blog/product-description-examples) show how those facts become buyer-facing language.

### Attributes and specifications

[Product attributes](https://www.getcatalog.ai/blog/product-attributes-guide) are often the difference between a product that can be filtered, compared, recommended, and accepted, and a product that becomes invisible. Material, dimensions, compatibility, care instructions, capacity, fit, ingredients, finish, and use-case fields all matter differently by category.

Catalog's guide to [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) covers this deeper problem: many products technically have data, but not enough structured detail for downstream systems to use well.

### Media and rich content

Images, videos, alt text, lifestyle assets, pack shots, PDFs, manuals, and rich media all need channel-specific handling. One destination may require a white-background main image. Another may support lifestyle imagery. Another may reject images below a certain resolution.

Media syndication breaks when teams only track asset URLs, not usage rules.

### Price, availability, and policies

Price and inventory are the freshness layer. They often change faster than descriptions, specs, or media. Shipping, return, warranty, compliance, and regional policy fields also need to stay current, especially when channels display them directly.

A beautiful product record still fails if it sends shoppers to stale availability or the wrong price.

### Structured data and AI-facing facts

Modern syndication increasingly includes structured fields designed for machines, not just shoppers. That can include [structured data](https://www.getcatalog.ai/glossary/structured-data), schema markup, feed labels, normalized product facts, review summaries, compatibility fields, and AI-facing product context.

These fields help search engines, product discovery systems, and AI shopping surfaces understand what a product is, who it is for, and why it is different.

## A practical product data syndication workflow

A good workflow is repeatable. It should not depend on one person cleaning a spreadsheet before every launch.

### 1. Centralize the source product record

Start with one approved source for product information. This could be a [PIM database](https://www.getcatalog.ai/glossary/pim-database), ecommerce platform, product data layer, ERP-backed catalog, or another source-of-truth system.

The point is not the tool itself. The point is that teams know which record is canonical and which systems are downstream copies.

### 2. Normalize product data

Normalize categories, units, attribute names, variant structures, media references, identifiers, and naming conventions. For example, one system might store a color as `navy`, another as `dark blue`, and another as `blue/navy`. Syndication should resolve those differences before the data reaches channels.

Normalization makes product records easier to map and easier for software to compare.

### 3. Enrich missing or weak fields

Syndication exposes weak product data quickly. Missing dimensions, generic descriptions, incomplete compatibility fields, thin material data, and unclear variant relationships can cause feed errors or low-quality listings.

Enrichment fills those gaps with stronger product facts. That may mean better attributes, clearer descriptions, richer taxonomy, additional images, normalized values, or more machine-readable data.

### 4. Map data to each destination's requirements

Mapping is where syndication becomes channel-specific. Each destination has required fields, accepted values, category rules, image standards, title limits, and validation logic.

A practical mapping should answer:

- Which source field feeds each destination field?
- Which values need to be transformed?
- Which fields are required, recommended, or optional?
- Which products are eligible for each destination?
- Who owns exceptions when a channel rejects a product?

The best teams treat mappings as living data contracts, not one-time setup notes.

### 5. Transform and publish

Once data is mapped, it has to be delivered. That might happen through a feed file, API, marketplace connector, retailer portal, social catalog integration, or partner data exchange.

The delivery method matters less than the reliability of the output. Products should arrive in the right format, on the right schedule, with enough validation to catch errors before they hit the channel.

### 6. Validate acceptance and quality

Publishing does not mean the product is live or correct. Channels may reject products, suppress listings, ignore optional fields, or accept data that still creates a weak product experience.

Validation should cover both technical acceptance and quality:

- Did the channel accept the product?
- Which required fields failed?
- Which warnings are recurring?
- Are titles, images, attributes, and variants displaying correctly?
- Are products eligible for search, ads, marketplace placement, and recommendations?

### 7. Monitor and resync

Syndication is ongoing because products change and channels change. Prices move. Inventory shifts. New variants launch. Retailers update requirements. AI systems and search surfaces change how they interpret product information.

A healthy workflow monitors those changes and resyncs the product record before small errors become channel-wide drift.

## Where syndication workflows usually break

Most product data syndication problems come from a few recurring failure points.

**Spreadsheet drift.** Teams export data, manually edit it for one channel, and forget that the edited file is now different from the source record. The next update overwrites fixes or reintroduces old errors.

**Complete internal records that are not channel-ready.** A product may look complete inside a PIM, but still fail a marketplace requirement because a field name, accepted value, category, image rule, or identifier is missing.

**Retailer requirement changes.** Channels change schemas, required fields, image rules, category lists, and validation logic. A mapping that worked last quarter may not work now.

**Weak attributes and taxonomy.** Products with thin attributes are harder to filter, recommend, and compare. They may appear live, but still underperform because discovery systems do not have enough structured detail.

**Stale price and availability.** Static product data can be fine for descriptions and evergreen specs. It is risky for inventory, price, promotions, and fulfillment details.

**Vague AI-facing data.** AI shopping systems need explicit product facts. If a product record says "premium material" but never names the material, or says "great for travel" without dimensions, weight, capacity, or compatibility, software has less to work with.

## How AI shopping changes product data syndication

[AI shopping](https://www.getcatalog.ai/blog/ai-visibility-ecommerce) expands the destination map. Product data no longer only needs to populate pages and feeds. It also needs to be understandable to systems that summarize, compare, and recommend products in conversational interfaces.

That changes the syndication standard in three ways.

First, product facts need to be machine-readable. AI systems can read prose, but structured fields make products easier to parse consistently. Clear attributes, normalized values, variant relationships, prices, availability, reviews, and policies reduce ambiguity.

Second, data has to stay fresh. An AI answer that recommends an out-of-stock product or repeats an old price creates a bad shopper experience. Freshness becomes part of trust.

Third, product differentiation has to be explicit. If a product's strongest selling points live only in brand copy, systems may miss them. Product records need concrete facts about use cases, compatibility, materials, constraints, and alternatives.

This is the shift Catalog is built around. Catalog helps brands structure and enrich product data so products are easier for AI shopping surfaces to understand, evaluate, and recommend. Developers can use the resulting live, normalized product objects in AI-commerce applications without maintaining brittle scraping pipelines.

## How to evaluate your syndication setup

Use this checklist to find the weak points in your current workflow.

- **Source of truth:** Is there one canonical product record, or do teams maintain different versions by channel?
- **Field completeness:** Are required and recommended fields complete by category and destination?
- **Channel mappings:** Are mappings documented, versioned, and owned?
- **Validation:** Do you track acceptance, rejection, warnings, and listing quality after publishing?
- **Freshness:** How quickly do price, inventory, new variants, discontinued products, and policy changes sync?
- **Exception handling:** Who resolves rejected products, missing fields, bad images, or category mismatches?
- **AI readiness:** Are product facts structured enough for search engines, AI answer systems, and shopping agents to parse?
- **Measurement:** Can you connect product data quality to channel visibility, feed health, conversions, and AI visibility?

A syndication setup is healthy when teams can change a product once, translate it for each destination, see what failed, and keep every channel current without rebuilding the workflow manually.

## Frequently asked questions

### Is product data syndication the same as product content syndication?

Not exactly. Product data syndication focuses on structured fields such as identifiers, attributes, taxonomy, variants, price, availability, and channel-specific data. Product content syndication focuses more on product copy, images, rich media, and the customer-facing product experience. In practice, most ecommerce teams need both.

### Is a product feed the same as product data syndication?

No. A product feed is one output of syndication. Product data syndication is the broader workflow that prepares, maps, transforms, publishes, validates, and updates product data across channels. A feed can send data to a destination, but it does not by itself solve source quality, enrichment, mapping, or monitoring.

### Do you need a PIM for product data syndication?

You need a reliable source of truth. For many teams, that is a PIM or PXM system. For others, it may be an ecommerce platform, ERP-connected catalog, product data layer, or internal system. The key requirement is that product data is centralized, governed, and structured enough to map into downstream channels.

### How does product data syndication help AI shopping visibility?

AI shopping systems need accurate, structured, and current product facts before they can confidently compare or recommend products. Syndication helps by making product information more complete, machine-readable, and available across the places AI systems may read from: storefronts, feeds, APIs, structured data, marketplaces, and product databases.

## Build syndication on product data you can trust

Product data syndication works when the source data is strong, the mappings are clear, and every destination stays synchronized. It fails when teams treat syndication as a one-time export or rely on manual fixes for every channel.

The next generation of syndication has to support more than retailer portals and product feeds. It has to support AI shopping surfaces that need structured, fresh, product-level facts. Brands that build that foundation now will be easier to discover, compare, and recommend wherever shoppers ask next.

---

Canonical: https://www.getcatalog.ai/blog/product-data-syndication
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Search merchandising: a rule framework for ecommerce search

*July 2, 2026 · Hamish Gunasekara · Business · 13 min*

> Learn how search merchandising works, which rules to use for each query type, and how to balance relevance, inventory, margin, and product data.

Search merchandising is not just boosting products a merchant wants to sell. It is the discipline of deciding how ecommerce search should respond when shoppers tell you what they want.

A shopper who searches for "black trail running shoes size 9" needs a different search experience from someone who searches for "gift for new homeowner" or "waterproof jacket." The first query needs exact matching and size availability. The second may need a curated collection or guided suggestions. The third needs attribute understanding, [useful filters](https://www.getcatalog.ai/blog/ecommerce-filters), and inventory-aware ranking.

This guide explains how to design search merchandising rules around query intent, rule type, product data, and performance signals so search results stay relevant while still supporting business goals. If the underlying product facts are the bottleneck, start with the [product data quality dimensions](https://www.getcatalog.ai/blog/product-data-quality) that make search fields consistent enough to rank, filter, and explain products.

## What is search merchandising?

Search merchandising is the practice of shaping ecommerce search results with rules, ranking signals, product data, and merchandising logic.

Most search merchandising rules combine:

- **A condition:** when the rule applies, such as a query, product attribute, customer segment, inventory state, promotion, or campaign window.
- **An action:** what the search system does, such as boosting, burying, pinning, hiding, redirecting, adding synonyms, or showing a banner.
- **A guardrail:** how the team prevents the rule from hurting relevance, such as an expiration date, inventory threshold, relevance floor, preview check, or post-launch metric review.

The guardrail is the part teams often skip. Without it, search merchandising becomes a pile of manual overrides. With it, rules become a controlled layer on top of search relevance.

Search merchandising is also called **searchandising**. The terms are usually used interchangeably.

## Search merchandising vs. site merchandising

Search merchandising is one part of [site merchandising](https://www.getcatalog.ai/blog/site-merchandising), but it has a narrower job.

Site merchandising covers the full storefront: homepage modules, navigation, category pages, collection pages, recommendation slots, product tiles, content placements, promotions, and search. Search merchandising focuses on the search results experience after a shopper enters or selects a query.

That difference changes the decision logic. A homepage can introduce a campaign. A category page can inspire browsing. A search results page has to answer stated intent first. Business goals can influence the order of relevant products, but they should not make the search engine ignore the shopper's words.

## Start by classifying the query

The best search merchandising rule depends on the query type. Before writing a boost, pin, synonym, or redirect, classify what the shopper is asking for.

| Query type | Examples | What the shopper expects | Best merchandising response | Avoid |
|---|---|---|---|---|
| Exact-product or SKU query | "air max 90," "replacement filter x100" | The specific product, compatible variant, or closest available match | Protect exact matches, show availability, expose variants, avoid broad campaign overrides | Boosting unrelated promoted products above the exact match |
| Attribute-led query | "waterproof hiking shoes," "linen shirt," "oak dining table" | Products with specific attributes, not just keyword matches | Use normalized attributes, facets, and inventory-aware ranking | Relying only on title text or inconsistent tags |
| Category query | "running shoes," "sofas," "dresses" | A broad but relevant assortment with strong filters | Rank best-fit products, add useful facets, optionally boost high-performing items within relevance limits | Pinning one campaign product for every broad query |
| Problem-led query | "shoes for plantar fasciitis," "gift for dad," "small apartment desk" | Help translating a need into products | Use synonyms, buying-guide links, curated collections, or banners when product data alone is not enough | Treating the query like a simple category match |
| Brand or collection query | "nike trail," "summer linen collection" | A named brand, campaign, or collection | Route to the brand/collection, then rank by availability and relevance | Redirecting when the search results already answer the query better |
| Zero-result or low-result query | Misspellings, shopper language that differs from catalog language | A recovery path | Add synonyms, spelling tolerance, attribute normalization, or a fallback collection | Hiding the problem with a generic results page |

This classification step keeps search merchandising practical. Instead of asking, "What should we promote?" ask, "What kind of query is this, and which rule type helps the shopper complete the search?"

## Choose the right search merchandising lever

Search merchandising platforms often give you similar tools: boost, bury, pin, hide, synonym, redirect, facet, and banner. The hard part is choosing the tool that matches the problem.

| Lever | Use it when | It is the wrong move when | Watch for |
|---|---|---|---|
| Boost | Relevant products should rank higher because they are in stock, high-converting, seasonal, high-margin, new, or campaign-priority | The product is only commercially attractive, not a good match for the query | Lower click-through rate, higher no-click searches, or more refinements after launch |
| Bury | Products are relevant but less desirable, such as low-stock items, old models, weak performers, or out-of-season products | The product should be excluded entirely for legal, regional, compatibility, or availability reasons | Shoppers scrolling deeper than before or missing a product they still expect |
| Pin | A specific product or small set must occupy a position for a narrow query and limited time | The query is broad, the item may go out of stock, or personalization should decide the order | Pinned products with poor availability, stale campaign dates, or declining click share |
| Hide | Products should not appear for a query or audience | You are using hiding to compensate for weak ranking or messy data | Sudden drops in result count, zero-result increases, or support complaints |
| Synonym | Shopper language differs from catalog language | The words are not actually interchangeable or map to different product intents | Irrelevant matches, rising refinements, or shoppers adding more specific follow-up terms |
| Redirect | The query is better answered by a collection, guide, compatibility page, or brand page | Product results can answer the query directly and faster | Redirect exits, back-button behavior, or lower add-to-cart rate |
| Facet or filter | Shoppers need to narrow broad results by attributes such as size, material, color, fit, compatibility, price, or availability | The attribute is incomplete, inconsistent, or not important to selection | Low facet usage, confusing filter values, or filters that remove too many products |
| Banner or content block | The query needs context, education, promotion, or a guided next step | The banner pushes results below the fold or repeats information shoppers already know | Banner clicks, product clicks below the banner, and conversion from banner-assisted sessions |

A good rule usually changes one thing at a time. If you add a synonym, boost a margin group, pin a hero product, and show a banner for the same query, you will not know which change helped or hurt.

## Keep relevance as the floor

Business signals should refine relevant results, not replace them.

A simple way to manage this is to use a relevance floor:

1. **Return products that match the query intent.** For "black ankle boots," the result set should still be black ankle boots or very close alternatives.
2. **Remove or lower products that would disappoint the shopper.** Out-of-stock, wrong-season, unavailable-size, incompatible, or restricted products should not dominate the first page.
3. **Apply business signals inside the relevant set.** Margin, inventory depth, newness, discount, sales velocity, ratings, or campaign priority can change order once relevance is protected.
4. **Preview the first page of results.** Do not approve a rule by looking only at the first product. The full first page is what shoppers experience.

For example, a merchant may want to boost higher-margin hiking shoes. That can work for a broad query like "hiking shoes" if the boosted products are in stock, match the category, have common sizes available, and still compete on shopper value. It is a bad rule if it pushes low-relevance shoes above waterproof shoes for "waterproof hiking shoes" or above wide-fit shoes for "wide hiking shoes."

## Design rules around data fields, not guesswork

Search merchandising depends on [machine-readable product data](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce). A rule can only use the fields the search system can trust.

For each rule, write down the fields it depends on:

- **Query fields:** normalized query, tokens, misspellings, synonyms, category match, and query type.
- **Product identity fields:** title, brand, product type, category, collection, SKU, variant, and compatibility.
- **Selection attributes:** color, material, size, fit, dimensions, capacity, use case, gender, age range, style, and technical specs.
- **Commercial signals:** price, discount, margin, sales velocity, rating, review count, return rate, and lifecycle stage.
- **Availability signals:** inventory, variant availability, location, delivery speed, backorder status, and regional eligibility.
- **Content signals:** image quality, description completeness, badges, comparison copy, and product-card claims.

If a rule relies on a field that is incomplete or inconsistent, fix the data before trusting the rule. A "waterproof" boost will fail if half the waterproof products use "water resistant," some use "rainproof," and others have no material-performance value at all.

This is where a product data layer matters. Teams building search, recommendations, feeds, or AI shopping experiences need live, normalized product objects they can reuse across systems. Catalog is built for that kind of structured product-data foundation.

## Set rule precedence before rules collide

Search merchandising gets risky when overlapping rules apply to the same query. A campaign boost, synonym rule, inventory bury, and personalization model can all try to change the same result set.

Create a simple precedence order before the rule library grows. For many ecommerce teams, a practical order looks like this:

1. **Eligibility and safety rules:** remove products that cannot be sold, shipped, shown, or legally recommended.
2. **Exact-match protection:** preserve exact product, brand, SKU, and compatibility matches where the shopper intent is clear.
3. **Query understanding:** apply spelling correction, synonyms, and attribute normalization.
4. **Redirects and guided paths:** route only when a page or collection answers the query better than product results.
5. **[Inventory and availability logic](https://www.getcatalog.ai/blog/inventory-management-process):** lower products that cannot satisfy demand, especially unavailable variants.
6. **Business boosts and buries:** apply margin, campaign, newness, discount, lifecycle, or sales-velocity signals within the relevant set.
7. **Pins and banners:** use sparingly, with expiration dates and narrow query triggers.
8. **Personalization or audience rules:** adjust results only after the core query answer remains intact.

The exact order can vary. The important point is that every team knows which rule wins when rules conflict.

## Build rules with expiration dates and failure signals

Every manual rule should answer five questions:

1. **What query or query type triggers this rule?** Be specific. "Gift" and "gift for mom under $50" should not necessarily share the same rule.
2. **What action does the rule take?** Boost, bury, pin, hide, synonym, redirect, facet, or banner.
3. **Which product data fields does it rely on?** If the fields are weak, the rule is weak.
4. **When should the rule expire or be reviewed?** Campaign, seasonal, inventory, and launch rules should not live forever.
5. **What signal means the rule needs revision?** Decide before launch.

Useful failure signals include:

- Zero-result rate rises for related queries.
- No-click searches increase.
- Shoppers click lower-ranked products more than boosted products.
- Average click position moves deeper into the results.
- Query refinements increase after the rule fires.
- Facet usage drops because the result set became too narrow or confusing.
- Revenue improves but conversion rate, add-to-cart rate, or return rate worsens.
- Pinned or boosted products lose availability.

These signals keep the team from judging rules only by revenue. Search merchandising should make search easier and more commercially effective.

## A search-specific workflow

Use this workflow when improving an important search query or query group.

### 1. Pick the query group

Start with top queries, high-value queries, zero-result queries, no-click queries, low-conversion searches, or queries tied to a campaign. Group similar queries before writing rules so you do not create one-off clutter.

### 2. Classify the intent

Decide whether the query is exact-product, attribute-led, category-led, problem-led, brand/collection-led, or a recovery query. The intent determines the right rule type.

### 3. Audit the current result set

Review the first page of results. Check relevance, availability, variant coverage, product-card quality, facets, and whether shoppers have a clear next step.

### 4. Fix data gaps first

If the query depends on attributes, variants, taxonomy, compatibility, or inventory, check those fields before creating manual rules. If the data is unreliable, a rule may make the problem look solved while quietly breaking related queries.

### 5. Apply the narrowest useful rule

Choose the smallest rule that solves the problem. A synonym may be enough for shopper-language mismatch. A facet improvement may be better than a boost for broad category queries. A redirect may be right for a buying guide query, but wrong for an exact product query.

### 6. Preview with edge cases

Test the rule against close variants: singular and plural forms, misspellings, attribute combinations, brand modifiers, price modifiers, and size or compatibility modifiers. The rule should improve the intended query without damaging neighboring ones.

### 7. Measure and retire

Track the failure signals you chose before launch. Keep rules that improve search behavior. Narrow, revise, or retire rules that create irrelevant results, stale promotions, or unnecessary manual work.

## FAQ

### What is search merchandising?

Search merchandising is the practice of shaping ecommerce search results with rules, ranking signals, and product data. It helps teams decide when to boost, bury, pin, hide, redirect, add synonyms, improve facets, or show content for specific queries.

### Is search merchandising the same as searchandising?

Yes. Searchandising is shorthand for search plus merchandising. It usually refers to the same work: applying merchandising logic to ecommerce search results.

### What is the difference between search merchandising and site merchandising?

Site merchandising covers the full ecommerce storefront, including homepage modules, navigation, category pages, promotions, recommendations, product content, and search. Search merchandising focuses specifically on the search results experience and the rules that shape it.

### When should you use a boost instead of a pin?

Use a boost when a group of relevant products should move higher but the search algorithm can still decide the final order. Use a pin when a specific product or small set must appear in a fixed position for a narrow query and limited time. Pins need stricter review because they can become stale when inventory, seasonality, or shopper behavior changes.

### What product data do search merchandising rules need?

Common fields include product type, category, attributes, variants, inventory, availability, price, discount, margin, lifecycle stage, ratings, product descriptions, and compatibility data. The exact fields depend on the rule. A facet rule needs reliable attributes. An inventory-aware bury rule needs live availability. A synonym rule needs normalized product and query language.

### How do you measure search merchandising?

Track search conversion rate, add-to-cart rate, revenue per search, zero-result rate, no-click searches, average click position, query refinements, facet usage, redirect exits, rule conflicts, and expired rules. Strong search merchandising should improve business outcomes without making shoppers work harder to find relevant products.

---

Canonical: https://www.getcatalog.ai/blog/search-merchandising
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Site merchandising: how to turn product data into better shopping experiences

*June 25, 2026 · Hamish Gunasekara · Business · 16 min*

> Learn how site merchandising works across search, categories, recommendations, promos, and product pages, and why product data quality matters.

Physical stores have aisles, endcaps, shelf placement, signs, associates, and seasonal displays. Ecommerce sites have search results, category pages, homepage modules, recommendation slots, product cards, filters, promotions, and product detail pages.

Site merchandising is the work of making those online surfaces sell.

Done well, it helps shoppers find the right product faster, understand why it fits, and move to checkout with fewer doubts. Done poorly, even a good catalog becomes a maze: irrelevant search results, weak filters, stale promos, out-of-stock recommendations, generic product pages, and category pages that all look the same.

The difference comes down to data quality as much as creative judgment. A merchandising team can only promote, rank, filter, bundle, and personalize products based on the product data available to them. If attributes are missing, categories are inconsistent, inventory is stale, or product content is thin, the onsite experience breaks in ways shoppers notice immediately, especially in [ecommerce search results](https://www.getcatalog.ai/blog/search-merchandising).

This guide explains what site merchandising is, where it shows up, how it works, which metrics matter, and why structured product data is the foundation for better ecommerce merchandising.

## What is site merchandising?

Site merchandising is the process of arranging, ranking, grouping, promoting, and explaining products across an ecommerce site so shoppers can find the right products and buy with confidence.

It includes the decisions a merchant or ecommerce team makes across the full onsite journey:

- Which products appear on the homepage.
- How categories and collections are organized.
- Which products rank higher on category pages.
- Which [filters and facets](https://www.getcatalog.ai/blog/ecommerce-filters) shoppers can use.
- Which products are boosted or buried in search results.
- Which recommendations, bundles, and cross-sells appear.
- Which badges, offers, and product content are shown.
- Which add-ons appear in the cart or checkout flow.

You may also see this called website merchandising, online merchandising, ecommerce merchandising, or digital merchandising. The core idea is the same: translate the judgment of a great retail merchant into the structure of an online store.

That means site merchandising is broader than homepage banners. It is also broader than search-result ordering. Search is one important merchandising surface, but a shopper's path includes category pages, product detail pages, recommendations, promotions, and checkout prompts too.

## Site merchandising vs. search merchandising vs. product merchandising

These terms overlap, but they are not interchangeable.

| Term | What it covers | Example |
| --- | --- | --- |
| Site merchandising | The full onsite product-discovery and product-presentation experience | A seasonal landing page, category sort order, promoted products, search boosts, recommendation modules, and PDP content working together |
| Search merchandising | How products are ranked, filtered, boosted, buried, and explained inside search results and autosuggest | Boosting exact-match products for "black running shorts" and suppressing unavailable variants |
| Product merchandising | How a product or assortment is positioned, grouped, priced, promoted, and explained | Bundling a camera with a compatible lens, memory card, and case |

[Search merchandising](https://www.getcatalog.ai/blog/search-merchandising) is a subset of site merchandising. Product merchandising is one of the inputs and outputs of site merchandising. A strong ecommerce team connects all three instead of letting each surface run on a different logic.

For example, if the merchandising team launches a "summer travel" campaign, the same logic should show up across the homepage, travel category, search results, recommendation modules, PDP cross-sells, and promotional emails. If each system uses a different product feed or stale attributes, shoppers get a fragmented experience.

## Where site merchandising shows up on an ecommerce site

Every product surface is a merchandising surface. The most important ones are usually the ones shoppers touch before they know exactly what they want.

### Homepage and campaign landing pages

The homepage is the highest-visibility merchandising surface. It usually carries seasonal campaigns, new arrivals, best sellers, product launches, sale events, and brand storytelling.

Good homepage merchandising answers a simple question: what should this visitor see first?

For a first-time visitor, that might be a best-seller collection and a few category entry points. For a returning shopper, it might be recently viewed products, replenishment reminders, or recommendations based on prior behavior. For a seasonal campaign, it might be a curated assortment with clear eligibility: available now, relevant to the season, and worth promoting.

The data behind this surface includes product availability, category, margin, launch date, inventory depth, popularity, imagery, and audience fit.

### Navigation, taxonomy, and category pages

Navigation is merchandising before the product grid even appears. The labels, hierarchy, and category structure decide how shoppers understand the store.

A category page then turns that structure into a shoppable assortment. The same "men's jackets" page can feel useful or useless depending on whether it has the right filters, sort order, product cards, copy, and subcategory links.

Strong category merchandising depends on clean taxonomy and attributes. If jackets are inconsistently tagged by size, material, warmth, waterproofing, activity, color, or fit, the page cannot support useful filters or reliable product ranking.

### Search results and filters

Search is where shoppers tell you what they want. Site merchandising should make sure the answer is useful.

That means search results need more than keyword matching. The system needs product names, synonyms, attributes, category context, variants, inventory, price, content, and performance signals. A query like "waterproof hiking shoe" should not depend only on whether those words appear in the title. It should understand waterproofing, terrain, intended use, size availability, and shopper context.

Catalog has written separately about why better product data creates [better ecommerce search results](https://www.getcatalog.ai/blog/search-merchandising). The same logic applies here: weak product data limits the quality of every search and filter experience built on top of it.

### Recommendations, cross-sells, and bundles

Recommendations are merchandising decisions at the individual shopper level. They can help shoppers discover products they did not search for, complete an outfit, replenish a product, compare alternatives, or add accessories.

Useful recommendations require more than "people also bought" logic. They need product relationships and constraints:

- Which items are compatible?
- Which products are substitutes?
- Which products are complementary?
- Which variants are available?
- Which items are in the right price range?
- Which products should not be recommended together?

Without structured product relationships, recommendation modules often become noisy. They may show generic best sellers, incompatible accessories, unavailable variants, or products that do not match the shopper's intent.

### Promotional placements and badges

Promotions are merchandising shortcuts. Badges like "best seller," "new," "limited stock," "back in stock," "sustainable," or "bundle and save" help shoppers understand why a product deserves attention.

But badges only work when they are trustworthy. If "new" products are months old, "best sellers" are out of stock, or sale badges do not match the final price, shoppers learn to ignore the merchandising layer.

Promotion logic needs accurate price, inventory, launch date, margin, sale eligibility, and channel rules.

### Product detail pages

A product detail page is where merchandising turns into conviction. The shopper has clicked. Now the page needs to answer the buying questions.

Good PDP merchandising includes high-quality images, clear benefits, complete specifications, variant clarity, comparison content, reviews, shipping information, trust signals, and relevant add-ons.

This is where product content quality matters most. Thin descriptions and missing attributes do not only hurt SEO. They also make the shopper work harder to decide.

If you need a broader foundation, Catalog's [ecommerce product data guide](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) explains why product titles, descriptions, images, attributes, and structured records matter across the full buying journey.

### Cart and checkout modules

Site merchandising does not stop at the cart. The cart can show add-ons, replenishment offers, free-shipping thresholds, protection plans, bundles, and last-minute product reminders.

This surface should be handled carefully. Bad cart merchandising feels like clutter. Good cart merchandising is relevant, low-friction, and tied to the product already being purchased.

The data requirement is simple: the add-on must make sense. A charger should match the device. A case should fit the model. A subscription prompt should apply to a replenishable product. A free-shipping threshold should be accurate.

## The product data behind good site merchandising

Merchandising decisions look creative on the surface. Underneath, they are data operations.

A merchandising system needs to know what a product is, where it belongs, who it is for, what it works with, whether it is available, how it performs, and how it should be described. That information has to be consistent across the tools that power search, category pages, recommendations, promotions, feeds, and AI shopping surfaces.

| Product data | How it supports site merchandising |
| --- | --- |
| Category and taxonomy | Determines navigation, category pages, collections, and product grouping |
| Attributes and facets | Power filters, comparison tables, eligibility rules, and search refinement |
| Product titles and descriptions | Help shoppers and search systems understand the product quickly |
| Images and video | Support visual merchandising, PDP confidence, and campaign modules |
| Variant data | Prevents broken size/color availability and mismatched recommendations |
| Price, margin, and promotion data | Controls sale modules, badges, bundles, and business-priority ranking |
| Inventory and availability | Prevents out-of-stock products from being over-promoted |
| Compatibility and use-case data | Powers bundles, cross-sells, accessories, and guided discovery |
| Performance data | Helps teams test what actually converts, not just what gets clicks |

Take a hiking shoe category as an example. If the catalog has complete attributes for waterproofing, terrain, ankle support, gender, size, width, color, material, and activity, the merchandising team can build useful filters, rank products by shopper need, create trail-running and backpacking collections, and recommend compatible socks or care products. If the copy itself is thin, structured attributes also give the team enough source material to write better [product descriptions](https://www.getcatalog.ai/blog/product-description-examples) for product pages and campaign modules.

If those attributes are missing or inconsistent, the team is stuck with shallow rules. The page may still look merchandised, but it cannot adapt well to shopper intent.

Product data should not be treated as back-office cleanup. It is the operating layer for onsite revenue.

## How to build a site merchandising workflow

A good site merchandising workflow connects commercial goals, shopper needs, product data, and measurement. Use this sequence as the baseline.

### 1. Define the business goal

Start with the outcome, not the module.

Do you want to increase conversion rate? Raise average order value? Move seasonal inventory? Improve product discovery for new visitors? Reduce search exits? Launch a new collection? Promote higher-margin products without hurting relevance?

The goal determines the merchandising logic. A clearance campaign should not use the same rules as a premium new-arrivals page.

### 2. Audit the product data

Before changing the page, check whether the data can support the experience you want.

Look for missing attributes, inconsistent category labels, weak product titles, duplicate variants, outdated inventory, incomplete images, unclear product relationships, and promotion rules that live outside the main product record.

This is where many merchandising projects stall. Teams design a better experience, then discover that the catalog does not contain the fields needed to run it.

### 3. Map the shopping journey

Identify the surfaces that matter for the goal.

A shopper looking for a specific replacement part may depend on search, filters, compatibility data, and PDP specifications. A shopper browsing gifts may depend more on homepage modules, collections, price bands, imagery, and recommendations.

The path decides where merchandising effort should go first.

### 4. Set rules and guardrails

Merchandising rules can boost, bury, pin, exclude, group, badge, or recommend products. They should be explicit enough to control the experience but flexible enough to avoid stale manual work.

Useful guardrails include:

- Do not promote unavailable products.
- Do not show region-ineligible products.
- Suppress low-rated products unless there is a strategic reason.
- Prioritize exact matches for high-intent search queries.
- Keep high-margin boosts within relevance boundaries.
- Use variant availability when ranking product cards.
- Refresh seasonal collections automatically when inventory changes.

Rules should help the shopper, not just the merchant.

### 5. Combine rules with personalization where appropriate

Manual rules are useful for launches, campaigns, compliance, brand priorities, and major seasonal moments. Personalization is useful when shopper behavior should change the product order.

A returning shopper who regularly buys running gear should not see the same category order as a first-time visitor shopping for hiking boots. But personalization should still respect product data constraints: available sizes, price range, compatibility, inventory, and category relevance.

### 6. Test, measure, and refresh

Site merchandising is not a set-and-forget project. Product availability changes. Promotions expire. Search behavior shifts. New products launch. Seasonal demand moves. Winning placements get stale.

Set a review cadence for important pages and modules. Look at the metrics, review the product data, and update the logic before shoppers notice the decay.

Catalog helps with the data layer behind this process: live, normalized product data that can be used across search, recommendations, product feeds, AI shopping surfaces, and internal merchandising workflows. Teams building directly on product data infrastructure can use that structured data to power these experiences.

## Practical site merchandising examples

The easiest way to understand site merchandising is to look at specific surfaces.

### Seasonal category page

A retailer creates a "summer travel essentials" category.

Weak merchandising might show a static grid of products tagged "travel," including out-of-stock items and products from last year's campaign.

Strong merchandising would use current inventory, seasonality, margin, product ratings, shipping availability, price bands, and use-case tags. It might group products into "carry-on favorites," "beach day," "long-haul comfort," and "family travel" collections.

### New customer homepage

A new visitor does not have behavioral history yet. The homepage should help them understand the store quickly.

Useful modules might include best sellers, category entry points, new arrivals, editorial collections, and a clear explanation of what the brand is known for. The goal is orientation before personalization.

### Returning customer recommendations

A returning shopper has signals: viewed products, previous purchases, preferred categories, sizes, price ranges, and abandoned carts.

A strong recommendation module uses those signals with product data. It does not just show generic best sellers. It shows relevant, available, compatible products that match the shopper's context.

### Search result refinement

A shopper searches "black linen shirt."

A weak search experience may match only titles and return black shirts, linen pants, and unrelated products. A strong search merchandising setup understands color, material, product type, size availability, gender or fit, and product freshness. It can also expose useful filters and suppress unavailable variants.

### Product detail page cross-sell

A shopper views a camera.

Good site merchandising can recommend a compatible lens, memory card, case, and tripod. Bad merchandising recommends unrelated best sellers or accessories that do not fit the model.

Compatibility data is the difference.

## KPIs for site merchandising

Measure site merchandising by what it helps shoppers do, not by whether a module exists.

| KPI | What it tells you | Where it matters |
| --- | --- | --- |
| Conversion rate | Whether the merchandised experience turns visits into orders | Sitewide, category pages, search, PDPs |
| Revenue per visitor | Whether placements improve revenue quality, not just clicks | Homepage, categories, recommendations |
| Average order value | Whether bundles, cross-sells, and recommendations increase basket size | PDP, cart, recommendations |
| Product click-through rate | Whether a surface attracts interest | Homepage modules, category pages, recommendations |
| Add-to-cart rate | Whether clicked products match shopper intent | Search, category pages, PDPs |
| Search exit rate | Whether shoppers leave after searching | Search results |
| Zero-results rate | Whether search understands product and synonym data | Search results |
| Filter usage | Whether attributes help shoppers narrow choices | Category and search pages |
| Out-of-stock click rate | Whether unavailable products are overexposed | Search, category pages, recommendations |
| Return or support rate | Whether product content sets accurate expectations | PDPs and post-purchase experience |

A warning: click-through rate alone can be misleading. A promoted product may get clicks because the image is attractive, but if it does not convert, match intent, or stay in stock, the placement is not doing its job.

## Common site merchandising mistakes

### Treating merchandising as homepage banners only

The homepage matters, but it is only one surface. Most shoppers will also rely on category pages, search, filters, recommendations, PDPs, and cart modules. A polished homepage cannot fix a poor product-discovery system.

### Promoting products that cannot be bought

Out-of-stock, region-ineligible, discontinued, or unavailable variants should not be heavily promoted. Merchandising should respect availability by default.

### Building filters on incomplete attributes

Filters only work if the underlying attributes are complete and consistent. If half the catalog is missing material, size, fit, compatibility, or use-case fields, shoppers cannot refine effectively.

### Letting each surface use a different data source

Search, category pages, recommendations, product feeds, and promotions often evolve as separate systems. That creates inconsistent customer experiences. A product might be available in one system, missing in another, and incorrectly categorized in a third.

Catalog's work around [trusted data sources for agentic commerce](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce) comes from the same principle: commerce systems perform better when they use reliable, structured data instead of scraped or stale fragments.

### Overriding everything manually

Manual rules are useful, but too many static overrides become hard to maintain. If a human has to update every collection, promotion, and boost whenever inventory changes, the system will drift.

Use manual rules for strategic moments. Use structured data and automated guardrails for everything that should stay current.

### Measuring activity instead of outcomes

A merchandising module can look busy and still fail. More banners, more badges, and more recommendations do not automatically create a better experience. Tie each placement to a goal and measure the business outcome.

## How Catalog supports site merchandising

Catalog is built around a simple idea: ecommerce experiences are only as good as the product data underneath them.

Site merchandising depends on that data every day. Search needs attributes and synonyms. Category pages need taxonomy and facets. Recommendations need product relationships and compatibility. Promotions need price, inventory, eligibility, and timing. AI shopping surfaces need machine-readable product facts they can trust.

Catalog helps brands structure, normalize, enrich, and keep product data live so the same product truth can support merchandising, search, recommendations, feeds, and AI commerce channels.

That matters because site merchandising is moving from static placement to data-driven product discovery. The brands that win will not only have better creative. They will have better product data, connected across every surface where a shopper or agent decides what to buy.

## FAQ

### What does a site merchandiser do?

A site merchandiser manages how products are presented, grouped, ranked, promoted, and explained across an ecommerce site. That can include homepage modules, category pages, search rules, product badges, collections, recommendations, promotions, and product-page content.

### What is the difference between site merchandising and search merchandising?

Search merchandising focuses on the search experience: result ranking, boosts, filters, synonyms, zero-results handling, and search-driven product discovery. Site merchandising is broader. It includes search plus homepage modules, category pages, recommendations, product pages, promotional areas, and cart experiences.

### What product data fields matter most for site merchandising?

The most important fields usually include category, taxonomy, product type, title, description, attributes, variants, price, inventory, availability, images, compatibility, promotions, margin, ratings, and performance data. The exact fields depend on the category and shopper journey.

### How often should site merchandising rules be updated?

High-traffic and seasonal surfaces should be reviewed frequently, often weekly or during campaign cycles. Rules tied to inventory, price, availability, and promotions should update automatically whenever the underlying data changes. Static rules should be audited regularly so they do not keep promoting stale products.

### How do you measure site merchandising performance?

Measure conversion rate, revenue per visitor, average order value, product click-through rate, add-to-cart rate, search exit rate, zero-results rate, filter usage, out-of-stock clicks, and return or support signals. Choose metrics based on the surface and goal. A recommendation module and a category page should not be judged by the exact same scorecard.

---

Canonical: https://www.getcatalog.ai/blog/site-merchandising
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Price monitoring API: ecommerce price tracking without brittle scrapers

*June 24, 2026 · Hamish Gunasekara · Business · 13 min read*

> Learn what a price monitoring API returns, how to evaluate coverage and freshness, when an API beats scrapers, and where Catalog fits.

A price monitoring API gives your software current product and offer data without making your team maintain a web scraper for every retailer, marketplace, and variant page you care about.

That matters because ecommerce price data is not useful for long. A product can change price, go out of stock, switch seller, gain a promotion, or appear under a different variant while your application still shows yesterday's answer. Teams building comparison shopping experiences, repricing workflows, assortment analysis, or AI shopping tools need a repeatable way to check prices and know when the data was last refreshed.

The core decision is simple: use a custom scraper when the target set is narrow and stable. Use an API when coverage, freshness, normalization, and reliability matter more than owning the scraping code.

## What is a price monitoring API?

A price monitoring API is an application programming interface that returns product price and offer data from ecommerce pages, marketplaces, comparison surfaces, or product-data sources.

The exact response depends on the provider and source, but a useful price monitoring API usually returns fields such as:

- product URL or source URL;
- product title;
- seller or merchant;
- current price and currency;
- availability or stock status;
- variant, size, color, or pack information;
- timestamp for when the data was collected or refreshed;
- source marketplace or retailer;
- shipping, promotion, or discount details when available.

You may also see the category described as a price tracking API, product pricing API, price scraping API, competitor price monitoring API, or ecommerce price API. The labels overlap. The practical question is whether the API can return the sources, fields, freshness, and structure your use case needs.

## Common price monitoring API use cases

Price monitoring is not only a dashboard problem. Price data usually feeds a downstream decision, workflow, or product experience.

| Use case | What the API needs to support |
| --- | --- |
| Competitor price monitoring | Track competitor offers across target products, sellers, and marketplaces. |
| Repricing and margin control | Feed current competitor prices into pricing rules while protecting margin. |
| Marketplace price comparison | Compare prices across Amazon, Walmart, eBay, Google Shopping, retailer pages, or niche marketplaces. |
| Price alerts | Trigger alerts when a product crosses a threshold, changes seller, or comes back in stock. |
| Price history | Store timestamped records so teams can analyze changes over time. |
| Affiliate or comparison shopping | Keep buyer-facing price and availability data current enough to be trusted. |
| Product research | Monitor assortment, availability, and price bands across categories or regions. |
| AI shopping and buying guides | Give agents and recommendation tools fresh structured product data instead of stale page snippets. |

The last category is becoming more important. If an AI shopping surface, buying guide, or internal agent uses outdated price and availability data, the recommendation can look unreliable even if the product match is good. Catalog's guide to [making products show up in ChatGPT](https://www.getcatalog.ai/blog/how-to-make-products-show-up-in-chatgpt) explains the same issue from the product-discovery side: price and availability drift across product pages, feeds, and merchant sources creates trust problems.

## What data should a price monitoring API return?

The minimum useful response is price, currency, source, and timestamp. Most ecommerce teams need more than that.

### Current price and currency

The API should return the price currently visible for the source being checked, plus the currency. If you operate across regions, make sure the response distinguishes local prices instead of flattening everything into one number.

For repricing and margin workflows, a price without currency, marketplace, seller, and timestamp is hard to trust. The same SKU can have different offers depending on geography, merchant, promotion, fulfillment option, and marketplace state.

### Seller, merchant, and source URL

Price monitoring is only useful when you know where the price came from. A marketplace listing might include multiple sellers, while a retailer page may show its own offer, a marketplace seller, or a third-party fulfillment option.

Keep the source URL and seller details with each record. That makes debugging easier when a price looks wrong and helps downstream teams understand whether they are comparing like with like.

### Availability and stock status

A low price is not actionable if the item is out of stock, available only through an unexpected seller, or hidden behind a shipping constraint. A good API should return availability, stock state, or a clear missing-data signal when the source does not expose it reliably.

For shopper-facing experiences, stock status can matter as much as price. Showing the cheapest unavailable offer is worse than showing no answer.

### Variants, pack sizes, and identifiers

Variant handling is where many price feeds break. A product page may include multiple colors, sizes, subscriptions, bundles, multipacks, or regional versions. The API should make it clear which variant the price belongs to.

Useful matching fields include SKU, GTIN, MPN, UPC, ASIN, seller SKU, handle, product URL, variant URL, normalized title, image, brand, size, color, and pack size. You may not get every identifier from every source, but you need enough structure to avoid comparing a single unit with a six-pack or a base model with a premium variant.

### Timestamp and freshness

Every price record should include a timestamp. Freshness is part of the data, not a footnote.

A daily refresh may be enough for category research. A repricing workflow may need hourly, near-real-time, or event-driven updates. A buying guide that sends shoppers to merchants may need a different cadence for fast-moving products than for slow-moving catalog items.

### Normalized product fields

Raw HTML extraction can tell you what appeared on a page. A stronger product data API turns that into fields software can use consistently across sources.

That is why normalized title, brand, image, description, specifications, identifiers, price, availability, and variant fields matter. Catalog's [product data enrichment guide](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) goes deeper on this machine-readable product-data layer. The same principle applies to broader [product data extraction](https://www.getcatalog.ai/blog/product-data-extraction): collection is only useful when the output becomes clean, comparable fields. For price monitoring, structured product objects are easier to compare, store, and pass into agents than loose text scraped from pages.

## Coverage and freshness questions to ask before choosing an API

The best price monitoring API for your team depends less on the generic feature list and more on the sources and decisions you need to support.

Ask these questions before you choose a provider or build your own system:

1. **Which sources are covered?** Confirm the marketplaces, retailer product pages, search surfaces, and custom domains you actually need. Common requests include Amazon, Walmart, Google Shopping, eBay, Home Depot, brand sites, regional stores, and niche marketplace pages.
2. **How fresh can the data be?** Check whether the API supports scheduled refreshes, on-demand checks, near-real-time updates, or cached responses.
3. **What happens when a fetch fails?** Failures should be visible. You need retry behavior, error codes, status fields, and enough logging to know whether a missing price means unavailable, blocked, changed layout, rate-limited, or not yet refreshed.
4. **Is the response normalized across sources?** A single schema is easier to use than a different response shape for every marketplace.
5. **Can it handle variants?** The API should distinguish variant-level price and stock, not only the parent product page.
6. **Does it return historical records or only current snapshots?** Price history, change alerts, and trend analysis require storage design even if the API itself only returns the current value.
7. **What are the rate limits and pricing rules?** A cheap proof of concept can become expensive if every refresh, retry, or source check counts differently.
8. **How good is the developer experience?** Clean documentation, predictable JSON, useful examples, and reliable support matter when the API becomes part of a production workflow.

Coverage and freshness should be stated in operational terms. "Real-time" sounds attractive, but the useful question is whether the cadence is fast enough for your decision. A weekly category benchmark, a daily merchandising report, and an automated repricing rule do not need the same refresh model.

## Price monitoring API vs. custom scraper

A custom scraper can be the right starting point when you have a small, stable target list and you mainly need to prove a concept. If you only track a few known pages, own the target site, or can tolerate occasional gaps, a simple scraper may be cheaper and faster.

The tradeoff changes when the workflow becomes business-critical.

| Decision point | Custom scraper | Price monitoring API |
| --- | --- | --- |
| Initial control | High. You own the code and extraction rules. | Lower. You depend on the provider's API and coverage. |
| Setup speed | Fast for a narrow target set. | Fast when the API already supports your sources. |
| Maintenance | Your team handles layout changes, selectors, proxies, retries, and anti-bot issues. | Provider usually absorbs more of the source maintenance and normalization. |
| Coverage | Expands one source at a time. | Can cover multiple marketplaces, retailers, and product-data sources through one interface. |
| Data structure | You design the schema and cleanup. | A useful provider returns normalized fields and timestamps. |
| Reliability | Depends on your infrastructure and monitoring. | Depends on provider reliability, error handling, and source coverage. |

The [hidden cost of DIY scraping](https://www.getcatalog.ai/blog/why-smart-ecommerce-companies-choose-catalog-ai) is not the first script. It is the ongoing work: source layout changes, anti-bot defenses, proxy rotation, captchas, retries, missing fields, duplicate variants, and normalization bugs. Large marketplaces and retailers can change behavior often enough that scraping becomes an infrastructure project rather than a data task.

An API does not remove every constraint. You still need to validate coverage, budget for usage, store history when needed, and build your downstream workflow. But it can turn price collection from a brittle source-by-source project into a more predictable data layer.

## Price monitoring API vs. marketplace-native pricing APIs

Marketplace-native pricing APIs can be useful when your workflow lives mostly inside one marketplace ecosystem. For example, a seller operating on a marketplace may use that marketplace's own pricing or seller APIs for authorized offer, listing, or repricing workflows.

A third-party price monitoring API is different. It is usually chosen when a team needs cross-source visibility: competitor prices across marketplaces, retailer pages, comparison surfaces, and product URLs that do not all belong to one marketplace account.

The choice depends on the job:

- Use a marketplace-native API when you need authorized seller or listing data inside that marketplace.
- Use a third-party price monitoring or product data API when you need broader coverage across external sources.
- Use both when internal marketplace data and external market data need to meet in one pricing or merchandising workflow.

For many teams, the right architecture is not one API forever. It is a product-data pipeline where each source has a clear role and every record keeps its source, timestamp, and confidence.

## How Catalog fits into price monitoring workflows

Catalog is not a generic price-alert dashboard or repricing tool. It is better understood as product-data infrastructure for teams that need live, normalized product objects their software can consume.

Catalog is relevant when price monitoring depends on more than a single price field. It can return product data from Shopify, Amazon, custom builds, and raw HTML; normalize 86+ fields; expose variant-level price and stock; and include timestamped freshness. That makes it useful when a team needs product records that are structured enough for internal tools, recommendation systems, buying guides, or AI agents.

A practical example: a team building an AI buying guide does not only need the lowest visible price. It needs the product title, merchant, URL, images, variants, availability, specifications, and freshness timestamp so the agent can compare products without mixing stale, incomplete, or mismatched records. That is adjacent to the broader shift toward [agentic commerce](https://www.getcatalog.ai/blog/what-is-agentic-commerce), where software needs product data it can reason over instead of pages written only for human shoppers.

Use Catalog when the price monitoring workflow needs a reliable product data layer. Use a dedicated repricing platform when the main job is pricing rules, alerts, dashboards, or automated price changes.

## Implementation checklist for price monitoring

Before you wire a price monitoring API into production, define the workflow in data terms.

1. **Define the target products.** Start with the SKUs, URLs, categories, competitors, and regions you care about.
2. **Define the target sources.** Separate marketplace pages, retailer product pages, search/shopping results, affiliate destinations, and owned domains.
3. **Set freshness requirements by use case.** Repricing, alerting, research, and AI shopping experiences may need different refresh cadences.
4. **Choose required fields.** At minimum, include price, currency, source URL, seller, availability, variant, and timestamp.
5. **Plan product matching.** Decide which identifiers and fallback matching rules prevent variant or pack-size errors.
6. **Store history intentionally.** Keep timestamped records if you need trend analysis, price alerts, or margin reporting.
7. **Monitor failures.** Track fetch failures, missing fields, unexpected schema changes, blocked sources, and stale records.
8. **Connect price data to the decision.** A price record should feed an alert, dashboard, pricing rule, product experience, or agent action. Otherwise it becomes another unused data feed.

The best systems treat price monitoring as part of product-data operations, not a one-off extraction script. That means every record should be current enough, structured enough, and explainable enough for the decision it supports.

## FAQ

### What is the difference between a price monitoring API and a price tracking API?

In most ecommerce contexts, the terms overlap. A price monitoring API often emphasizes ongoing source coverage, freshness, and operational use cases such as competitor monitoring or repricing. A price tracking API may emphasize checking a product price over time and storing changes. The important distinction is not the label; it is whether the API supports your sources, fields, refresh cadence, and history needs.

### How often should ecommerce prices be refreshed?

Refresh cadence depends on the use case. Competitive repricing may need hourly, near-real-time, or event-driven updates. A category research report may work with daily or weekly snapshots. Shopper-facing comparison pages and AI buying guides need a cadence that keeps price and availability trustworthy enough for the buyer journey.

### Is a price monitoring API better than web scraping?

A price monitoring API is usually better when you need multiple sources, source reliability, retries, anti-bot handling, structured fields, variant support, and lower maintenance. A custom scraper can still make sense for a narrow proof of concept or a small set of stable pages.

### Can a price monitoring API track Amazon or Walmart prices?

Many price monitoring tools focus on major marketplaces and retailers, including Amazon and Walmart, but coverage varies by provider, region, and use case. Confirm the exact source, marketplace, seller, variant, and refresh requirements before assuming support.

### Does Catalog provide price monitoring?

Catalog provides live, normalized product data that can support price monitoring workflows. It is not positioned as a standalone repricing dashboard or generic price-alerting app. Catalog fits when your team needs structured product objects with fields such as variant-level price, stock, source data, and timestamped freshness for software, agents, or internal tools.

---

Canonical: https://www.getcatalog.ai/blog/price-monitoring-api
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Shopify Agentic Storefronts: what merchants need to know

*June 23, 2026 · Hamish Gunasekara · AI Commerce · 10 min*

> Learn how Shopify Agentic Storefronts work, which AI channels they cover, what product data they use, and how Catalog helps merchants prepare for AI shopping.

Shopify Agentic Storefronts are Shopify's native path into AI shopping channels. Shopify says they let customers discover and purchase products in AI channels such as ChatGPT, Google AI Mode, Gemini, and Microsoft Copilot.

That is useful distribution. It is also easy to misunderstand.

Agentic Storefronts do not remove the need for product data work. They make eligible products available to AI shopping surfaces. Those surfaces still need enough structured, current, product-level context to decide when your product is the right answer for a shopper's prompt.

This guide explains what Shopify Agentic Storefronts are, how they work, what merchants should check now, and where Catalog fits if you want AI systems to understand your products beyond one native Shopify channel.

## The short version

Here is what merchants need to know:

- **Shopify Agentic Storefronts are for AI shopping channels.** Shopify names ChatGPT, Google AI Mode, Gemini, and Microsoft Copilot as examples.
- **Eligible stores are included by default.** Shopify says Agentic Storefronts are active by default for eligible stores, with channel management available in the Agentic section of Shopify admin.
- **Availability differs by channel.** Shopify says Google AI Mode and Gemini support is in early access and not available for all stores.
- **Product data paths differ by channel.** Shopify Catalog is a core path for eligible products, while Shopify says Google AI Mode and Gemini use the Google & YouTube sales channel. Products can also appear through crawling, indexing, and feeds you share elsewhere.
- **ChatGPT is currently a referral surface.** Shopify's [ChatGPT agentic storefront documentation](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/chatgpt) describes ChatGPT as discovery-focused. Shoppers complete purchases through the merchant's online store checkout.
- **Some AI channels can support direct checkout.** For other Shopify-powered AI channels, Shopify says buyers may complete purchases in-channel when direct purchasing is activated.
- **Product data quality is the bottleneck.** AI shopping systems need complete, structured, current data to match products to real buyer intent.

The practical job is not only turning on a channel. It is making your product catalog legible to shopping agents.

## What are Shopify Agentic Storefronts?

Shopify Agentic Storefronts are Shopify's way to make merchant products available inside AI shopping experiences. In Shopify's [Agentic Storefronts overview](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts), shoppers can discover and purchase products in AI channels such as ChatGPT, Google AI Mode, Gemini, and Microsoft Copilot.

A normal Shopify storefront is built for humans. It has product pages, navigation, search, checkout, and merchandising that a shopper can see and click.

An agentic storefront is built for AI-mediated shopping. A shopper asks an AI assistant for a recommendation. The assistant searches product data, compares options, returns products, and may send the shopper to checkout or complete a Shopify-powered checkout flow depending on the channel.

For a merchant, the important change is distribution. Your products can appear where the shopper starts the buying journey, even if that journey starts in an AI answer box rather than on your website.

The important caveat is control. AI systems can only reason over the data they can access and parse. If your product data is thin, stale, inconsistent, or missing the facts shoppers ask for, the channel can be active while your products still lose the recommendation.

## How Shopify Agentic Storefronts work

Shopify describes two broad patterns.

### ChatGPT discovery and referral

For ChatGPT, Shopify says the agentic storefront acts as a discovery-focused referrer platform. A shopper can discover products in ChatGPT, then complete the purchase through the merchant's online store checkout in a ChatGPT in-app browser or a new tab on ChatGPT web.

That model keeps the merchant's existing checkout in the flow. Shopify says checkout customizations, branding, selling strategies, and payment methods are preserved because the final purchase happens through the online store checkout.

This also means product discovery and purchase are separate jobs. ChatGPT has to understand which products to show. Shopify checkout has to complete the order after the shopper chooses.

### Direct checkout AI channels

Shopify also describes other AI channels with Shopify-powered direct checkout. In those channels, if direct purchasing is activated, customers can complete purchases inside the AI channel without leaving the conversation.

That is a different operational model. The AI surface is no longer only a referrer. It can become part of the transaction flow.

For merchants, the strategic direction is clear: AI shopping is moving from recommendations to product selection, cart building, checkout, and post-purchase help. Shopify's developer documentation already describes agent workflows that can search products, build carts, start checkout, and monitor orders. Teams with custom storefronts should also understand how [Shopify Storefront API and Agentic Storefronts](https://www.getcatalog.ai/blog/shopify-storefront-api-agentic-storefronts) solve different parts of that product-discovery path.

You do not need to build a custom agent to prepare. You do need product data that can support those workflows.

## What Shopify Catalog contributes

Shopify Catalog is one of the main product data paths for Agentic Storefronts, but it is not the only setup path merchants should check. Shopify's [Agentic Storefronts overview](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts) says products are made available to AI channels through Shopify Catalog, or through the Google & YouTube sales channel for Google AI Mode and Gemini.

Shopify's [product discovery documentation](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products) also says eligible products can be discovered through Shopify Catalog, as well as other methods such as web crawling, indexing, or product feeds merchants share elsewhere.

For merchants, this means Shopify Catalog is a core starting point for AI shopping visibility, while Google AI Mode and Gemini also require attention to the Google & YouTube sales channel path.

For Shopify Catalog-backed paths, Shopify Catalog can make product data available to AI channels. It can carry core product facts such as titles, descriptions, options, images, pricing, availability, and attributes. It can also update product data so supported channels have current price and inventory information.

The nuance is mapping.

Many Shopify stores do not keep their best product data in one clean place. Important details may live in metafields, metaobjects, tags, custom apps, variant naming conventions, bundled-product rules, comparison tables, PDFs, images, or theme copy.

Shopify's Catalog Mapping guidance matters because of that. Shopify says stores that use custom fields, metafields, metaobjects, tag prefixes, or product-title patterns can use mapping so Shopify Catalog sources the right product data.

If the best answer to a shopper's prompt lives outside the mapped product data, an AI system may never see it.

## What merchants should check now

Use this as a practical readiness pass.

### 1. Check the Agentic section in Shopify admin

Confirm whether Agentic Storefronts are available for your store, which channels are active, and whether anyone has changed channel settings.

Shopify says Agentic Storefronts are active by default for eligible stores. That does not mean every channel is available to every store at the same time. Shopify also says Google AI Mode and Gemini support is in early access and not yet available for all Shopify stores. If Google AI Mode or Gemini matter to your roadmap, verify your Google & YouTube sales channel setup and the current channel availability or eligibility in Shopify admin.

### 2. Confirm product and store eligibility

For ChatGPT, Shopify lists requirements such as selling to customers in the United States, having products eligible for Shopify Catalog, accepting Shopify's Agentic Storefronts supplemental terms, and completing required policy pages in Shopify admin.

Policy pages are not only compliance work. AI shopping surfaces need policy context when shoppers ask about returns, refunds, shipping, restrictions, or whether a product is safe to buy.

### 3. Audit product fields for AI-readable facts

Start with the facts a shopping agent needs to compare products:

- product type and category;
- material, ingredients, dimensions, fit, sizing, and compatibility;
- variants, bundles, and substitutions;
- use cases and constraints;
- price, availability, and shipping facts;
- return, warranty, care, and restriction details;
- reviews, provenance, certifications, and trust signals.

Do not rely on lifestyle images, vague product copy, or theme-only content to carry critical information. Put important facts in structured product data that Shopify Catalog and other AI shopping systems can use.

### 4. Map custom data sources

If your store uses metafields, metaobjects, tags, custom apps, or naming patterns, check whether those fields are actually being sourced correctly.

This is especially important for stores with complex variants, technical products, regulated categories, custom bundles, wholesale logic, or merchandising rules that were designed for human browsing rather than AI retrieval.

### 5. Review sensitive and unsupported products

Shopify notes that B2B-only products are not supported for agentic storefronts when Shopify can identify them. It also describes product discoverability controls for merchants who need products hidden from AI channels.

Be careful with custom B2B logic, gated products, wholesale-only products, prohibited products, and any product where a mistaken recommendation creates compliance or customer-experience risk.

### 6. Understand `/agents.md` and `/llms.txt`

Shopify stores automatically serve [`/agents.md`, `/llms.txt`, and `/llms-full.txt`](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#agent-discovery-files). These files help AI agents discover store context and endpoints.

They are not a replacement for product data.

An AI system can know that your store exists and still miss the product facts needed to recommend the right SKU. Treat discovery files as infrastructure, not the strategy.

### 7. Test real shopping prompts

Do not only check whether your products are eligible. Test prompts that match how customers buy.

For example:

- "best navy running shorts with a phone pocket";
- "gift for a new parent under $75";
- "non-toxic dinnerware that can go in the dishwasher";
- "replacement part compatible with model X";
- "waterproof travel bag that fits under an airplane seat".

Then record what the AI system recommends, which product facts it uses, which competitor products appear, and which of your products are missing.

## Why native availability is not enough

Agentic Storefronts can make eligible products available. They do not guarantee that an AI system will choose your product.

The recommendation layer still has to answer practical questions:

- Is this product relevant to the shopper's stated need?
- Which variant should be shown?
- Is the price and inventory current?
- Does the product have enough evidence to beat similar alternatives?
- Are there restrictions, policies, or compatibility details the buyer needs before checkout?
- Can the AI assistant explain why this product is a good match?

A standard Shopify product record often was written for a human looking at a product page. AI shopping systems need cleaner structure. They need attributes, synonyms, relationships, policies, product-level context, and fresh operational data.

That is why the work should not stop at "Shopify made us discoverable." The next question is whether your product data is strong enough to be recommended.

## Where Catalog fits

Shopify is the commerce system. Catalog is the product data layer for AI shopping.

That distinction matters.

Shopify Agentic Storefronts can make eligible products available to native AI channels. Catalog helps make products understandable, comparable, and measurable across the AI surfaces where shoppers ask what to buy.

With [Catalog](https://www.getcatalog.ai/), merchants connect Shopify once. Catalog ingests product data, enriches it with the attributes AI systems need, and keeps pricing, inventory, variants, and product context synced. It can add details that are often missing from standard product records: fit, material, use case, compatibility, provenance, policy facts, review themes, restrictions, and structured variant detail.

Catalog also helps beyond one native channel. Shoppers do not only ask ChatGPT. They ask Gemini, Perplexity, Claude, Copilot, Rufus, and new shopping agents that have not reached scale yet. Catalog's role is to distribute clean product data across surfaces and measure what happens.

That measurement matters. A merchant should be able to see:

- which products are recommended;
- which prompts surface competitors;
- which product attributes are missing;
- which AI channels send qualified traffic;
- which enrichments improve product visibility.

If you are starting with ChatGPT specifically, read Catalog's guide to [Shopify ChatGPT visibility](https://www.getcatalog.ai/blog/shopify-chatgpt-product-visibility). If you are building a broader measurement program, Catalog's [AI visibility for ecommerce](https://www.getcatalog.ai/blog/ai-visibility-ecommerce) guide explains how to track product-level AI visibility.

## A practical rollout plan

A simple rollout looks like this:

1. **Verify availability.** Check the Agentic section of Shopify admin and confirm channel status.
2. **Confirm eligibility.** Review Shopify Catalog eligibility, Google & YouTube sales channel setup when Google AI Mode or Gemini matter, policy pages, terms, B2B-only products, and sensitive products.
3. **Map product data.** Make sure custom fields, metafields, metaobjects, tags, and variant details are sourced correctly.
4. **Enrich weak products.** Add the product facts AI systems need for matching: use cases, materials, sizing, compatibility, restrictions, policy facts, and proof points.
5. **Test prompts.** Run realistic buying prompts across ChatGPT, Gemini, Perplexity, Claude, Copilot, and other surfaces your buyers may use.
6. **Measure product-level outcomes.** Track whether the right products appear, what competitors appear, and which missing attributes explain visibility gaps.
7. **Expand beyond the native channel.** Treat Shopify Agentic Storefronts as one distribution path, not the whole AI commerce strategy.

The durable advantage is not being first to toggle a channel. It is having the clearest, freshest, most useful product data when a shopping agent decides what to recommend.

## FAQ

### Are Shopify Agentic Storefronts active by default?

Shopify says Agentic Storefronts are active by default for eligible stores. Merchants should still check Shopify admin because rollout status and channel availability can differ.

### Does ChatGPT checkout happen inside Shopify?

For Shopify's ChatGPT agentic storefront, Shopify says shoppers complete purchases through the merchant's online store checkout in a ChatGPT in-app browser or a new tab on ChatGPT web. That makes ChatGPT a discovery and referral surface rather than a full direct-checkout channel.

### Are Shopify Agentic Storefronts the same as the Shopify Storefront API?

No. Shopify Agentic Storefronts are native AI shopping channel experiences for product discovery and purchase. The Shopify Storefront API is a developer API for building custom storefronts and buyer experiences. They can both involve product data and checkout, but they are different surfaces with different use cases.

### Is `/llms.txt` enough for Shopify Agentic Storefront visibility?

No. Shopify stores automatically serve `/agents.md`, `/llms.txt`, and `/llms-full.txt`, but those files help AI systems discover store context and endpoints. Product recommendation still depends on complete, structured, current product data.

### Can I turn off Shopify Agentic Storefronts?

Shopify provides channel management and product discoverability controls, but merchants should read Shopify's documentation carefully. Removing Shopify Catalog access for one AI channel may not fully hide products from all external discovery methods such as crawling, indexing, or other feeds. Stronger hiding steps can affect sitemaps, search engines, and store search.

### What should Shopify merchants improve first?

Start with product data completeness. Make sure product titles, descriptions, variants, images, price, availability, materials, sizing, use cases, policies, and restrictions are clear and machine-readable. Then test real shopping prompts and measure whether AI systems recommend the right products.

---

Canonical: https://www.getcatalog.ai/blog/shopify-agentic-storefronts
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Shopify ChatGPT visibility guide for merchants

*June 23, 2026 · Hamish Gunasekara · AI Commerce · 11 min*

> Learn how Shopify Agentic Storefronts make products discoverable in ChatGPT, what data ChatGPT can read, and how to improve AI shopping visibility.

Shopify products can now show up in ChatGPT through [Shopify Agentic Storefronts](https://www.getcatalog.ai/blog/shopify-agentic-storefronts). For eligible stores, Shopify says the ChatGPT agentic storefront is active by default, uses Shopify Catalog product data, and sends shoppers to the merchant's online store checkout to buy.

That is the important baseline. It is not the whole strategy.

A product can be available to ChatGPT and still fail to appear for the prompts that matter. AI shopping systems do not choose products from a flat list of SKUs. They compare product details against shopper intent: material, fit, use case, size, compatibility, price, inventory, policies, reviews, and constraints that may never be obvious from a standard Shopify product record.

This guide explains how Shopify ChatGPT visibility works, what product data ChatGPT can use, and how merchants should prepare their catalog so AI shopping surfaces can understand and recommend the right products.

## The short version

Here is what Shopify merchants need to know about ChatGPT and Agentic Storefronts:

- **ChatGPT is part of Shopify Agentic Storefronts.** Shopify describes Agentic Storefronts as a way for customers to discover and buy products in AI channels such as ChatGPT, Google AI Mode, Gemini, and Microsoft Copilot.
- **ChatGPT is discovery-focused.** Shopify's [ChatGPT agentic storefront documentation](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/chatgpt) says ChatGPT acts as a discovery-focused referrer platform.
- **Checkout still runs through your online store.** ChatGPT shoppers complete purchases in your Shopify online store checkout, either inside a ChatGPT in-app browser or in a new tab on ChatGPT web.
- **Eligible products are shared through Shopify Catalog.** Shopify Catalog is the main feed that makes product data available to agentic storefronts.
- **Product data quality still matters.** Being available to ChatGPT is not the same as being the best answer for a shopper's question.

The work now is not just "turn on ChatGPT." It is making sure your product data is complete, structured, current, and useful enough for AI systems to choose your products.

## How Shopify Agentic Storefronts work with ChatGPT

Shopify Agentic Storefronts are Shopify's native path into AI shopping channels. Shopify's [Agentic Storefronts overview](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts) says products can be discovered and purchased in AI channels including ChatGPT, Google AI Mode and Gemini, and Microsoft Copilot.

ChatGPT works differently from some of the direct-checkout AI channels. In Shopify's docs, ChatGPT is a discovery and referral surface. The shopper can find products in ChatGPT, but the purchase completes through the merchant's online store checkout. Shopify notes that this keeps existing checkout customizations, branding, selling strategies, and payment methods supported.

That matters because it keeps the merchant's own storefront and checkout relationship intact. Orders still flow through Shopify admin with channel or referrer attribution, and the merchant keeps ownership of the customer relationship and post-purchase experience.

There are still eligibility requirements. For the ChatGPT agentic storefront, Shopify lists requirements including:

- the store must sell to customers in the United States;
- products must be eligible for Shopify Catalog;
- the merchant must accept Shopify's Agentic Storefronts supplemental terms;
- terms of service, privacy policy, and Return and refund policy must be completed in Shopify admin.

Shopify also notes that B2B-only products are not supported for agentic storefronts, and products covered by OpenAI's prohibited products and services policies do not display in ChatGPT product discovery results.

## What ChatGPT can learn from your Shopify store

Shopify's [product discovery documentation for agentic storefronts](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products) is the key page for merchants who want to improve visibility. Shopify says eligible products are automatically discoverable through Shopify Catalog, plus other discovery methods such as web crawling, indexing, or product feeds merchants share elsewhere.

When Shopify Catalog syndicates products to AI channels, Shopify says products are listed with fields such as:

- title;
- description;
- options;
- images;
- price;
- availability;
- other key attributes structured so AI agents can parse and understand them.

Shopify also says Catalog continuously updates product data so AI channels receive accurate inventory and pricing. That is table stakes for AI shopping. An agent cannot safely recommend a product if it cannot trust that the price, availability, or selected variant is still correct.

Merchants with custom product logic should pay close attention to mapping. In the [Shopify Catalog product data mapping section](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#data-mapping), Shopify says stores that keep product data in custom fields, metafields, metaobjects, tag prefixes, or unusual product-title patterns can use Shopify Catalog Mapping so agentic storefronts source the right data.

Shopify also says stores automatically serve [agent discovery files](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#agent-discovery-files) at `/agents.md`, `/llms.txt`, and `/llms-full.txt`. The important nuance: these files help agents understand store context, policies, sitemaps, and discovery endpoints. Shopify says they are separate from Shopify Catalog and do not replace Shopify Catalog capabilities.

The same nuance applies to crawler controls. Shopify's [AI crawler access guidance](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#ai-crawlers) says blocking AI crawlers through robots.txt or the network layer affects open-web discoverability, but it does not stop product data from being sent through Shopify Catalog to activated agentic storefronts. In other words, product-feed readiness and crawler posture are related, but they are not the same control.

## Eligibility is not the same as being recommended

Shopify can make eligible product data available. ChatGPT still has to decide which products answer a shopper's prompt.

That is where many Shopify stores are underprepared. A product title and a short description may be enough for a human browsing a PDP. They are often not enough for an AI shopping agent comparing products across brands.

Consider the kinds of prompts shoppers ask:

- "Find a machine-washable navy blazer for travel under $250."
- "What is a good non-toxic rug for a nursery?"
- "Which running shorts have a phone pocket and work for humid weather?"
- "I need a gift for someone who likes Japanese design and already owns a pour-over setup."

Those prompts require more than a product name. They require attributes, use cases, constraints, variants, policy facts, and real-world language that maps to how shoppers describe needs.

Common Shopify product-data gaps include:

| Gap | Why it hurts AI shopping visibility |
| --- | --- |
| Thin descriptions | The agent has less context for use cases, materials, care, fit, compatibility, and differentiators. |
| Missing attributes | Products are harder to match to prompts with constraints like size, ingredient, material, color, style, or budget. |
| Unclear variants | The agent may not know which size, bundle, color, or configuration answers the shopper's question. |
| Stale availability or pricing | AI systems are less useful if they send shoppers to products that cannot be bought at the shown price. |
| Hidden policy details | Shipping, returns, warranty, and restrictions can be deciding factors in product recommendations. |
| Single-channel thinking | A store may be visible in one AI channel but absent or weak across other surfaces where shoppers ask. |

Shopify ChatGPT visibility starts with eligibility. Recommendation strength depends on whether the product data gives AI enough evidence to choose your product confidently. If your team also runs a headless Shopify build, compare that AI-channel path with the [Shopify Storefront API](https://www.getcatalog.ai/blog/shopify-storefront-api-agentic-storefronts) so product data decisions stay aligned.

## Shopify ChatGPT visibility checklist

Use this checklist before treating ChatGPT as "handled" in Shopify.

### 1. Confirm your Agentic Storefronts status

Check the Agentic section of Shopify admin. Confirm whether ChatGPT and other channels are available for your store, whether Shopify is managing access by default, and whether anyone on your team has changed opt-in or opt-out settings.

Shopify says the ChatGPT agentic storefront is active by default for eligible stores, but availability can still depend on eligibility and rollout status.

### 2. Complete the required store policies

For ChatGPT eligibility, Shopify lists completed terms of service, privacy policy, and Return and refund policy as requirements in its [ChatGPT agentic storefront requirements](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/chatgpt#requirements). These are not just compliance chores. AI shopping systems need policy context when shoppers ask about returns, refunds, delivery, restrictions, or buying confidence.

### 3. Put important product facts in real product data

Do not bury key facts only in lifestyle images, tabs, PDFs, or vague copy. Put the details AI needs in product fields that Shopify Catalog can source and structure.

Prioritize:

- materials and ingredients;
- dimensions, sizing, fit, and compatibility;
- care instructions;
- use cases and occasions;
- variant-specific details;
- bundles and included items;
- shipping, returns, warranties, and restrictions;
- inventory and price accuracy.

In its [ChatGPT agentic storefront considerations](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/chatgpt#considerations), Shopify says relevant legal disclosures should appear in the first 6,000 characters of product descriptions.

### 4. Audit custom fields and metafields

If your best product data lives in metafields, metaobjects, tags, or custom naming patterns, check Shopify's [Catalog Mapping guidance](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#data-mapping) and make sure Shopify Catalog is sourcing it correctly. This is especially important for brands with complex variants, custom bundles, technical products, regulated categories, or merchandising logic that was built for humans rather than agents.

### 5. Review unsupported or sensitive products

Check B2B-only products, wholesale-only products, prohibited categories, gated products, and any product where the wrong surface would create compliance or customer-experience risk.

Shopify says B2B-only products are excluded when Shopify can identify them. If you use custom B2B logic through third-party apps or theme modifications, do not assume every exclusion will be detected automatically.

### 6. Understand `/agents.md` and `/llms.txt`

Shopify stores automatically serve [`/agents.md`, `/llms.txt`, and `/llms-full.txt`](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#agent-discovery-files). Review them, but do not confuse them with a product-data strategy.

These files help AI systems discover store context and endpoints. The product recommendation work still depends on complete, structured, fresh product data.

### 7. Measure product-level AI visibility

A broad AI visibility report can tell you whether your brand appears in ChatGPT or Gemini. Ecommerce teams need a more specific view:

- Which products are recommended?
- Which products are skipped?
- Which prompts produce competitor recommendations?
- Which product facts are wrong, missing, or stale?
- Which channels send qualified shoppers back to the store?

Catalog's guide to [AI visibility for ecommerce](https://www.getcatalog.ai/blog/ai-visibility-ecommerce) goes deeper on how to measure this at the product and prompt level.

## Where Catalog fits

Shopify is the commerce system. Catalog is the product data layer that helps AI systems understand what you sell.

That distinction matters. Shopify Agentic Storefronts can make eligible products available to AI channels. Catalog helps make those products more understandable, comparable, and measurable across the AI shopping surfaces where customers ask questions.

With [Catalog](https://www.getcatalog.ai/), merchants connect Shopify once. Catalog ingests product data, enriches it with the attributes AI weighs, and keeps pricing, inventory, and variants synced. It can add the missing context that standard product records often lack: fit, material, use case, compatibility, provenance, reviews, policy facts, and structured variant detail.

Catalog also helps beyond a single native channel. Shoppers do not only ask ChatGPT. They ask Gemini, Perplexity, Claude, Copilot, Rufus, and the next AI shopping interface that appears in their workflow. Catalog distributes structured product data across surfaces and measures what happens: AI referrals, surfacing rate, catalog completeness, distribution coverage, and tests of titles, attributes, and enrichments.

The practical promise is simple: keep your Shopify site, checkout, URLs, and design intact, while giving AI shopping systems a product layer they can read.

## What to watch next

Shopify ChatGPT visibility is the near-term hook. The larger shift is agentic commerce.

Shopify's developer documentation for commerce agents describes workflows for product discovery, carts, checkout, and order monitoring. Shopify's own channel set already points beyond ChatGPT to Google AI Mode, Gemini, Microsoft Copilot, and other AI shopping surfaces.

That means the durable strategy is not a one-off ChatGPT integration. It is a product data foundation that can support discovery, comparison, variant selection, checkout handoff, measurement, and governance across every surface where shoppers ask AI what to buy.

If your Shopify catalog is thin, inconsistent, or hard for machines to parse, ChatGPT exposure will not fix it. If your product data is complete, structured, enriched, and current, Shopify Agentic Storefronts become a much stronger distribution opportunity.

## FAQ

### Do Shopify products automatically appear in ChatGPT?

Shopify says the ChatGPT agentic storefront is active by default for eligible stores, and eligible products can be discoverable through Shopify Catalog. Availability still depends on eligibility, Shopify Catalog requirements, store policies, product rules, and channel settings.

### Does ChatGPT checkout happen inside Shopify?

For Shopify's ChatGPT agentic storefront, shoppers complete purchases through the merchant's online store checkout in a ChatGPT in-app browser or a new tab on ChatGPT web. Shopify says this preserves existing checkout customizations, branding, selling strategies, and payment methods.

### Is `/llms.txt` enough for Shopify ChatGPT visibility?

No. Shopify stores automatically serve [`/agents.md`, `/llms.txt`, and `/llms-full.txt`](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#agent-discovery-files), but Shopify says these discovery files do not replace Shopify Catalog. They help agents understand store context and endpoints. Product visibility still depends on complete, structured product data.

### Can I opt out of ChatGPT product discovery?

Shopify lets merchants [remove ChatGPT's access to product data through Shopify Catalog](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/chatgpt#opt-out). Shopify also notes that products may still appear through other discovery methods such as web crawling, indexing, or other feeds. If you need a product fully hidden from AI channels, review Shopify's [product discoverability guidance](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#hiding-product-discoverability) carefully because stronger exclusions can also hide products from sitemaps, search engines, and store search.

### What should Shopify merchants improve first?

Start with product data completeness. Make titles, descriptions, variants, images, price, availability, materials, sizing, use cases, policies, and restrictions clear and machine-readable. Then check Shopify's [Catalog Mapping guidance](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#data-mapping) for custom fields and measure which products actually appear for high-intent AI shopping prompts.

---

Canonical: https://www.getcatalog.ai/blog/shopify-chatgpt-product-visibility
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Shopify Storefront API: Guide and Agentic Storefronts Comparison

*June 23, 2026 · Hamish Gunasekara · AI Commerce · 11 min*

> Learn what Shopify Storefront API does, how access tokens, GraphQL queries, carts, and checkout work, and when Agentic Storefronts fit AI shopping.

Shopify Storefront API is Shopify's GraphQL API for building custom customer-facing commerce experiences. Developers use it to query products and collections, create carts, power custom storefronts, and send shoppers into checkout.

That makes it important for headless commerce, mobile apps, product configurators, custom discovery experiences, and any frontend that needs Shopify commerce data without using a standard Shopify theme.

It is not the same thing as Shopify Agentic Storefronts. Storefront API helps you build the owned shopping experience. Agentic Storefronts help eligible products appear in AI shopping channels such as ChatGPT, Google AI Mode, Gemini, and Microsoft Copilot.

The practical question is not "Which one replaces the other?" It is: what do you need to build, what data does that surface need, and how will your products be understood outside your own storefront?

## The short answer

Use Shopify Storefront API when you need a custom storefront, app, or commerce interface that reads from Shopify and lets shoppers browse products, add items to cart, and check out.

Use Shopify Agentic Storefronts when you want eligible products to be discoverable and purchasable inside supported AI shopping channels.

Use Catalog when you need the product data layer underneath both paths to be richer, cleaner, more complete, and more portable across AI surfaces.

| Question | Shopify Storefront API | Shopify Agentic Storefronts |
| --- | --- | --- |
| Main job | Build custom customer-facing storefronts | Make products available in supported AI shopping channels |
| Primary user | Developers and ecommerce teams | Merchants and commerce teams preparing for AI discovery |
| Interface | Your website, app, game, or custom frontend | ChatGPT, Google AI Mode, Gemini, Microsoft Copilot, and other supported channels |
| Technical model | GraphQL API for products, collections, carts, checkout, customers, metaobjects, and search | Channel and product-discovery model tied to Shopify Catalog, Google & YouTube, eligibility, mapping, and agent discovery |
| Control | High control over frontend UX, merchandising, and custom logic | Less control over the AI interface; more focus on data quality, eligibility, and channel setup |
| Product data problem | The API can only return the fields and structure you query | AI agents need enough structured product context to understand when to recommend a product |

## What Shopify Storefront API is

[Shopify Storefront API](https://shopify.dev/docs/api/storefront) is a GraphQL API for creating customer experiences on any platform, including the web, apps, and games. Shopify says the API lets customers view products and collections, add products to a cart, and check out.

In plain terms, Storefront API is the customer-facing commerce API for Shopify.

It is commonly used for:

- Headless Shopify storefronts.
- Mobile commerce apps.
- Product discovery, filtering, and search interfaces.
- Custom product detail pages and collection pages.
- Bundles, configurators, quizzes, and guided shopping flows.
- Content-commerce experiences where Shopify powers products, carts, and checkout behind a custom frontend.
- Frontends built with Hydrogen, another JavaScript framework, or a fully custom stack.

The API is separate from the Shopify Admin API. Storefront API is for customer-facing commerce experiences. Admin API is for store management operations such as products, orders, customers, inventory, apps, and merchant back-office workflows.

That distinction matters. Do not expose Admin API credentials in a public storefront. A custom storefront should use Storefront API access with the right scopes for the customer-facing data and actions it needs.

## How Shopify Storefront API works

Storefront API uses GraphQL. Instead of calling many REST endpoints, a frontend sends a GraphQL query to Shopify and asks for the exact product, collection, cart, customer, or metaobject fields it needs.

A typical setup has four parts.

### 1. Storefront API access token

A custom storefront uses a Storefront API access token. Many teams casually call this a Shopify Storefront API key, but Shopify's [Storefront API authentication documentation](https://shopify.dev/docs/api/storefront#authentication) usually describes it as an access token.

That token is used with requests to the Storefront API. It should not be confused with a private Admin API token. Shopify's official docs are the right next step for the current token-creation flow and supported authentication headers before you wire a production storefront.

### 2. GraphQL endpoint

Storefront API requests go to a Shopify GraphQL endpoint for a specific shop and API version. Shopify documents the current [endpoints and queries](https://shopify.dev/docs/api/storefront#endpoints-and-queries) on the Storefront API reference; the production pattern is to call the versioned GraphQL endpoint for the shop with the Storefront API token in the request headers.

Versioning matters because Shopify releases new API versions. A production storefront should pin an API version, monitor deprecations, and plan upgrades instead of relying on whatever happens to be latest.

### 3. Queries and mutations

Queries read data. Mutations change or create customer-facing commerce state.

Common Storefront API reads include:

- Products.
- Product variants.
- Collections.
- Search results.
- Metaobjects.
- Selling plans.
- Product availability.

Common Storefront API actions include:

- Creating a cart.
- Adding or removing cart lines.
- Updating quantities.
- Applying discount codes or buyer identity where supported.
- Sending the buyer into checkout.

For example, Shopify's Storefront API `products` query returns a paginated product list. It can support filters for availability, product type, tags, variants, vendor, updated dates, and other product fields. That is why the API is useful for custom collection pages, search interfaces, product grids, and filtering.

A simplified product query might look like this:

```graphql
query ProductsForStorefront($first: Int!) {
  products(first: $first) {
    nodes {
      title
      handle
      description
      featuredImage {
        url
        altText
      }
      variants(first: 10) {
        nodes {
          title
          availableForSale
          price {
            amount
            currencyCode
          }
        }
      }
    }
  }
}
```

The exact query you use depends on the storefront experience you are building. A lightweight landing page may only need product titles, images, handles, prices, and availability. A comparison tool may need variants, metafields, product options, media, collections, tags, selling plans, and custom data.

### 4. Frontend application

The frontend turns Storefront API responses into the shopping experience. Shopify offers Hydrogen, its React-based framework for headless commerce, and officially supported clients for different stacks. Teams can also build with their own framework if they handle data fetching, caching, routing, analytics, SEO, and checkout behavior correctly.

This is where Storefront API becomes valuable. It gives the development team control over the experience, while Shopify remains the commerce system behind the scenes.

## What Storefront API is good for

Storefront API is strongest when the merchant needs a controlled owned experience.

### Headless storefronts

A headless storefront separates the frontend from the Shopify backend. The store can use a custom frontend while Shopify continues to manage products, carts, checkout, payments, inventory, and commerce operations.

This is useful when a standard theme cannot support the experience the brand wants.

### Custom product discovery

Storefront API can power custom product grids, filters, search interfaces, quizzes, collections, and product detail pages. If your merchandising logic depends on product type, tags, variants, metafields, vendor, availability, or custom grouping, the API gives developers a way to query and assemble that experience.

### Apps and embedded commerce

The API can support mobile apps, in-game commerce, creator storefronts, content sites, and campaign microsites where products and carts still come from Shopify.

### Performance and UX control

A custom frontend gives teams more control over performance, routing, content modeling, personalization, experimentation, and analytics. Storefront API is the Shopify data layer that lets that frontend stay connected to products and checkout.

## What Storefront API does not solve by itself

Storefront API is powerful, but it is not a full AI commerce strategy by itself.

It does not automatically make a product easy for an AI assistant to understand. It does not decide which product is best for a shopper's prompt. It does not enrich thin product data, normalize inconsistent fields, or distribute the catalog across every AI surface where shoppers may ask for recommendations.

It can return product data, but the quality of that data still depends on what exists in Shopify and what the frontend queries.

If product titles are vague, descriptions are thin, variant data is confusing, metafields are unmapped, compatibility notes are buried in images, or return/shipping constraints are missing, Storefront API can expose those weaknesses as easily as it exposes the products.

That is why Storefront API and AI shopping readiness should be treated as related but different problems.

## What Shopify Agentic Storefronts do

Shopify Agentic Storefronts are about AI shopping distribution. Shopify's [Agentic Storefronts documentation](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts) describes them as a way for customers to discover and purchase products in AI channels such as ChatGPT, Google AI Mode, Gemini, and Microsoft Copilot.

Catalog has a deeper guide to [Shopify Agentic Storefronts](https://www.getcatalog.ai/blog/shopify-agentic-storefronts) for merchants who want the channel-by-channel view. The important distinction here is that Agentic Storefronts are not a headless frontend framework.

They are closer to an AI-channel participation path.

The same Shopify documentation says products can be made available to AI channels through Shopify Catalog or, for Google AI Mode and Gemini, through the Google & YouTube sales channel. Shopify also notes that Google AI Mode and Gemini support is early access and not available for all stores.

So while Storefront API asks, "How do we build a custom commerce experience?" Agentic Storefronts ask, "How do our products become discoverable and purchasable where AI assistants are shopping on behalf of customers?"

## Storefront API vs. Agentic Storefronts

Storefront API and Agentic Storefronts are not substitutes.

A merchant can use Storefront API and not be ready for AI shopping. A merchant can participate in Agentic Storefronts and still need Storefront API for a custom website or app.

Here is the simplest way to separate them:

- Storefront API is for owned surfaces you build and control.
- Agentic Storefronts are for supported AI shopping surfaces you do not fully control.
- Catalog is for the product data quality and distribution problem that sits underneath AI commerce.

### If you are building a custom frontend

Start with Storefront API. Decide whether to use Hydrogen, another frontend stack, or an existing site architecture. Define the product, variant, collection, cart, search, and checkout behavior the experience needs.

Then make sure the product data model supports that experience. If the frontend depends on product attributes, use-case labels, compatibility rules, materials, dimensions, care instructions, availability, bundles, or reviews, those details need to be structured somewhere the application can query.

### If you are preparing for AI shopping channels

Start with Agentic Storefronts eligibility and channel setup. Check which AI channels are available, what each channel requires, and how products are discovered.

Then audit the product data like an AI assistant would. The issue is not only whether a product is present. It is whether the product can be understood, compared, and recommended accurately for a shopper's specific need.

### If you need both

Many merchants will need both.

A brand may want a fast custom frontend for owned conversion and, at the same time, want products to appear in AI-mediated shopping journeys. In that case, Storefront API powers the owned experience, while Agentic Storefronts and a richer product data layer help with AI-channel visibility.

## Product data is the shared bottleneck

The Storefront API can query product fields. Agentic Storefronts can make eligible products available in AI channels. Neither path magically fixes weak product data.

AI shopping systems need structured product facts, not just a product page URL.

Useful product context can include:

- Accurate titles and descriptions.
- Variant availability and price freshness.
- Product options, sizes, colors, materials, dimensions, and compatibility.
- Use cases and shopper-fit signals.
- Product comparisons and alternatives.
- Reviews and common objections.
- Shipping, returns, subscriptions, restrictions, and regional availability.
- Images and visual attributes that a text-only description misses.
- Metafields, metaobjects, tags, and other custom Shopify data.

Shopify's [Catalog and product discovery documentation](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products) says Shopify Catalog can list products with title, description, options, images, price, availability, and other key attributes structured for AI agents to parse. Shopify's [product data mapping guidance](https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products#data-mapping) also points to Catalog Mapping when important product data lives in custom fields such as metafields, metaobjects, tag prefixes, or product-title patterns.

That is important because many Shopify stores keep their best product context outside default fields. Fit notes, product education, bundle logic, compatibility rules, and comparison copy may live in custom data, apps, theme sections, PDFs, images, reviews, support docs, or merchandising spreadsheets.

If those facts are not mapped or structured, the product can be technically available through an API or channel and still be hard for an AI system to recommend correctly.

## Where Catalog fits

Catalog does not replace Shopify Storefront API. It does not require merchants to ignore Shopify's native AI channels.

Catalog fits around both as the product data layer for AI commerce.

Storefront API helps teams build owned commerce experiences. Agentic Storefronts help eligible products participate in Shopify-supported AI shopping channels. Catalog helps make product data richer, more complete, and more portable across AI surfaces.

Catalog connects to Shopify, ingests the catalog, enriches product facts, and structures the details AI systems need before they recommend products. It is built for teams that need live, structured product data for commerce agents and product discovery systems, including normalized product fields, live pricing, stock confidence, variant matching, review signals, image analysis, similar products, and product enrichment.

That matters because AI shopping is not limited to one native Shopify channel. Shoppers ask product questions in ChatGPT, Gemini, Claude, Perplexity, search results, marketplaces, affiliate tools, and future shopping agents that do not all read merchant data the same way.

A merchant can use Shopify's native paths and still need Catalog if they want broader AI visibility and better product understanding.

The strongest setup is layered:

1. Use Shopify as the commerce system of record.
2. Use Storefront API where you need custom owned experiences.
3. Use Agentic Storefronts where Shopify-supported AI channels are available and relevant.
4. Use Catalog to enrich, normalize, and distribute product context across AI shopping surfaces.

## Storefront API implementation checklist

If you are planning a Shopify Storefront API build, start with the technical basics and the product-data basics together.

### Confirm the storefront job

Do not start with the API call. Start with the experience.

Are you building a full headless storefront, a mobile app, a product finder, a configurator, a content-commerce page, or a campaign microsite? The answer determines which product fields, cart behavior, routing, SEO, analytics, and checkout flow you need.

### Choose the frontend approach

Hydrogen is Shopify's official React-based framework for headless commerce. It can be a good fit when the team wants Shopify-native headless tooling.

A custom stack can also work if the team is ready to own more decisions: data fetching, caching, routing, SEO, hosting, analytics, error handling, and deployment.

### Set up access carefully

Use Storefront API access for customer-facing experiences. Do not expose Admin API credentials in frontend code.

Give the storefront only the access it needs, document which API version it uses, and make token handling part of your security review.

### Model product data before building UI

The storefront can only render the data available to it. Before building templates, confirm where important data lives:

- Shopify product fields.
- Variants and options.
- Metafields.
- Metaobjects.
- Tags.
- Collections.
- Selling plans.
- Reviews or third-party app data.
- Shipping, returns, and policy information.

If important facts are only present in theme copy, images, PDFs, or support articles, the API may not return them in a reliable way.

### Plan caching and freshness

Product pages need to be fast, but prices, inventory, variants, and availability can change. Decide which data can be cached, which data must stay fresh, and how the storefront handles unavailable variants or changed carts.

### Treat AI readiness as a separate layer

A Storefront API build can improve the owned shopping experience, but AI assistants need richer product understanding. If AI shopping visibility matters, build a product data layer that can support both the storefront and external AI discovery.

## FAQ

### What is Shopify Storefront API used for?

Shopify Storefront API is used to build customer-facing commerce experiences on top of Shopify. Common uses include headless storefronts, mobile apps, product discovery flows, custom carts, collection pages, product detail pages, and checkout journeys.

### Is Shopify Storefront API GraphQL?

Yes. Shopify Storefront API is a GraphQL API. Developers write queries and mutations to read products, collections, carts, search results, customer-facing data, and related commerce objects.

### How do I get a Shopify Storefront API key?

Most teams mean a Storefront API access token when they say Storefront API key. The exact setup depends on the Shopify configuration and app or custom storefront approach. Use Shopify's current [Storefront API authentication documentation](https://shopify.dev/docs/api/storefront#authentication) for token creation and request authentication, and do not confuse the Storefront API token with a private Admin API token.

### Is Shopify Storefront API free?

Storefront API is included in Shopify's customer-facing development model, but a production build is not automatically free. The practical cost depends on the Shopify plan, build approach, hosting, development work, app architecture, and any third-party systems you use. Check Shopify's current plan and API documentation for eligibility and limits before planning a production build.

### Is Shopify Storefront API the same as Agentic Storefronts?

No. Shopify Storefront API is a GraphQL API for building custom customer-facing storefront experiences. Agentic Storefronts are Shopify's path for making eligible products available in AI shopping channels.

### Do Agentic Storefronts replace headless commerce?

No. Headless commerce and Agentic Storefronts solve different jobs. Headless commerce controls your owned storefront experience. Agentic Storefronts help supported AI channels discover and transact with Shopify products.

### Do I need Storefront API to use Agentic Storefronts?

Not necessarily. Agentic Storefront setup is tied to Shopify's channel and product discovery paths, not to building a custom Storefront API frontend. But many merchants may use both if they have a custom storefront and also want AI-channel visibility.

### Is Shopify Catalog enough for AI shopping visibility?

Shopify Catalog is an important native path for eligible products, but it is not the whole AI-commerce strategy. Shopify itself notes channel-specific paths, including Google & YouTube for Google AI Mode and Gemini. Merchants still need complete, mapped, current product data that AI systems can parse and use.

### Where does Catalog fit if Shopify has native Agentic Storefronts?

Catalog helps enrich and distribute product data beyond one storefront or native channel. It turns Shopify product data into richer machine-readable context for AI shopping surfaces such as ChatGPT, Gemini, Claude, Perplexity, and future commerce agents.

## The bottom line

Shopify Storefront API is the right tool when you need to build a custom customer-facing Shopify experience. It gives developers GraphQL access to the products, collections, carts, checkout, and commerce data needed for a headless storefront or custom app.

Agentic Storefronts solve a different problem: making eligible Shopify products available in supported AI shopping channels.

Catalog fits underneath the AI-commerce side of the equation. It helps turn Shopify product data into richer, more complete, more portable product context so products can be understood wherever AI shopping happens.

If your goal is only a custom frontend, start with Storefront API. If your goal is AI commerce, do not stop at the endpoint or the channel toggle. Make sure the product data itself is good enough to be chosen.

---

Canonical: https://www.getcatalog.ai/blog/shopify-storefront-api-agentic-storefronts
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# AI visibility for ecommerce: metrics and product discovery

*June 23, 2026 · Hamish Gunasekara · Business · 12 min read*

> Learn what AI visibility means for ecommerce, which metrics matter, where tools help, and how to connect brand visibility to product discovery.

AI visibility is the measure of whether AI systems mention, cite, recommend, and accurately describe your brand when shoppers ask relevant questions.

For ecommerce teams, that definition has a second layer. It is not enough for the brand to appear in an AI answer. The right products also need to appear when a shopper describes a use case, compares options, asks for a budget recommendation, or narrows by attributes such as material, fit, size, ingredients, compatibility, delivery, or returns.

That makes AI visibility both a marketing metric and a product discovery problem.

A broad AI visibility report can tell you that your brand was mentioned in ChatGPT, Perplexity, Gemini, or an AI Overview. An ecommerce AI visibility program should go further: which prompts matter, which competitors appear, which sources are cited, which facts are wrong, and which products are invisible because the data behind them is too thin, stale, or hard to parse.

## What does AI visibility mean in ecommerce?

AI visibility in ecommerce is the degree to which AI search and answer systems can find, understand, trust, and recommend your brand and products for shopper questions.

Traditional search visibility is measured through rankings, impressions, clicks, and organic revenue. AI visibility is different because the shopper may never see a ranked list. They may see a synthesized answer, a shortlist, a recommendation, a cited source, a product carousel, or a shopping action.

That changes the questions ecommerce leaders need to ask:

- Does our brand appear when shoppers ask category-level questions?
- Are our products recommended for the use cases we actually serve?
- Which competitors appear more often than we do?
- Which pages or third-party sources are cited as proof?
- Are product facts such as price, availability, materials, sizing, or policies accurate?
- Can we connect AI visibility to sessions, assisted revenue, and product-data improvements?

This page is the strategy and measurement guide for that problem. Catalog's guide to [making products show up in ChatGPT](https://www.getcatalog.ai/blog/how-to-make-products-show-up-in-chatgpt) goes deeper on one implementation path: improving product-level visibility in ChatGPT. This guide is broader. It explains how to think about AI visibility across the whole ecommerce discovery channel.

## Which AI visibility metrics matter?

Most AI visibility programs start with brand tracking, but ecommerce teams need a mix of brand, source, and product-level metrics.

### 1. Brand mention rate

Brand mention rate measures how often your brand appears across a defined prompt set.

If you test 100 prompts and your brand appears in 18 answers, your brand mention rate is 18%. This is the simplest signal of whether AI systems recognize your brand as relevant to the category.

Segment this by prompt type. A brand might appear often for broad category prompts but rarely for high-intent buying prompts. That gap tells you where visibility is not yet commercially useful.

### 2. Recommendation rate

Recommendation rate measures how often the AI system actively suggests your brand or product, not just mentions it.

A mention might say your brand exists. A recommendation says it is a good choice for the shopper's stated need. For commerce, that distinction matters because recommendation language is closer to purchase influence.

Track recommendation rate by category, product line, and buyer scenario. If a product is mentioned but never recommended, the answer may lack enough proof, specificity, or offer confidence.

### 3. Share of voice

AI share of voice compares your presence with competitors across the same prompt set.

This is useful when the category is still forming. Track which competitors are named, where they rank in the answer, whether they are recommended, and which sources support them.

### 4. Citation and source coverage

Citation coverage measures which URLs AI systems cite or use as support.

For ecommerce, the source matters as much as the mention. An answer might cite your product page, a category page, a retailer listing, a review article, a marketplace page, a Reddit thread, or a competitor comparison. Each source reveals how the AI system is grounding the recommendation.

If third-party pages are cited more often than your own site, your owned content may not be specific enough. If your product detail pages are never cited, your product records may not be easy enough to extract or trust.

### 5. Accuracy

Accuracy measures whether the AI answer describes your brand and products correctly.

Brand-level accuracy includes positioning, audience, category, and product range. Product-level accuracy includes price, availability, size, color, material, compatibility, shipping, returns, warranty, and current offers.

Wrong facts are not just reporting noise. They can make the AI surface avoid the product, disappoint the shopper, or send demand to the wrong place.

### 6. Product coverage

Product coverage measures which products appear when they should.

This is where ecommerce AI visibility differs from generic brand monitoring. A retailer can have decent brand visibility while a strategic product line remains invisible. Track which SKUs appear, which are skipped, and which data gaps explain the difference.

## Which AI platforms should ecommerce teams monitor?

Start with the AI surfaces your shoppers already use, then expand. For most ecommerce teams, that means monitoring at least three platform types.

### Conversational assistants

ChatGPT and similar assistants are useful for open-ended product questions, shortlists, comparisons, and follow-up refinement. Shoppers can describe a situation instead of typing a clean keyword.

That makes prompts more varied. A running shoe might need to match questions about wide sizing, wet pavement, marathon training, injury history, and budget. A beauty product might need to match ingredient concerns, skin type, shade, finish, and routine.

### Answer engines with citations

Perplexity-style answer engines are important because source transparency is part of the experience. They show where the answer came from, which gives merchants a clearer view of the pages and third-party sources shaping discovery.

If comparison articles, review sites, or community discussions describe competitors more clearly than they describe you, the answer may tilt away from your products even when they are a strong fit.

### Google AI and shopping surfaces

Google is the clearest public example of AI visibility becoming commerce infrastructure.

In its May 2026 [Universal Cart announcement](https://blog.google/products-and-platforms/products/shopping/google-shopping-cart/), Google said people shop across Google more than a billion times a day and described the Shopping Graph as a catalog of over 60 billion product listings.

Google's earlier [Shopping Graph explainer](https://blog.google/products/shopping/shopping-graph-explained/) is useful for the mechanics. It describes the graph as an ML-powered, real-time dataset of products and sellers, with information such as availability, reviews, pros and cons, materials, colors, and sizes.

Google is also moving beyond answers into shopping actions. The Universal Cart post describes a cart that works across Search, Gemini, YouTube, and Gmail, with features for price drops, back-in-stock alerts, product compatibility, payment perks, loyalty information, and merchant offers.

And Google's retailer announcement for the [Universal Commerce Protocol](https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/) says UCP is designed to support agentic commerce across discovery, buying, and post-purchase support. The same announcement says new Merchant Center data attributes are being built for conversational commerce and can include answers to common product questions, compatible accessories, and substitutes.

The practical takeaway: ecommerce AI visibility is being built into search, shopping graphs, merchant feeds, carts, checkout protocols, and product-data systems.

## Where do AI visibility tools help?

AI visibility tools can help ecommerce teams monitor a channel that is hard to inspect manually. They are useful when they save time, reveal patterns, and create a repeatable baseline.

The most useful tool capabilities are:

- **Prompt tracking:** monitoring a stable set of category, product, comparison, and buying-intent prompts over time.
- **Competitor benchmarking:** showing which brands appear more often, where they appear, and how recommendations shift.
- **Citation extraction:** collecting the URLs and domains AI systems use as support.
- **Accuracy review:** flagging incorrect brand, product, pricing, or positioning statements.
- **Trend reporting:** showing whether visibility is improving after content, product-data, or authority work.
- **Team workflow:** turning findings into tasks for content, merchandising, product data, engineering, or partnerships.

But tools do not fix the underlying reason a product is invisible. They can show that a product is missing from a prompt set. Your team still has to diagnose whether the cause is missing attributes, weak reviews, inaccessible pages, stale inventory, inconsistent feeds, thin category content, or poor third-party coverage.

Use tools to make the measurement loop repeatable. Do not use them as a substitute for channel strategy.

## How does AI visibility connect to product discovery?

AI visibility becomes commercially useful when it improves product discovery.

There are two levels:

1. **Brand-level visibility:** AI systems know your brand belongs in the category.
2. **Product-level visibility:** AI systems can match specific products to specific shopper needs.

Brand-level visibility can win awareness. Product-level visibility wins consideration. A shopper does not only ask, "What brands sell luggage?" They ask for a lightweight carry-on under a budget, a washable rug for a high-traffic dining room, or a moisturizer without a specific ingredient.

That is where product data matters. AI systems need product facts they can retrieve, compare, and trust. Important facts often include material, size, fit, dimensions, weight, compatibility, ingredients, certifications, use cases, substitutions, accessories, bundles, availability, shipping, returns, and current offers.

This is the bridge to [product data enrichment for AI commerce](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce). Enrichment gives AI systems more ways to map messy shopper language to a concrete product. It also explains why broad AI visibility and product-data operations need to work together.

## A 30-day AI visibility baseline for ecommerce

A useful baseline does not have to be complicated. The goal is to understand where you show up, where competitors show up, and which fixes are likely to move the channel.

### Week 1: Build the prompt set

Create 30 to 50 prompts across five groups:

- category education prompts;
- brand comparison prompts;
- product recommendation prompts;
- use-case and constraint prompts; and
- objection prompts about price, trust, compatibility, shipping, or returns.

Keep the prompt set stable enough to compare month over month.

### Week 2: Run the baseline

Test the prompts across the AI surfaces that matter for your category. Record brand mentions, product mentions, recommendations, cited URLs, competitor mentions, and obvious accuracy issues.

Look for patterns across prompt groups and platforms.

### Week 3: Diagnose the gaps

Separate the findings into four buckets:

- content gaps, where your site does not answer the question clearly;
- source gaps, where third-party pages talk about competitors more than you;
- product-data gaps, where product facts are incomplete or inconsistent; and
- technical access gaps, where AI or search systems cannot reliably retrieve the page or data.

This prevents every problem from becoming a blog post or an engineering ticket.

### Week 4: Prioritize fixes

Prioritize the fixes closest to revenue. Start with products, categories, and prompts that already matter commercially.

If the brand is missing from broad category prompts, improve category education and third-party authority. If the brand appears but the wrong products are recommended, inspect product data and merchandising. If facts are wrong, fix the source of truth before scaling the prompt set.

## What should you do next?

Treat AI visibility as a new operating loop, not a one-off report.

The loop is simple:

1. Define the prompts that matter.
2. Measure brand, source, and product visibility.
3. Diagnose the reason for each gap.
4. Fix content, data, authority, or access.
5. Repeat on a stable cadence.

Catalog fits when the bottleneck is product data quality, structure, and distribution. It is built around live, normalized product data that software can read. That matters because AI visibility eventually depends on whether systems can understand what you sell, when it is available, and why it fits the shopper's request. Teams should also watch for [dark agentic commerce traffic](https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic) when AI-influenced shoppers arrive without a visible referrer.

If you are ready for the product-level implementation work, start with the guide to [making products show up in ChatGPT](https://www.getcatalog.ai/blog/how-to-make-products-show-up-in-chatgpt). Use this page for the measurement strategy. Use that page when you are ready to fix the product records behind one of the most important AI discovery surfaces.

## FAQ

### Is AI visibility the same as SEO?

No. SEO focuses on search rankings, clicks, and organic traffic. AI visibility focuses on whether AI systems mention, cite, recommend, and accurately describe your brand or products in generated answers. The two overlap, but AI visibility also depends on answer inclusion, source coverage, product facts, and cross-platform prompts.

### What is a good AI visibility metric to start with?

Start with brand mention rate, recommendation rate, citation coverage, and accuracy across a fixed prompt set. Ecommerce teams should also track product coverage: which products appear for buying-intent prompts and which are skipped.

### Do AI visibility tools replace product-data work?

No. Tools help you monitor mentions, citations, competitors, and trends. They do not automatically fix missing attributes, stale inventory, weak product pages, crawl issues, or thin third-party proof. Use tools to find the gaps, then assign the fixes to the teams that own the underlying source.

### Why does product discovery belong in an AI visibility guide?

Because ecommerce visibility only matters when shoppers can find the right products. Brand mentions create awareness, but product discovery connects that awareness to consideration and purchase. That is why ecommerce teams need both brand-level and product-level AI visibility metrics.

---

Canonical: https://www.getcatalog.ai/blog/ai-visibility-ecommerce
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# How to turn your product catalog into machine-readable data for AI shopping

*June 16, 2026 · Catalog Team · Business · 15 min read*

> Learn how product data enrichment turns messy catalogs into machine-readable records for AI shopping, including workflows, vendor types, and Catalog's role.

Yes, there are services that can turn a [product catalog](https://www.getcatalog.ai/glossary/product-catalog) into machine-readable data.

The harder question is which kind of service you need.

A one-time conversion project can extract fields from PDFs, spreadsheets, supplier feeds, or product pages and return a structured file. A product data enrichment service can add missing attributes, map products to a taxonomy, and clean inconsistent records. A PIM or [PXM system](https://www.getcatalog.ai/blog/product-experience-management) can help teams manage richer product content over time. A feed tool can format product data for specific channels.

If the goal is AI commerce, the bar is higher. AI shopping systems need product data they can parse, compare, trust, and keep fresh. The output cannot be a nicer spreadsheet or a longer product description. It needs to behave like a live, structured product object.

That is where product data enrichment becomes strategic. [Catalog fits here as a product data layer](https://www.getcatalog.ai/blog/why-smart-ecommerce-companies-choose-catalog-ai) for brands that need AI shopping systems to understand what they sell, not as a generic extraction vendor.

## What machine-readable product data means

Machine-readable product data is product information organized so software can read it without guessing.

A human can look at a product page and infer a lot from the copy, photos, reviews, and layout. Machines need the facts broken into fields.

For example, a shopper might understand this description:

> Blue ceramic table lamp with dimmable LED bulb, 9-inch shade, and brass base.

An AI shopping system needs the same product represented as structured facts:

```json
{
  "product_type": "table lamp",
  "color": "blue",
  "material": ["ceramic", "brass"],
  "shade_diameter": "9 in",
  "bulb_type": "LED",
  "dimmable": true,
  "room": ["bedroom", "living room", "office"]
}
```

That structure matters because AI shopping systems read and compare at the same time.

If someone asks for “a dimmable blue ceramic lamp under 12 inches wide,” the system needs to know which fields map to color, material, size, and feature constraints. If that information is buried in prose or missing from the catalog entirely, the product is harder to recommend confidently.

A machine-readable catalog usually includes:

- stable product identifiers such as SKU, GTIN, MPN, brand, and canonical URL;
- normalized product categories and taxonomy paths;
- typed attributes such as color, material, dimensions, size, compatibility, voltage, ingredients, or use case;
- variant relationships, including size, color, bundle, and pack options;
- media metadata such as image alt text, image role, and product angle;
- price, availability, shipping, returns, and policy signals;
- source URLs, update times, and other provenance details;
- structured outputs such as JSON, GraphQL, XML, CSV, or feed formats.

The exact schema depends on the category. A beauty catalog needs shades, ingredients, skin type, allergens, and compliance fields. An apparel catalog needs sizing, fit, fabric, care instructions, color families, and variant logic. A parts catalog needs compatibility, dimensions, materials, certifications, and replacement relationships.

The point is the same: machines need product facts in predictable places.

## Product data enrichment is the bridge

Product data enrichment is the process of improving raw product records so they become complete, consistent, and useful across systems.

It can include:

- extracting attributes from product descriptions, PDFs, spec sheets, supplier spreadsheets, images, and manufacturer pages;
- normalizing units, naming conventions, category paths, and option values;
- mapping products to a taxonomy;
- adding missing attributes, use cases, compatibility details, and merchandising fields;
- deduplicating records and resolving conflicting values;
- improving titles, descriptions, image metadata, and structured summaries;
- validating records against a schema;
- exporting the result to a PIM, ERP, storefront, marketplace feed, search index, or API.

Good enrichment makes product copy clearer and makes the product easier for software to reason about.

That distinction is important for AI commerce. A product can have a polished title and description and still be hard for AI systems to use. If the size is written three different ways, the variants are not connected, the category is too broad, and the return policy is not machine-readable, the product record is still weak.

Enrichment should create a cleaner object instead of stopping at prettier text.

## A before-and-after example

Here is a simplified raw catalog row:

| Field | Raw value |
| --- | --- |
| Title | Nessino light blue |
| Description | Iconic table lamp. Blue. Great for bedside or desk. Includes bulb. |
| Category | Lighting |
| Price | 245 |
| Stock | yes |

A human can guess what this is. A machine has to guess too much.

An enriched product record might look more like this:

```json
{
  "name": "Artemide Nessino Table Lamp",
  "brand": "Artemide",
  "product_type": "table lamp",
  "category_path": ["Home", "Lighting", "Table Lamps"],
  "color": "light blue",
  "materials": ["polycarbonate"],
  "dimensions": {
    "height": "8.8 in",
    "diameter": "12.6 in"
  },
  "bulb_included": true,
  "power_source": "corded electric",
  "room_suitability": ["bedroom", "office", "living room"],
  "style": ["modern", "mid-century", "statement lighting"],
  "price": {
    "amount": 245,
    "currency": "USD"
  },
  "availability": "in_stock",
  "canonical_url": "https://example.com/products/artemide-nessino-light-blue",
  "ai_summary": "A compact light-blue designer table lamp for desks, bedside tables, and modern interiors."
}
```

Now the product can be matched to more specific requests:

- “blue table lamp for a bedside table”
- “modern desk lamp under 13 inches wide”
- “Artemide lamp in light blue”
- “compact statement lighting for a small apartment”

The enriched version also makes errors easier to catch. If the product is marked as both “corded electric” and “battery powered,” validation can flag the conflict. If dimensions are missing for an item where size matters, the system can score the record as incomplete.

That is the value of machine-readable data. It gives every product a clearer shape.

## The usual workflow

Most product catalog enrichment projects follow the same basic pattern, even when the tools differ.

### 1. Inventory the source data

Start by listing where product information currently lives.

Common sources include:

- supplier spreadsheets;
- PDFs and printed catalogs;
- manufacturer websites;
- existing product pages;
- PIM, ERP, or inventory systems;
- marketplace listings;
- images, spec sheets, manuals, and reviews.

This step matters because source quality determines the project shape. Extracting data from clean spreadsheets is different from reconstructing product facts from old PDFs and inconsistent product pages.

### 2. Define the target schema

Before extracting fields, decide what the finished product record should contain.

A good schema defines:

- required fields;
- optional fields;
- accepted values;
- units;
- category-specific attributes;
- variant logic;
- output format;
- validation rules.

Do not use one generic schema for every product if your catalog spans multiple categories. Furniture, apparel, electronics, beauty, grocery, and industrial parts all need different attribute sets.

### 3. Extract the product facts

Extraction turns unstructured or semi-structured material into fields. If this collection step is new to your team, start with the broader [product data extraction](https://www.getcatalog.ai/blog/product-data-extraction) workflow before you design enrichment rules.

This can involve OCR, parsers, scraping, APIs, manual review, or large language models. The method matters less than the output: extracted fields should be accurate, category-aware, and traceable back to a source.

For AI shopping, source traceability matters. If a system recommends a product because it is compatible with a device, waterproof, vegan, or safe for children, the brand needs confidence that the field is correct.

### 4. Normalize categories, units, and variants

Raw catalogs often contain the same idea in many different forms.

One supplier says “light blue.” Another says “sky.” Another says “LB.” One file uses inches. Another uses centimeters. One product has variants as separate rows. Another stores them as one free-text option field.

Normalization turns that mess into consistent values.

That usually includes:

- category mapping;
- unit conversion;
- color and size standardization;
- title cleanup;
- variant grouping;
- duplicate detection;
- brand and manufacturer cleanup.

This is where many generic AI workflows break down. They can extract text, but they do not always create stable product data that works across a real catalog.

### 5. Enrich missing attributes

After extraction and normalization, the next job is filling gaps.

Missing attributes can come from manufacturer pages, spec sheets, product images, similar products, or structured rules. Some fields should be inferred. Others should only be added when there is a trusted source.

For example, an AI system might infer that a “linen maxi dress” is in the apparel category. It should not invent the exact fabric blend, care instructions, or return restrictions without evidence.

Good enrichment separates confident facts from guesses.

### 6. Validate the output

Validation is what keeps enriched product data from becoming a prettier version of the same mess.

Useful checks include:

- required-field completeness;
- category-specific field coverage;
- unit consistency;
- impossible combinations;
- duplicate SKUs;
- broken variant relationships;
- missing images or alt text;
- price and availability freshness;
- source confidence.

For AI commerce, validation should also ask: could an AI shopping system answer detailed questions from this record without hallucinating?

### 7. Publish the data where it needs to go

Machine-readable product data is only useful if downstream systems can use it.

Common outputs include:

- JSON or GraphQL APIs;
- CSV or XML exports;
- marketplace and shopping feeds;
- search indexes;
- [storefront structured data](https://www.getcatalog.ai/glossary/schema-markup);
- PIM or ERP updates;
- AI-ready product pages or a parallel storefront layer.

The right output depends on the job. A merchandising team may need a reviewed PIM import. A developer team may need typed product objects from an API. A brand focused on AI discovery may need a structured surface that AI systems can crawl, cite, and understand. For more on those data requirements, see [trusted data sources for agentic commerce](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce).

### 8. Keep the records synced

A one-time enrichment export gets stale quickly.

Prices change. Products go out of stock. Variants are retired. New attributes become important. AI shopping surfaces change how they discover and evaluate products. For workflows where price freshness is the core requirement, a [price monitoring API](https://www.getcatalog.ai/blog/price-monitoring-api) can keep offer data usable without brittle scrapers.

If machine-readable data is part of your growth strategy, treat it as a live system rather than a cleanup project.

## Which type of service do you need?

The best service depends on the problem you are solving.

| Service type | Best fit | Typical output | Watch out for |
| --- | --- | --- | --- |
| Document or OCR extraction | You have PDFs, printed catalogs, or messy files and need the data extracted | Tables, CSVs, basic JSON | Extraction alone may not normalize or enrich the data enough |
| Product data enrichment service | You need missing attributes, taxonomy mapping, classification, and SKU cleanup | Enriched product records, category mappings, attributes | Check how updates, validation, and category-specific schemas work |
| [PIM or PXM system](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) | You need an operational system for managing product content across teams | Governed product content, workflows, channel exports | A PIM can still contain thin or inconsistent data if enrichment is weak |
| Feed management tool | You need to format product data for Google, marketplaces, affiliates, or ad channels | Channel-specific feeds | Feed formatting does not automatically make products AI-ready |
| [Custom product data pipeline](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) | You have unique source formats or internal systems | Custom parsers, LLM extraction, schema validation, APIs | Requires maintenance, monitoring, and data-quality ownership |
| AI-commerce product data layer | You need AI shopping systems to understand, recommend, and cite products | Live structured product objects, AI-ready pages, measurement | Make sure it complements your existing systems of record |

Many companies need more than one layer.

If the choice is getting fuzzy, separate whether you are comparing [PIM with DAM](https://www.getcatalog.ai/blog/pim-vs-dam) for assets, [PIM with MDM](https://www.getcatalog.ai/blog/pim-vs-mdm) for governance, or enrichment with a downstream AI-commerce layer.

A PIM may manage internal workflow. A feed tool may distribute to channels. An enrichment layer may improve product attributes. An AI-commerce layer may expose the product data in a format that AI shopping systems can understand.

The mistake is assuming one cleaned spreadsheet solves every problem.

## What to check before choosing a vendor

Before choosing a product data enrichment or catalog-to-machine-readable-data service, ask these questions.

### What source formats can you handle?

List your real sources, not the ideal ones. If your catalog includes supplier PDFs, inconsistent spreadsheets, product pages, and image-only spec sheets, the service needs to handle that mix.

### What does the output schema look like?

Ask for an example output record. Look for typed fields, category-specific attributes, source URLs, timestamps, validation scores, and variant relationships.

If the output is mostly rewritten descriptions, it is not enough.

### How do you handle category-specific attributes?

A strong enrichment process knows that every category has different fields.

Shoes need size, fit, gender, material, and care details. Supplements need ingredients, serving size, allergens, and warnings. Electronics need compatibility, ports, power, dimensions, and certifications.

A generic flat schema will miss important details.

### How do you validate quality?

Ask how the service checks for mistakes.

Useful answers include required-field coverage, confidence scores, source traceability, duplicate detection, variant checks, unit validation, and human review workflows.

### How often does the data update?

If your products, prices, or inventory change often, a one-time export is not enough.

For AI shopping, stale data is worse than missing data. A recommendation that points to an out-of-stock product or wrong price erodes trust quickly.

### Where does the data go next?

Know the destination before you start.

Are you importing into a PIM? Updating Shopify? Feeding a marketplace? Building an API? Creating AI-readable pages? Powering a search index?

The best enrichment workflow is designed backward from the output.

## Where Catalog fits

Catalog is built for the AI-commerce version of this problem.

If your goal is only to digitize a PDF catalog once, you may need a document extraction service. If your goal is to manage internal product content workflows, you may need a PIM. If your goal is to format feeds for channels, you may need feed management.

Catalog fits when the goal is to make products understandable and recommendable across AI shopping surfaces.

Catalog helps brands create a product data layer for AI commerce: live, normalized product data that can be read by systems like ChatGPT, Gemini, Claude, Perplexity, and future shopping agents. It does not replace your storefront. It gives machines a clearer, structured version of what you sell. If you are comparing the broader stack, read how [modern product data infrastructure](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) fits across storefronts, feeds, APIs, search, and AI shopping.

That matters because AI shopping systems are becoming a new discovery surface. A shopper may not start on your category page. They may ask an assistant for the best product that fits a use case, constraint, budget, or compatibility need.

For that assistant to recommend your product, it needs product data it can trust.

Catalog is strongest when you need to:

- turn product information into structured, machine-readable records;
- keep product data live as price, stock, and variants change;
- expose product facts in a way AI systems can crawl and understand;
- measure how AI systems see and recommend your brand;
- support AI commerce without rebuilding the existing storefront.

For broader market context, read [what agentic commerce is](https://www.getcatalog.ai/blog/what-is-agentic-commerce) and [how to make products show up in ChatGPT](https://www.getcatalog.ai/blog/how-to-make-products-show-up-in-chatgpt).

## The short answer

If you are asking, “Can a service turn my product catalog into machine-readable data?” the answer is yes.

Choose based on the job:

- If you need to pull tables out of PDFs or scanned files, start with extraction.
- If you need missing attributes, taxonomy, and cleaner records, use product data enrichment.
- If you need team workflows and product-content governance, use a PIM or PXM system.
- If you need marketplace or ad-channel formatting, use feed management.
- If you need AI shopping systems to understand and recommend your products, use a product data layer built for AI commerce.

The best output is more than a file. It is a structured product record that stays accurate, complete, and usable wherever products are discovered.

That is what makes a catalog machine-readable.

## FAQ

### What is product data enrichment?

Product data enrichment is the process of improving product records by adding, cleaning, normalizing, and validating product information. It can include attributes, taxonomy, images, descriptions, identifiers, variants, compatibility, and policy data.

### What is a machine-readable product catalog?

A machine-readable product catalog is a catalog structured so software can parse and use it. Instead of relying only on product descriptions or page layout, it stores product facts in predictable fields such as category, material, size, color, price, availability, and variant relationships.

### Is product data enrichment the same as a PIM?

No. Product data enrichment improves the product records. A PIM manages product information workflows and publishing across teams and channels. Many companies use both: enrichment improves the data, while the PIM helps govern and distribute it.

### Can an LLM turn my catalog into structured data by itself?

An LLM can help extract and classify product information, but it should not be the whole system. Real catalog work needs schemas, validation, source traceability, category rules, human review, and update logic. Without those controls, the model may infer fields incorrectly or create inconsistent records.

### What output format should I ask for?

Ask for the format your downstream systems can use. Common outputs include JSON, CSV, XML, GraphQL, marketplace feeds, PIM imports, or API-accessible product objects. For AI commerce, structured JSON or API-accessible product objects are usually more useful than a flat spreadsheet alone.

### How do I know if my product data is AI-ready?

Your product data is closer to AI-ready when it is complete, structured, fresh, and easy to verify. An AI system should be able to answer specific product questions from the record without guessing: what the product is, who it is for, what variants exist, whether it is available, what it costs, and why it fits a shopper's request.

---

Canonical: https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# What is agentic commerce? How it works, examples, and what brands should do next

*June 9, 2026 · Catalog Team · Business · 9 min read*

> Learn what agentic commerce is, how AI shopping agents buy on a customer's behalf, real examples, and what brands need to do to prepare.

Agentic commerce is a buying model where AI agents can research products, compare options, and sometimes complete a purchase on a person's or business's behalf.

The important part is not only that the [interface becomes conversational](https://www.getcatalog.ai/blog/conversational-commerce-guide). The bigger change is that discovery, pricing, inventory, policy, and checkout all need to work for machines as well as humans.

In traditional ecommerce, the customer does the browsing, filtering, comparing, and checkout work. In agentic commerce, an agent can take on part of that job. The user sets the goal, preferences, and guardrails. The agent does the searching, narrows the options, checks the rules, and moves the purchase forward.

For brands, that changes more than the interface. Product pages still matter. So do structured attributes, live price and inventory signals, return-policy clarity, and checkout systems that can support agent-led flows.

## Agentic commerce, defined

A practical definition is this: agentic commerce is commerce where AI agents act on behalf of the buyer.

That usually means the agent can do more than recommend a product. It can interpret a goal, compare options, check constraints such as price or delivery windows, and move the transaction toward completion. In some cases, the human still approves the final purchase. In lower-risk flows, parts of the process may be fully automated.

This is different from older ecommerce AI.

A chatbot might answer a question. A recommendation engine might reorder a product grid. An agent goes further. It can handle a multi-step job from intent to action. [Salesforce](https://www.salesforce.com/commerce/ai/agentic-commerce/) describes that difference cleanly: older ecommerce AI tends to assist, while agentic AI can initiate and complete multi-step tasks more independently.

That is why the term matters. It is not just another label for personalization. It describes a shift in who is navigating the buying journey.

## How agentic commerce works

The exact flow changes by platform and purchase type, but the model usually looks like this:

1. **The shopper sets the goal and guardrails.**  
   A person might say, “Find me waterproof hiking boots under $150 that can arrive by Friday,” or “Reorder the dog food I buy every month, but only if the price stays within my normal range.”

2. **The agent searches, compares, and narrows the options.**  
   Instead of clicking through dozens of category pages, the user lets the agent pull products, compare price and availability, and refine the shortlist.

3. **Merchant systems validate the details.**  
   This is the part many explainers skip. An agent still needs reliable product data, pricing, stock status, shipping estimates, return rules, and checkout logic. If those systems are incomplete or outdated, the experience breaks down fast.

4. **The transaction is approved, executed, and supported after purchase.**  
   In a low-risk flow, the agent may complete the purchase automatically. In a higher-risk flow, it may pause for approval. After that, the same system can track shipment, manage a return, or handle a reorder.

[IBM](https://www.ibm.com/think/topics/agentic-commerce) breaks the model into a similar sequence: user-to-agent engagement, autonomous execution, product discovery, merchant-to-agent interaction, secure transaction, and post-purchase support. That is a useful mental model because it shows agentic commerce is not only discovery. It is a full workflow.

## Real examples of agentic commerce

The easiest way to understand the category is to look at the kinds of jobs agents are already being built to handle.

### 1. Conversational product discovery

A shopper asks for a birthday gift for a 10-year-old who likes art. The agent finds options, narrows them by price, and keeps refining the shortlist when the shopper asks a follow-up such as “What about something under $30?” That conversational discovery pattern is one of the clearest [AI shopping assistant](https://www.getcatalog.ai/blog/ai-shopping-assistant-guide) use cases.

That is a strong example because it shows what agents do better than static filters. The conversation can keep tightening around the buyer's real intent.

### 2. Repeat purchases and replenishment

Some purchases do not need a full evaluation every time. Think household staples, subscriptions, or replacement items. An agent can monitor price, reorder when inventory runs low, and only surface the choice when something important changes.

### 3. B2B procurement

[IBM](https://www.ibm.com/think/topics/agentic-commerce) highlights procurement and supply chain workflows as a natural fit. That makes sense. Many purchasing tasks are repetitive, rule-bound, and sensitive to price, vendor, and timing. An agent can compare approved suppliers, flag exceptions, and move routine orders forward faster.

### 4. Travel and other multi-step bookings

[Stripe](https://stripe.com/guides/agentic-commerce) uses a travel-style example: book the cheapest nonstop flight that lands before noon. That example works because it shows the agent handling a more complex constraint set, not just “find a product.” Flights, hotel stays, renewals, and other multi-step purchases are all good fits for agent-led workflows.

The common thread in these examples is not the industry. It is the job shape. Agentic commerce is strongest where the buyer has a clear goal, multiple variables matter, and the agent can reduce search and coordination work.

## Why brands care now

The category is still early, but it is no longer hypothetical.

[IBM](https://www.ibm.com/think/topics/agentic-commerce) says a 2026 IBM Institute for Business Value study found that 45% of consumers already use AI for part of the buying journey. [Shopify](https://www.shopify.com/blog/how-agentic-commerce-works) reports that AI-driven traffic to Shopify stores has grown 8x year over year since January 2025, while orders from AI-powered searches have increased 15x.

Those numbers matter because they point to a real operating change. The front door to commerce is no longer only a homepage, category page, or search box. It can also be a conversation inside ChatGPT, Copilot, Gemini, or another AI surface.

That changes what brands compete on.

If an agent is doing the discovery work, the brand with the best slogan does not automatically win. The brand with the cleanest structured data, the clearest pricing, the most reliable availability, and the fewest points of ambiguity has a better chance of being surfaced and selected.

This is one reason agentic commerce feels different from earlier AI waves. It pushes visibility and conversion closer to data quality, systems design, and trust signals.

## What infrastructure makes agentic commerce possible

Agentic commerce does not run on product pages alone.

It runs on structured systems that agents can read and act on.

At a minimum, that usually means:
- structured product data with consistent titles, attributes, variants, and category context;
- real-time pricing and inventory;
- shipping, return, and fulfillment details that can be interpreted programmatically;
- APIs or other machine-readable interfaces for catalog and checkout data;
- payment and approval logic that supports agent-led transactions safely.

[PwC](https://www.pwc.com/us/en/services/consulting/commercial-excellence/agentic-commerce.html) sums up the shift well: agentic commerce depends on clean, structured data, headless architectures, and APIs that expose real-time product, pricing, and availability information.

Catalog's own guide to [trusted data sources for agentic commerce](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce) pushes the same point from a product-data angle. Agents need machine-readable catalogs, live inventory, dynamic pricing, shipping details, return policies, and rich metadata. If they have to scrape inconsistent HTML and guess their way through missing fields, the experience gets worse for everyone.

This is also why checkout and policy systems matter as much as discovery. [Shopify](https://www.shopify.com/blog/how-agentic-commerce-works) makes this explicit in its explainer: once the agent finds the right product, the hard part is still verifying price, tax, fraud controls, payment, and fulfillment. For merchants, [Shopify Agentic Storefronts](https://www.getcatalog.ai/blog/shopify-agentic-storefronts) are one concrete path for making products available inside those AI shopping channels.

## How to prepare for agentic commerce

Most teams do not need to rebuild their entire stack tomorrow. They do need to get honest about where their current stack will fail if agents become a real acquisition and conversion path.

A practical starting checklist looks like this:

### 1. Audit product-data quality

Look at the basics first.

Are titles, attributes, variants, images, prices, and inventory signals complete and consistent? Can an external system interpret your catalog without a human cleaning it up first? If the answer is no, the problem starts there.

### 2. Expose machine-readable product and policy data

Agents need direct access to product facts, not just nicely written pages. That means thinking about APIs, structured feeds, policy endpoints, and data contracts that are legible to software, not only to shoppers.

### 3. Tighten payment, approval, and fraud rules

Not every purchase should be fully automated. Low-risk transactions might be. High-risk or high-value ones may still need explicit human approval. The right model is usually permissioned automation, not blind automation.

### 4. Treat returns, fulfillment, and service as part of the experience

Agentic commerce is not only about top-of-funnel discovery. An agent also needs to know whether the item can arrive on time, whether the merchant's return policy is clear, and whether the order can be supported after the sale.

### 5. Measure what agents are already doing

If AI surfaces are already sending traffic or orders, that should show up in your reporting. Start tracking visible referrals, [dark agentic commerce traffic](https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic) patterns, data-quality breakpoints, and which products convert well when discovery starts with an agent instead of a person.

## Where Catalog fits

Catalog fits best in the infrastructure layer.

If the bottleneck is [turning product information into live, structured, machine-readable data](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) that shopping agents can actually use, Catalog is built for that job. It provides live, normalized product objects from the open web.

That is the useful way to connect Catalog to this topic. Not as a vague AI promise. As the layer that helps make product data legible to systems that need to compare, rank, recommend, and transact.

## FAQ

### Is agentic commerce just AI shopping?

Not exactly. AI shopping is part of it, but the broader idea is that agents can take action across the buying journey. That can include discovery, comparison, payment, reordering, procurement, and post-purchase workflows.

### How is agentic commerce different from chatbots or product recommendations?

Chatbots and recommendation engines usually assist. Agentic commerce assumes the AI can carry out a multi-step task on the buyer's behalf. The difference is action, not only advice.

### Do brands need an agentic-commerce protocol to participate?

Not always, but they do need systems that agents can interact with reliably. Standards and protocols help because they reduce custom integration work, but the underlying requirement is still the same: structured data, clear rules, and accessible transaction systems.

### What data do AI shopping agents need most?

At a minimum: product attributes, variant data, pricing, inventory, shipping details, return policies, and other trust signals that help the agent compare options and complete a purchase safely.

### Will agentic commerce replace the merchant website?

No. Websites still matter. But they are no longer the only place where discovery and conversion can start. More of that activity can begin inside AI interfaces, which means brands need to support both the human-facing experience and the machine-readable one.

---

Canonical: https://www.getcatalog.ai/blog/what-is-agentic-commerce
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# AI search visibility for ecommerce: measure brands and products

*June 5, 2026 · Hamish Gunasekara · Business · 15 min*

> Learn how to measure ecommerce AI search visibility, verify product discovery, and improve the normalized data behind brand, citation, and SKU results.

AI search visibility has two jobs in ecommerce. Brand visibility asks whether an engine names your company, cites your site, or recommends your brand. Product visibility asks whether it surfaces the right product or SKU with a URL, price, and availability. A brand can earn mentions while priority products remain absent.

This guide gives ecommerce teams a repeatable loop: run fixed prompts across named engines on scheduled dates, record outcomes separately, connect results to product records and cited URLs, then compare changes with traffic, assisted conversions, and revenue. Fixes usually start in the normalized product data behind each result.

## AI search visibility for products at a glance

| If this is true on your site | What AI systems struggle with | What to fix first |
| --- | --- | --- |
| Your PDPs read well to humans but expose little structured product data | The system can describe the page, but it cannot reliably compare the product | Add machine-readable product and offer data, plus stable product URLs |
| Key attributes like material, fit, dimensions, compatibility, or use case are missing | The system cannot match your SKU to natural-language shopping prompts | Enrich the product record with the attributes buyers actually ask about |
| Sizes, colors, bundles, and packs are inconsistent across variants | The wrong SKU gets compared, or the model avoids the product entirely | Normalize variant relationships and label them clearly |
| Price and availability drift across the page, feed, and merchant sources | The offer looks unreliable or stale | Sync commercial data across every source AI can see |
| There is little proof beyond your own site | The model has less reason to trust the product details | Build reviews, retailer coverage, and third-party validation |
| You track one visibility score without its underlying results | You cannot tell whether a mention led to a recommendation or a product click | Report mentions, recommendations, citations, answer position, and SKU coverage separately |

## Brand visibility and product visibility answer different questions

Broad AI visibility measurement asks whether your brand appears in answers. It can show which engines mention you, which prompts create visibility, which competitors appear, and which sources get cited. Those are useful signals for brand and marketing teams.

Product visibility is more specific. It asks whether the right SKU appears for a product or use-case prompt, whether the answer points to the right product detail page (PDP), and whether the product has the facts needed to support the recommendation. A neutral brand mention is not a recommendation. A recommendation without a product or usable destination may not create a shopping opportunity.

For the broader measurement model, read our [AI visibility guide for ecommerce](https://www.getcatalog.ai/blog/ai-visibility-ecommerce). The operational layer beneath it is product discovery: measuring what surfaced and improving the data that an AI shopping surface can read.

## How AI shopping surfaces find product data

Start with your own product pages. They define the canonical product, the merchant, the current offer, and the destination a shopper should reach after the click. A page that sells well to humans is not automatically easy for software to trust.

That is where [structured product data](https://www.getcatalog.ai/glossary/schema-markup) matters. Google's [merchant listing structured data](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing) guidance shows the basic pattern machines need: a product entity, an offer, and clear merchant details in a standardized format. Google also explains that using product structured data alongside a Merchant Center feed can help it understand and verify product information.

The better working model is not that AI ignores webpages. Structured, comparable product data is easier for AI systems and shopping software to parse and verify than persuasive copy alone. Your PDP still matters. The product also needs to be legible as data. Those surfaces increasingly behave like [AI shopping assistants](https://www.getcatalog.ai/blog/ai-shopping-assistant-guide): they compare constraints, choose products, and hand shoppers back to a page or checkout.

Consistency matters just as much. If markup, feeds, and merchant systems disagree on price, availability, shipping, or returns, the offer starts to look unreliable. Merchant data is part of the commercial record, not an afterthought to the page.

ChatGPT's shopping results can use structured metadata from first-party and third-party providers. OpenAI also describes product feeds as an optional way for merchants to provide more control over product information. The [ChatGPT merchant page](https://chatgpt.com/merchants/) and [Product Feed documentation](https://developers.openai.com/commerce/specs/file-upload/products) describe the available submission path and formats. A feed gives a surface a cleaner input; it does not guarantee that a product will be shown or ranked.

You should also assume that first-party data will not carry the full load by itself. Reviews, retailer pages, and credible third-party coverage can confirm that the product is real and that its details hold up outside your own site.

## Discovery and submission: verify each surface without expecting a guarantee

There is no universal “submit to AI” button. A product can be eligible for a surface and still be left out of a particular answer. Treat discovery and submission as separate checks, then verify what the surface actually received.

| Surface or input | Prepare | Verify the received data |
| --- | --- | --- |
| Your site and web crawlers | Give every priority SKU a stable, indexable PDP URL. Keep the canonical URL consistent, avoid accidental `noindex` or blocked resources, and render the product identity and offer in the page's initial markup when possible. | Use your crawler, server logs, and an inspection tool to confirm the URL returns the intended product, can be fetched, and does not redirect to a category or a different variant. Record the canonical URL and the last product-data revision. |
| Product structured data | Mark up the product and its `Offer` with the visible name, image, identifier, price, currency, and availability. Use variant relationships that match the page and keep the markup current. | Run the page through the [Rich Results Test](https://search.google.com/test/rich-results) and compare the parsed values with the rendered PDP and checkout. A valid result means the markup can be read, not that a search feature will display it. |
| Google Merchant Center | Send a feed or Merchant API payload whose product link points to the specific PDP. Keep title, image, price, currency, availability, and variant data aligned with the page and structured data. | Check the feed fetch or API response, item diagnostics, and landing-page status in Merchant Center. Google says submitted data is checked against the landing page, so resolve mismatches before interpreting visibility changes. |
| ChatGPT Search | If a direct product feed is available to your business, provide the required fields and stable links through the official OpenAI process. If you rely on crawl-based discovery, keep the same product facts accessible on the PDP. | Save the feed acceptance or error response, then run a fixed shopping prompt in ChatGPT Search. Record the product card, exact URL, price, availability, and variant that ChatGPT actually shows. Acceptance is not inclusion, and inclusion is not a ranking guarantee. |

When a surface has a dashboard, use its fetch history, diagnostics, or product preview as the source of truth for what it received. When it does not, keep the submitted payload, request timestamp, response, rendered result, and cited URL together. This makes a missing SKU diagnosable instead of turning it into a guess about an algorithm.

## What information AI needs before it will trust a product

Most products do not disappear from AI answers because the prose is weak. They disappear because the system is missing the facts it needs to compare the item with confidence.

The first layer is **identity**:

- product name;
- brand;
- category;
- stable identifiers like SKU, MPN, or GTIN when available.

The second layer is **commercial state**:

- price and currency;
- availability;
- shipping and return context;
- merchant association.

The third layer is **decision-making attributes**. This is where many catalogs break down. Material, fit, use case, sizes, colors, and bundles are often the exact details a shopper puts into the prompt. Those fields need explicit values, not vague claims such as “premium” or “great for travel.”

The fourth layer is **variant logic**. A model needs to know whether two options are color variants, size variants, a refill, a bundle, or a different product entirely. If that relationship is muddy, the system may compare the wrong SKU or skip the product because it cannot tell which version matches the request.

The fifth layer is **proof**. Clean images help. Ratings and reviews help. Retailer consistency and third-party references help. AI systems are more comfortable surfacing products that look corroborated instead of isolated.

One practical rule matters here: prioritize attributes by category, not by spreadsheet convenience. If you sell apparel, fit, material, and weather use case move faster than another round of brand copy edits. If you sell supplements, ingredients, dosage, form factor, and restrictions matter more. If you sell hard goods, compatibility, dimensions, and included components usually matter first.

## Two illustrative before-and-after product record examples

The examples below are illustrative. They are based on the kinds of missing-attribute and variant problems we call out publicly, not on a named customer case study.

| Scenario | Before | After | Why it matters |
| --- | --- | --- | --- |
| Apparel PDP | Title: `Commuter Jacket`. Description: `Lightweight jacket for everyday wear.` Sizes and colors live in selectors. No material, weather use case, fit, waterproofing, or commute context. | Category: women's waterproof commuter jacket. Material: recycled nylon shell. Fit: relaxed. Weather: rain and wind. Features: taped seams, packable hood, reflective trim. Variants: sizes XS-XL, colors black/navy/olive. Price and stock exposed clearly. | A prompt like `best waterproof commuter jacket for rainy cities` now has concrete facts to match instead of vague copy. |
| Bundle / pack confusion | `Starter Kit` and `Starter Kit + Refill` share similar copy and images. No clear structured difference between the single item, the bundle, and the refill relationship. | Bundle type, included items, refill compatibility, unit count, and price per pack are separated into explicit fields. The parent-child relationship between the base product and the bundle is clear. | Software can stop confusing the single SKU with the bundle and choose the right offer for the prompt. |

The point is not to make the page sound smarter. The point is to turn a product listing into a product record that software can compare, trust, and reuse.

## What merchants usually get wrong first

Most merchants overestimate how much this is a content-marketing problem and underestimate how much it is a catalog-operations problem.

The common bad sequence looks like this:

1. buy a visibility tool;
2. collect a list of prompts;
3. rewrite a few descriptions;
4. wait for visibility to move.

The better sequence is usually the reverse:

1. choose the products and categories that already matter commercially;
2. fix the missing attributes and broken variant relationships on those products;
3. make sure offer data is current and consistent;
4. then measure which prompts and engines improve.

If you only have time for one pass, ignore the busywork. Do not start by generating dozens of speculative prompts or adding generic AI FAQ sections to every PDP. Start with the products that should already be winning and the fields buyers actually use to narrow choices.

## How to improve AI search visibility

The fastest way to improve AI search visibility is to work from the product-data layer out.

### 1. Fix the machine-readable layer

Make sure your product pages are indexable, canonical, and tied to stable URLs. Add clear product and offer markup. If the page is easy for people to read and hard for software to parse, visibility stays fragile.

### 2. Enrich the attributes shoppers actually ask about

Titles and descriptions are not enough. Use [product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) to add the fields that answer real buying prompts: material, fit, dimensions, compatibility, use case, ingredients, bundle contents, and other category-specific attributes.

### 3. Normalize variants and bundles

Do not leave software to infer whether `blue`, `XL`, `2-pack`, and `starter kit` are variants, bundles, or separate products. Make those relationships explicit.

### 4. Keep price and availability fresh everywhere

If the page, the feed, and the merchant source disagree, the product starts to look risky. Shopping systems are less likely to surface an offer they cannot trust.

### 5. Build corroboration around the product

First-party data matters most, but it is rarely enough by itself. Reviews, retailer listings, editorial mentions, and comparison coverage all help confirm that the product is real and that its details hold up outside your own site.

### 6. Measure prompt-level and SKU-level visibility

Once the product record is clean, measure where your products actually appear. Track prompts by use case, track which engines cite you, and track which URLs get surfaced. The measurement loop below turns those observations into product-data work.

## How to measure AI search visibility as an operating loop

The AI visibility software category exists for a reason. Brand-level monitoring matters. Merchants still need a product-level record of what appeared, where it appeared, and what happened next.

### Define the outcomes before running a prompt

Keep these outcomes separate. A single run can produce several of them, so do not collapse the result into one score before saving the raw evidence.

| Outcome | Count it when | Record with it |
| --- | --- | --- |
| **Brand mention** | The brand name appears in the answer, product card, or source list, whether the tone is neutral, positive, or negative. | Exact wording, context, engine, prompt, and raw response. |
| **Recommendation** | The engine explicitly suggests the brand or one of its products as a fit for the shopper's request. | The reason given, competing options, and whether the recommendation is brand-level or product-level. |
| **Citation** | The answer or product result shows a source URL or linked destination attributed to the result. | Full URL after redirects, source type, page title, and whether it is your PDP, category page, retailer page, or third-party page. |
| **Answer position** | The brand or product has an ordinal place in a list, carousel, or comparison. | Position, total visible results, surface type, and whether the answer is prose with no reliable ordinal. |
| **Product/SKU surfaced** | The exact product or variant appears as a named result, card, or linked destination that can be mapped to an expected SKU. | SKU, variant, canonical URL, price, availability, and any mismatch between the surfaced offer and your record. |

This vocabulary stops a brand mention from being reported as a product recommendation. It also lets merchandising teams see whether the issue is discovery, selection, source quality, or offer freshness.

### Build a repeatable prompt-and-engine run

Create a versioned prompt set that represents how shoppers actually ask for products. Include brand prompts, category prompts, use-case prompts, constraint prompts, comparisons, and product or SKU prompts. Keep the exact wording, market, language, currency, device, account state, and other relevant context with each prompt. A changed prompt is a new test, not a comparable run.

Choose engines and surfaces deliberately. A practical set might include ChatGPT Search, Google AI Overviews when they appear for the query, Gemini, Claude, and Perplexity. Record the exact engine, feature, model or mode shown, locale, and sign-in state. Do not combine a ChatGPT Search product result with a general ChatGPT answer under one channel name.

Run the same version of the set on scheduled dates and label each run with a timestamp, preferably in UTC. Repeat a prompt on separate runs when you need to distinguish a durable pattern from a one-off response. Save the raw answer or screenshot before annotating it. AI results can vary with time, context, personalization, inventory, and retrieval state.

For every run, capture:

- the prompt ID and exact prompt text;
- engine, surface, model or mode, locale, device, and account state;
- run date and timestamp;
- brand mention, recommendation, citation, answer position, and product/SKU outcome;
- every cited or linked URL, including its resolved canonical URL and page type;
- the expected SKU cohort and which exact variants surfaced;
- price, currency, availability, and other commercial values shown;
- raw output, screenshot, or product-card evidence.

### Map visibility to SKU coverage and business outcomes

Start with an expected SKU list for priority categories. Give each record a stable internal ID, SKU, variant, canonical URL, and product-data revision. For each run, mark whether the SKU surfaced, which source supplied it, whether a different variant was chosen, and whether price or availability was stale. This is where a normalized product-data layer turns a visibility observation into a fixable record.

Then connect the run to business outcomes. Track visible AI referrals, product-page sessions, add-to-cart events, checkout starts, purchases, revenue, and assisted conversions by product or category where your analytics can support it. Keep a baseline period and annotate product-data changes, feed updates, promotions, launches, and stock events. Some AI-origin discovery arrives without a clean referrer, a pattern covered in our guide to [dark agentic commerce traffic](https://www.getcatalog.ai/blog/dark-agentic-commerce-traffic), so visible referral sessions are a floor. Treat likely dark traffic as a labeled hypothesis, not confirmed attribution.

Catalog's normalized product-data layer gives this loop a useful control point. Store identity, attributes, variant relationships, offer state, provenance, and distribution revisions together. When a SKU disappears after a run, compare the cited URL and received feed payload with the product record revision. When a field or offer changes, rerun the same prompt cohort and look for movement in the separate outcomes. The result is a data-quality and distribution loop, rather than a dashboard number with no owner.

### Why AI visibility scores are not universal

An AI visibility score is a team's chosen index, not a universal property of the web. One score may count a brand mention in 100 prompts. Another may weight citations, recommendation language, answer position, and SKU coverage across several engines. Both can be internally useful while answering different questions.

Scores also change with the prompt mix, engine set, location, account state, date, sampling frequency, competitor set, and weighting rules. A score based on brand prompts cannot be compared directly with one based on product prompts. A score from ChatGPT Search cannot stand in for Google AI Overviews or Perplexity. Even the same prompt can return a different result on another run.

Keep a team score if it helps prioritize work, but publish the denominator and method beside it. Report raw counts and rates for each outcome, the prompt and SKU cohorts, engines, dates, cited URLs, and business outcomes. Compare your own versioned runs over time before comparing scores from different tools.

## Where Catalog fits

We built Catalog for the product-data layer behind AI commerce. Catalog structures and enriches product information, keeps product objects current, publishes machine-readable data to the surfaces that need it, and helps teams see what AI is doing with those records. It is a parallel layer for AI commerce, not a replacement for every storefront, PIM, or visibility tracker.

If the bottleneck is a missing attribute, an unclear variant relationship, stale offer data, or inconsistent channel payloads, fix the normalized product record first. Then use the same prompt, engine, URL, SKU, and outcome fields in your next measurement run. That is how broad brand visibility becomes an operational product-discovery program.

Three useful follow-on reads are already live:

- [Trusted Data Sources for Agentic Commerce](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce) maps the inputs shopping agents use.
- [Guide to Ecommerce Product Data Infrastructure](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) covers the product-data foundation.
- [Product Information Management Systems: PIM vs Catalog](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) explains how an AI-commerce layer can sit beside a traditional stack.

If your product data is fragmented across systems and surfaces, [talk to Catalog](https://www.getcatalog.ai/) about building the normalized layer behind your AI commerce workflow.

## FAQ

### How should I measure AI search visibility for ecommerce?

Create a fixed, versioned prompt set and run it across the same named engines and surfaces on scheduled dates. Record brand mention, recommendation, citation, answer position, and exact product/SKU surfaced as separate outcomes. Save cited URLs, product-card evidence, price and availability, expected SKU coverage, and the prompt's engine and locale. Compare those runs with product-page sessions, add-to-cart, purchases, revenue, and assisted conversions. Keep visible AI referrals separate from likely dark traffic, and do not treat one score as universal.

### What is the difference between brand visibility and product visibility?

Brand visibility measures whether an engine mentions, cites, or recommends your company. Product visibility measures whether it surfaces the correct product or variant for a shopper's request and sends the shopper to a usable destination. A brand can be visible while key SKUs are missing, linked to a category page, or shown with stale price and availability. Measure both levels and connect the product result to its normalized record.

### Does schema alone make products show up in ChatGPT?

No. Structured data helps expose the product clearly, but it is only one part of the job. You still need complete attributes, clean variants, current commercial data, and enough corroboration that the product looks trustworthy. A valid schema result does not guarantee inclusion or ranking in ChatGPT Search.

### What matters more, copy or attributes?

You need both, but they do different jobs. Copy helps frame the product. Attributes help software compare it. If you have to fix one thing first, fix the missing structured attributes that answer real buying prompts.

### Do I need a feed, structured data, or an API?

Most brands need more than one surface. Structured product pages and merchant or feed data are the baseline. APIs become useful when products need to be normalized, enriched, or consumed across agents and internal systems. Choose each delivery method based on what the destination can receive, then verify the actual payload and result.

### Why do some SKUs show up while others from the same brand do not?

Because AI visibility often breaks at the item level. The SKUs with better attributes, cleaner variant logic, fresher availability, and stronger external proof are easier to trust and easier to compare. A missing SKU can also reflect a surface's product-selection rules or a feed and page mismatch, so check the received data before changing copy.

---

Canonical: https://www.getcatalog.ai/blog/how-to-make-products-show-up-in-chatgpt
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# PIM vs DAM: Differences, Use Cases, and When You Need Both

*May 29, 2026 · Catalog Team · Business · 8 min*

> Compare PIM vs DAM in plain language. Learn what each system does, when to choose PIM, DAM, or both, and where AI-ready product data fits.

If you are comparing PIM vs DAM, start with the job you need the system to do.

A **PIM** helps you manage, enrich, and publish product information. A **DAM** helps you store, govern, and distribute digital assets like images, video, and brand files. If your biggest problem is messy product data, you usually start with PIM. If your biggest problem is broken media workflows, brand inconsistency, or asset chaos, you usually start with DAM.

Many commerce teams end up needing both.

That is where the confusion starts. Both systems can touch product content. Both can improve consistency. And some platforms blur the line by adding just enough overlapping functionality to make the comparison feel murky. But the real difference is still simple: **PIM manages product facts. DAM manages product and brand assets.**

## PIM vs DAM at a glance

| Dimension | PIM | DAM |
| --- | --- | --- |
| Primary job | Manage structured product information | Manage digital assets and asset workflows |
| What it owns | SKUs, specs, attributes, descriptions, pricing, variants, channel-ready product data | Images, video, design files, brand assets, usage rights, versions, approvals |
| Primary users | Ecommerce, merchandising, product-content, catalog, and operations teams | Marketing, creative, brand, content, and campaign teams |
| Best-fit problem | Product data is inconsistent, incomplete, or hard to syndicate | Assets are hard to find, hard to govern, or hard to reuse across channels |
| Main output | Accurate, enriched, publish-ready product information | Approved, searchable, channel-ready assets |
| Typical time-to-value | Faster when catalog data is the bottleneck | Faster when asset operations are the bottleneck |

## The real difference between PIM and DAM

A PIM and a DAM can both support product launches, but they are built for different kinds of work.

A [**PIM**](https://www.getcatalog.ai/glossary/pim) is the operating system for product information. It gives teams one place to collect product data, clean it up, enrich it, localize it, validate it, and publish it across channels. In practice, that usually means fields like titles, descriptions, specifications, dimensions, pricing, variants, taxonomy, and retailer-ready attributes.

A **DAM** is the operating system for digital assets. It gives teams one place to organize, tag, review, version, rights-manage, and distribute files such as product photography, brand imagery, video, creative files, PDFs, and campaign assets.

That sounds simple, but the confusion usually comes from overlap.

Some PIM platforms can store images. Some DAM platforms carry useful metadata. Neither of those facts makes the two systems interchangeable. If your team needs advanced search, rights management, review workflows, version control, or heavy reuse of media across markets and campaigns, a standalone DAM still does a very different job from a PIM.

The fastest way to explain it is this:
- **PIM = product facts**
- **DAM = product and brand files**

If you sell products across more than one channel, you usually need both kinds of control somewhere in the stack.

## How the day-to-day work changes

A PIM and a DAM also feel different because the teams using them are trying to accomplish different things.

With a **PIM**, the daily work usually sounds like this:
- collect product data from suppliers, ERPs, spreadsheets, and internal teams;
- enrich titles, descriptions, specs, and attributes;
- localize copy for different regions or channels;
- check completeness and approval status;
- push accurate product information to ecommerce sites, marketplaces, feeds, and retailers.

Success is measured in cleaner catalogs, faster launches, fewer listing errors, and less manual rework.

With a **DAM**, the daily work usually sounds like this:
- upload and tag images, video, and creative files;
- make approved assets easy to find;
- control versions and permissions;
- manage usage rights and brand consistency;
- distribute approved files to campaigns, retailers, partners, and content teams.

Success is measured in faster asset reuse, stronger brand consistency, lower legal risk, and less wasted creative effort.

That is why ownership often splits naturally.

If the loudest complaints come from merchandising or ecommerce, the answer often points toward PIM. If the loudest complaints come from marketing, creative, or brand teams, the answer often points toward DAM.

## Should you buy PIM, DAM, or both?

The best answer depends on the bottleneck that is already slowing the business down.

### Choose PIM if:
- product information is scattered across spreadsheets, ERPs, and ecommerce tools;
- your listings are inconsistent across channels;
- launches keep slowing down because attributes, specs, or descriptions are incomplete;
- your team needs stronger localization, enrichment, or syndication workflows;
- compliance-heavy or channel-specific product fields are hard to manage at scale.

### Choose DAM if:
- teams cannot reliably find the latest approved images, videos, or brand files;
- you struggle with asset version control, permissions, or rights management;
- visual quality and brand consistency are a bigger bottleneck than product specs;
- your asset library keeps growing across channels, campaigns, and teams;
- product launches break because the wrong files keep reaching the wrong places.

### Choose both if:
- you need accurate product information **and** strong asset governance;
- your product launches depend on matching the right specs to the right media;
- ecommerce, merchandising, marketing, and creative teams all touch the [same product experience](https://www.getcatalog.ai/blog/product-experience-management);
- one system alone would only solve half the problem.

This is also where the `DAM lite` question matters.

Some PIM vendors include basic asset storage. That can be enough if you only need a few product images attached to a catalog record. It usually falls short when your team needs broader asset search, richer metadata, approval workflows, rights controls, or heavy cross-channel asset reuse. In other words: storing an image is not the same thing as managing a media operation.

## What a good PIM + DAM handoff looks like

When both systems exist, they should not fight over every field.

A strong setup usually looks like this:
- **PIM** owns the structured product record: attributes, specs, pricing, variants, taxonomy, and channel-ready product content.
- **DAM** owns the asset library: photography, video, packaging files, brand assets, approvals, versions, and usage governance.
- The two systems connect through product IDs, metadata, and workflow rules so teams can match the right assets to the right products without manual cleanup every time.

That handoff matters more than people think.

If the systems are disconnected, teams end up checking product specs in one place and hunting for approved imagery in another. That slows launches, increases mistakes, and creates exactly the kind of brand inconsistency the stack was supposed to fix.

It also helps explain a related question: **PIM vs DAM vs CMS**.

A CMS publishes content experiences, such as product pages, landing pages, or brand pages. It is not usually the system of record for structured product data, and it is not a full digital asset governance system either. In most mature stacks, the CMS publishes what the PIM and DAM supply.

## Where Catalog fits

Catalog fits best when your real gap is not creative asset governance, and not only traditional internal catalog administration, but **AI-ready product data**.

If your team is evaluating classic internal catalog operations, start with the narrower question of whether a traditional PIM is still the right foundation. This guide on [Product Information Management Systems: PIM vs Catalog](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) is the better comparison for that decision.

If your challenge is making product data machine-readable for shopping agents, comparison workflows, AI search, or live product retrieval across the open web, Catalog is closer to a product-data layer than to a DAM. Catalog is built around live, structured product data, normalized fields, and infrastructure for agentic commerce.

That means Catalog is not a substitute for a DAM. It is also not a blanket replacement for every traditional PIM deployment. It is a stronger fit when the missing layer is structured product data for AI commerce.

## FAQ

### Is DAM the same as PIM?
No. A PIM manages structured product information. A DAM manages digital assets and the workflows around those assets.

### Can a PIM store images?
Yes, many can. But storing images is not the same as replacing a full DAM. If your team needs richer asset metadata, rights management, approvals, and broader media workflows, you will usually still want a dedicated DAM.

### Should ecommerce teams start with PIM or DAM?
Start with whichever bottleneck is causing more damage right now. If product data is slowing launches and breaking listings, start with PIM. If asset chaos is causing brand inconsistency and launch delays, start with DAM.

### How is CMS different from PIM and DAM?
A CMS publishes page content. A PIM manages product facts. A DAM manages digital assets. In most cases, the CMS is the presentation layer, while PIM and DAM are the systems supplying the underlying content.

---

Canonical: https://www.getcatalog.ai/blog/pim-vs-dam
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# PIM vs MDM for ecommerce: which do you need?

*May 27, 2026 · Catalog Team · Business · 12 min*

> Compare PIM vs MDM for ecommerce, map ERP, MDM, PIM, and channel roles, and choose an implementation path with clear ownership and handoffs.

Choosing between product information management (PIM) and master data management (MDM) depends on where your ecommerce data breaks. PIM makes product information complete, localized, and ready for each channel. MDM makes shared records, identifiers, and relationships trustworthy across the business. Choose MDM first when product records conflict between an enterprise resource planning (ERP) system, suppliers, and operations. Choose PIM first when identity is stable but listings lack attributes or channel-ready content. Choose both when both conditions apply. Catalog can sit beside either system as a product data layer for normalized, machine-readable outputs that support artificial intelligence (AI) commerce.

## PIM vs MDM: the direct comparison

PIM and MDM can both store product fields. Their decisions are different. PIM asks, “Can a customer understand and buy this product on every channel?” MDM asks, “Is this the same trusted product record wherever the business uses it?”

| Dimension | PIM | MDM |
| --- | --- | --- |
| Primary job | Collect, enrich, approve, localize, and publish product information | Match, deduplicate, govern, relate, and distribute trusted master records |
| Main scope | Product content, attributes, media references, variants, localization, and channel requirements | Product plus other domains such as customer, supplier, location, and organization data |
| Authoritative source | Usually the authority for customer-facing product content and channel versions | Usually the authority for shared identities, identifiers, relationships, and governed attributes |
| Typical owners | Merchandising, ecommerce, catalog, marketing, and product-content teams | Data governance, information technology, operations, finance, analytics, and stewardship teams |
| Key integrations | ERP or supplier inputs, digital asset management (DAM), commerce platforms, marketplaces, and feeds | ERP, customer relationship management (CRM), finance, supply chain, suppliers, PIM, analytics, and other enterprise systems |
| Main output | Complete, channel-ready product content | Reconciled records and relationships that other systems can trust |
| Best diagnostic signal | Products are identifiable, but content is incomplete, inconsistent, or slow to publish | Different systems disagree about what a product, supplier, or related entity is |
| Typical time to value | Often narrower and quicker when product identity and source data are already stable | Often broader and slower because match, merge, governance, and cross-system adoption take more coordination |

Neither row is a universal rule. Product MDM can include rich product content, and many PIM products include validation, matching, and workflow. The useful boundary is the decision the system owns and the teams that rely on its answer.

## What each system does in an ecommerce stack

An ecommerce stack has more roles than a PIM-versus-MDM label suggests. A clean implementation gives each system a defined responsibility and treats authority as field-specific.

- **ERP:** An enterprise resource planning system commonly holds operational facts such as internal item numbers, purchasing data, cost, inventory, and sometimes price. The exact owner varies by company and integration design.
- **MDM:** Master data management establishes canonical identities, matches duplicates, relates products to suppliers or locations, and governs shared fields that many teams need to use consistently. Catalog's [master data management glossary](https://www.getcatalog.ai/glossary/master-data-management-mdm) gives the concise definition.
- **PIM:** Product information management turns approved product inputs into useful content. Teams use it for titles, descriptions, specifications, merchandising attributes, translations, variant presentation, completeness checks, approvals, and channel mappings. See the [product information management glossary](https://www.getcatalog.ai/glossary/pim) for the core concept.
- **DAM:** A digital asset management system manages approved images, video, documents, rights, versions, and renditions. A PIM will often reference those assets rather than become their long-term file-of-record.
- **Commerce platform:** The platform renders the storefront, product detail pages, cart, checkout, and often the commerce address. It may receive product content from PIM and price or availability from ERP, inventory, or another offer system.
- **Marketplaces and feeds:** A marketplace applies its own product schema and validation. A feed is the destination-specific representation that carries product and offer fields to that marketplace or another channel. The feed is an output, not automatically the master record.
- **Catalog:** Catalog sits beside these systems as a product data layer. Catalog can normalize approved inputs, enrich product records, preserve structure and provenance, and distribute machine-readable product data for AI commerce surfaces and other destinations.

This division avoids a common mistake: calling one application the single source of truth for every field. A business may trust the MDM record for a global trade item number (GTIN), the ERP for inventory, the PIM for a localized product title, the DAM for image rights, and the commerce platform for a live storefront address. Each source is authoritative for a defined field or process.

## How product data moves from source to channel

Consider a retailer that receives a new running shoe from a supplier. A stock keeping unit (SKU) is the source-specific item key in this example. A workable architecture might use this flow:

| Step | System or handoff | Data work | Ownership at the handoff |
| --- | --- | --- | --- |
| 1 | Supplier and ERP into MDM | Ingest supplier SKU, internal item number, brand, GTIN, pack details, and source attributes | The source system owns the submitted values until MDM validates and matches them |
| 2 | MDM matching and mastering | Resolve duplicate items, assign a canonical product and variant identity, relate parent and child records, and apply shared taxonomies or units | MDM owns the canonical identity, crosswalk, relationships, and governed shared fields |
| 3 | MDM into PIM | Pass the canonical identifier, mastered attributes, variant structure, and approved relationships to the product-content workflow | MDM remains authoritative for the fields it owns; PIM can use them without rewriting them |
| 4 | DAM and supplier content into PIM | Add approved images, specifications, descriptions, translations, merchandising copy, and channel-specific attributes | PIM owns the customer-facing content and approval state; DAM retains asset and rights ownership |
| 5 | PIM, MDM, and offer systems into commerce | Join the product record to the storefront, price, availability, shipping, and purchase rules | Each source sends only the fields it owns; the platform renders and sells the offer |
| 6 | Commerce and product data outputs into channels | Map fields for marketplaces, search feeds, retail partners, and machine-readable destinations | Each destination receives a validated representation without becoming the system of record |

The sequence matters. **Normalization** makes equivalent values consistent, such as converting `0.75 L`, `750 ml`, and `750ml` into one typed volume with a display value. **Enrichment** adds approved information that makes the record usable, such as a material, fit, compatibility, or localized description. **Identifiers** connect the records: keep the supplier SKU and internal item number, add the canonical product or variant identifier, and preserve a GTIN or manufacturer part number when one exists. **Handoffs** should carry ownership and provenance with the field so a downstream editor knows where a change belongs.

Here is what field ownership could look like for that running shoe:

- MDM owns the canonical product identifier, parent-child variant relationship, brand identity, GTIN, and the approved link between the shoe and its supplier.
- The ERP or inventory system owns cost and available quantity when those systems are the operational source.
- PIM owns the customer-facing title, description, size and width labels, translated copy, channel taxonomy, and completeness state.
- DAM owns the approved product photography, usage rights, and image renditions. PIM stores the references needed to use them.
- The commerce platform owns the product page address and storefront presentation. The ERP or a dedicated offer system may still own price and inventory.
- Catalog can consume those approved records, normalize units and attributes, enrich the structured representation, and distribute a typed, machine-readable product object with its identifiers and provenance.

This is one model, not a universal placement of every field. The important rule is that a field has one deliberate writer. A system can read a field without claiming authority over it.

## The day-to-day difference

PIM work starts with the product experience. A merchandiser asks whether a new item has the required attributes, whether the title fits a marketplace limit, whether the translated description is approved, and whether the right image is attached for each region. The workflow ends in a product record that a storefront, marketplace, feed, or other channel can publish.

MDM work starts with trust between systems. A data steward asks whether two supplier items are the same product, whether a variant belongs to the correct parent, whether a location or supplier is duplicated, and which value should be distributed to finance, operations, analytics, and commerce. The workflow ends in a governed record and relationship that multiple applications can reuse.

The distinction also changes the integration conversation. PIM usually needs fast feedback from product teams and outbound mappings to selling channels. MDM usually needs match rules, stewardship queues, change approval, data-quality policies, and integrations with systems outside the storefront. A PIM project can be a narrow product-content rollout when the underlying identities are stable. An MDM project usually reaches further into the organization, so its implementation scope and adoption plan need to account for those dependencies.

## How to choose: diagnose the bottleneck

Start with the failure that creates the most rework. The answer should follow the record or workflow that needs a clear owner.

### When records conflict across systems

If the same item has different identifiers, brand values, pack relationships, or supplier associations in the ERP, supplier file, and commerce platform, address identity and reconciliation first. MDM is the usual first candidate because the business needs matching rules, a canonical record, and a governed way to resolve conflicts. A PIM can make the final content consistent while the underlying product identity remains disputed, so it should not be asked to solve an enterprise identity problem alone.

If the conflict is limited to two versions of customer-facing copy inside the commerce workflow, the problem is narrower. PIM workflow, approvals, and channel mappings may be enough.

### When product attributes are missing or inconsistent

If a product is identifiable but lacks dimensions, materials, compatibility, care instructions, or localized copy, PIM is usually the most direct place to collect, enrich, approve, and publish those fields. When supplier values use different units, labels, or category terms, add a normalization step before the content reaches every channel. Catalog can sit beside PIM or MDM to turn approved inputs into typed, normalized product data without taking ownership of the source record.

### When channel content is the bottleneck

If the same product needs different titles, descriptions, taxonomy values, variant labels, or required attributes for a storefront, marketplace, retail feed, and AI shopping surface, choose the system that can manage channel rules and content approvals. That is usually PIM for human-facing commerce content. Catalog can then distribute a machine-readable representation for destinations that need explicit fields, identifiers, relationships, and freshness signals.

### When governance is the bottleneck

If finance, operations, analytics, supply chain, and ecommerce cannot agree on the same product, supplier, customer, or location record, the work is broader than channel content. MDM provides a place to define stewardship, match and merge rules, relationships, approvals, and shared data policies. A PIM can remain the product-content workspace while MDM governs the shared fields it depends on.

### When implementation order is unclear

Sequence the work around dependencies rather than choosing a product by category label:

1. Establish product identity and source ownership if duplicates, missing identifiers, or conflicting records prevent downstream systems from agreeing on an item.
2. Add or expand PIM workflows when the identity is stable and the immediate gap is incomplete product content, localization, or channel publishing.
3. Add a product data layer when approved data still needs normalization, enrichment, machine-readable distribution, or AI commerce readiness across destinations.
4. Extend MDM governance to other domains or deeper relationships when the business needs the same trusted model for suppliers, customers, locations, or operations.

The order can change. A business with clean ERP identifiers and an urgent launch may begin with PIM. A business with duplicate item masters should resolve identity and governance before investing in channel polish. A business with both problems can run the workstreams in parallel as long as the field owners and handoffs are documented.

### Choose PIM first when:

- products are already identifiable, but listings are missing attributes, media references, translations, or channel-specific copy;
- merchandising and ecommerce teams spend too much time fixing spreadsheets or repeating content work;
- the near-term outcome is a complete product experience across the storefront, marketplaces, feeds, or retail partners;
- approvals, localization, and channel rules are the main workflow gaps.

### Choose MDM first when:

- product, supplier, customer, or location records disagree across systems;
- duplicate records or weak identifiers undermine reporting, operations, finance, or fulfillment;
- the business needs shared governance, stewardship, lineage, and relationships beyond the storefront;
- an acquisition, regional expansion, or system change has made the master-data model unreliable.

### Choose both when:

- the business needs trusted product identity across enterprise systems and rich content across selling channels;
- MDM must govern identifiers, relationships, and shared attributes while PIM manages copy, localization, media references, and channel readiness;
- multiple business units share products but need different markets, languages, assortments, or channel versions;
- the organization can assign separate owners and a controlled handoff instead of asking two systems to write the same field.

## How PIM and MDM coexist without competing for fields

PIM and MDM work together when their boundaries are explicit. MDM does not need to author every sentence a shopper reads. PIM does not need to decide whether two supplier records represent the same legal or product entity.

A practical ownership matrix might look like this:

| Data concern | Likely owner | Downstream use |
| --- | --- | --- |
| Canonical product and variant identifiers | MDM or a governed item master | Joins, deduplication, relationships, and system-wide references |
| Shared identity, brand, units, and core relationships | MDM, with approved source systems | ERP, PIM, commerce, analytics, and operations |
| Customer-facing descriptions, translations, and merchandising attributes | PIM | Storefront, marketplace, retail, and feed content |
| Image files, rights, and renditions | DAM | PIM references and channel delivery |
| Price, inventory, and fulfillment state | ERP, inventory, or offer system | Commerce and channel offers |
| Machine-readable normalized product output | Catalog or another designated product data layer | AI shopping surfaces, feeds, and structured destinations |

The exact owner can differ. The control pattern should not:

1. Assign one system as the writer for each field.
2. Pass canonical identifiers and relationship keys with every handoff.
3. Mark mastered fields read-only in downstream tools where possible.
4. Route corrections back to the owning system instead of editing a downstream copy.
5. Keep one-way publication paths where they prevent sync loops, and document the exception when a destination must return a status or approval.

This is a more useful interpretation of “single source of truth.” A stack can have several authoritative sources, as long as each field has one accountable owner and every downstream representation can be traced back to it.

## Where Catalog fits beside PIM and MDM

Catalog is a product data layer for the space between approved source records and the destinations that need to read them. Catalog can sit alongside an existing PIM, MDM, ERP, or commerce platform rather than asking that system to become something else.

Catalog is useful when you need to:

- **Normalize:** map supplier and system variations into consistent, typed attributes while retaining the source value and provenance;
- **Enrich:** structure approved product information into the facts, relationships, and context that a destination needs to interpret it;
- **Distribute:** publish machine-readable product data for feeds, structured destinations, and AI shopping surfaces;
- **Prepare for AI commerce:** make product identity, variants, attributes, offers, and freshness explicit enough for shopping agents and other machine-facing experiences.

That role complements PIM's content workflow and MDM's governance model. Catalog does not need to replace either one to add value. If you are comparing a product data layer with a traditional PIM workflow, see [Catalog vs traditional PIM systems](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems).

## FAQ

### Is PIM the same as MDM?

No. PIM manages product information for merchandising, localization, enrichment, approval, and channel publishing. MDM governs trusted master records, identities, relationships, and shared attributes across one or more domains. Some products overlap, so compare the ownership model and workflow rather than the feature names alone.

### What is the difference between PIM, MDM, and ERP?

An ERP is an enterprise resource planning system for operational and transactional processes such as purchasing, finance, item setup, and inventory. MDM reconciles and governs records that multiple systems need to trust. PIM turns product information into complete, customer-facing content for channels. An ERP may supply a PIM or MDM, and a PIM or MDM may send approved data back into commerce or operations. They are connected roles, not interchangeable labels.

### Which should be implemented first, PIM or MDM?

Implement the system that resolves the first blocking dependency. If duplicate products, missing identifiers, or conflicting cross-system records make it impossible to agree on what an item is, establish MDM or another governed identity process first. If product identity is stable and the gap is missing attributes, localization, approvals, or channel content, implement PIM first. Add both in coordinated phases when identity and content are blocking one another.

### Which system should be the system of record for product data?

There is no responsible universal answer. Assign authority by field and process. MDM may own canonical identity, GTIN, and relationships; an ERP or inventory system may own stock and cost; PIM may own customer-facing copy and localization; DAM may own image rights; and a commerce platform may own storefront addresses. Document the owner, downstream readers, update path, and approval rules for each important field.

### Can you start with PIM and add MDM later?

Yes, when product identities and key source records are already stable enough for a content workflow. Start with PIM if channel readiness is the immediate constraint, then introduce MDM as the business needs cross-domain governance, more system relationships, or a shared master-data model. If the current catalog contains duplicates or conflicting identities, postponing that governance can create more downstream cleanup.

### What are the four common MDM implementation styles?

The four common styles describe where mastered data lives and how much authority the MDM hub has:

- **Registry:** MDM indexes and links records from source systems. Sources keep ownership, while the registry provides cross-references and a view across systems.
- **Consolidation:** MDM collects records into a hub for matching, reporting, or analytics. Source systems continue to own the operational records.
- **Coexistence:** MDM and source systems share stewardship. The hub and participating systems exchange governed changes under defined synchronization rules.
- **Centralized:** MDM owns the mastered record and distributes approved values to downstream systems. This provides the clearest hub authority and requires the broadest adoption of the hub's processes.

These styles are architecture choices, not a ranking. The right choice depends on source-system authority, governance maturity, integration scope, and how much change the organization can absorb.

### How does Catalog fit if your organization already has a PIM or MDM?

Catalog can consume approved product inputs from those systems, normalize and enrich the data for machine-facing use, and distribute structured outputs while the existing systems retain their field ownership. Catalog is a complementary product data layer for AI commerce readiness and other destinations that need explicit, current product facts.

---

Canonical: https://www.getcatalog.ai/blog/pim-vs-mdm
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Product Information Management Systems: PIM vs Catalog

*May 25, 2026 · Catalog Team · Business · 8 min*

> Learn what product information management systems do, when traditional PIMs are the right fit, and where Catalog differs for AI commerce and live product data.

If you are comparing product information management systems, start with the job you need the system to do.

Traditional PIMs are built to centralize product data, clean up messy catalogs, manage approval workflows, and push consistent product content across ecommerce channels. They are still the right answer when your biggest problem is catalog governance.

Catalog solves a different problem. It gives brands a parallel, AI-ready product data layer so ChatGPT, Gemini, Claude, Perplexity, and other AI shopping surfaces can understand what you sell without forcing a storefront rebuild.

That usually leaves you with one of three paths:

| If your biggest problem is... | Best fit |
| --- | --- |
| Coordinating thousands of SKUs, translations, channel exports, and internal approvals | A traditional PIM |
| Getting accurate, live product data into AI shopping surfaces | Catalog |
| Both of the above | Keep the PIM for internal operations and use Catalog for the AI layer |

## What product information management systems actually do

A traditional product information management system is the operating system for market-ready product content. It brings product data into one place, helps teams enrich and validate it, and pushes consistent information out to the channels that matter.

In practice, that usually means a PIM manages:

- product titles, attributes, and technical specs
- product images, videos, and related assets
- pricing and sales content used in listings or catalogs
- taxonomy, variants, bundles, and relationships
- localized copy for regions, languages, and retailers
- channel-ready product content for websites, marketplaces, distributors, and print or [digital catalogs](https://www.getcatalog.ai/glossary/digital-catalog)

Common examples of traditional product information management systems include Akeneo, inriver, Informatica Product 360, Salsify, Syndigo, SAP, and Stibo Systems. The category is mature because the problem is real: once a catalog gets large, multichannel, and global, product content gets messy fast.

It also helps to separate PIM from nearby systems:

- **ERP** manages operational and transactional data like inventory, orders, and financials.
- **DAM** manages files such as images, videos, and PDFs; [PIM vs DAM](https://www.getcatalog.ai/blog/pim-vs-dam) is the better comparison when the question is product content versus digital assets.
- **MDM** governs master data across the business, not just product content; [PIM vs MDM](https://www.getcatalog.ai/blog/pim-vs-mdm) matters when the question is product enrichment versus enterprise data governance.
- **PIM** sits closer to merchandising and distribution. Its job is to make product information accurate, usable, and ready to publish.

## When a traditional PIM is the right choice

A traditional PIM is usually the right move when internal catalog operations are the bottleneck.

That is especially true if several of these sound familiar:

1. Your product data still lives across spreadsheets, ecommerce tools, ERPs, and shared drives.
2. You sell across more than one channel and each channel needs different formatting.
3. Product launches keep slowing down because teams are chasing missing attributes, approvals, or assets.
4. You need multi-language or multi-region product content.
5. Listing errors are creating bad customer experiences, returns, or internal rework.
6. Merchandising, marketing, ecommerce, and operations all need one governed product source of truth.

This is where [traditional PIM systems](https://www.getcatalog.ai/glossary/pim-system) earn their keep. They are strong at structure, workflow, localization, syndication, and process control. If your problem is that your product content operation is too manual, too fragmented, or too hard to scale, a traditional PIM can be the right foundation.

## Where traditional PIM systems start to struggle for AI commerce

Traditional PIMs were built for managed catalogs and planned distribution. AI commerce changes the shape of the problem.

In an [agentic commerce](https://www.getcatalog.ai/blog/what-is-agentic-commerce) workflow, the system is no longer only preparing product content for a human-run channel. It may need to support live recommendations, variant-aware answers, machine-readable policies, and continuous updates across AI shopping surfaces.

That creates requirements that many traditional PIM implementations handle only indirectly:

- **Freshness matters more.** AI systems need current price, stock, and variant data, not just a clean scheduled export.
- **Output shape matters more.** Agents need structured, machine-readable product objects, not only merchandising copy and channel feeds.
- **Measurement changes.** Teams need to know where AI is surfacing products, what is getting skipped, and how AI-driven traffic behaves.
- **Control changes.** Brand teams need reviewability and channel-level control for AI surfaces, not only internal approvals.

Many traditional PIM vendors now add [AI-assisted product data enrichment](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) or automation. That can help teams move faster. It is not the same thing as giving agents live, [machine-readable product data](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce), reviewable changes, and clear distribution controls.

That does not mean traditional PIMs are obsolete. It means the main job may have shifted. If your core challenge is AI discoverability, live structured data, and AI-surface distribution, a traditional PIM by itself is often not the most direct answer.

## Product information management systems vs Catalog

The easiest way to compare the two is to look at the primary job each system is built to do.

| Criteria | Traditional PIM | Catalog |
| --- | --- | --- |
| Primary job | Centralize, enrich, govern, and syndicate product content across channels | Give brands a parallel AI-ready product data layer for AI commerce |
| Data freshness | Often tied to managed imports, exports, and channel workflows | Built around live structured data, continuous sync, and AI-readable outputs |
| Output | Market-ready product content and channel-specific feeds | AI storefront data, structured product objects, and AI-surface distribution |
| Implementation model | Usually part of the core merchandising and catalog stack | Runs as a parallel layer, so nothing has to change on the existing storefront |
| Governance | Strong internal workflows and approvals | Reviewable enrichments plus allowlist / blocklist control by AI surface |
| Analytics | Usually focused on catalog quality, channel publishing, or operational reporting | Focused on AI referrals, surfacing rate, completeness, and distribution coverage |
| Best fit | Complex internal product-content operations | Brands that need to be legible to AI shopping systems without rebuilding their site |

The important nuance is that Catalog is not a one-for-one replacement for every traditional PIM deployment. If your team needs deep internal catalog governance, localization workflows, retailer syndication, and broad cross-functional product operations, a PIM still makes sense.

Catalog becomes the stronger fit when the missing layer is AI readiness.

## Should Catalog replace your PIM or sit beside it?

For most teams, the best answer is one of these three:

### Choose a traditional PIM first

Start with a traditional PIM if your internal product operation is broken. If data is scattered, product launches are delayed, and teams do not trust the same source of truth, fix that first.

### Choose Catalog first

Start with Catalog if your main goal is to make your brand legible to AI shopping systems, publish structured product data without changing your storefront, and measure what AI is actually doing for you.

This is especially true if you do not have a massive internal catalog-operation problem and do not want to take on a long PIM implementation before you can improve AI visibility.

### Use both

This is the most realistic path for many larger brands.

A traditional PIM can remain the internal system for product enrichment, localization, and governance. Catalog can then sit beside it as the AI-commerce layer that publishes AI-ready product data, keeps information live, and gives the team control and visibility across AI surfaces.

If you already have a PIM, this is usually the fairest evaluation question to ask: **do we need to replace the PIM, or do we need a new downstream layer for AI commerce?**

## How to evaluate product information management systems in 2026

If you are actively comparing systems, use a checklist that reflects the job you need done, not just the longest feature list.

Ask these questions:

1. **What is the source of truth?** Does the system really centralize product information, or does it just add another layer of operational complexity?
2. **How does it handle variants, localization, and approvals?** These are table stakes for traditional PIM use cases.
3. **How well does it integrate with the rest of your stack?** ERP, DAM, ecommerce platform, CRM, and any downstream publishing systems all matter.
4. **How does content get distributed?** Is the system designed for channel feeds, for AI-readable outputs, or for both?
5. **How fresh is the data at the moment of recommendation?** This matters much more once AI systems are part of the buying flow.
6. **What does AI readiness actually mean in the product?** Look for live structured outputs, reviewability, measurable distribution, and policy-aware product data, not just an "AI" label on enrichment features.
7. **How much implementation burden are you taking on?** Some systems belong at the center of the merchandising stack. Others work better as a parallel layer that solves one urgent job fast.

Buyers get into trouble when they buy a classic PIM to solve an AI-commerce problem, or when they try to use an AI-commerce layer to solve a deep internal catalog-operations problem. Once you know where the bottleneck sits, the system choice usually gets much easier.

## Frequently asked questions about product information management systems

### What is a product information management system?

A [product information management system](https://www.getcatalog.ai/glossary/pim) is software that centralizes, enriches, governs, and distributes product content across sales and marketing channels.

### Is a PIM the same as ERP or DAM?

No. ERP manages operational and transactional data. DAM manages digital files. A PIM manages market-ready product information and connects those systems when needed.

### What are examples of PIM systems?

Common examples include Akeneo, inriver, Informatica Product 360, Salsify, Syndigo, SAP, and Stibo Systems.

### Can a traditional PIM support AI shopping channels?

It can help, especially if it already owns clean product content. But many AI-commerce use cases also need live structured data, AI-surface control, and measurement, which often requires another layer.

### Can Catalog work with an existing PIM?

Yes. For many brands, that is the most practical setup: keep the traditional PIM for internal catalog operations and use Catalog for the AI-commerce layer.

## The simplest decision rule

If your biggest problem is internal product-data operations, choose a traditional PIM.

If your biggest problem is making your catalog understandable to AI shopping systems, choose [Catalog](https://www.getcatalog.ai/).

If both problems are real, keep the PIM and let Catalog handle the AI layer.

---

Canonical: https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Trusted Data Sources for Agentic Commerce

*May 6, 2026 · Hamish Gunasekara · Business Intelligence · 7 min*

> Explore trusted data sources for agentic commerce and what AI shopping agents need from catalogs, APIs, and machine-readable product data at scale.

## What Is Agentic Commerce and Why It Matters

Agentic commerce is an AI-driven retail paradigm where autonomous agents manage buying end-to-end — from interpreting customer intent to payment and delivery — enabling coordinated interaction among consumers, businesses, and agents (see [TechRepublic](https://www.techrepublic.com)). The Agentic Commerce Protocol (ACP) provides open standards that let agents, people, and businesses interoperate (see [OpenAI](https://openai.com)).

Unlike human-driven browsing, agentic systems parse natural language, compare products across retailers, and execute purchases autonomously. Current usage patterns show the potential: ChatGPT processes billions of prompts daily, with a measurable share about purchasable products (see [Digital Commerce 360](https://www.digitalcommerce360.com)), which implies millions of agent-mediated purchase opportunities.

| Traditional E-commerce | Agentic Commerce |
| --- | --- |
| Human browsing and searching | AI agent product discovery |
| Manual price comparisons | Automated cross-retailer analysis |
| Click-through purchasing | Natural language transactions |
| Static product pages | Dynamic, contextual recommendations |
| Individual retailer focus | Multi-vendor orchestration |

Agentic commerce delivers adaptive personalization, real-time optimization, and the ability to handle complex, multi-step purchases that traditional interfaces struggle with.

## Core Data Sources Powering Agentic Commerce

Agentic commerce depends on comprehensive, structured, and API-accessible data: machine-readable product catalogs (JSON/GraphQL), real-time inventory, dynamic pricing, shipping and fulfillment details, return policies, and rich product metadata (see [HumanSecurity guide](https://humansecurity.com)). These feeds must be consistently formatted and able to sustain high-volume, low-latency agent queries.

Data volume and update frequency matter: large catalogs (e.g., Walmart's hundreds of millions of SKUs) require platforms that support instant updates and real-time access (see [Digital Commerce 360](https://www.digitalcommerce360.com)). Typical platform roles include:

| Platform | Primary Function | Agentic Commerce Strengths | Typical Use Cases |
| --- | --- | --- | --- |
| Databricks | Big Data Analytics | Real-time processing, ML model training | Customer behavior analysis, demand forecasting |
| Snowflake | Data Warehousing | Scalable storage, fast queries | Centralized product catalogs, historical analytics |
| Apache Airflow | Pipeline Orchestration | Automated data workflows | Inventory updates, price synchronization |
| Kafka | Stream Processing | Real-time data streaming | Live inventory feeds, pricing updates |
| Elasticsearch | Search & Analytics | Fast product discovery | Agent-powered search, recommendation engines |

Combine these tools to create an ecosystem where Databricks processes transactions and behaviors, Snowflake stores catalogs at scale, Airflow orchestrates pipelines, Kafka streams live updates, and Elasticsearch enables rapid discovery. That same structured approach is what delivers [better search results](https://www.getcatalog.ai/blog/search-merchandising) when retailers want AI systems to surface the right products. The key differentiator for agentic commerce is machine-optimized formats with standardized attributes, availability signals, and metadata rather than human-readable pages alone.

## Leading Frameworks for Building Agentic AI Systems

Agentic frameworks coordinate autonomous agents, data feeds, and commerce APIs. Choose components that support orchestration, data retrieval, and secure enterprise integration.

- LangChain: strong for data integration and composing workflows that chain multiple operations.
- LlamaIndex: optimized for retrieval and fast contextual search across large catalogs, useful in MLOps.
- Semantic Kernel: enterprise-focused, secure, and integrates with legacy systems.
- AutoGen vs. CrewAI: AutoGen excels at real-time, concurrent interactions; CrewAI offers an easier entry point for prototypes.

| Framework | Primary Strength | Best Use Cases | Deployment Complexity |
| --- | --- | --- | --- |
| LangChain | Data integration & workflows | Complex purchasing flows | Medium |
| LlamaIndex | Retrieval & search | Product discovery | Low-Medium |
| Semantic Kernel | Enterprise integration | Large-scale deployments | High |
| AutoGen | Real-time collaboration | Live negotiations | High |
| CrewAI | Ease of use | Prototype development | Low |

Often these frameworks are combined: use LlamaIndex for retrieval, LangChain to orchestrate steps, and Semantic Kernel to secure enterprise connections.

## Steps to Integrate Trusted Data into Your Agentic Commerce Stack

A repeatable integration process minimizes risk and accelerates deployment.

**Infrastructure Assessment and Planning**
Catalog existing sources, APIs, and formats; measure data quality, update cadence, and access patterns to identify gaps and conversion needs.

**Framework Selection and Architecture Design**
Select tools based on real-time needs, scale, and integration complexity; design an architecture that supports growth and reliability.

**Data Structure Conversion and API Development**
Convert or build machine-readable catalogs (standardized schemas), implement real-time inventory feeds, and expose lightweight APIs with fields for [price and availability](https://www.getcatalog.ai/blog/price-monitoring-api), shipping options, and return policies (see [HumanSecurity](https://humansecurity.com)).

**Agent Integration and Testing**
Connect agents to APIs with fast endpoints, and run synthetic tests and load scenarios to validate accuracy and performance under expected conditions.

**Monitoring and Operational Excellence**
Deploy dashboards, alerts, and audit trails to monitor agent activity, API health, and data quality; train incident responses and rollback paths.

Following these phases ensures agents receive reliable, timely data and that systems remain operable at scale.

## Best Practices for Data Privacy and Compliance in Agentic Commerce

Privacy-by-design and robust governance are essential as agents handle sensitive transactional and personal data.

- Human-in-the-loop: Implement oversight for high-value or unusual decisions to boost trust and control (see [Tkxel](https://tkxel.com)).
- Model Context Protocol (MCP): Use standardized gateways for secure, auditable agent access to enterprise resources (see [NetSolutions](https://netsolutions.com)).
- Data Minimization: Restrict agents to only the data they need.
- Encryption: Apply end-to-end encryption across communications.
- Access Controls: Enforce granular permissions by agent role.
- Audit Logging: Keep comprehensive, tamper-evident logs of agent activity.
- Consent Management: Record and honor customer consent for agent actions.
- Cross-Border Compliance: Address international transfer rules (GDPR, CCPA).
- Incident Response: Define procedures for breaches or agent failures.

Additionally, document retention policies, customer rights handling, and clear disclosures about agent capabilities to maintain compliance and customer trust.

## Measuring Success: Analytics and Optimization for AI-Powered Agents

Measure agentic commerce with both traditional KPIs and agent-specific indicators, then iterate.

Key metrics:

- Transaction Performance: conversion rate, cart abandonment, completion time.
- Operational Efficiency: API latency, data freshness, uptime.
- Agent Effectiveness: task completion, escalation rate, error frequency.
- Customer Experience: satisfaction, repeat usage, recommendation accuracy.
- Compliance & Security: policy adherence, audit completeness.

| Metric Category | Key Indicators | Optimization Focus |
| --- | --- | --- |
| Transaction Performance | Conversion rate, cart abandonment, purchase completion time | Agent decision-making accuracy |
| Operational Efficiency | API response times, data freshness, system uptime | Infrastructure optimization |
| Agent Effectiveness | Task completion rate, escalation frequency, error handling | Agent training and refinement |
| Customer Experience | Satisfaction scores, repeat usage, recommendation accuracy | Personalization and service quality |
| Compliance & Security | Policy adherence, audit trail completeness, privacy compliance | Risk management and governance |

Operational dashboards should surface real-time agent behavior, data quality issues, and compliance flags. Use synthetic testing to stress scenarios (high traffic, data loss, edge cases) and continuous feedback loops to refine agent policies, models, and data schemas.

## Preparing for the Future of Agentic Commerce and AI-Driven Retail

AI agents are shifting discovery from SEO to AEO (Agent Engine Optimization), requiring product data optimized for agent consumption (see [MissionCloud](https://missioncloud.com)). Predictions include widespread personal AI assistants negotiating and purchasing continuously, which demands infrastructure that supports millions of concurrent agent interactions (see [McKinsey](https://mckinsey.com)).

Market potential: with modest conversion rates on high-intent queries, daily agentic orders could reach millions (see [Digital Commerce 360](https://www.digitalcommerce360.com)), stressing the need for elastic, resilient data platforms.

**Emerging Opportunities:**

- Personalized Agent Services: agents tailored to budgets and tastes.
- B2B Agent Networks: procurement agents for complex purchases.
- Cross-Platform Integration: agents operating across retailers and marketplaces.
- Predictive Commerce: agents anticipating needs and pre-positioning stock.
- Negotiation Automation: real-time price and terms negotiation.

**Preparation Strategies:**

- Run pilots to validate agent interactions with existing systems.
- Invest in continuous learning for engineering and product teams.
- Partner with agentic commerce platform providers.
- Develop agent-optimized product schemas and APIs.
- Establish governance and risk frameworks for autonomous agents.

Early adopters that invest in agent-tuned data, APIs, and governance will gain a head start in converting agent-driven demand into reliable revenue.

## Frequently Asked Questions About Agentic Commerce Data Sources

### What is agentic commerce?

Agentic commerce is online shopping where AI agents discover, compare, and purchase products on a consumer's behalf, often using natural language and predefined preferences to act autonomously.

### How does agentic commerce work?

Agents access structured, real-time data via APIs, compare offers, and execute purchases according to rules and user preferences; orchestration layers and protocols coordinate multi-agent workflows and transactions.

### What types of data are most important for agentic commerce systems?

Critical data includes structured product catalogs, real-time inventory, dynamic pricing, shipping and return policies, and product specifications, all in machine-readable formats like JSON or GraphQL.

### Why are trusted data sources crucial for agentic commerce?

Trusted sources prevent incorrect purchases and failed transactions by ensuring agents have accurate, timely information; poor data quality directly undermines agent effectiveness and customer trust.

### How can businesses ensure data privacy in agentic commerce?

Apply privacy-by-design, encryption, granular access controls, audit logging, consent management, and human-in-the-loop checks while complying with regulations like GDPR and CCPA.

### What are leading frameworks and tools for agentic commerce integration?

Common choices include LangChain (workflows), LlamaIndex (retrieval), Semantic Kernel (enterprise integration), and AutoGen or CrewAI for multi-agent scenarios; selection depends on scale and use case.

### How are results measured and optimized in agentic commerce stacks?

Use conversion and operational metrics plus agent-specific KPIs, monitoring via dashboards and synthetic tests, and iterate with feedback loops to refine agents, models, and data pipelines.

---

Canonical: https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Ecommerce product data: Fields, feeds, and AI readiness

*April 28, 2026 · Catalog Team · Business · 17 min*

> Learn what ecommerce product data includes, how to structure and validate it, and how to connect catalogs to feeds, structured data, and AI shopping.

Ecommerce product data answers a simple question: what exactly is this item, and can every system trust the answer? The record behind a product page also drives filters, search, inventory, feeds, marketplaces, and AI shopping. When it is incomplete or inconsistent, each surface tells a different story.

A durable product-data operation gives every item a canonical record, clear ownership, controlled values, and a reliable path to each destination. Here is the working model, from fields and identifiers to validation, feeds, structured data, and AI-shopping readiness.

## What ecommerce product data means

Ecommerce product data is the set of facts, content, assets, relationships, and commercial signals used to describe, sell, fulfill, and distribute a product online. It includes the visible copy on a product detail page and the less visible fields that make a product searchable, comparable, and eligible for a channel.

A useful product record answers seven questions:

1. **What is it?** Name, brand, category, description, and product type.
2. **Which item is it?** SKU, GTIN, MPN, product ID, variant ID, and canonical URL.
3. **What is it like?** Material, color, dimensions, ingredients, compatibility, fit, and other category attributes.
4. **Which version is it?** Size, color, pack, configuration, bundle, or other variant relationship.
5. **Can I buy it now?** Price, currency, availability, inventory, condition, and region.
6. **What will I receive?** Images, video, included components, shipping, returns, warranty, and compliance details.
7. **Why should a system choose it?** Use cases, benefits grounded in facts, reviews, relationships, and provenance.

Product data is the raw material for a [product catalog](https://www.getcatalog.ai/glossary/product-catalog). Product content is the customer-facing expression of that data. A product feed is a destination-specific output. A PIM is one possible system for governing the records. Keeping these terms separate prevents a feed or storefront from becoming an accidental source of truth.

### Why the business role extends beyond the product page

Product data connects teams and surfaces that used to operate separately:

- **Discovery:** Search, facets, recommendations, category pages, shopping results, and AI prompts use attributes to match products to intent.
- **Purchase confidence:** Clear dimensions, fit, ingredients, compatibility, care, and policies answer the questions that create hesitation and returns.
- **Operations:** SKUs, variants, inventory, supplier details, and fulfillment fields support planning, picking, reporting, and support.
- **Distribution:** Marketplaces, retailers, ad platforms, affiliates, and social catalogs each consume a mapped version of the same product facts.
- **Machine interpretation:** Structured fields let software compare products without guessing from a long paragraph or an image.

[Google's ecommerce documentation](https://developers.google.com/search/docs/specialty/ecommerce/share-your-product-data-with-google) describes product data as attributes such as title, description, color, pricing, and availability. It recommends combining product structured data on product pages with direct data sharing through Merchant Center when appropriate. That pairing reflects the practical reality: a human-facing page and a machine-facing record have to agree.

## A practical ecommerce product data model

Start with a shared core record, then extend it by category and destination. Apparel needs fit and fabric. Electronics need ports and compatibility. Beauty products need ingredients and warnings. Industrial parts need dimensions, tolerances, and replacement relationships.

| Layer | Example fields | Primary job |
| --- | --- | --- |
| Identity | Product ID, SKU, GTIN, MPN, brand, canonical URL | Match, deduplicate, and update the right item |
| Description | Title, short description, long description, bullets, product type | Explain the product to people and systems |
| Taxonomy | Category path, product type, collection, channel category | Place the item in the right browse and feed context |
| Attributes | Size, color, material, dimensions, ingredients, fit, compatibility | Support filtering, comparison, recommendations, and use-case matching |
| Variants and relationships | Parent ID, variant ID, item group ID, bundle contents, accessories | Keep sellable versions and related products distinct |
| Commercial state | Price, sale price, currency, availability, inventory, condition | Represent the offer a shopper can actually buy |
| Logistics and policy | Weight, package dimensions, shipping, returns, warranty, restrictions | Set fulfillment expectations and channel eligibility |
| Media | Primary image, alternate images, video, manuals, alt text, image role | Show and support the product and its claims |
| Provenance | Source system, source URL, owner, confidence, last updated | Make values traceable and refreshable |

The model should distinguish facts from derived values. A manufacturer-confirmed material is different from an inferred style tag. A review summary is different from a specification. Keep that distinction visible so enrichment does not turn an assumption into a product promise.

### An illustrative product record

This example shows one sellable variant of an apparel product. The values are illustrative. Replace them with approved data from your own sources.

```json
{
  "product_id": "northline-commuter-jacket",
  "parent_id": "northline-commuter-jacket",
  "variant_id": "northline-commuter-jacket-navy-m",
  "sku": "NL-JKT-NVY-M",
  "gtin": "0614141123452",
  "brand": "Northline",
  "title": "Northline Waterproof Commuter Jacket, Navy, Medium",
  "category_path": ["Apparel", "Outerwear", "Rain Jackets"],
  "attributes": {
    "color": "navy",
    "size": "M",
    "fit": "relaxed",
    "material": "recycled nylon",
    "features": ["taped seams", "packable hood", "reflective trim"],
    "use_cases": ["bike commuting", "travel", "light rain"]
  },
  "offer": {
    "price": 148.00,
    "currency": "USD",
    "availability": "in_stock",
    "condition": "new"
  },
  "media": {
    "primary_image": "https://example.com/images/nl-jkt-nvy-m.jpg",
    "image_role": "variant_front"
  },
  "relationships": {
    "variant_options": {"color": "navy", "size": "M"},
    "accessories": ["northline-packable-rain-pants"]
  },
  "provenance": {
    "spec_source": "supplier-sheet-2026-05",
    "inventory_source": "erp",
    "last_verified": "2026-05-15"
  }
}
```

The parent identifies the product family. The variant identifies the sellable item with its own SKU, price, inventory, URL, and image when those differ. That structure lets a site show one product with options while a feed or order system still updates the exact item.

## How product data moves from source to channel

Treat the architecture as a pipeline with a canonical record in the middle:

> **Supplier files, manufacturer pages, ERP, PIM, DAM, storefront, reviews** → **ingest** → **canonical product model** → **normalize** → **enrich** → **validate and approve** → **publish to PDPs, feeds, marketplaces, APIs, search indexes, structured data, and AI shopping surfaces** → **monitor and resync**


Each source can remain authoritative for a different field. An ERP may own inventory and cost. A DAM may own approved media. A PIM may own localized descriptions and category attributes. A storefront may own the live URL and offer presentation. Supplier documentation may be the source for dimensions and materials. Record the owner and timestamp instead of blending values silently.

A PIM coordinates product-content workflow. An ERP manages operational and transactional data. A DAM manages files and rights. A feed system maps records to channel schemas. An API exposes records to software. A product data layer can connect these systems and provide a normalized, live output for AI commerce. A [PIM and Catalog comparison](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) explains why these layers can work beside each other rather than forcing one system to do every job.

The architecture is healthy when a team can change an approved fact once, see which outputs are affected, and trace a channel value back to its source.

## The product-data workflow

### 1. Collect the source material

Inventory every place product facts live: supplier spreadsheets, PDFs, manufacturer pages, product detail pages, PIM and ERP exports, DAM assets, marketplace listings, reviews, and internal databases. Record format, owner, update cadence, coverage, and known gaps.

Collect the source, not just the extracted value. A dimension without its specification sheet or retrieval time is hard to audit. For external pages and documents, retain the source URL, retrieval timestamp, and extraction method.

### 2. Define the schema before enrichment

Create a core field list and category extensions. Mark each field as required, recommended, conditional, or prohibited for every important destination. Define accepted value sets, units, locale rules, and validation logic.

Keep a field dictionary. `color`, `primary_color`, and `finish` should represent distinct concepts, or be mapped intentionally. A shared dictionary makes source mappings reviewable and prevents every channel team from inventing its own names.

### 3. Normalize values and structure

Normalization makes equivalent facts comparable:

- Convert dimensions, weight, volume, and temperature to agreed units.
- Map categories to a controlled taxonomy and preserve the source category when useful.
- Normalize colors, sizes, materials, ingredients, conditions, and compatibility values.
- Standardize casing, punctuation, date formats, currency, and decimal rules.
- Split parent products from sellable variants and assign stable relationships.
- Deduplicate records and flag conflicting values rather than choosing silently.

Free text still has a place in descriptions. High-impact fields used for filters, feeds, and comparisons need typed values or controlled vocabularies.

### 4. Enrich from evidence

Enrichment fills gaps in a record: category-specific attributes, clearer titles, buyer-facing descriptions, use cases, compatibility, product relationships, image metadata, and channel fields. The input can come from approved supplier specs, manufacturer pages, product images, manuals, reviews, or internal systems.

AI can accelerate extraction, classification, and drafting. It should not invent a fabric blend, safety claim, voltage, ingredient, or compatibility fact. Require a source, confidence level, and review path for values that affect a purchase or compliance. Our guide to [product data enrichment for AI commerce](https://www.getcatalog.ai/blog/product-data-enrichment-ai-commerce) covers the difference between a nicer description and a usable structured record.

### 5. Validate before publishing

Run gates before a record reaches any destination:

- required-field completeness by category and channel;
- identifier format, uniqueness, and parent-child relationships;
- accepted values, units, currency, and locale;
- price, sale price, availability, and inventory logic;
- image URLs, variant-image matching, and media requirements;
- category and attribute compatibility;
- claims, restrictions, warnings, and policy fields;
- structured data and feed syntax.

Then validate the rendered destination. A valid source can still create a broken selector, wrong image, stale price, or hidden attribute on the product page.

### 6. Publish, monitor, and resync

A product record produces channel-specific outputs. Publish the right fields and format to each destination, then inspect acceptance, warnings, display, and freshness. Feed diagnostics, structured-data reports, zero-result searches, support questions, and product returns all reveal gaps the source audit missed.

Use event-driven or frequent updates for price, availability, and inventory. Use an approval workflow for slower-changing copy, attributes, and media. The right cadence depends on how quickly the field can change and how costly a stale value is.

For a deeper distribution model, see [product data syndication](https://www.getcatalog.ai/blog/product-data-syndication).

## Identifiers and variants are the join layer

Identifiers connect product data across systems. They deserve an explicit policy.

| Identifier | Scope | Use |
| --- | --- | --- |
| SKU | Internal to the seller | Inventory, fulfillment, reporting, and internal updates |
| GTIN, UPC, or EAN | Shared trade-item identity when assigned | Marketplace matching, product feeds, and cross-retailer recognition |
| MPN | Manufacturer's model or part number | Product matching, parts catalogs, and technical commerce |
| Product ID | Your canonical record key | Database joins, APIs, and durable references |
| Variant ID or item group ID | Parent-child relationship | Group size, color, pack, and configuration options |

A SKU is not a GTIN. Do not reuse a SKU for a different sellable item, assign one GTIN to unrelated variants, or rely on a title to join records. Link to the [GTIN definition](https://www.getcatalog.ai/glossary/gtin-global-trade-item-number) when you document the policy for merchandisers and suppliers.

For variants, define which differences create a new sellable item. A navy medium jacket and a navy large jacket need separate inventory and usually separate SKUs. They can share a parent product and canonical family page. A two-pack and a single unit are different offers and need explicit pack or bundle data. A replacement filter compatible with a vacuum is a related product, not a color variant.

When a channel requires one row per item, send the sellable variant with its own ID, title or selected options, URL, image, price, availability, and identifiers. When a channel groups variants, send the stable parent or item-group relationship as well. Never make downstream systems infer whether two rows are options, bundles, or different products.

## Feeds and structured data are outputs, not the catalog

A product feed is a file, stream, or API transfer built for a destination. It may be CSV, TSV, XML, JSON, or another channel-supported format. A feed can contain title, description, link, image, price, availability, brand, category, identifiers, variants, shipping, and custom fields. [Google Merchant Center's product data specification](https://support.google.com/merchants/answer/7052112) is one example of a destination-specific contract.

The same canonical record can produce different outputs for Google Merchant Center, marketplaces, Meta catalogs, affiliate networks, internal search, and AI shopping surfaces. Each destination has different required fields, taxonomies, limits, accepted values, and update rules. Fix upstream when possible. A channel-specific rule should translate the record, not become a hidden second catalog.

Structured data is selected product information embedded in the product page with a machine-readable vocabulary such as Schema.org. [Google's ecommerce structured-data guidance](https://developers.google.com/search/docs/specialty/ecommerce/include-structured-data-relevant-to-ecommerce) supports `Product`, `Offer`, `ProductGroup`, and related types for ecommerce. Google recommends product structured data on product pages, and its [product structured-data documentation](https://developers.google.com/search/docs/appearance/structured-data/product-snippet) notes that merchant pages should keep markup in the initial HTML when possible for changing values such as price and availability. Markup must match what shoppers see. Structured data increases eligibility and understanding, it does not guarantee a rich result or a ranking.

Pair page markup with direct channel data where the destination supports it. Google's guidance explains that structured data can improve its understanding of price, discounts, and shipping, while Merchant Center feeds give larger or frequently changing catalogs more control over coverage and update timing. Test markup and monitor warnings after template changes. Our [structured data glossary](https://www.getcatalog.ai/glossary/structured-data) and [product feed guide](https://www.getcatalog.ai/blog/product-feed-management) cover the implementation details without treating one output as the source of truth.


## Make the record ready for AI shopping

AI shopping surfaces compare products against natural-language constraints. A shopper may ask for a navy rain jacket for bike commuting, a fragrance-free moisturizer for sensitive skin, or a USB-C monitor that works with a specific laptop. The record needs explicit facts that map to those constraints.

Prioritize five layers:

1. **Identity:** Stable IDs, brand, category, product URL, and variant relationships.
2. **Decision attributes:** Materials, dimensions, fit, ingredients, compatibility, use cases, included items, and constraints.
3. **Commercial state:** Current price, currency, availability, seller, shipping, returns, and regional eligibility.
4. **Machine-readable delivery:** Structured product pages, feeds, APIs, and typed product objects with consistent field names.
5. **Evidence and control:** Source provenance, reviews or Q&A where available, policy data, update timestamps, and a way to block or correct an output.

[OpenAI's current product-feed documentation](https://developers.openai.com/commerce/specs/file-upload/products) illustrates the baseline for ChatGPT discovery: a stable item ID, title, factual description, URL, brand, seller, image, price, and availability, with richer fields for variants, attributes, shipping, returns, and reviews. The exact contract will vary by integration. The durable rule is to expose complete, current records instead of relying on a model to infer missing facts.

AI readiness is a data-quality discipline. [Product data quality](https://www.getcatalog.ai/blog/product-data-quality) means records are accurate, complete, consistent, current, valid, unique, and useful across the places they appear. We provide a parallel product data layer, the foundation for a parallel storefront in AI commerce. We structure and enrich product data, publish live normalized product objects, keep changes synchronized, and measure how AI surfaces use the catalog. It complements a storefront or PIM, so teams can improve machine readability without replacing their existing commerce operation.

## A practical implementation plan

Start with a narrow slice of the catalog and make the loop work end to end.

### Phase 1: Choose a high-value scope

Select one category, one region, and the products or variants that matter most to revenue, returns, support volume, or channel eligibility. Include a few products with known feed or search problems. Define the destinations you will support first: storefront, Google Merchant Center, a marketplace, an API, or an AI shopping surface.

### Phase 2: Assign ownership and design the model

Write the core schema, category extensions, field dictionary, identifier policy, source-of-truth map, and approval roles. Set a quality threshold for every destination. A product can be complete for the storefront and incomplete for a marketplace, so score completeness by channel.

### Phase 3: Build the canonical pipeline

Connect sources, retain provenance, normalize values, resolve duplicates, group variants, and enrich missing fields from evidence. Keep transformations versioned. If you change a mapping, you should be able to explain which output records changed and why.

### Phase 4: Publish and test the outputs

Render a sample of product pages. Inspect one record in each feed. Test structured data. Verify that the right variant image, price, availability, and URL appear together. Check channel diagnostics and trace failures upstream.

### Phase 5: Operate the refresh loop

Monitor freshness lag, completeness, validation failures, duplicate rate, feed rejections, structured-data warnings, search gaps, and AI product visibility. Give every failure an owner and a response time. Expand to another category after the first loop is reliable.

A traditional PIM can remain the system for internal approvals, localization, and product-content governance. A feed platform can handle destination mappings. We built Catalog for teams that need a live, normalized product data layer for AI commerce beside those systems. The [PIM versus Catalog comparison](https://www.getcatalog.ai/blog/catalog-ai-vs-traditional-pim-systems) helps decide whether you need one layer or both.

## Ecommerce product data audit checklist

Use this checklist for a representative sample, then automate the checks that repeat:

- **Scope:** Have you selected the categories, regions, channels, and high-impact products to audit?
- **Completeness:** Does each category have required fields for identity, attributes, media, commercial state, logistics, and policy?
- **Accuracy:** Can each important claim be traced to an approved source?
- **Consistency:** Are names, units, categories, colors, sizes, and materials normalized across PDPs, feeds, and marketplaces?
- **Identifiers:** Are SKUs unique, GTINs valid where assigned, MPNs mapped correctly, and canonical URLs stable?
- **Variants:** Are parent, variant, bundle, pack, and accessory relationships explicit? Does every sellable item have its own inventory and offer state?
- **Freshness:** How long does a price, inventory, or availability change take to reach each destination?
- **Media:** Does each variant use the right image and working URL, with required formats and useful alt text?
- **Structured data:** Does page markup match visible price, currency, availability, product identity, and variants? Is it present in the initial HTML where required?
- **Feeds:** Are destination fields, taxonomies, accepted values, and update schedules mapped and monitored?
- **AI readiness:** Can an AI shopping system answer who the product is for, what it is made of, which variant fits, what it costs, and whether it is available without guessing?
- **Ownership:** Does every failure route to a person or team with a documented fix path?

## FAQs

### What is ecommerce product data?

Ecommerce product data is the structured and unstructured information that describes, sells, fulfills, and distributes products online. It includes product facts, content, media, identifiers, variants, prices, availability, policies, and relationships.

### What fields matter most?

Start with stable identity, title, category, product URL, price, availability, primary image, and variant relationships. Add category-specific decision fields such as material, dimensions, fit, ingredients, compatibility, care, and included items. The right field set depends on the product and its destinations.

### Is ecommerce product data the same as a PIM?

No. Product data is the information itself. A PIM is a system for managing, enriching, approving, and distributing some of that information. A PIM can be the source of truth, while a product data layer or feed system handles downstream use cases.

### What is the difference between a product feed and product data?

Product data is the broader record a business maintains. A product feed is a channel-specific file, stream, or API output created from that record. One canonical catalog can produce many feeds.

### How do I prepare product data for AI shopping?

Make product facts explicit, typed, current, and traceable. Normalize identifiers and variants, expose price and availability, add category-specific attributes and policies, publish structured outputs, and monitor which products and variants are surfaced. Copy alone cannot supply missing product facts.

## Build product data that travels

A product record should survive the trip from a supplier file to a product page, feed, marketplace, API, and AI shopping surface without changing meaning. That requires a canonical model, clear ownership, normalization, evidence-based enrichment, validation, and refresh rules.

We help brands build that product data layer for AI commerce. [See how Catalog can structure and distribute your catalog](https://www.getcatalog.ai/) so AI shopping systems can read live product facts while your existing storefront stays in place.

---

Canonical: https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Ecommerce data scraping: data, tools, and trade-offs

*April 26, 2026 · Catalog Team · Business · 13 min*

> Learn what ecommerce data scraping collects, compare APIs, tools, and services, and decide when Catalog's product-data layer fits your team.

Ecommerce data scraping turns storefront pages into structured records of products, prices, variants, availability, and reviews. Teams use those records to monitor markets, analyze assortments, and enrich internal catalogs. The hard decision is how to collect it: an authorized feed, an in-house crawler, an ecommerce scraping tool or API, or a managed service. This guide explains the data, trade-offs, operating costs, compliance boundaries, and the point where a product-data layer such as Catalog is a better fit.

## What is ecommerce data scraping?

Ecommerce data scraping is the automated extraction of product and commerce information from online storefronts, marketplaces, or other retail pages. A scraper fetches a permitted source, identifies the fields a team needs, and stores the results in rows or typed product objects. It can run once for a research project or on a schedule for price, assortment, and availability monitoring.

Ecommerce web scraping focuses on commerce fields rather than a page's full text. Depending on the source and permission, a collector may read HTML, rendered page content, embedded structured data, or an authorized endpoint. The output should include the value, its source, and the time it was captured. Without that provenance, a price or availability value is only a number with no useful context.

Scraping is a collection method. It is different from maintaining a product-data layer:

| Dimension | Ecommerce data scraping | Product-data layer |
| --- | --- | --- |
| Primary source | External storefronts or marketplaces | Owned, supplied, or permissioned catalog sources |
| Main job | Capture market observations | Govern, normalize, and distribute product facts |
| Typical output | A snapshot or time series | A canonical product record and channel-ready feeds |
| Core question | What changed in the market? | What should every selling and discovery surface know? |

Catalog works on the second problem. It structures a brand's product data, keeps it synchronized, and publishes live, normalized product data to AI shopping surfaces. It does not scrape competitor pages or grant permission to collect them.

## What data do teams collect?

The useful unit is a product or offer record with an identity, commercial state, and provenance. A practical ecommerce product data scraping schema can include:

| Data group | Common fields | Why teams use it |
| --- | --- | --- |
| Product identity | Product URL, title, brand, category, SKU, product ID, GTIN or MPN when published | Match records and find duplicates across sources |
| Price and promotion | List price, sale price, currency, unit price, promotion text, capture time | Track price movement and compare offers |
| Availability | In-stock state, backorder status, quantity when shown, pickup or delivery status | Monitor stock signals and service promises |
| Variants and attributes | Size, color, pack, configuration, material, dimensions, compatibility | Compare like-for-like products and fill attribute gaps |
| Merchandising content | Descriptions, images, badges, category paths, specifications | Study assortment and product presentation |
| Seller and fulfillment | Seller, shipping promise, delivery estimate, return terms when shown | Understand marketplace and fulfillment differences |
| Customer evidence | Rating, review count, review text, question-and-answer content | Identify sentiment, recurring issues, and demand signals |
| Provenance | Source URL, locale, device or rendering context, timestamp, parser version | Reproduce results and investigate changes |

Google's [Merchant Center attributes](https://support.google.com/merchants/answer/7052112?hl=en) show why downstream systems treat identifiers, titles, prices, availability, and variants as separate fields. A scraper that saves only visible title text loses the structure needed for comparison or validation.

### Why collect it?

The use case determines the fields, refresh rate, and acceptable cost. Common examples include:

- **Price monitoring:** Ecommerce price scraping can show a competitor's listed price, promotion, currency, and timestamp. A team can investigate a change without treating a captured price as a permanent truth.
- **Assortment and trend analysis:** Product titles, categories, attributes, and availability reveal new launches, discontinued items, pack sizes, and gaps in a range.
- **Catalog benchmarking:** Comparing attribute coverage, descriptions, images, and variant structure can expose where an internal catalog is incomplete.
- **Review analysis:** Ratings and review themes can inform product quality, messaging, and support priorities. Review text needs extra care because it may contain personal information or copyrighted material.
- **Marketplace monitoring:** Seller, delivery, and offer fields help teams understand how an item appears across a marketplace or region.

Collection should be scoped to a decision. A team tracking weekly assortment changes needs a different pipeline from a team requiring minute-level stock signals. More fields and faster refreshes increase operating cost and the amount of data that must be governed.

## Collection options for ecommerce scraping

Start with the source's authorized path. A public page is not automatically an invitation to automate requests or reuse its content.

### Official feeds, APIs, and partner exports

An official API, product feed, data export, or partner agreement gives the source a defined schema and access rules. It is usually the clearest route for recurring collection. It can also expose fields that a public page omits, such as stable IDs, region, inventory state, or historical changes.

The trade-off is scope. An API may cover only a partner's own offers, impose quotas, or omit the competitor and market signals a research team wants. The agreement should state the permitted use, retention, refresh limits, and redistribution rights before a team builds around it.

### An in-house scraper

An in-house build can fit a small set of stable sources or a workflow with unusual parsing and business rules. The system typically needs a scheduler, fetch layer, parser, storage, identity matching, validation, monitoring, and an owner for source changes.

It gives the team direct control over code, cadence, and output. The team also owns every failure. A layout change, new variant selector, localized price, client-side render, rate limit, or pagination rule can create silent data loss. The initial script is only the first cost.

### An ecommerce scraping tool or API

An ecommerce scraping tool or scraper API can shorten setup by handling fetching, browser rendering, extraction templates, or delivery. This approach suits teams that need a usable dataset quickly and can work within a provider's supported sources and schema.

Coverage, field-level accuracy, refresh controls, failure reporting, export formats, and usage limits are the comparison points. A tool that returns a row is not necessarily validating the row. The workflow still needs checks for stale prices, missing variants, duplicate products, and the source's terms.

### Ecommerce data scraping services

An ecommerce data scraping service takes on more of the pipeline, from source configuration to extraction, normalization, quality checks, and delivery. It can suit a recurring, multi-source program when an internal team does not want to operate collectors.

The service introduces a vendor relationship and a delivery contract. Define the schema, provenance, correction process, service levels, allowed sources, retention, and exit path. A managed service should reduce operational work, not make the data model or compliance responsibility invisible.

### Licensed market data

For established market research, a licensed dataset may provide normalized history, category coverage, and explicit reuse rights. It can cost more per record than a one-off script and may be less flexible, yet the rights and data lineage can be easier to govern. It is worth comparing when historical continuity matters more than owning the extraction code.

## Build vs. buy: compare the whole operating model

“Buy” can mean a scraper API, a no-code ecommerce scraping tool, or a managed service. These options solve different portions of the work. The decision should reflect the workflow you need to run every week, not just the first successful export.

| Decision factor | Build in-house | Tool or API | Managed service |
| --- | --- | --- | --- |
| Best fit | Few sources, custom rules, strong engineering ownership | Fast start and supported source patterns | Recurring, multi-source collection with limited internal operations |
| Control | Highest control over code, cadence, and storage | Control depends on provider settings and schema | Control moves into the contract and delivery process |
| Initial effort | Engineering design, source mapping, and QA | Configuration, mapping, and integration | Requirements, onboarding, and acceptance tests |
| Ongoing work | Maintain selectors, rendering, jobs, tests, and alerts | Monitor output and provider changes; add exceptions | Review quality, source coverage, and vendor performance |
| Reliability work | Your team detects and repairs failures | Provider handles some fetching; your team validates output | Provider handles agreed pipeline work; your team governs acceptance |
| Normalization | You design identity and category rules | Templates vary by provider | Schema and normalization must be defined in the contract |
| Cost drivers | Engineering time, compute, storage, monitoring, and triage | Usage, pages or records, add-ons, storage, and integration | Setup, recurring delivery, change requests, and minimum commitments |
| Compliance ownership | Internal team owns source and use decisions | Shared operational model, with your use still your responsibility | Contract can assign tasks, but it does not remove your obligations |

The right choice depends on the value of the decision the data supports. A small, short-lived study can justify a lightweight build. A daily feed that affects pricing or buying decisions needs stronger monitoring and recovery. A provider may be cheaper in staff time while costing more in usage. An internal build may look inexpensive in software spend while consuming engineering capacity for every source change.

## Reliability, maintenance, and total cost

An extraction pipeline fails in ways that are easy to miss. A request can succeed while a price field is blank. A page can return one product when it previously returned twelve variants. A locale can change `$49.00` into `49,00 €`. A product can move to a different category and appear as a new item. A scraper that reports HTTP 200 for each page can still produce a bad dataset.

Treat quality as a set of checkpoints:

1. **Fetch health:** Record response status, load time, source version, and whether the expected page or feed was returned.
2. **Schema validity:** Require valid types for price, currency, availability, identifiers, and variant relationships. Keep missing values distinct from zero or “out of stock.”
3. **Freshness and change checks:** Store capture time and flag values that are unexpectedly stale or change beyond a review threshold.
4. **Identity and deduplication:** Match stable IDs and canonical URLs where available. Review sudden additions, removals, and duplicate variants.
5. **Provenance and review:** Keep the source URL, locale, parser version, and permission context with each record. Route failed checks to a human or a defined recovery path.

For example, a daily run could stop publication when currency disappears, required IDs fall below an agreed completeness level, or a large share of variants vanishes. That checkpoint costs less than sending an unreviewed price or availability change to downstream decisions.

The total cost of ecommerce data scraping is:

**Implementation + fetching and provider usage + storage + monitoring and QA + human triage + compliance work.**

The estimate should include each component at the refresh rate and source count you actually need, along with backfills, historical retention, schema changes, and the time to explain a disputed record. An ecommerce data scraping service or tool provider should state how it prices pages, records, browser sessions, refreshes, retries, storage, and custom changes. A low entry price does not describe the full operating cost.

## Authorized data paths and compliance boundaries

Scraping can be legitimate in an authorized market-research workflow. The permission and intended use matter. A careful program should:

- Prefer official feeds, APIs, exports, licenses, or written permission when they meet the need.
- Source terms, partner agreements, API rules, and data licenses define the conditions for collecting or redistributing records.
- Respect access controls, rate limits, and stated crawler preferences. Do not bypass logins, paywalls, CAPTCHAs, technical blocks, or other controls.
- Minimize collection of personal information. Reviews, seller profiles, and customer questions can include names, contact details, or other sensitive details. Protect credentials, restrict access, and set retention and deletion rules.
- Review copyright, database rights, trademarks, contract terms, and jurisdiction-specific rules for the source and your intended use. Public visibility does not automatically make content free to collect or reuse.
- Keep a record of the source, capture time, permission or terms, purpose, and retention decision for each collection program.

The [Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html) describes robots.txt as a requested crawler behavior, not an access authorization system. Respecting robots.txt is good operational practice, yet it does not answer the separate questions of permission, contract, privacy, or reuse rights. The Ninth Circuit's [hiQ opinion](https://cdn.ca9.uscourts.gov/datastore/opinions/2022/04/18/17-16783.pdf) concerned publicly available LinkedIn profiles and preliminary-injunction relief. It does not provide blanket permission for ecommerce data scraping.

For a material commercial program, have counsel review the sources, jurisdictions, data categories, and downstream use. This is a boundary to design into the system, not a checkbox after launch.

## When a product-data layer is the better fit

Scraping answers an external observation problem. A product-data layer answers an ownership and distribution problem. That boundary keeps a comparison fair:

| If you need to… | Start with… |
| --- | --- |
| Track a competitor's public price or assortment | An authorized feed, API, licensed dataset, scraper, or managed collection service |
| Build a historical market snapshot | A governed collection pipeline with provenance and retention |
| Keep your own products consistent across commerce channels | A product-data layer and the source systems that feed it |
| Give shopping agents current, machine-readable product facts | A structured product-data layer with controlled distribution |
| Measure how your products appear in AI shopping surfaces | A product-data layer and outcome measurement |

Catalog is designed for the last three needs. It structures owned product information into typed product objects, keeps data synchronized, publishes a parallel storefront to AI shopping surfaces, and measures outcomes. It can sit alongside an authorized market-data workflow. It does not replace a competitor-price collector, and it does not make external collection lawful.

If your team is spending engineering time turning its own catalog into reliable data for ChatGPT, Gemini, Claude, Perplexity, or other AI shopping surfaces, that is the Catalog use case. Start with the [ecommerce product data guide](https://www.getcatalog.ai/blog/complete-guide-ecommerce-product-data-catalog-ai) to see the fields, feeds, and controls involved. Our guide to [trusted data sources](https://www.getcatalog.ai/blog/trusted-data-sources-agentic-commerce) explains the provenance expectations around agentic commerce.

## Ecommerce data scraping FAQs

### Is ecommerce data scraping legal?

There is no single answer for every source or use. Legality depends on permission, terms, access controls, privacy, intellectual-property rights, contracts, and jurisdiction. Publicly visible data is not automatically free to collect or reuse, so authorized paths and legal review belong in material programs.

### What is the difference between scraping and an API?

An API is a supported interface with a defined schema and access rules. Scraping interprets a page or other exposed representation and can break when the presentation changes. An official API or feed is usually easier to govern when it covers the fields and use you need.

### How much does ecommerce data scraping cost?

Costs include implementation, fetching or provider usage, storage, monitoring, QA, triage, historical retention, and compliance work. A sound estimate uses your required source count and refresh rate. A tool or service can reduce engineering time while adding usage or subscription fees.

### Is Catalog an ecommerce scraping tool?

No. Catalog is a product-data layer for a brand's own catalog. It structures, synchronizes, distributes, and measures product data for AI commerce. Use an authorized collection path when you need external market observations.

If the challenge is making your own catalog ready for AI commerce, [explore Catalog](https://www.getcatalog.ai/).

---

Canonical: https://www.getcatalog.ai/blog/why-smart-ecommerce-companies-choose-catalog-ai
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.

---

# Catalog Raises $3M for AI Commerce Infrastructure

*March 23, 2026 · Catalog Team · Company News · 2 min*

> Catalog announces a $3M pre-seed led by Acrew Capital to make merchant product data legible to AI systems.

Catalog, the data infrastructure layer for agentic commerce, today announced a $3 million USD pre-seed round led by Acrew Capital, with participation from WndrCo and Hustle Fund. The company is launching its platform to help merchants structure and distribute product data so they can be understood, ranked, and recommended by AI systems.

The raise comes as a fundamental shift takes hold in how people shop online. Consumers are moving from browsing websites to asking platforms like ChatGPT what to buy. Instead of navigating pages and blogs, they describe intent in plain language and receive personalized recommendations. In this new model, AI becomes the storefront — filtering, comparing, and increasingly completing transactions on behalf of users.

But the underlying infrastructure has not caught up. Product data today is built for human browsing, not machine reasoning. It lives in inconsistent formats, buried in copy, and lacks the structure required for AI systems to interpret it reliably. As a result, even strong products are often excluded from AI-driven discovery.

Founded in San Francisco by Hamish Gunasekara and Dylan Farrell, [Catalog](https://www.getcatalog.ai/) addresses this gap by transforming merchant catalogs into structured, machine-readable product data designed for AI systems.

## Four core components

Catalog's platform is built around four core components:

- **Ingestion without integration.** Catalog extracts product data directly from merchant websites and commerce platforms, requiring no schema redesign or engineering lift.
- **Normalization and enrichment.** The system structures variants, resolves inconsistencies, and extracts key attributes such as material, dimensions, and use cases, producing deterministic product objects optimized for machine reasoning.
- **Distribution to AI ecosystems.** Catalog delivers product data to AI platforms through protocols such as ACP and UCP, as well as agent-driven storefronts and APIs, ensuring products can be discovered and recommended across AI interfaces.
- **Continuous synchronization.** Pricing, availability, and catalog changes are monitored and updated in real time so AI systems operate on accurate, up-to-date data.

With this approach, Catalog enables merchants to participate in AI-driven commerce without rebuilding their existing infrastructure. Setup takes hours, not months.

> Catalog is building critical infrastructure for how commerce will work in an AI-first world. As AI agents take on a larger role in discovery and purchasing, structured and reliable product data becomes essential. Catalog ensures merchants can show up and compete in that environment.

— Lauren Kolodny, General Partner at Acrew Capital

Catalog plans to use the funding to expand its engineering team, deepen integrations with major AI platforms, and continue building toward a broader vision of agentic commerce infrastructure.

As AI becomes the interface for how people search, compare, and buy, visibility will depend on whether products can be understood by the systems making those decisions. [Catalog](https://www.getcatalog.ai/) is building the layer that makes that possible.

---

Canonical: https://www.getcatalog.ai/blog/catalog-raises-3m-pre-seed
Site guide for agents: https://www.getcatalog.ai/llms.txt — every page is available as markdown via `Accept: text/markdown` or a `.md` suffix.