How to Prepare Product Feeds for AI Shopping Agents

What AI shopping agents need from a product feed

AI shopping experiences interpret a customer's constraints and try to match them with products. A request may include category, use case, size, material, compatibility, budget, delivery location, or timing. The agent can only compare those constraints reliably when the merchant supplies structured, current, and specific product facts.

OpenAI's current product-feed documentation describes identifiers, descriptions, pricing, inventory, media, and fulfillment options as core feed content. Google Merchant Center similarly requires correctly formatted product data and warns that missing identifiers, variant attributes, poor images, or conflicts between a feed and a website can limit eligibility or produce incorrect displays. These are not separate editorial preferences; they are operational requirements for keeping a catalog understandable.

A feed does not guarantee that a product will be shown. Relevance, availability, price, seller quality, policy compliance, and the destination's own systems still affect selection. The merchant's controllable task is narrower: provide accurate evidence, keep it synchronized, and remove ambiguity that would prevent a suitable product from being understood.

Continue reading: Agentic commerce for small business · OpenAI Agentic Commerce key concepts ↗

Choose a source of truth before building exports

Choose the system that owns each field before mapping any destination feed. The commerce platform may own sellable status and price. An inventory or warehouse system may own stock. A product information system may own descriptions, attributes, and media. A shipping service may calculate delivery options. The feed pipeline should assemble approved values from these owners rather than create a second catalog that employees update by hand.

Document field ownership in plain language. For example, marketing may propose a title, merchandising approves it, the commerce platform stores it, and the feed exporter reads it. When the website and feed disagree, the team should know which value wins and who corrects the underlying record.

Avoid channel-only corrections that never return to the source. If a color, GTIN, or package weight is wrong in one feed, fix the approved product record and republish all affected destinations. Otherwise each channel gradually becomes a different version of the same product.

Continue reading: AI workflow automation guide

Keep product and variant identifiers stable

A product ID should remain attached to the same sellable item over time. Google recommends using a unique value, commonly the SKU, and keeping it stable when product data changes. OpenAI's feed specification also relies on identifiers to connect catalog records with price, inventory, media, and seller information. Reusing an old ID for a different item can join the wrong facts to the wrong product.

Model variants deliberately. A blue small shirt and a blue medium shirt may share a parent style but require separate sellable records because availability, price, barcode, or image can differ. Use a group identifier for the parent relationship and a unique product ID for every purchasable variant. Supply the attributes that distinguish them, such as size, color, material, pattern, capacity, or compatibility.

Use manufacturer identifiers only when they are genuinely assigned. Do not invent a GTIN, MPN, ISBN, or brand to fill a required-looking field. When a product legitimately has no global identifier, follow the destination's documented rule for that case and retain a dependable internal SKU.

Continue reading: Google Merchant Center product data specification ↗

Write titles and descriptions for retrieval, not slogans

A useful product title identifies the item and its distinguishing attributes without forcing the agent to infer the basics. Put the product type, important variant, model, size, or compatibility in a natural order. Remove promotional filler, repeated capital letters, and claims that do not help a shopper decide whether the product fits the request.

Descriptions should explain observable product facts: what the item is, who or what it is for, important materials, dimensions, included parts, compatibility, care, limitations, and meaningful features. Benefits are useful when they follow from a verifiable feature. Unsupported statements such as 'best,' 'safest,' or 'guaranteed to work' create risk and provide little structured evidence.

Use the same factual foundation on the landing page and in the feed. The wording does not need to be character-for-character identical, but the material claims must agree. If generative AI helps draft product content, preserve human approval and use any destination field that identifies algorithmically generated text when the specification requires it. Google, for example, provides structured title and description attributes that can declare trained algorithmic media.

Continue reading: AI vs machine learning

Synchronize price, availability, and the landing page

Price and availability are decision fields, not decorative metadata. The feed should specify the same currency, current price, sale conditions, condition, and purchasable status that the customer sees. If a sale has a start and end time, publish those boundaries consistently. If stock reaches zero, stop claiming that the item is available.

The landing page must support the exact product or variant in the record. It should load reliably, expose the offer without requiring a visitor to change country or variant to discover the stated price, and keep important information visible to both people and crawlers. Google requires structured data to match the page and recommends server-returned markup rather than markup added only after JavaScript runs.

Use Product and Offer structured data as a public consistency layer. At minimum, the visible page, structured data, and merchant feed should agree on product identity, price, currency, availability, condition, and URL. Structured data does not replace a destination feed, and a feed does not repair a misleading product page. Each source verifies the others.

Continue reading: Google Product structured data ↗

Use images as product evidence

Product images should help a shopper verify the exact item, not merely create a mood. Use a clear primary image with the product fully visible, then add useful views for scale, material, details, packaging, and included parts. Variant-specific images are important when color, pattern, finish, or configuration changes what the buyer receives.

Keep image URLs stable and accessible. Do not place essential product facts only inside an image because a system may not read them reliably and a customer may not be able to access them. Avoid watermarks, placeholder graphics, borders that consume the frame, or lifestyle scenes that conceal the actual product.

Create an image-quality check in the catalog workflow. Confirm that the file belongs to the record, the variant matches, the resolution meets the destination requirement, the background and crop are appropriate, and the image does not contain restricted or misleading content. When an image changes materially, update the source record and let the pipeline publish the approved asset.

Publish fulfillment, returns, and seller context

Shopping decisions often depend on the total offer rather than the product alone. A lower item price may not be useful when shipping is unavailable, delivery misses the required date, or the return policy excludes the category. Supply destination, service level, cost, handling time, and delivery information using the destination's supported fields instead of hiding them in promotional copy.

Return information should state the window, method, fees, exclusions, and responsible party. Keep the feed, policy page, checkout, and customer-service procedure aligned. If a product is final sale or has hygiene, custom, hazardous, or perishable restrictions, disclose those conditions before purchase.

Seller identity and policy links also support trust. ChatGPT's shopping documentation explains that merchant selection may consider availability, price, quality, and whether the seller is the maker or primary merchant. That does not create a fixed ranking formula. It does mean that accurate seller and offer context are part of the information a shopper may need to compare merchants.

Continue reading: ChatGPT shopping guidance ↗

Design refresh, validation, and reconciliation controls

A successful upload is not the same as a healthy feed. Define what is sent, how often it is sent, how the destination acknowledges records, and how errors return to the responsible owner. OpenAI's current onboarding guidance starts with a sample feed, validation, and regular catalog delivery; its key-concepts guide describes daily snapshots for approved direct-feed integrations. Price and inventory may need a faster path where the integration supports it.

Validate before delivery. Required fields should be present, values should use the correct type and accepted vocabulary, URLs should resolve, images should be reachable, variants should be complete, and business rules should detect impossible combinations. A zero price on a paid product, an in-stock status with no sellable quantity, or a size value outside the product's variant set should stop the record.

Reconcile after delivery. Record the batch, timestamp, schema version, number of submitted records, accepted records, warnings, and rejected records. Route each error to a named owner and track whether the source data, mapping, or destination rule caused it. When a delivery fails completely, preserve the last known good feed and follow a documented recovery path rather than publishing a partially assembled catalog.

Continue reading: OpenAI product-feed get-started guide ↗

Run a controlled product-feed readiness review

Begin with a representative sample instead of the entire catalog. Include a simple product, a multi-variant item, a sale item, a temporarily unavailable product, an item with unusual shipping, and a product with a restricted return policy. Trace each record from source systems through the export to the live page and structured data.

Test customer-relevant questions rather than only file syntax. Can a system distinguish every variant? Does the shown price match checkout? Is an unavailable option excluded? Are delivery and returns clear? Can the team identify who approved a claim? Technical validation and merchandising review should reach the same conclusion about what the customer will receive.

Roll out only after the sample passes and the monitoring loop works. Direct OpenAI product-feed onboarding is currently limited to approved partners, and Instant Checkout also requires approval. A retailer that is not eligible can still improve its source catalog, website, structured data, Google Merchant Center feed, policies, and internal controls. Those foundations are useful across shopping surfaces rather than being work for one platform alone.

• Confirm one source of truth and a named owner for every critical field.
• Check stable IDs, verified manufacturer identifiers, and complete variant relationships.
• Compare price, currency, availability, condition, and sale timing with the live page.
• Verify image accuracy, variant coverage, stable URLs, and destination requirements.
• Test shipping, returns, seller identity, and policy links for representative products.
• Validate the file before delivery and reconcile accepted, warned, and rejected records afterward.
• Record approvals, mapping changes, incidents, and the last known good delivery.

Continue reading: AI agent governance framework · AI agent definition