Lexsis AI
All articles
Agentic CommerceEcommerceGuides

How to Structure Product Data for ChatGPT and Perplexity

Build a practical product-data contract for AI shopping across ChatGPT, Perplexity, product feeds, storefronts, variants, offers, and fulfillment.

By Aditya Vernekar (Adi)
10 min read7 views

TL;DR

  • AI shopping systems need a dependable product entity, not a loose collection of marketing copy.
  • A product-data contract covers identity, product attributes, variants, price, availability, fulfillment, policies, evidence, source URLs, and freshness.
  • Keep the catalog, product page, structured data, feeds, and checkout offer aligned. A complete field in one system cannot repair a contradiction in another.
  • Write for comparison. Make the facts that distinguish products easy to retrieve, verify, and explain.
  • Shopify is a practical starting point for many teams, but the contract should remain portable across ecommerce platforms and shopping destinations.
  • Better data can improve clarity and reduce ambiguity for AI shopping workflows. It does not guarantee a mention, citation, recommendation, ranking, or sale.

When a shopper asks ChatGPT or Perplexity to find a product, the system may need to identify the right product, compare attributes, select a variant, check the current offer, explain why the item fits, and send the shopper to a reliable buying path.

That makes product data an operating concern for ecommerce, merchandising, SEO, paid media, and engineering teams. The goal is one clear, reviewable description of each product and offer that can travel across discovery surfaces.

The exact ingestion path differs by platform. OpenAI documents product feeds and merchant data for ChatGPT shopping, while Perplexity describes its own discovery and buying workflows. Read the OpenAI commerce documentation and Perplexity Instant Buy overview as platform references, not substitutes for catalog governance.

Shopify's default product-discovery baseline

Shopify already provides a structured starting point for agentic shopping. Eligible products can be syndicated through Shopify Catalog with titles, descriptions, options, images, prices, availability, and other key attributes. Shopify can keep inventory and pricing current, and its agentic storefront settings can make eligible products discoverable through connected channels. Every store also exposes /agents.md, /llms.txt, and /llms-full.txt for store context. These files do not replace product data.

On supported Liquid storefronts, Shopify's WebMCP tools can help an agent search the catalog, inspect products and variants, update a cart, answer policy questions, and navigate toward checkout. That is a useful transport layer. It does not decide whether a product title is clear, whether a claim is supported, or whether a variant is the right fit.

Shopify providesThe brand still owns
Catalog distribution and product updatesProduct identity, attributes, and variant labels
Store context files and supported storefront toolsEvidence, reviews, policies, and limitations
Channel and checkout controls where availableMarket rules, offer clarity, and page accuracy
Native product and offer fieldsOwnership, validation, and cross-surface consistency

Read Shopify's agentic storefront guidance, product discovery guidance, and WebMCP documentation for current availability and channel limits.

Why AI shopping needs a product-data contract

A product page, feed, structured data, and checkout offer serve different jobs. They should agree without being treated as the same representation.

The risk appears when they disagree:

  • The title says one thing while the selected variant has another name.
  • The feed shows a price the landing page does not honor.
  • A product is available, but the relevant option is out of stock.
  • A material, ingredient, compatibility detail, or use case appears only in an image.
  • A market-specific shipping or return statement is presented as universal.
  • A generated description fills an unknown attribute with a plausible guess.

An AI system may then recommend the wrong item or omit a comparison. A contract gives each field an owner, source, format, and validation rule.

The practical product-data contract

Start with one representative product from each major category. Document the following fields before scaling the model across the catalog.

Contract areaRequired contentReview question
IdentityBrand, product name, product ID, canonical URL, product type, GTIN or other approved identifierCan a system distinguish this product from similar items?
Decision attributesMaterial, ingredients, dimensions, capacity, compatibility, fit, flavor, format, dietary or safety informationWhich facts change whether a shopper considers it?
VariantsOption names, combinations, variant IDs, variant URLs, variant images, variant price and stockCan the shopper select the exact item being described?
OfferPrice, currency, sale terms, subscription terms, tax presentation, market, sellerIs this the current purchasable offer?
AvailabilityIn-stock state, quantity rules, backorder or preorder state, effective timeCan the shopper buy this option now, and under what conditions?
FulfillmentShipping regions, delivery terms, pickup options, return policy, exchange limitsAre the post-purchase conditions clear for this market?
EvidenceApproved claims, specifications, reviews, certifications, usage instructions, limitationsWhat source supports each statement?
MediaPrimary image, variant images, video, alt text, media URLsCan the product and its important differences be inspected?
ProvenanceSource system, owner, last reviewed time, transformation rule, change historyCan a reviewer explain where this value came from?

1. Make identity unambiguous

Use a stable product ID and canonical URL. Keep the brand, product name, product type, and important identifier consistent across the catalog, page, structured data, and feeds.

Avoid internal abbreviations. “Hydration Powder, Citrus, 30 Servings” is easier to compare than “HP-CIT-30.” If two products have similar names, include the attribute that separates them: fit or material for apparel, model or compatibility for electronics, and flavor, format, or pack count for food.

The Schema.org Product vocabulary and Google's Product structured data guidance are useful references for entity fields search systems can interpret.

2. Separate product facts from offer facts

A product can have several offers. Price, currency, availability, seller, shipping, and return terms may vary by market, channel, subscription status, or selected variant. Store those distinctions explicitly. Do not let a product-level “in stock” label hide an unavailable size or color.

Google's merchant listing documentation is a helpful checklist for offer details such as price, availability, shipping, and returns. Your own checkout and policy systems remain the final authority for what a shopper can actually receive.

3. Model variants as relationships

Variants are selectable combinations of options that can change price, image, availability, dimensions, or compatibility.

Give every option a shopper-readable label:

  • Color: Navy
  • Size: Medium
  • Capacity: 500 ml
  • Pack: 12 cans
  • Compatibility: iPhone 15

Keep the parent product, variant ID, option values, URL, image, price, and stock state connected. If a shopper asks for “the navy medium,” the system should identify whether that combination exists and is available. If the request is ambiguous, ask for clarification rather than select a nearby option.

For complex variants, review Google's product variant structured data guidance. The markup should reflect the catalog relationship and visible selection experience.

4. Add the attributes that drive comparison

AI shopping queries often contain constraints: fragrance-free, compatible with a device, suitable for a dietary preference, large enough for a use case, or available before a date. These details determine the candidate set.

Build category-specific attribute templates:

  • Beauty: ingredients, concern, skin or hair context, format, sensitivities, usage, size.
  • Food and beverage: ingredients, allergens, dietary attributes, flavor, serving format, pack size, storage.
  • Apparel: material, fit, measurements, size system, care, color, construction.
  • Electronics and home: model, compatibility, dimensions, capacity, power requirements, included items, warranty.

Do not infer a benefit, certification, safety property, or compatibility from a product name. If the value is unknown, leave it unknown or route it for review.

Write product data for comparison, not persuasion

Marketing copy can be memorable, but AI shopping needs language that answers a constrained question. Lead with what the product is, then add the attribute or proof that explains why it may fit.

A useful description pattern is:

  1. Identify the product and its main use.
  2. State the decision-critical attributes.
  3. Explain the material, formula, construction, or mechanism where relevant.
  4. Add limitations, care, compatibility, or usage requirements.
  5. Link to the detailed product page and supporting policy information.

Keep claims tied to an approved specification, manufacturer document, certification record, real review, or policy page. Preserve the source reference in the catalog workflow.

Reviews are evidence, not product specifications. A customer saying that a shirt feels light does not establish a measured fabric weight. Keep the difference visible so an AI system is less likely to turn anecdote into a universal claim.

Align every product representation

Create a comparison for a sample of high-value products:

SurfaceCheck
Source catalogProduct identity, attributes, variants, inventory, prices, policies
Product pageVisible name, facts, selected offer, media, reviews, shipping and returns
Structured dataProduct, variant, offer, price, currency, availability, review values
Shopping feedSubmitted title, description, identifiers, images, offer, destination
AI-facing integrationAccepted fields, source URLs, refresh behavior, errors, exclusions
CheckoutFinal selected product, variant, price, currency, terms, fulfillment

The Google Merchant Center product data specification is a useful reference for feed requirements, even when Google is not your only destination. For Shopify merchants, the Shopify product and variant documentation helps clarify how the catalog represents option combinations.

Shopify is the current entry point, not the boundary

Shopify supplies a useful catalog and storefront baseline, but the brand still owns field mapping, conflict resolution, and cross-surface consistency. Mapping a metafield does not make its value accurate. Keep the contract portable across marketplaces, regional catalogs, subscriptions, and headless stacks. See the Shopify product feed optimization guide.

A review-gated workflow for AI shopping readiness

1. Inventory the catalog

Select priority products by category or complexity. Record fields that are available, missing, transformed, or disputed.

2. Define ownership

Merchandising can own names and attributes. Operations can own inventory and fulfillment. Legal or compliance can review regulated claims. Engineering can own feeds and rendering.

3. Normalize and validate

Standardize units, currencies, option labels, identifiers, URLs, and date formats. Add required fields by category. Validate combinations, not just individual cells. A valid color and a valid size can still form an unavailable variant.

4. Distribute deliberately

Send only supported fields and offers. Preserve the source value, transformation, destination value, timestamp, and error response. Do not let a feed or connector become an unowned second catalog.

5. Test buyer questions

Build a prompt set from real shopping decisions: “best fragrance-free moisturizer for sensitive skin,” “black running shoes in size 10,” or “12-pack electrolyte drink under a defined price.” Check whether products match the constraints and whether the explanation is supported.

6. Monitor changes

Watch for stale prices, unavailable variants, broken URLs, missing images, rejected records, policy mismatches, and changes in platform descriptions.

Where Lexsis fits

Lexsis helps ecommerce teams connect AI visibility work with the product and storefront experience that follows discovery. The AI visibility workflow can help teams monitor AI answers, competitor inclusion, answer language, and citations when available. Shopify is the first integration today, while the operating model applies broadly. Book a Lexsis demo to connect product truth, discovery evidence, and storefront execution.

Final checklist

Before calling a catalog ready for ChatGPT, Perplexity, or another AI shopping surface, confirm:

  • Every product has a stable identity and canonical destination.
  • Decision-critical attributes are structured by category.
  • Variants have readable option values and connected offer state.
  • Prices, currency, availability, shipping, and returns are scoped to the right market.
  • Claims and reviews have clear evidence.
  • Images, URLs, page content, structured data, feeds, integrations, and checkout agree.
  • Test prompts cover real constraints, ambiguity, and unavailable options.

Good AI shopping data is a maintained contract between the product, its evidence, and the systems that help a shopper decide.

Related themes

#product data for ChatGPT#Perplexity shopping#AI shopping#agentic commerce#ecommerce product data#AI visibility#product feed

Ready for the agentic commerce era?

AI agents are sending shoppers to your store. Lexsis makes sure they land on pages built for them, not generic PDPs.