The AI Shopping Product Data Checklist: Product Truth for ChatGPT, Gemini, and Copilot

An AI shopping channel can only work with the product information it can access. If the identifier points to one variant, the image shows another, and the landing page has a third price, the problem starts before the model writes an answer.

In this guide, product truth means the current, supportable record of what a merchant sells: the exact item, its attributes, available variants, price, availability, policies, and valid relationships to other products. It is an operating term, not a promise that any feed will guarantee placement or eliminate model error.

The goal is not to produce special “AI copy.” It is to make the same product consistently identifiable across the source catalog, channel feed, and product page—and, where the channel supports purchase, consistent through cart and checkout.

The product-truth model

Treat product data as a contract with several connected parts.

Part	Question it must answer	Typical failure
Identity	What exact item or variant is this?	Reused IDs, unstable SKUs, or variants represented as one offer
Suitability	What is it, who is it for, and what constraints apply?	Promotional prose without material, size, compatibility, or use information
Offer state	What does it cost, and can it be bought now?	Feed, landing-page, and checkout prices or availability disagree
Trust	What should the buyer know about shipping, returns, warranties, and restrictions?	Missing, stale, or conflicting policy text
Relationships	Which variants, accessories, substitutes, or required parts belong together?	Related items are inferred from names instead of declared relationships
Delivery	Which channel receives which record, and how is it refreshed?	A correct source record is mapped incorrectly or stops updating

This separation matters because channels ask for different schemas, but the underlying facts should not change with the destination.

The AI shopping product data checklist

1. Give every sellable item a stable identity

Use a persistent merchant ID for each sellable item. Supply standard identifiers such as GTIN or MPN where they legitimately apply, and keep the brand name consistent.

A parent product and a purchasable variant are not interchangeable. If size, color, capacity, material, or another option changes what the buyer receives, the channel needs a reliable way to identify that specific offer.

Google’s current Merchant Center product data specification tells merchants to keep IDs stable and identifies missing or incorrect product identifiers and variant attributes as causes of display and eligibility problems. OpenAI’s current product-feed specification likewise treats the merchant item ID as unique per variant.

2. Make titles identify the product rather than advertise the promotion

A useful title names the product and includes the attributes needed to distinguish its sellable version. It should agree with the landing page.

Move temporary offers, shipping messages, and unsupported superlatives into the fields or surfaces designed for them. Do not make a channel parse “best,” “premium,” or “free shipping” to discover what the item is.

Descriptions should add decision information that is true for the represented item: material, construction, intended use, fit, care, compatibility, included components, and meaningful limitations. A description should not claim that a product fits every use case when the source catalog cannot support that conclusion.

3. Put comparable facts in structured fields

Store specifications as named attributes rather than leaving every fact inside prose. The relevant fields depend on the category, but the principle is stable: values that buyers compare should use consistent names, units, and formats.

Examples include:

dimensions and weight;
material and finish;
capacity or performance specifications;
compatibility requirements;
care instructions;
certifications or warnings that can be substantiated.

Structured data does not replace the description. It gives a system explicit values for filtering and comparison while the description explains the product in context.

4. Model variants and product families explicitly

Group related variants under a stable family identifier and declare which properties distinguish them. Do not rely on a channel to infer the relationship from similar titles.

Check that each variant has the correct:

item ID;
option values;
image where appearance differs;
price and sale price;
availability;
landing-page URL or selectable state.

The current OpenAI feed schema recommends group and variant fields when listings have variations. Google’s specification uses fields such as item group ID, color, and size, and warns that missing or conflicting variant data can cause display problems.

5. Keep price, availability, and purchase conditions aligned

Price and availability change more often than most descriptive fields. They deserve their own update and validation path.

For a sampled offer, compare the source system, channel record, product page, structured data, cart, and checkout. Record whether the item is in stock, out of stock, on preorder, or on backorder using the destination’s supported values. If a promotion has a defined period, make its start and end state explicit where the channel supports that information.

Do not describe “available” as universal inventory truth unless the feed represents the location and purchase context the shopper is using.

6. Use media that represents the same item

The primary image should show the product attached to that record. Additional images can provide context, alternate angles, scale, or variant-specific detail.

Prefer a clean image of the represented item and reject inherited images that show a different color or configuration. For Google product data specifically, the current image rules prohibit placeholders, promotional text, watermarks, and borders. Check that URLs are accessible to the intended channel and that the merchant has the right to distribute the media.

7. Treat policies as product-decision data

Returns, exchanges, shipping, warranties, subscriptions, restricted-product disclosures, and other purchase conditions can change whether an item is suitable.

Keep policy pages current and make the relevant relationship clear. A store-wide return policy should not silently conflict with a product-specific exception. A warranty claim in the description should resolve to the same terms the buyer sees after clicking through.

OpenAI’s current feed specification includes seller and return-policy fields. Shopify requires completed store policies for its supported agentic-storefront channels. These requirements are channel-specific, but the underlying policy must remain the merchant’s real policy.

8. Add Q&A, documents, and relationships only when they are governed

Product questions, manuals, compatibility documents, accessories, substitutes, and required parts can help a system answer needs that a short description cannot cover.

Google currently provides optional conversational attributes for questions and answers, document links, related products, product-family titles, variant options, and popularity rank. OpenAI’s current schema also includes Q&A, reviews, related-product relationships, and additional media fields.

Optional does not mean harmless. Do not generate speculative answers, link obsolete manuals, or mark a product as an accessory without an owner for that relationship. Google also advises merchants not to duplicate facts already supplied through description, product-highlight, or product-detail fields.

9. Map the source record deliberately for each channel

Different delivery paths expose different fields:

Destination	Current product-data path	Implementation boundary
ChatGPT direct feed	OpenAI’s supported stable feed schema	Direct feed access and current schema requirements must be checked with OpenAI
ChatGPT for eligible Shopify merchants	Shopify Catalog	No separate OpenAI feed is required for Catalog-based discovery, but store and product eligibility still apply
Google AI surfaces	Merchant Center product sources and Merchant API	Core product data comes first; conversational attributes are optional additions
Microsoft Copilot for eligible Shopify merchants	Shopify Catalog	Discovery and direct-checkout eligibility are separate questions
Shopify agentic storefronts	Shopify Catalog, with Google and Meta using their named Shopify sales-channel paths	Custom fields or grouping logic may require Shopify Catalog Mapping

The existence of a field such as is_eligible_checkout in a schema does not prove that every merchant or product can use a particular checkout experience. Schema capability, merchant eligibility, and live channel behavior are separate facts.

10. Test conflicts, not just completeness

A completeness score can miss the most damaging errors: two populated fields that disagree.

For each sampled variant, test these questions:

Can every system identify the same sellable item?
Do the title, image, and option values describe that item?
Do price, currency, sale state, and availability match the landing page and checkout?
Are material, dimensions, compatibility, and included components consistent?
Do shipping, return, warranty, and restriction statements resolve to current policies?
Are related products and documents still valid?
Does the record remain correct after the source catalog changes?

Log the authoritative source, channel mapping, owner, and last successful validation for every recurring error class. That creates a repair process instead of a one-time cleanup.

A complete feed is not a guarantee

Product data is one input to discovery and representation. Channels can apply their own eligibility, safety, relevance, ranking, and presentation logic. OpenAI explicitly notes that not every available product will necessarily be shown, while Shopify warns that external AI channels may rerank Shopify Catalog results.

More fields can also make a catalog less trustworthy when no one maintains them. A smaller set of consistent, current attributes is preferable to an extensive record containing contradictions.

The useful standard is therefore not “populate everything.” It is:

Represent each sellable item with enough current, supportable information for the intended channel, and verify that the channel record still agrees with the transaction surface.

Primary sources

The channel details in this checklist were verified on July 12, 2026. Recheck them before implementation because schemas and eligibility rules can change.