Product Catalog Enrichment for AI Shopping: The Playbook

Short answer: catalog enrichment is the work of putting every buying fact about a product into a named field that machines can read, and keeping those fields true. AI shopping assistants such as ChatGPT, Google AI Mode, Microsoft Copilot and Amazon's Alexa for Shopping (formerly Rufus) choose and describe products from structured data: feeds, catalogs and page markup. If material, size, compatibility, GTIN or availability exist only in a paragraph or a photo, an assistant either skips the product or guesses. This playbook covers what to enrich, how the fields map across Shopify, Amazon, schema.org and Google Merchant Center, how to audit what you have, who should own each field, and whether to build or buy.

What is product catalog enrichment?

Product catalog enrichment is adding, correcting and structuring product data so that each fact a shopper might ask about lives in its own field with a controlled value. It covers attributes (material, dimensions, fit, ingredients, compatibility), identifiers (GTIN, MPN, brand), variant structure, image metadata, and the offer facts that change daily: price, availability, shipping and returns. SKU enrichment is the same work counted per variant, which is the level most offer facts live at.

Product catalog enrichment

The process of turning product facts into structured, validated fields (attributes, identifiers, variant data, offer and policy data) and keeping them accurate across every channel that reads them, so people and AI systems can filter, compare and quote them.

Why it matters more now than it did for classic SEO: an assistant answering a shopper doesn't read your page the way a person does. A person reads "crafted from buttery full-grain Italian leather" and concludes leather. An assistant asked "is this real leather?" needs material: full-grain leather as a value it can match, filter on and repeat. Prose persuades; fields answer. You need both, but only fields can be read reliably by a machine.

Structured attribute

A named, machine-readable field with a discrete value (material: cotton, sleeve_length: short, dishwasher_safe: true), as opposed to the same fact sitting inside a marketing paragraph.

Enrichment is not the same as writing better descriptions. Descriptions still matter, because assistants summarize them, but a description is one field. Enrichment is the other forty. Skipping it costs you in declined answers, wrong recommendations and products that never make a shortlist, and that cost compounds as more AI surfaces read the same thin data: see what incomplete product data costs you.

Where do AI shopping assistants get product data?

Each major AI shopping surface reads your catalog through a pipe you can name. These are the documented ones:

• Shopify Catalog feeds Shopify's agentic storefronts in ChatGPT, Microsoft Copilot, Google AI Mode and Gemini. By default it lists title, description, options, images, price and availability, and Catalog Mapping can source category, title and description from metafields or other custom data (Shopify Help Center).
• ChatGPT picks products using structured metadata from first-party and third-party providers, such as price and product description, according to OpenAI's help center. Shopify merchants are integrated through Shopify Catalog; other merchants can apply to send a direct product feed.
• Google (AI Overviews, AI Mode, Shopping and Gemini) reads your pages through Search and your products through Merchant Center. Google says AI features need no special markup, but your structured data should match the visible text on the page.
• Alexa for Shopping works from Amazon's own product catalog, customer reviews, community Q&A and information from across the web, so on Amazon your product-type attributes are the catalog it reads.

The practical consequence: one product fact may be read by four or five systems under different field names. Enriching once in a source of truth and mapping it to each output is cheaper than fixing each channel separately, and it's the only way the channels stay consistent with each other. The field map is next. For how the engines decide what to recommend once they have your data, read how to get products recommended by AI.

Which product fields map across Shopify, Amazon, schema.org and Merchant Center?

Use this field map as the spine of your catalog schema. Names are as each platform documents them. Amazon's attributes are defined per product type, so pull the definition for yours from the Product Type Definitions API (or the category template in Seller Central) before you map; the names below appear in Amazon's own listing examples.

Two notes on the map. OpenAI's product feed, for merchants approved to send one directly, requires nine fields (item_id, title, description, url, brand, seller_name, image_url, availability, price) and treats GTIN, MPN, condition, category and return policy as optional; Shopify merchants reach ChatGPT through Shopify Catalog instead. And Google's merchant listing guidance recommends defining store-wide shipping and return policies once, on your Organization, and overriding them on an Offer only where a product differs. Merchant Center works the same way, with account-level policies and per-item overrides.

Where a fact lives in Shopify decides whether it travels. A value in a category metafield or a typed metafield with a definition can be mapped to feeds and markup; the same value typed into a description can't. The rules for each field (type, unit, controlled vocabulary, required or optional) belong in a written schema: see designing a product attribute schema AI can use.

How do I audit my product catalog for AI shopping?

Audit before you enrich. You're looking for three things: a shopper question with no field to answer it, a field with a wrong value, and two systems that disagree. Work per category, on an export, in this order. The output is a ranked backlog, not a score.

1. 01

   Export and segment

   Export products and variants with their metafields (a Shopify CSV or bulk export), your Merchant Center diagnostics, and an inventory report from Seller Central if you sell on Amazon. Tag every SKU with its category and its revenue rank for the last 12 months.

2. 02

   Write the question set

   For each category, list the questions shoppers ask before buying, taken from support tickets, reviews, on-site search and marketplace Q&A. Each recurring question is a candidate field. Start from the category metafields Shopify suggests for that category, then add what your shoppers ask that the taxonomy doesn't cover.

3. 03

   Score coverage per field

   For every field, record the share of SKUs (or variants, for variant-level facts) with a non-empty, valid value. Keep it per category. A healthy store-wide average can hide a category where the fields that decide the purchase are empty.

4. 04

   Find prose-trapped specs

   Search descriptions for numbers with units, material words, care terms and phrases like "fits", "works with" and "suitable for". Every hit that isn't also a field is an extraction task: the fact exists, just not where a machine can use it.

5. 05

   Check identifiers

   Validate GTIN lengths (8, 12, 13 or 14 digits) and check digits, look for the same GTIN on two different products, and flag private-label items that need brand plus MPN instead. Never fill a GTIN you aren't sure of.

6. 06

   Check variant structure

   Option names spelled one way across the store, variant-level facts (size, color, weight) stored on the variant rather than the parent, and availability tracked per variant, not per product.

7. 07

   Check parity across surfaces

   For your top 25 revenue SKUs, compare the admin value, the server-rendered JSON-LD, the Merchant Center item and the Amazon listing for price, availability, GTIN and the two or three attributes that decide the purchase. Every mismatch is a wrong answer waiting to happen.

8. 08

   Rank the fixes

   Weight each gap by the revenue of the SKUs it touches and sort. Gaps on hero SKUs and on purchase-deciding fields go first. That ranked list is your enrichment backlog.

If you want to see the worksheet run on real products before committing a whole catalog, read how a 10-SKU enrichment sample works and what a 10-SKU enrichment sample returns.

Which attributes does each product category need?

Start from Shopify's Standard Product Taxonomy. Assign every product a standard category and Shopify offers that category's attributes as category metafields: a shirt, for example, gets clothing size, neckline and sleeve length type, each with default values you can use or extend. Shopify maps existing Google product categories to the matching Shopify category, and the standard category is also what Shopify Tax uses to pick a rate (Shopify Help Center).

Category metafield

A Shopify metafield tied to a category in the Standard Product Taxonomy (where it's called a product attribute), such as size, color or material, with predefined values that can be linked to variant options and reused across products.

Then add the fields your shoppers need that the taxonomy doesn't carry: fit notes, use cases, a "best for" statement, ingredients and allergens, certifications, care. Each one should trace back to a question from your audit, not to a field your team finds interesting. Tier them. Required fields block publishing when empty, recommended fields are measured every week, and optional fields are left alone. Store numbers as numbers with one unit per field, and use a fixed list of values for anything an assistant will filter or compare on.

Category structure matters as much as the fields inside it. A tree that's too flat makes an assistant guess which products are comparable; one that's too deep scatters similar products. Starter field sets for apparel, beauty, home goods and supplements are in product attribute templates by category; how to shape the tree itself is in product taxonomy design for AI discovery.

How should I structure variants so AI doesn't mix them up?

Most wrong recommendations trace back to variants. A shopper asks for the navy one in a medium, and the assistant answers from the parent product: the wrong price, a size that's sold out, or a color that doesn't exist. Three rules prevent most of it. Spell each option name and value one way across the whole store (Color, not Color on one product and Colour on another). Store facts that change by variant (size, color, weight, dimensions) on the variant and facts about the whole product on the parent. And track availability per variant, then make sure your markup and feeds expose it at that level.

Every channel has its own grouping construct, and they need to agree: Shopify's product with variants, Amazon's parent-child variation family with a variation_theme, schema.org's ProductGroup with hasVariant and variesBy, and Merchant Center's item_group_id. If a variant is grouped on Shopify but listed as a standalone product on Amazon, assistants that read both see two different products.

The two most expensive variant failures each have their own guide: when AI recommends the wrong size and when AI recommends an out-of-stock product. The full modeling rules for Shopify are in variant data that doesn't confuse AI agents.

What is compatibility data, and why do agents lean on it?

Compatibility data records what a product works with, fits or is suitable for: a case for an iPhone 16 Pro, a filter that fits a specific pitcher, a strap for a 22mm lug, a supplement that's safe alongside another. Shoppers phrase their highest-intent questions this way, so assistants resolve them by filtering on compatibility fields. When the field is empty, the product can't qualify, however good it is.

The data usually already exists in manuals, supplier spec sheets, support tickets and return reasons. Sourcing it is mining, not invention. Model it as a list field with canonical names (one spelling per device or model), not a sentence. In schema.org, isAccessoryOrSparePartFor and isRelatedTo express the relationship. In Merchant Center, product_detail carries spec-style pairs. On Amazon it depends on whether your product type defines a compatibility attribute.

One rule matters more than any other here: a wrong compatibility value is worse than an empty one, because an assistant will state it confidently and the shopper will return the product. Have a person verify compatibility claims before they publish. Sourcing and modeling are covered in compatibility data: the attributes AI agents rely on most.

Do I need GTINs for AI shopping, and how do I get them?

GTIN (Global Trade Item Number)

The GS1 identifier behind UPC (GTIN-12), EAN (GTIN-13) and ITF-14 barcodes. It identifies a specific trade item, so the same product can be matched across retailers, marketplaces and shopping engines.

If your product has a GTIN, send it. Google's Merchant Center help says products that have a GTIN but are submitted without one may get limited visibility, that a wrong GTIN gets the product disapproved, and that you shouldn't guess or make one up (Google Merchant Center Help). Products that genuinely have no GTIN, such as private label or custom-made items, should send brand and MPN instead. Shopify's Google & YouTube channel applies the same rule: a product that has a GTIN needs it entered before it can publish, and products without one need brand and MPN.

In the US, GTINs come from GS1 US, which licenses either a single GTIN (with no annual renewal fee) or a company prefix for a range of numbers, renewed yearly. Barcodes generated for internal use, such as inventory labels, aren't GTINs and shouldn't go in the GTIN field. On Amazon, a listing needs a product identifier unless your brand qualifies for a GTIN exemption; the process is in Seller Central Help under "GTIN exemption" (sign-in required). OpenAI's feed treats GTIN as optional and asks you not to invent an MPN to replace a missing one.

In Shopify, the GTIN goes in the variant's barcode field, one per variant. A shared or duplicated GTIN across two variants is one of the most common errors a markup audit turns up: see what a schema audit actually finds.

Does image metadata count as catalog data?

Yes. Assistants and crawlers can't reliably see what an image shows, so alt text is how a picture of the navy variant says it's navy. Good shopping alt text names the product, the attribute visible in that particular image, and the context: in use, a detail, a size reference. Template it by category and image role rather than writing one string per file, and set IPTC title and description in bulk from the same template where your DAM or PIM supports it. Automate the first draft; keep a person on hero SKUs and anything where color or pattern is subtle. The method is in image metadata and alt text at catalog scale.

Who should own which product fields?

Enrichment without owners decays. New products arrive half-filled, a supplier changes a material, a sale ends on Shopify but not on Amazon, and within a season the catalog drifts back to where it started. Governance means three things: one owner and one source of truth for every field group, a publishing gate that stops a SKU going live with required fields empty, and a known path for each change to reach every channel.

Write the propagation path down, because it's where drift starts. Shopify Catalog picks up changes continuously, but Amazon listings, a direct feed or a theme that hardcodes values won't change until someone changes them. A quarterly parity check on your top SKUs (step 7 of the audit) catches what the paths miss. Governance is tested hardest at peak, when teams freeze changes and invent fields under launch pressure; the pre-peak drill is in peak season catalog mistakes for AI shopping.

Should I build or buy catalog enrichment: PIM, apps or a service?

Catalog enrichment software and services sell the same outcome through different shapes. Choose by your channel count, how many people edit product data, and how often it changes, not by feature lists.

Schema discipline transfers between tools; tools don't transfer discipline. Every hour spent defining fields in metafields carries straight into a PIM if you move later. The thresholds where metafields stop being enough are in Shopify metafields vs. a PIM.

In what order should I enrich a large catalog?

Don't enrich a large catalog evenly. Your patience runs out before you reach the products that matter. Sequence by revenue:

1. 01

   Hero SKUs first

   The products that drive most of your revenue. Full enrichment: every required and recommended field, every compatibility relationship, GTINs checked, variants verified. This is where answer accuracy moves revenue fastest.

2. 02

   High-traffic categories next

   The categories shoppers and assistants hit most. Enrich every product in the category to the same schema so comparisons inside the category work.

3. 03

   The long tail, to a baseline

   For everything else, fill the required fields so an assistant never has to decline a basic question. Perfect is the enemy of shipped here.

4. 04

   Lock it in with governance

   Turn on the publishing gate so new products can't go live half-empty, and put the quarterly parity check on the calendar.

The unit of work is the category template, not the SKU: build the template once, then apply it hundreds of times with bulk tools and AI-assisted drafting, with a person checking every drafted value before it ships. Batching, staffing and where automation is safe are in enriching a 10,000-SKU catalog without a team of ten.

How do I know catalog enrichment is working?

Measure the data, the channels and the answers, in that order:

• Coverage and validity. Re-run step 3 of the audit monthly. The number to watch is coverage of required fields on hero SKUs, per category.
• Channel diagnostics. Merchant Center item issues and disapprovals, Amazon listing issues, and any errors your feed tool reports. A falling issue count is the quickest confirmation that fixes reached the channel.
• Google's AI reporting. Merchant Center's AI performance insights report shows how your products perform on shopping queries in AI Mode and AI Overviews (English-language queries, accounts in the US, Canada, Australia, New Zealand and India, organic traffic only).
• The answers themselves. Ask the assistants the questions from your audit and check whether the answers are now right. Track the share of correct answers on hero SKUs.
• Downstream signals. Returns coded "not as described" or "wrong size", and support tickets asking facts that should be fields.

To turn the gaps you found into a business case before you start, estimate what they cost per year. The method behind that estimate is in catalog debt: measuring what incomplete data costs you.

What are the most common catalog enrichment mistakes?

• Enriching evenly. Spreading effort across the catalog gives dead stock the same attention as hero SKUs. Sequence by revenue.
• Filling fields with junk. A populated but wrong attribute is worse than an empty one, because the assistant states it confidently. Accuracy beats coverage.
• Guessing identifiers. A made-up GTIN can get a product disapproved. Use brand and MPN when there's no GTIN.
• Fixing one channel at a time. Correcting Merchant Center without correcting the source means the next sync undoes it. Fix the source, then let the change flow out.
• Skipping governance. Without owners and a publishing gate, the catalog drifts back to half-empty within a season.
• Ignoring compatibility. It's the most tedious data to assemble and the most valuable for high-intent questions.