Agentic Commerce Feed Readiness: What UCP, ACP and AI Mode Actually Require

Something quietly structural happened to e-commerce over the last eighteen months, and most of the writing about it has been either breathless or vague. Here is the concrete version. When a shopper asks an AI assistant to find them a product, the assistant does not visit your homepage. It does not see your photography, your brand story, or the product description your copywriter agonised over. It reads structured product data — a feed, a schema block, an API response — and decides from that whether to recommend you or someone else. Your feed was always the input to your ads. It is now the input to the recommendation itself. Three systems now define how that works: **Google's Universal Commerce Protocol (UCP)**, **OpenAI and Stripe's Agentic Commerce Protocol (ACP)**, and **Perplexity's merchant program**. They are frequently written about as if they were the same thing wearing different logos. They are not. They consume different data, in different formats, with different requirements, and they are live in different countries. This guide covers what each one actually requires at the field level, what genuinely overlaps, what doesn't, and — because most readers of this blog do not sell primarily in the United States — what is worth doing if agentic checkout hasn't reached your market yet. --- ## The landscape, honestly | | **UCP** (Google) | **ACP** (OpenAI / Stripe) | **Perplexity Merchant Program** | |---|---|---|---| | **Announced** | January 11, 2026, at NRF | September 2025 | November 2024 | | **Governance** | Open source, Google-initiated, co-developed with Shopify, Etsy, Wayfair, Target, Walmart | Open standard, maintained by OpenAI and Stripe | Proprietary program | | **What it covers** | Discovery, cart, checkout, identity linking, post-purchase | Discovery, checkout, payments, fulfilment notifications | Discovery, citation, checkout | | **Consumer surfaces** | AI Mode in Search, Gemini, YouTube Shopping | ChatGPT | Perplexity | | **Data source** | Merchant Center feed → Shopping Graph | Merchant-pushed feed to an OpenAI endpoint | Merchant program feed, plus crawling | | **Feed format** | Merchant Center spec (XML/TSV/API) | CSV or JSON, structured per the ACP product feed spec | Google Shopping format, delivered via API, SFTP or S3 | | **Checkout availability** | Selected merchants, US / Canada / Australia at time of writing | Approved partners | US-scoped | | **Compatible with** | A2A, AP2, MCP | Stripe payment rails, MCP | — | Two observations before going further. **First: discovery and checkout are separate problems.** Being *findable* by an AI agent is a data-quality problem that applies everywhere in the world, today. Being *transactable* inside an AI surface is a protocol-integration problem that is currently limited to a handful of markets. Conflating the two is the single most common mistake in the coverage of this topic, and it leads merchants outside the US to conclude none of it applies to them. The opposite is true — the discovery layer applies to everyone and is where almost all the available value currently sits. **Second: the protocols are converging on infrastructure, not on data.** UCP explicitly works alongside A2A, AP2 and MCP. ACP is built on the same broad idea. But their product schemas remain genuinely different, and a feed built for one does not drop into the other. That is a feed management problem, not a strategy problem, and it has a straightforward solution: maintain one enriched internal source of truth, and generate per-destination exports from it. --- ## Layer 1: The discovery baseline (applies everywhere, today) Before any protocol-specific work, there is a set of requirements every one of these systems shares. If you do nothing else from this article, do this layer. It costs nothing in integration work and it is what actually determines whether you get recommended. ### Product identifiers GTIN is the join key of the entire AI shopping ecosystem. Every one of these systems uses standardised identifiers to match your product to the same product elsewhere — to compare prices, to aggregate reviews, to know that your listing and a review site's listing describe the same object. Missing GTINs don't produce an error message. They produce silence: your product simply isn't part of the comparison the agent is running. Perplexity in particular is reported to weight identifier completeness more strictly than Google does. Audit GTIN coverage as a percentage of active SKUs. If it's below 90%, that number is your first project. ### Attribute completeness Traditional Shopping ads worked with a fairly small set of required attributes. An agent reasons over everything you give it. Each populated field is a potential reason for the agent to recommend you — material, dimensions, compatibility, care instructions, power requirements, warranty terms. The mental shift is this: an attribute is no longer a filter value. It is an **argument**. `material: full-grain leather` is not a facet — it is the sentence the agent uses when a shopper asks which of two bags will age better. ### Consistency across every surface This is the requirement most often skipped and most likely to hurt you. A human shopper who sees ₺2,499 on your product page and ₺2,399 in a comparison result shrugs and moves on. An agent treats the mismatch as a reliability signal about your data — and a checkout that fails because the price moved is a much worse outcome for the agent's operator than simply not recommending you. Audit for consistency across: your product pages, your Merchant Center feed, your on-page structured data, and any marketplace listings you run. Prices, availability, shipping terms, and return policy all need to agree. Return and shipping policy in particular are increasingly read by agents and quoted back to shoppers. ### Freshness The nightly feed refresh is no longer sufficient. Google's Shopping Graph refreshes at a scale measured in billions of listings per hour and prefers live data; OpenAI's feed ingestion accepts refreshes as frequently as every 15 minutes. The reason isn't cosmetic. When an agent is capable of completing a transaction, stale inventory data doesn't produce a mildly disappointed shopper — it produces a failed transaction. Systems that fail transactions get down-weighted. Practical target: price and availability propagating within 15 minutes for fast-moving inventory, hourly at minimum for everything else. For most merchants this means moving from scheduled file fetches to API-based or push-based updates. ### Crawl access Check your `robots.txt` for the AI crawlers. Many merchants blocked them reflexively in 2024 and 2025 during the "should we let AI train on our content" debate, and never revisited the decision. Blocking the crawler that populates a shopping index is a different decision from blocking a training crawler — and it is frequently made by accident, by a team that never saw it as a commerce decision. --- ## Layer 2: Google — conversational attributes This is the most concrete, least discussed and most immediately actionable part of the entire topic, and it's the section I'd read twice. Alongside UCP, Google added a set of **conversational attributes** to the Merchant Center product data specification. They are optional, they complement your existing product data, and their explicit purpose is to help AI systems and conversational agents understand the specific nuances of your products. Google states that including them does not affect the approval status of your existing products. That last point matters: **the downside risk is zero.** You are adding descriptive data, not changing anything Google validates for approval. Here is the set: | Attribute | What it carries | Example value | |---|---|---| | `question_and_answer` | Q&A or FAQ content about the product | `"Does it have a headphone jack?":"This version doesn't have a headphone jack."` | | `document_link` | A related PDF — manual, assembly instructions, spec sheet, care guide | `https://example.com/manual.pdf` (comma-separate for multiple) | | `related_product` | Structured relationships to other products. Sub-attributes: `relationship_type`, `identifier_type`, `identifier` | `required_part:id:AZ7B, accessory:gtin:811571013579` | | `item_group_title` | A human title for the variant family, used with `item_group_id` | `Organic cotton men's T-shirt` | | `variant_option` | All variant-identifying properties as name/value pairs. Sub-attributes: `name`, `value` | `width:narrow,size:8` | | `popularity_rank` | This product's popularity as a percentage of your total inventory — higher is better performing | `95.5` | Google's own worked example, for one variant of a phone, combines `item_group_title`, `variant_option`, `question_and_answer`, `product_highlight`, `product_detail`, `related_product`, `popularity_rank` and `document_link` on a single item alongside the standard attributes. ### Why these six, and what they're really for Look at what each one does for an agent: - **`question_and_answer`** is the agent's script. A shopper asks "is this dishwasher safe?" and the agent either has your answer or it doesn't. If it doesn't, it either says it doesn't know — which loses the sale — or recommends a competitor who did populate the field. - **`document_link`** gives the agent a document it can reason over. Assembly instructions answer "how hard is this to put together?" Spec sheets answer compatibility questions you couldn't anticipate. - **`related_product`** is how cross-sell survives the disappearance of your website from the shopping journey. `required_part` in particular prevents the worst outcome in agentic commerce: a shopper buying something that doesn't work on its own. - **`item_group_title` and `variant_option`** solve the problem that has bedevilled variant feeds since they existed — an agent seeing eight rows and not understanding they are one product in eight sizes. This is the variant structuring problem in a new context. - **`popularity_rank`** is you telling the agent which of your products actually sells. Nobody else can give it that signal. ### Getting them populated at scale The honest obstacle: nobody has a `question_and_answer` column sitting in their PIM. But most merchants do have the raw material — customer service ticket themes, on-page product FAQs, review content, returns reasons. The highest-value Q&A pairs are usually visible in the questions your support team answers most often, and in the reasons products get returned. A return that says "didn't fit my machine" is a compatibility question you should be answering in the feed. Google recommends adding these via a [supplemental data source](https://www.feedance.com/supplementary-feeds) rather than reworking your primary feed — which is the right call operationally, because the team that owns product data and the team that owns support content are rarely the same team. At catalog scale this becomes a rules problem: derive `item_group_title` from your parent product name, build `variant_option` from the attributes you already store as colour and size, compute `popularity_rank` from your own sales data as a percentile, and map `document_link` from your existing manual library by SKU pattern. In Feedance these are [feed rules](https://www.feedance.com/feed-rules) applied on every refresh, and `popularity_rank` in particular can be recomputed from sales data automatically rather than maintained by hand. Start with your top 200 SKUs by revenue and three Q&A pairs each. That's a week of work and it covers the majority of your agent-visible impressions. --- ## Layer 3: OpenAI's ACP — a genuinely different shape If you assume the ChatGPT feed is your Google feed with different column names, you will build the wrong thing. The ACP product feed schema is structurally different, and the differences are instructive about what agentic systems want. **Products contain variants.** Google's feed is flat: every variant is its own row, tied together by `item_group_id`. ACP inverts this — a product object is the canonical record, and it holds an array of variant objects. Each variant carries its own id, title, price, availability, media and options. This is a better model for an agent, and it's worth understanding why. A flat feed makes the agent reconstruct "this is one shoe in nine sizes" from a shared grouping key. A nested feed hands it that fact directly. Merchants with variant-heavy catalogs — fashion above all — get a real accuracy benefit here. **Prices are integers in minor units.** `{ "amount": 7999, "currency": "USD" }` is 79.99 USD. Not a decimal string. Any pipeline doing float arithmetic on prices needs to be checked before it silently produces something wrong. **Descriptions are objects, not strings.** The `description` object accepts `plain`, `html` and `markdown` — you can supply any combination. **Seller policy links are first-class.** The `seller` object holds `links`, typed as `privacy_policy`, `terms_of_service`, `refund_policy`, `shipping_policy` or `faq`. Read that list again: the agent wants your returns policy as a structured field. In a world where the shopper never sees your website, your policies have to travel with the product. **Condition is an array.** `["new"]`, and more than one value may apply — which anticipates resale and refurbished inventory. A minimal shape: ```json { "id": "SKU12345", "title": "Trail Running Shoe", "description": { "plain": "Waterproof trail shoe with cushioned sole." }, "url": "https://example.com/products/SKU12345", "media": [ { "type": "image", "url": "https://example.com/images/SKU12345.jpg", "alt_text": "Black trail running shoe", "width": 1200, "height": 1200 } ], "variants": [ { "id": "SKU12345-BLK-10", "title": "Black / 10", "barcodes": [{ "type": "gtin", "value": "1234567890123" }], "price": { "amount": 7999, "currency": "USD" }, "list_price": { "amount": 9999, "currency": "USD" }, "availability": { "available": true, "status": "in_stock" }, "variant_options": [ { "name": "color", "value": "Black" }, { "name": "size", "value": "10" } ], "categories": [ { "value": "Apparel & Accessories > Shoes", "taxonomy": "merchant" } ], "condition": ["new"], "seller": { "name": "Example Store", "links": [ { "type": "refund_policy", "title": "Returns policy", "url": "https://example.com/returns" } ] } } ] } ``` The feed file is accompanied by a header carrying `feed_id`, `account_id`, `target_merchant` and `target_country` — note that country is set at the feed level, which means multi-market merchants ship one feed per market. OpenAI's recommended delivery pattern is a full feed once daily via file upload, with intra-day updates pushed through the API. Small catalogs can do both through the API. One thing worth being clear-eyed about: OpenAI's in-chat checkout has had a more complicated first year than the announcements suggested, and the company has publicly acknowledged that the initial Instant Checkout implementation was less flexible than intended, shifting emphasis toward product discovery with a handoff to the merchant's site for payment. If you are prioritising, treat ACP **discovery** as the near-term opportunity and ACP **checkout** as a longer bet. --- ## Layer 4: Perplexity Perplexity's merchant program is the least documented of the three and, for that reason, the most misreported. Guides that publish a detailed Perplexity field specification are extrapolating from Google — no official field spec is published. What is known: - The program is free and application-based; onboarding has been expanding through 2025 and 2026. - The feed is delivered as CSV or XML, over API, SFTP or a dedicated S3 bucket, in Google Shopping format. - Product data completeness functions as a ranking input — more complete data gives the system more to work with when generating comparisons and pros-and-cons summaries. - Identifier completeness, review data and on-page Schema.org markup appear to be weighted more heavily than Google weights them. - A feed is not strictly required to be cited — a crawlable catalog with clean Product schema can be surfaced — but a feed improves the odds of being a recommended product. - Transactional features are US-scoped. Outside the US you can be cited and linked, not sold through. The practical read: for Perplexity, the work is **Schema.org hygiene on your product pages plus review data**, not a new feed integration. If your PDPs already emit valid `Product` and `Offer` markup with GTIN, price, availability and `aggregateRating`, you have done most of it. --- ## Layer 5: Checkout — and the honest geography This is where the coverage tends to get carried away, so let's be precise about what is actually live. **UCP checkout.** Available to selected merchants, with product eligibility in the United States, Canada and Australia at time of writing. It surfaces as a Buy button on eligible listings in AI Mode and Gemini. You remain the seller of record. Customers pay through Google Pay using credentials already in their Google Wallet. Participation requires meeting the technical requirements, submitting an interest form, and completing the implementation — and critically, **only listings carrying the `native_commerce(checkout_eligibility)` product attribute will show the Buy button.** That last detail is the feed-level takeaway. Everything else in UCP checkout is backend integration work; the eligibility signal itself lives in your product data. Google announced simplified UCP onboarding through Merchant Center in March 2026, alongside cart, catalog and identity-linking capabilities, and has signalled global expansion through 2026. **ACP checkout.** Requires implementing three flows — a product feed, a checkout API, and delegated payment through a PSP such as Stripe — and is open to approved partners. **Perplexity Buy with Pro.** US-scoped. ### If you sell outside the US Most of our clients sell in Turkey, the Gulf, and Europe. Here is the honest position for that situation: **Agentic checkout is not available to you yet. Agentic discovery is, completely, today.** A shopper in Istanbul asking Gemini or ChatGPT to compare products is getting an answer built from structured product data right now. Whether that answer includes your products is determined entirely by Layer 1 and Layer 2 above — identifier coverage, attribute completeness, conversational attributes, freshness and consistency. None of that requires a protocol integration, a US entity, or an early-access application. So the sequencing for a non-US merchant is clean: 1. **Do Layer 1 completely.** It is pure upside and it also improves your existing Shopping and Performance Max performance. 2. **Do Layer 2 now.** Conversational attributes are available in the standard Merchant Center specification, carry no approval risk, and almost nobody in your market has populated them. 3. **Watch Layer 5.** When checkout reaches your market, the merchants who did Layers 1 and 2 will integrate in weeks. The merchants who didn't will start from an incomplete catalog. The advantage of moving early is not that you'll transact in ChatGPT this quarter. It's that catalog data quality takes months to fix and cannot be bought in a hurry when the window opens. --- ## ⚠️ One deadline that is not optional Separate from all of the above, and far more urgent: **Google's Content API for Shopping sunsets on August 18, 2026.** After that date, calls to the legacy v2.1 endpoints stop working. This affects programmatic integrations only — manual uploads, scheduled fetches and Google Sheets feeds are unaffected. Merchants on official platform integrations (Shopify's Google & YouTube channel, WooCommerce's Google Listings & Ads) are handled by the platform. Custom integrations and some third-party tools need to migrate to Merchant API v1 manually. Two things to check today: in Merchant Center, go to **Settings → Data Sources** and look at the Source column. If it reads "Content API," you have an action item. And be aware that feed labels do not automatically carry over — if your Google Ads campaign structure depends on feed labels, a migration done carelessly can stop campaigns serving. If your feed reaches Merchant Center through Feedance, this migration is handled on our side and your export configuration doesn't change. --- ## What "agent-ready" means field by field Pulling the layers together into one operational view: | What the agent needs to know | Google Merchant Center | ACP | Why it matters | |---|---|---|---| | Which product is this, universally | `gtin`, `mpn`, `brand` | `barcodes[]` | Cross-source matching, comparison, review aggregation | | What is it, in one line | `title` | `title` | The first thing the agent reads | | What is it, in detail | `description`, `product_detail`, `product_highlight` | `description` (plain/html/markdown) | Raw material for the agent's reasoning | | Which variants exist | `item_group_id`, `item_group_title`, `variant_option` | nested `variants[]`, `variant_options[]` | Prevents the agent treating one product as nine | | What does it cost, right now | `price`, `sale_price` | `price`, `list_price` (minor units) | Stale price = failed transaction | | Can I get it | `availability`, `availability_date` | `availability.available`, `availability.status` | Same | | What does it look like | `image_link`, `additional_image_link`, `video_link` | `media[]` with `alt_text` | Multimodal models read images, not just fields | | Common questions | `question_and_answer` | (in description) | Directly answers shopper objections | | Supporting documents | `document_link` | — | Manuals, specs, compatibility | | What goes with it | `related_product` | — | Cross-sell after the website disappears | | What sells well | `popularity_rank` | — | Your own ranking signal | | What are your policies | account-level, `shipping`, `return_policy_label` | `seller.links[]` typed | Agents quote your return policy back to shoppers | | Where does it fit | `google_product_category`, `product_type` | `categories[]` with `taxonomy` | Query routing | Reading that table sideways is the useful exercise: notice how much of the right-hand behaviour is driven by fields that are optional, and that most catalogs leave empty. --- ## The readiness checklist **Table stakes — do these first, they apply to every surface** - [ ] GTIN coverage above 90% of active SKUs - [ ] Price and availability propagating in 15 minutes to an hour, not overnight - [ ] Price, availability, shipping and returns consistent across site, feed and marketplaces - [ ] All images at least 500×500 (also required by Google from January 31, 2027) - [ ] Valid `Product` and `Offer` Schema.org markup on every PDP, with `aggregateRating` where you have reviews - [ ] AI crawlers not blocked in `robots.txt` by accident - [ ] `google_product_category` mapped correctly, not left to inference - [ ] Content API migration confirmed complete **Competitive — most of your market has not done these** - [ ] `question_and_answer` populated on your top 200 SKUs, 3+ pairs each - [ ] `item_group_title` and `variant_option` on every variant family - [ ] `popularity_rank` computed from your own sales data - [ ] `document_link` mapped from your existing manual and spec-sheet library - [ ] `related_product` for accessories and required parts - [ ] `video_link` on hero products - [ ] Attribute completeness above 95% on your top revenue decile **Frontier — for merchants in eligible markets** - [ ] ACP feed generated and delivered, daily full plus intra-day API updates - [ ] Perplexity merchant program application submitted - [ ] UCP interest form submitted, `native_commerce` eligibility signalled on qualifying listings - [ ] Agent-originated traffic and orders tagged separately in analytics That last item is worth stressing. Agent-driven orders will not attribute like search or paid social, and if you don't tag them at the point of integration you will not be able to prove any of this worked. Set up the measurement before you need it. --- ## Should you bother? A balanced answer, because the topic attracts more certainty than the evidence supports. **Reasons for scepticism.** Checkout adoption has been slower than the launch announcements implied. OpenAI publicly reset its approach after the first Instant Checkout attempt. Most of the transactional features are geographically restricted. Published data on incremental revenue is thin, and the impressive-sounding growth multiples usually start from a very small base. **Reasons to act anyway.** Almost everything in Layers 1 and 2 improves your existing paid performance regardless of whether agentic commerce lives up to the projections. Complete attributes, accurate identifiers and fresh inventory data make Performance Max work better today. Conversational attributes carry no approval risk. And catalog data quality is a months-long project with no shortcut — the merchants who start when the opportunity is obvious will be starting from behind. The framing we'd suggest: **don't build for agentic commerce, build a catalog that is complete and correct.** Agentic readiness is what a complete and correct catalog looks like in 2026. The protocol work is a thin layer on top, and it's the part that can be done quickly once the data underneath is right. If you want a baseline before committing to any of it, our [free product feed audit tool](https://www.feedance.com/tools/free-product-feed-audit-tool) scores any feed on data completeness, data quality and technical health — which is a reasonable proxy for how much of this you already have. --- ## Sources - Google Merchant Center Help — About the Universal Commerce Protocol (UCP): https://support.google.com/merchants/answer/16837055 - Google Merchant Center Help — How to use conversational attributes: https://support.google.com/merchants/answer/17085370 - Google Merchant Center Help — Product data specification: https://support.google.com/merchants/answer/7052112 - Google Developers Blog — Under the Hood: Universal Commerce Protocol: https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/ - Google for Developers — Migrate from Content API for Shopping to Merchant API: https://developers.google.com/merchant/api/guides/compatibility/overview - OpenAI Developers — Product Feed Spec (Agentic Commerce): https://developers.openai.com/commerce/specs/spec - OpenAI Developers — Agentic Commerce key concepts: https://developers.openai.com/commerce/guides/key-concepts - Agentic Commerce Protocol: https://www.agenticcommerce.dev/ - Universal Commerce Protocol: https://ucp.dev