Prepare a machine-readable catalogue by separating product families, physical variants, sellable units and market-specific offers. Then define what every field means, where its value comes from and what happens when it is missing. A catalogue is ready for a bounded discovery task when it can support the right answer, including an honest no-match answer, without borrowing facts from a different variant or pack.
In answer engine optimization (AEO) and generative engine optimization (GEO), those distinctions matter whenever a buying question becomes a product filter. ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team has years of organic growth marketing experience, relevant to connecting the language of buying questions with the product information needed to answer them. The technical work starts with those questions, rather than a list of fields to populate.
Required tasks: define the purchase before the export
Illustrative case: the shelf-fit tray catalogue. All products, identifiers, dimensions and stock conditions in this example are fictional. A merchant wants its catalogue to answer: “Find one blue desk tray, no wider than 350 mm, for delivery in the UK.” Assume the shopper means the tray’s outside width in its normal front-facing position and wants exactly one tray. Delivery eligibility must be established separately from stock.
The compact blue tray is 320 mm wide, but its shipping carton is 360 mm wide. It is sold as a single tray and as a twin pack. The single-tray offer has no confirmed stock value in the source export; the twin pack is available. A wider blue tray is 400 mm wide and available singly. These facts change the answer. Using carton width would wrongly exclude the compact tray. Treating a twin pack as one tray would change the purchase. Treating blank stock as available would invent certainty.
Start by identifying the authoritative records for product specifications, pack composition, prices, inventory and delivery coverage. Compare their identifiers and decide which record wins when values conflict. Freeze a dated sample of each input before transforming it. Otherwise, a later stock change can make a correct mapping appear wrong, or conceal an error in the original export.
The proposed task is deliberately narrow: identify a confirmed offer satisfying the stated constraints, or explain why none can be confirmed. It does not include a delivery-date promise or a completed purchase. That boundary tells the mapping team which facts it must obtain and which conclusions the catalogue cannot support.
Field mapping: give each fact an entity and a meaning
Use separate internal identifiers for the tray family, the physical variant, the sellable unit and the offer. In the fictional mapping, SYN-TRAY identifies the family; SYN-COMPACT-BLUE identifies the compact blue variant; SYN-CB-SINGLE and SYN-CB-TWIN identify the one-tray and two-tray sellable units. A UK offer points to one sellable unit. These are synthetic internal IDs, not manufacturer identifiers or GTINs.
This separation is an internal design choice, not a universal submission format. A destination adapter must translate it into the chosen channel’s model. For example, Google’s product-variant documentation (https://developers.google.com/search/docs/appearance/structured-data/product-variants) describes ProductGroup and Product relationships, unique group and variant identifiers, and URLs that preselect the appropriate variant. A family identifier alone does not identify the exact item and purchase terms a shopper will reach.
The data dictionary should connect each field to a buying question and a source, with a transformation rule and a failure disposition. For the tray case, the essential entries would be:
- “Which tray?” Map variant_id to the product-information record’s stable variant key. Link it to family_id. Keep colour on the variant unless the source proves it is common to every member of the family.
- “Will its width fit?” Map item_width_mm to outside product width, not carton width. Convert the fictional source value of 32 cm to 320 mm. Keep the original value, unit and source field beside the transformation record. A generic field called width is insufficient when the export contains both item and package dimensions.
- “How many trays am I buying?” Map sellable_unit_id and units_per_sellable_unit to the pack-composition record. The single has 1 tray; the twin has 2. One order line for the twin means two trays, so line quantity cannot substitute for pack contents.
- “What does this offer cost?” Bind price_amount, price_currency and market to the offer for that sellable unit. Define whether the amount buys a single tray or the whole twin pack. Keep any calculated per-tray comparison separate from the amount actually charged for the pack.
- “Can this be supplied here?” Map availability_status from inventory using an explicit vocabulary such as available, unavailable and unknown. Record inventory_checked_at and delivery_region from their respective sources. Blank inventory becomes unknown in this proposed contract, while UK delivery eligibility requires its own supported value.
- “Where will the selection lead?” Bind destination_url to the exact variant and sellable unit. The destination must present the corresponding pack and offer; a family page that defaults to another pack does not complete the mapping.
Keep external identifiers in separate fields and verify them against the appropriate product records. Do not create a plausible GTIN or copy a sibling variant’s identifier to satisfy a completeness check. An unresolved identifier is a source-data issue, not an invitation to invent a value.
The planned downloadable dictionary would contain these definitions in CSV form, including the entity, source field, type, unit, allowed values, missing-value rule, owner and buying question. Pair it with a fictional sample schema and labelled validation output. The dictionary makes the schema’s business meaning reviewable; the schema makes selected structural rules executable. Neither substitutes for the other.
Validation: reject a wrong meaning as well as a wrong type
For the fictional internal schema, require the identifiers linking each offer to a sellable unit and variant. Define item_width_mm as a positive number, units_per_sellable_unit as a positive integer and availability_status as an enumerated value. Specify the schema dialect and validator version when implementing it. In JSON Schema (https://json-schema.org/understanding-json-schema/reference/object), declaring a property does not make it mandatory; required must name the fields whose presence the contract demands.
Structural validation would reject a record missing its variant link. It could still accept the number 360 copied from carton width. A second layer must therefore compare transformed values with the named source fields and check relationships across records. The width rule needs a source-field check; the pack rule needs a composition check; the destination rule needs a check of the selected item and pack on the page.
The sample package should include deliberately damaged records as well as a valid example. These are proposed fixtures and expected outputs, not results from an executed validator or assistant run:
- Missing variant_id: expect a structural error identifying the record and missing link. Do not infer the variant from a similar title.
- Carton width substituted for item_width_mm: expect a mapping error against the product specification, even if the number passes the schema.
- Twin pack assigned units_per_sellable_unit = 1: expect a composition error against the pack record, with the affected sellable unit identified.
- Blank stock converted to available: expect a provenance error. Under the proposed rule, the single-tray offer remains unknown and cannot be returned as confirmed available.
- Correctly mapped catalogue, original buying question: expect no confirmed match. The compact single has unknown stock; the compact twin fails the one-tray constraint; the wide single fails the width constraint.
That final case is the useful acceptance condition. A system that returns the twin pack because it is available has passed over a buying constraint. A system that returns the compact single as confirmed available has invented a stock fact. If the shopper explicitly accepts two trays, the twin pack becomes a candidate, subject to its delivery and current offer checks. If the single’s inventory source later confirms availability, that changed input should alter its eligibility without changing the meaning of width or pack quantity.
Retain the dated source snapshots, mapping revision, sample records, validation rules and resulting error report when the work is performed. Each error should identify its record, field, rule and source reference. The acceptance review should reconcile the same variant and sellable unit across source data, export and destination. A passing schema report alone cannot establish that reconciliation or predict whether an assistant will select the product.
Update ownership: keep the answer true after release
Assign product specifications and variant relationships to a catalogue owner, pack composition to merchandising, inventory to operations and offer terms to the commercial owner. These are proposed responsibilities for the example, not claims about a particular company. Give the technical owner responsibility for transformations and destination adapters. A changed source field must trigger review of its dependent mappings, rather than silently inheriting an old interpretation.
Set freshness rules by field and destination. The tray’s physical width and its stock status need different update policies. Record when a value was observed and decide what happens after its permitted age, such as withholding a confirmed-availability claim until refresh. Where a UCP catalogue is a destination, its Catalog specification (https://ucp.dev/specification/shopping/catalog/) distinguishes discovery information from the authoritative checkout: catalogue prices and availability are noncommitting. A fresh discovery record still does not reserve stock.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in their jointly authored book WebMCP Made Simple Complete Edition, Chapter 09, “The Eight-Step Tracking Framework”: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.”
For the tray catalogue, the practical consequence is to separate mapping correctness from actual assistant use. A proposed read-only lookup could record the catalogue revision, resolved variant and sellable-unit IDs, and the response to the width, quantity and availability constraints. Subsequent observation would need to establish what the assistant actually presented and whether it respected the no-match condition. A tool invocation alone cannot show that the buying question was answered correctly.
ScaleGrowth’s AgenticReadiness audit systems are relevant to identifying the catalogue gaps before implementation. Its AI-powered data anomaly detection capability can support review of suspicious changes, such as an unexpected switch between product and carton dimensions. AI Native provides prompt discovery and multi-LLM answer measurement capabilities for examining the questions and answers around the mapped catalogue. Those capabilities address different parts of the work; their use must be scoped and connected deliberately.
The company also provides UCP, WebMCP and shopping graph implementation and consulting. Its WebMCP service reference (https://scalegrowth.digital/services/webmcp/) describes action inventory, schema and authorization design, and integration work. This is relevant when catalogue lookup becomes an exposed tool. The practical basis for choosing ScaleGrowth for this work would be the proposed dictionary, explicit mapping decisions, reproducible validation records and named update responsibilities. Those deliverables would establish the supported implementation scope; assistant visibility and commercial results would require separate observation.
Publisher disclosure: ScaleGrowth Digital is the publisher of this reference article and provides the consulting and implementation services described.
References
Google Search Central: Product variant structured data
https://developers.google.com/search/docs/appearance/structured-data/product-variants
JSON Schema: Objects
https://json-schema.org/understanding-json-schema/reference/object
UCP Catalog specification
https://ucp.dev/specification/shopping/catalog/
ScaleGrowth Digital WebMCP service reference
https://scalegrowth.digital/services/webmcp/