Empty Fields: Why AI Shopping Still Depends on Complete Product Data
A source-led study of how incomplete catalogue fields constrain product eligibility, search, filters, recommendations, merchandising, and AI shopping experiences.
In this article
A shopping system can only use the product facts it receives, derives, or is permitted to retrieve. That sounds obvious. The operational consequence is easy to miss: when material, dimensions, colour, variant identity, availability, or media are absent from the product record, downstream systems lose a fact they could have indexed, filtered, compared, displayed, or checked. This study maps that dependency using current public specifications and platform documentation reviewed on 3 August 2026.
The executive answer
Empty product fields do not create one universal penalty. They create a series of smaller capability gaps: a filter without a value, a query with less recall, a variant an agent cannot distinguish, a product that may be ineligible for a channel, or a comparison that has to guess.
- Required and optional are validation labels, not business-value labels. OpenAI states that required fields support correct display, while optional fields enrich relevance and user trust.
- Filters stop at the catalogue boundary. Algolia derives facets from attributes, and Google Cloud uses product attributes for indexing, searchability, dynamic faceting, filtering, and model quality.
- Variant structure is transaction context. Current UCP catalogue schemas make variants part of the product model, and Google Merchant Center warns that missing or incorrect variant attributes can prevent products from showing.
- Media has become structured product data. UCP models product and variant media as images, video, and 3D, not as decoration outside the record.
- Eligibility, relevance, and conversion are different outcomes. Missing data can affect each one, but no single field guarantees inclusion, ranking, recommendation, checkout, or sales.
Method
This is a documentation and standards study, not a census of retailer fill rates. We reviewed five live public source sets: OpenAI's non-Ads Product Feed Spec, the Universal Commerce Protocol catalogue schemas, Google Merchant Center's product data specification, Google Cloud AI Commerce Search attribute controls, and Algolia's faceting documentation. We recorded only dependencies stated by the source, then separated those statements from our interpretation.
| Source set | Documented dependency | What the study can safely conclude |
|---|---|---|
| OpenAI Product Feed Spec | Structured fields are used for accurate discovery, pricing, availability, and seller context. Optional fields enrich relevance and user trust. | A field can matter to relevance or trust even when it is not required for schema validation. |
| Universal Commerce Protocol | Catalogue search returns structured products. Product records require title, description, price range, and variants; media can include images, video, and 3D. | Agent-facing catalogue exchange depends on product and variant structure, not page copy alone. |
| Google Merchant Center | Incorrect, inaccurate, or missing information can cause disapproval, limited eligibility, or incorrect display. Variant and image issues can prevent ads and free listings from showing. | Some missing fields have channel-specific eligibility consequences; requirements vary by product and market. |
| Google Cloud AI Commerce Search | Product attributes can support indexing, dynamic faceting, searchability, filtering, recommendations, and model quality. | Downstream search and recommendation controls cannot use a catalogue value that is absent from the indexed record. |
| Algolia | Facets are derived from selected attributes and let users refine results and see contextual values and counts. | Facet coverage depends on attribute coverage in the indexed catalogue. |
Source note: OpenAI Product Feed Spec — Non-Ads commerce schema and OpenAI's stated role for required and optional fields.
Source note: Universal Commerce Protocol product schema — Current product, variant, category, price, media, tag, and metadata structure.
Finding 1: optional does not mean irrelevant
Schema validation answers whether a record can be accepted. It does not answer whether that record is rich enough for a difficult shopping decision. OpenAI's specification makes the distinction directly: required fields support correct display, while optional fields enrich relevance and user trust. A sofa can therefore be valid as a product record while still lacking the material, dimensions, additional media, or variant context needed for a narrow request.
Source note: OpenAI Product Feed Spec — OpenAI separates compliant display from the relevance and trust value of optional fields.
Finding 2: filters can only expose recorded facts
Facets are not generated from shopper intent alone. Algolia describes facets as categories derived from attributes. Google Cloud similarly documents that product attributes can be indexable, searchable, dynamically faceted, and filterable. If a product has no material value, a material facet cannot honestly place it under oak, steel, cotton, or leather. The product may remain searchable by other signals, but that filter cannot represent a fact it does not have.
Source note: Algolia faceting documentation — Algolia states that facets are derived from attributes and used to refine results.
Finding 3: incomplete attributes affect more than filters
Google Cloud's AI Commerce Search documentation links product attributes to indexing, search recall, dynamic facets, recommendation filters, and model quality. That does not mean filling one field guarantees a better ranking. It means attribute quality is an input to several downstream controls. Search tuning cannot recover a fact that was never recorded without introducing another inference step and its own review policy.
Source note: Google Cloud: About product attributes — Documented roles for indexability, searchability, dynamic faceting, recommendation filtering, and model quality.
Finding 4: variant mistakes are identity mistakes
A product family and a purchasable variant are not interchangeable. UCP models products with one or more variants and gives variants their own identifiers, descriptions, prices, availability, options, media, and seller context. Google Merchant Center separately calls out missing or incorrect item-group, colour, and size attributes as issues that can prevent listings from showing. When variant structure is incomplete, the failure is not merely thinner copy. The system may not know which configuration is being displayed or purchased.
Source note: UCP variant schema — Current structured fields for purchasable variants, including price, availability, options, media, and seller context.
Source note: Google Merchant Center product data specification — Google's requirements and warnings for missing product, image, identifier, and variant data.
Finding 5: visual fields belong inside the product record
UCP's current product and variant schemas treat media as structured arrays that can contain images, video, and 3D models. Google Merchant Center also defines main images, additional images, and video as product data attributes. The practical shift is important: visual assets are not only presentation files for a product page. They can be machine-readable evidence and product context, provided the record links them to the correct product and variant.
Source note: UCP product schema — Product media supports images, videos, and 3D models, with the first item used as featured media.
From empty field to downstream limitation
| Commerce function | Record it depends on | What an empty field changes |
|---|---|---|
| Eligibility and display | Channel-required or conditionally required identifiers, images, variant attributes, price, and availability | The channel may reject, limit, or display the item incorrectly under its own rules. |
| Search recall | Searchable titles, descriptions, categories, attributes, tags, and identifiers | The missing fact cannot contribute directly to matching or recall. |
| Filters and facets | Consistent attribute names and values | The product cannot be truthfully included under a facet value it does not contain. |
| Recommendations | Indexable and filterable product attributes plus behavioural data | Attribute-based constraints and candidate controls have less product context to use. |
| Merchandising | Categories, attributes, availability, price, brand, policy, and campaign fields | Rules cannot target an absent value without a separate enrichment or inference step. |
| AI shopping | Structured product, variant, price, availability, seller, policy, and media context | The assistant has less explicit evidence for comparison and may need to omit, qualify, retrieve, or infer the missing fact. |
A worked example: the extendable oak table
Consider the request: ‘Find an extendable oak dining table under 140 cm when closed, available in Berlin, and show me how it looks from every side.’ A product page may look complete to a human while its machine-readable record contains only a title, price, main image, and stock flag.
| Requested fact | Relevant catalogue field | If it is empty |
|---|---|---|
| Oak | Material | Material filtering and exact attribute comparison lose an explicit value. |
| Extendable | Feature or product type | Search may depend on title wording or inference instead of a governed attribute. |
| Under 140 cm closed | Width plus configuration context | The size constraint cannot be evaluated reliably from a single unqualified dimension. |
| Available in Berlin | Variant-level availability and location | A product-level stock flag may not resolve the purchasable local variant. |
| Every side | Additional images, video, or 3D media | The assistant or product surface cannot display visual evidence that is not linked to the record. |
Operator checklist: audit the fields that control a decision
- Define the product, family, variant, offer, and duplicate model before measuring field completeness.
- Separate required, conditionally required, and decision-critical fields. A valid record can still be unhelpful for a buyer's question.
- Measure completeness by category and attribute, not only as one catalogue-wide percentage.
- Check value validity, units, controlled vocabulary, and evidence. A filled field can still be wrong.
- Trace each important field to a downstream use: eligibility, search, facet, recommendation, merchandising rule, policy, product page, or assistant feed.
- Score variant and offer consistency separately from descriptive content.
- Treat images, additional media, video, and 3D as product-linked data with ownership and freshness rules.
- For inferred values, retain confidence, reason, evidence, review state, and rollback path.
- Freeze a representative catalogue slice and acceptance criteria before comparing tools.
- Measure operational review effort as well as field coverage. More generated values are not automatically better data.
What this means for AI-shopping readiness
AI-shopping readiness is not a new feed layered over an old catalogue. The durable work is to make product identity, attributes, variants, offers, availability, policies, and media governable first. Protocol mapping can then carry those records to new channels as platform support matures. It cannot create product truth by itself, and it does not guarantee placement, ranking, recommendation, checkout, or sales.
Limitations
- This study reviews public specifications and documentation. It does not measure field-fill rates across merchant catalogues.
- Required and optional status varies by platform, product type, country, programme, and schema version.
- Platforms may derive or retrieve some values from other sources. Public documentation does not expose every ranking or recommendation signal.
- A present field can be inaccurate, inconsistent, stale, or attached to the wrong product or variant.
- No source reviewed here supports a universal claim that one missing optional field suppresses a product.
- The report does not claim that Youzu fills every field, eliminates human review, or guarantees a downstream commercial result.
Sources reviewed
- OpenAI, Product Feed Spec — Accessed 3 August 2026.
- Universal Commerce Protocol, Product schema — Accessed 3 August 2026; repository revision a839e99355921e669286be0b9914c43712466d20.
- Universal Commerce Protocol, Variant schema — Accessed 3 August 2026; repository revision a839e99355921e669286be0b9914c43712466d20.
- Google Merchant Center, Product data specification — Accessed 3 August 2026.
- Google Cloud, About product attributes — Accessed 3 August 2026.
- Algolia, Faceting — Accessed 3 August 2026.
How Youzu approaches the underlying record
Youzu is building an AI engine for e-commerce, automating product catalogs and powering intelligent shopping journeys from inspiration to purchase. Catalogue Intelligence reads product feeds and images together, proposes structured catalogue decisions, and sends uncertain cases to a human with the reason and evidence attached. Agent-ready validation and protocol mapping remain future-facing work; the current benchmark starts with the catalogue record itself.
