OpenAI Product Feeds: From Catalogs to Conversations
OpenAI’s new commerce feed is drastically evolving the shopping game. We’re no longer optimizing static listings for an SERP; we’re supplying machine-readable context to an assistant that negotiates intent in real time.
Search has always loved structured data. For years we’ve shipped well-formed product catalogs to Google Merchant and tuned attributes to win in Shopping. That mental model still helps—but OpenAI’s new commerce feed is drastically evolving the game. We’re no longer optimizing static listings for a SERP; we’re supplying machine-readable context to an assistant that negotiates intent in real time.
Here’s how it’s different and how we’ll approach it with semantic data.
What’s fundamentally different
I spent a few hours tinkering and reviewing the specifications and reading a few of the early commentary. Here is my take:
1) From “listing” to “reasoning input.”
A Google Merchant feed describes a product so it can be ranked and priced in a comparison grid. An OpenAI feed becomes evidence the assistant uses while reasoning inside a conversation. Attributes aren’t merely filters; they’re facts the agent mentions, contrasts, and turns into answers.
2) From keywords to use-cases.
Google expects taxonomy + attributes. OpenAI benefits from use-case semantics: what the product is for, what it pairs with, who it fits, and under what constraints (budget, materials, delivery window, accessibility, sustainability). Think “compatible with iPhone 15 Pro,” “works for cold brew,” “fits 28–30″ waists,” “vegan leather,” “next-day in Milan.”
3) From click-through to task completion.
Shopping ads chase CTR and conversions off-site. Agentic commerce optimizes for problem resolution in-chat: shortlisting, trade-off explanations, bundle suggestions, and—if enabled—instant checkout. The quality bar shifts from glossy creatives to clean facts, variant logic, inventory freshness, and clear policies. Remember, ChatGPT controls its own memory of you.
4) From one PDP to many variants.
Assistants excel when they can reason across variants (size, color, region, price, fulfillment). That means embracing item_group_id
+ per-SKU offers, not flattening everything into the parent. Variant hygiene is no longer optional. GS1 Digital Link data is foundational for higher-quality, context-aware product interactions, delivering a distinctive experience across categories. And the magic doesn’t stop online, these experiences can flow naturally into local retail.
5) From periodic uploads to near-real-time truth.
Google tolerates slower cadences. Assistants need fresh stock, price, and delivery estimates to avoid hallucinations and broken promises. Treat availability and shipping as live signals, not static attributes.
What the OpenAI feed wants (practically)
- Identifiers that won’t wobble: stable
id
(SKU/offer),item_group_id
for variants, plus GTIN/MPN when you have them. - Plain-text clarity: descriptions without HTML; avoid marketing fluff that can’t be reasoned over.
- Rich, typed attributes: condition, materials, dimensions with units, compatibility, care instructions, warranty.
- Related products: accessories, add-ons, and upgrades that enhance compatibility, expand capabilities, or improve performance.
- Media that proves it: primary + additional images; video or 3D where useful.
- Commercial truth: price with currency, sale windows, inventory quantity, preorder/ETA.
- Fulfillment reality: shipping regions, costs, and delivery estimates (ideally per region/warehouse).
- Policy surfaces: returns, privacy, terms, seller identity. These build trust and unlock checkout.
If you also enable Instant Checkout, plan for the server-side bits (checkout session endpoints, order notifications, payment token handling). It’s closer to an integration than a feed.
A KG-first blueprint for product feeds
1) Model products are entities, not rows.
Our Knowledge Graph already expresses Product
↔ Offer
↔ Organization
↔ Place
. We’ll map entities to feed records while preserving relationships the assistant can use (brand lineage, compatibility, accessories, store locations).
2) Promote use-case facts to first-class fields.
We’ll extract and normalize attributes that answer “Will this work for me, here, now?”—sizes (with systems), fit, allergens, power standards, region availability, and compatible devices. These become reason-ready snippets the agent can quote.
3) Treat variants as citizens.
Each variant gets its own entity with a shared item_group_id
. Parent PDP stays canonical; variants carry offer-level price, stock, personalized description and media.
4) Keep the truth fresh.
We already join, in most cases, the KG with inventory/OMS and pricing to keep availability
, inventory_quantity
, and shipping promises current. Stale data erodes trust; assistants remember. This will become even more interesting when the local inventory as well are added to the mix.
5) Make policies explicit and linkable.
Clear, crawlable URLs for returns, privacy, and terms—plus seller name and contact—are mandatory for assistant-mediated trust and checkout eligibility.
6) Write like we’re talking to a colleague.
The assistant isn’t swayed by superlatives. We write descriptions, product highlights and details that are specific, comparable, and testable: materials, tolerances, standards, care, and limitations. All of this is done already at scale using our Content Generation tool.
The mindset shift
Google Merchant rewards catalogs that rank. OpenAI rewards knowledge that helps—facts an assistant can rely on to guide someone to the right choice, confidently and quickly. That’s where structured data and graph thinking change the game.
With a Knowledge Graph as the source of truth, we don’t just list products—we model the domain and the language around it:
- Domain entity graph: products, offers, brands, categories, compatibility (“works with”), substitutes, bundles, store locations, return policies—typed and linked with Schema.org/GS1. This gives the agent grounded relationships to reason over (e.g., “this filter fits the Aeropress; this lens is for Nikon Z-mount; this size maps to EU 42”).
- Lexical graph: the text side—chunked PDP copy, specs, care instructions, size guides, manuals, reviews, and structured Q&A. We attach each chunk to the right entities, so the assistant can quote precise, verified passages instead of guessing.
The combination is powerful: the entity graph tells the agent what is connected to what; the lexical graph supplies the exact words and evidence to answer follow-ups (“how to clean it,” “is it vegan,” “will it arrive by Friday in Milan?”). This is the difference between a shoppable catalog and an assistant-ready product memory.
Practically, we ship three things in the feed (and keep them fresh):
- Facts: identifiers, price, stock, variants, dimensions with units, compatibility.
- Context: use-case attributes (fit, allergens, power standards, regional availability) and policy surfaces (returns, warranty).
- Evidence: linked text chunks and Q&A snippets the agent can cite verbatim.
OpenAI (and any other AI Agent) then has everything it needs to explain trade-offs, propose bundles, and complete tasks—not just rank SKUs. With a semantic layer (a Product Knowledge Graph), you’re ready to ship not just products, but understanding.
Make your catalog agent-ready with WordLift B+. Start your Product Knowledge Graph today.
Frequently Asked Questions on the Agentic Commerce Protocol (ACP)
What is the Agentic Commerce Protocol (ACP)?
The Agentic Commerce Protocol (ACP) is an open standard, co-developed by OpenAI and Stripe, that standardizes how AI agents, merchants, and payment systems interact to programmatically discover products and complete purchases.
It functions by defining machine-readable schemas and API endpoints that allow an agent to execute the entire commerce lifecycle: discovering a merchant’s products, constructing an order, requesting user consent, authorizing payment, and receiving fulfillment updates—all through a secure and standardized messaging framework.
How does a ChatGPT Product Feed look like?
Here is a simplified structured product feed.
What are the key technical components of the ACP architecture?
Think of ACP as a universal language that allows AI agents, merchants, and payment systems to communicate securely and efficiently. It’s an open standard designed for interoperability.
The core components include:
- Agent & Intent Schema: A standardized format for an AI agent to express a user’s goal, such as the intent to purchase a specific product with defined constraints (e.g., budget, delivery time).
- Capability Discovery: A mechanism for merchants to advertise their capabilities—what products are in their catalog, current pricing, availability, and shipping options—so agents can discover them.
- Standardized Checkout API: A consistent, predictable flow for an agent to build an order, get the user’s approval, and authorize payment.
- Authentication & Consent: A secure system of temporary tokens and consent records that allows an agent to act on a user’s behalf, with a clear audit trail that the user can revoke at any time.
- Pluggable Payment Layer: An adaptable interface that connects to various payment processors (like Stripe) and methods (such as credit cards or digital wallets).
- Post-Purchase Webhooks: Standardized event notifications for fulfillment processes, including inventory updates, shipping confirmations, and returns.
- Security & Auditing: A framework for cryptographically signing key messages and maintaining detailed logs to prevent fraud and resolve disputes.
How does ACP enable AI agents to create personalized shopping experiences?
ACP provides the standardized framework for communication and consent that AI agents need to act on a user’s unique preferences. It allows an agent to:
- Understand User Constraints: Pass critical information like budget, brand preferences, or dietary restrictions to a merchant system.
- Query Merchant Capabilities: Ask for specific product variants, sizes, or delivery windows.
- Execute Tailored Purchases: Leverage rich metadata from merchants—such as product bundles or custom fulfillment options—to create a hyper-personalized selection and checkout flow for the user.
This eliminates the need for custom, one-off integrations for each merchant, allowing any agent to provide a personalized experience with any ACP-enabled business.
How does the Agentic Commerce Protocol handle user data privacy?
The ACP framework is built on core principles of data privacy and user control:
- Explicit Consent: Agents can only act on a user’s behalf with an explicit, revocable consent token.
- Scoped Permissions: Agent actions are limited to authorized scopes, preventing overreach.
- Data Minimization: The protocol encourages agents to request only the data fields necessary to complete a transaction.
- Auditability: Users can review a clear log of their agent’s actions, ensuring transparency.
While the exact implementation depends on the vendors involved, the protocol’s design prioritizes user privacy.
What is Instant Checkout, and how does it work in ChatGPT?
Instant Checkout is a streamlined purchase flow designed to minimize friction. By leveraging securely stored payment, shipping, and consent data, it allows a customer to complete a purchase with a single confirmation, eliminating the need to fill out traditional checkout forms.
In the context of an AI assistant like ChatGPT, this process is even more seamless. The AI agent constructs the purchase order directly within the conversation, presents the terms, and upon user confirmation, authorizes the transaction via a payment processor like Stripe. This allows a purchase to happen at the point of discovery, creating a frictionless, in-context buying experience.
What technologies enable Instant Checkout and Agentic Commerce?
This new commerce paradigm is made possible by the convergence of several key technologies:
- Large Language Models & Agent Platforms (e.g., ChatGPT)
- Standardized Protocols (i.e., the Agentic Commerce Protocol)
- Advanced Payment Processors (e.g., Stripe)
- Digital Wallet Standards (e.g., Apple Pay, Google Pay)
- Modern Authentication & Telemetry Layers (e.g., OAuth, JWTs)