Universal Product Identity Is the Missing Layer in Agentic Commerce

Agentic commerce has a catalog problem before it has a checkout problem

AI shopping agents are often described as a new front end: a conversational layer that finds products, compares offers, and calls a checkout API. That description skips the difficult part. Before an agent can choose, compare, or buy anything, it must know whether two listings represent the same product, two variants of one product, or two genuinely different products.

My argument is simple: universal product identity is the missing control plane for agentic commerce. A merchant should not treat a product page, SKU, feed row, variant, and offer as interchangeable identifiers. They are different entities with different lifecycles. If a business collapses them into one string or one URL, every downstream agent experience inherits that ambiguity.

This is not a theoretical concern. Shopify’s engineering team describes clustering billions of listings into Universal Product Identifiers (UPIs) because merchants model the same real-world product differently. One merchant may put twelve flavors under one product; another may publish twelve separate products. A human can infer the relationship. An agent needs the relationship represented, tested, and governed.

That is why the next commerce architecture investment should be an identity layer—not another chatbot, feed exporter, or storefront redesign.

A listing is not a product, a variant, or an offer

The first implementation decision is to separate the entities that commerce systems routinely blur. A practical identity model looks like this:

Entity	What it represents	Typical owner	What can change
Product model	The real-world thing or product family	PIM/catalog	Name, attributes, composition
Variant	A sellable choice that differs on defined dimensions	Catalog/inventory	Size, color, pack, availability
Listing	A channel-specific representation	Channel/feed team	Title, copy, images, taxonomy
Offer	A seller’s commercial terms for a variant	Pricing/merchant	Price, promotion, stock, shipping
Order line	The historical purchase decision	OMS/order system	Almost nothing after capture

The same product model can have different listings on a brand site, Google Merchant Center, a marketplace, and an agent’s catalog. The same variant can have multiple offers by seller, region, or fulfillment method. A URL is useful for navigating to a listing; it is not a durable identity for the physical product.

Google’s Merchant API makes this distinction operational. Its item_group_id is a shared identifier for variants of one product, while fields such as color, size, brand, and gtin describe the individual item. Google’s product documentation likewise recommends product-variant structured data so it can understand which products are variations of the same parent product. The implication is important: a channel already expects merchants to declare product relationships rather than infer everything from titles.

Schema.org’s ProductGroup expresses the same idea at the vocabulary level. A group represents products that vary in specific ways; variesBy says which dimensions matter; hasVariant connects the group to concrete products. That is much closer to an agent’s decision model than a collection of similarly named pages.

The data model does not need to be identical across every platform. It does need to preserve the distinctions. A minimum internal representation could be:

type ProductModel = {
  id: string                 // durable internal identity
  brand: string
  model: string
  identityAttributes: Record<string, string>
  variantDimensions: string[]
}

type Variant = {
  id: string                 // sellable unit identity
  productModelId: string
  options: Record<string, string>
  gtin?: string
}

type Offer = {
  id: string
  variantId: string
  sellerId: string
  market: string
  price: Money
  availability: Availability
  validFrom: string
  validUntil?: string
}

The key field is not title; it is the relationship between productModelId, variantId, and offer. Titles are channel projections. Identity should survive a title rewrite.

Shopify’s clustering work reveals the real judgment call

The hardest catalog question is not “can these strings be embedded close together?” It is “what makes these items the same product for this buyer?” Shopify’s catalog-clustering research calls this the core value proposition test: if changing an attribute does not change what the buyer is primarily purchasing, that attribute may be a variant; if it changes the value proposition, it may define a separate product identity.

That rule explains why flavor can be a variant for protein powder but a product-defining attribute for paint. In both cases the words look similar—a color or flavor name appended to a title—but their meaning in the buying decision differs. A universal identity service therefore cannot rely on a global rule such as “all color changes are variants.” It needs category context, merchant context, and an auditable reason for each grouping decision.

Shopify reports a precision-first strategy. Incorrectly merging products can cause an agent to recommend or purchase the wrong item; failing to merge a valid variant usually leaves the item discoverable as a separate result. The asymmetry is architectural: false positives are transaction and trust failures, not merely search-quality defects.

That suggests a useful quality contract for a merchant catalog:

Decision	Failure	User impact	Default policy
Same product or not	False merge	Agent recommends the wrong item	Require stronger evidence
Same product or not	Missed merge	Duplicate or incomplete results	Queue for review and retain discoverability
Variant dimension	Wrong dimension	Agent cannot answer a preference correctly	Require explicit option semantics
Offer selection	Stale offer	Price or stock mismatch at checkout	Revalidate at transaction time

Do not hide the uncertainty. Store a confidence score, the evidence used, the model or ruleset version, and a review state. An agent can safely work with “identity unresolved” if the system routes that case to a human or a conservative search path. It cannot safely work with an incorrect identity presented as fact.

Global identifiers are anchors, not the whole catalog

A GTIN or manufacturer part number is valuable because it can anchor a product to an identifier with meaning beyond one storefront. GS1 describes the GTIN as a unique, verifiable identifier used to distinguish products across online marketplaces and physical retail. Its Digital Link standard connects that identifier to online information without making the web page itself the product identity.

This separation is exactly what agentic commerce needs. Product identity should be persistent while online content, campaign pages, instructions, and APIs can change. GS1’s guidance emphasizes that a Digital Link URI identifies the product, while a redirect can change as the related information evolves. A merchant can therefore update the destination without reprinting the identifier embedded in packaging.

But global identifiers have limits. Private-label goods may not have a GTIN at every stage. Bundles, multipacks, refurbished items, subscriptions, and region-specific configurations may need a merchant or marketplace identity in addition to a manufacturer identifier. A GTIN tells systems which trade item an identifier refers to; it does not, by itself, define a merchant’s current price, inventory position, return policy, or legal selling unit.

Use identifiers in layers:

1. Global identity: GTIN, GS1 Digital Link, manufacturer part number, or another authoritative external identifier when available.
2. Merchant identity: a durable product-model and variant ID owned by the merchant.
3. Channel identity: feed IDs, listing IDs, handles, and marketplace references mapped to the merchant identity.
4. Transaction identity: the exact offer and price snapshot used to create an order line.

Never use a channel ID as the primary key for the business. Channel identifiers are integration artifacts. They can be reissued, scoped to an account, or changed by a platform migration.

The feed should be a projection of identity, not its source of truth

Google recommends combining product structured data on pages with Merchant Center feeds. Those surfaces reinforce each other, but neither should become the canonical catalog. They are projections for a particular discovery system, with its own required fields and eligibility rules.

This is where many feed programs become fragile. A team exports a row from a commerce database, changes the title to fit a channel, adds a promotional price, and assumes the row is the product. That row actually combines at least four concerns: identity, merchandising copy, offer terms, and channel eligibility. Once an agent begins comparing results across channels, the ambiguity becomes visible.

Build a projection pipeline with explicit joins instead:

ProductModel ──< Variant ──< Offer ──< ChannelListing
      │             │          │             │
   identity      options    price/stock    title/taxonomy

Each projection should answer five questions:

• Which durable variant does this listing represent?
• Which offer is valid for this market, seller, and time window?
• Which fields are inherited from the product model versus overridden by the channel?
• Which identifier should be sent back when an agent creates a cart or checkout session?
• What event invalidates the projection?

Google UCP makes the last two questions urgent. Its commerce protocol separates catalog, checkout, orders, and extensions into capabilities that agents can discover and negotiate. The merchant still needs to reconcile a discovered item with a live cart and a final order. A product identity map is the bridge between discovery and execution.

That also extends the lesson from Google UCP and the product-feed checkout boundary: a feed identifier must map to the item the checkout API accepts, but the feed must not be trusted for final price or availability. The identity layer tells checkout what was selected; inventory, pricing, tax, and fulfillment services determine whether and how it can be sold.

Agent quality should be measured at the identity boundary

Most commerce teams will initially measure agentic commerce with clicks, add-to-cart rate, and completed orders. Those are useful, but they hide catalog failures. An agent can lose a sale because it selected the wrong variant, returned duplicate offers, or presented an offer that expired between discovery and checkout.

Add identity-specific metrics to the operating dashboard:

Metric	Definition	Why it matters
Variant resolution rate	Share of listings mapped to a valid variant	Measures basic joinability
False-merge rate	Incorrectly grouped items in reviewed samples	Protects buyer trust
Unresolved identity rate	Listings requiring fallback or review	Shows catalog debt
Offer freshness	Time from offer update to channel projection	Exposes stale prices and stock
Selection-to-checkout mismatch	Orders where chosen identity differs from cart identity	Detects dangerous integration drift
Reconciliation latency	Time to propagate identity or availability changes	Predicts agent-visible inconsistency

The review set should be stratified by category, merchant, and product structure. A clustering system that performs well on apparel can fail on replacement parts, cosmetics, or configurable furniture. Likewise, a model can appear accurate in aggregate while making high-cost mistakes in a small category.

Run negative-path tests, not just happy-path demos. Give an agent two variants that differ only in a safety-critical attribute. Change the price after discovery. Remove one color from stock. Split a bundle into component SKUs. Move a listing to a new URL. Each scenario should verify that the agent preserves identity, revalidates the offer, and explains the failure without silently substituting another item.

The goal is not perfect automation. The goal is bounded automation: the system knows when it has enough evidence to proceed and when it must ask, defer, or hand off.

A practical 90-day identity rollout

Merchants do not need to build a global product graph before exposing any agent capability. They do need to establish a narrow, testable identity contract.

Days 1–30: inventory the identifiers. Export product, variant, SKU, GTIN, MPN, listing, feed, and order-line identifiers. Map their owners and lifecycles. Find duplicate IDs, reused handles, bundles represented as products, and variants with no stable sellable key. Select one category where the business understands the product structure well.

Days 31–60: create the canonical graph. Introduce product-model and variant records without deleting existing channel IDs. Add explicit variant dimensions and a mapping table for every channel listing. Record identity decisions and unresolved cases. Publish only the fields that are authoritative; do not copy a promotional price into a product record.

Days 61–90: expose a conservative projection. Produce one feed or catalog API projection from the graph. Add contract tests for identifier joins, variant selection, price revalidation, availability changes, and idempotent cart creation. Start with catalog discovery or cart transfer before autonomous checkout. The storefront-as-agent-API approach is useful here, but the API should expose identity and capabilities—not just page content.

Use a small decision rule throughout the rollout: if a system cannot explain why two listings are the same product, it should not merge them automatically. Precision is more valuable than a larger but unreliable catalog.

The competitive advantage is trustworthy sameness

Agentic commerce will not be won by the merchant with the most endpoints. It will be won by the merchant whose catalog can answer a deceptively hard question consistently: “Is this the same thing, a different choice of the same thing, or a different offer for the same choice?”

Universal Product Identifiers, variant-aware schemas, GS1 anchors, and capability-oriented protocols are pieces of that answer. None replaces the merchant’s catalog governance. Together, they create a stable identity layer on which search, recommendations, feeds, UCP checkout, fulfillment, and post-purchase support can agree.

Build that layer before adding more agent surfaces. Treat listings as projections, offers as time-bound commercial facts, and product identity as a durable contract. When an agent can preserve that contract from discovery through order history, conversational shopping stops being a demo and becomes dependable commerce infrastructure.

Sources: Shopify’s catalog-clustering engineering report, Shopify’s Universal Commerce Protocol architecture, Google’s Product structured data documentation, Google Merchant API ProductAttributes reference, Schema.org ProductGroup, GS1 Digital Link standard, and GS1 guidance on product identity.