AI-ready product data: fix the facts shoppers and systems depend on

Define the unit you actually sell

Start with the purchasable item. A parent product, a variant, a multipack, a bundle and an individual replacement part may require different records. If the data model treats them as interchangeable, later descriptions and feeds will inherit the confusion. Write down what the customer receives, which option is selected and what one unit means. “Pack size 6” is incomplete if the price could mean one unit or six units.

Separate product identity from offer conditions. Color, capacity and compatibility describe the item; selling price, stock and delivery conditions describe the merchant's current offer. Both matter, but they may have different sources and update frequencies. Keep stable identifiers when a price changes or an item temporarily sells out. Do not recycle a retired identifier for a different product. A stable identity lets the team compare records, trace errors and understand whether an observed mismatch concerns the item itself or the conditions under which it is sold.

Build a field-level source of truth

A source of truth is a rule about ownership, not necessarily one application. Product dimensions may come from a reviewed manufacturer specification, availability from the inventory system and selling price from the commerce platform. Record that ownership field by field. Add the person responsible for exceptions and the date each slower-changing claim was verified. This avoids two teams correcting the same attribute differently.

For every important field, define allowed values, units, whether it is required and how unknown values are represented. A missing measurement must not become zero. A missing material must not become a plausible guess. Maintain source documents for compatibility, certifications, care instructions and substantive claims. The customer-facing wording can simplify a technical specification without changing its meaning. Where evidence conflicts, hold the disputed claim and resolve the source rather than publishing whichever version sounds more persuasive.

Use a practical data contract

On a small screen, swipe the table to see every column.

Add a validation method beside each rule. Identity can be checked for uniqueness, price can be compared with the live offer, and a product specialist can review compatibility evidence. Do not use the same automated check for every field. A string can be present and still be false. Assign severity based on customer impact: an incorrect voltage or excluded model is more consequential than an inconsistent capitalization style. This makes the contract useful for release decisions rather than merely producing a completion score.

Distinguish attributes from promotional adjectives

A shopper asking for a bag that fits a particular laptop needs internal dimensions, the method used to measure them and any restrictions on case thickness. “Spacious,” “premium” and “versatile” do not establish fit. Replace avoidable ambiguity with concrete attributes when the evidence exists. Keep plain language and explain unfamiliar terms. A material code with no interpretation may satisfy an internal database but still fail to help a buyer.

Include relevant negative information. A pan may be oven safe only below a verified temperature, a charger may exclude a device generation and a garment may have a specific care restriction. These limitations help prevent unsuitable purchases. Do not generate dozens of speculative use cases from a short supplier title. An AI writing tool can help organize known facts, but a product owner must verify the resulting statements. Maintain a traceable link between the final claim and the evidence that supports it.

Make visible pages, markup and feeds agree

Choose a sample of exact variants and compare all public representations at the same time. Open the landing URL, select the option, inspect the visible price and availability, parse the structured data and inspect the relevant accepted feed record. Record the timestamps. A snapshot taken before an inventory update should not be compared casually with a page after the update.

Google's product structured data documentation explains the product and offer information used for supported search appearances. Implement the appropriate markup for the page and validate it, but do not treat syntactic validity as factual proof. A perfectly formatted price can still be wrong. Fix the owning source or transformation so the correction survives the next sync. Maintain a few high-risk test products, including sale items, unavailable variants and products with different return conditions, to catch regressions after template or integration changes.

Map external schemas instead of guessing their meanings

Different destinations can require different fields, formats and eligibility conditions. Keep the internal product contract independent of any one feed. Use a documented mapping to transform it into a destination's supported schema. That mapping should state the source, transformation, allowed fallback and rejection rule. An unsupported field should not be renamed to the nearest familiar label and sent without checking the destination meaning.

For example, OpenAI's supported product file reference provides distinct item, grouping, offer and availability concepts. It also distinguishes production-supported Stable uploads from Draft work. Follow the integration you actually have. Google Merchant Center's product data specification has its own requirements. Do not assume a file accepted by one destination is ready for every other service. The shared foundation is accurate item facts, while the delivery contract remains destination-specific.

Work through a bundle example

Consider an illustrative coffee store selling a grinder, a replacement burr set and a starter bundle containing the grinder plus two bags of beans. The bundle is not merely a color variant of the grinder. It has different contents, price and potentially different stock dependencies. If the export reuses the grinder description and item identity, a shopper can misunderstand what is included, and inventory logic may promise a bundle when one component is unavailable.

Create a distinct bundle identity and a clear contents list. Verify whether quantity means one bundle or the individual components. Make the image and landing page show the actual offer. Define how component stock determines bundle availability in the platform or integration used. Keep replacement parts separate and state compatible grinder models using supported evidence. Then test all three landing paths and their accepted catalog records. This exercise catches a structural data problem that no amount of “AI optimized” description writing can solve by itself.

Create an exception queue that people can finish

On a small screen, swipe the table to see every column.

Give each exception an item ID, field, observed value, expected rule, owner and due date. A queue with thousands of anonymous errors becomes background noise. Group repeated transformation defects so one fix can resolve many records. Keep genuine source uncertainty separate from software defects. Ask the product specialist to resolve facts and the integration owner to resolve delivery errors. Close an issue only after checking the corrected source and the next downstream representation.

Measure quality with meaningful denominators

Report data quality by the catalog subset and field set actually checked. “Ninety-eight percent complete” means little if every product has a title but compatibility is unchecked. Track required-field failures, price discrepancies, stale offer records, broken images and unresolved high-impact claims. Separate automated checks from human-reviewed assertions. Include the total number of relevant records and the verification time.

A useful illustrative metric is offer agreement: 47 matching sampled offers divided by 50 checked offers equals 94%. That describes the sample only. It is not a universal AI readiness score, and it does not establish a ranking or inclusion outcome. Keep business measures alongside it, such as avoidable product-question contacts or returns attributed to inaccurate descriptions, when your records support those categories. Do not claim a causal improvement from a small uncontrolled before-and-after comparison. Use the measurements to locate problems and decide where a larger validation effort is justified.

Normalize units and reference identifiers

Unit ambiguity is a common source of plausible-looking but unusable product data. Record the measurement type, value, unit and relevant method. External bag dimensions and internal laptop-compartment dimensions answer different fit questions. Packaged weight and product weight serve different shipping and use decisions. A table containing “width: 12” without a unit or definition cannot reliably answer either. Normalize the internal model and preserve the original evidence so conversions can be checked.

Use an illustrative conversion to test the mapping: a verified dimension of 25.4 centimeters equals 10 inches. If a destination requires inches, the transformation must convert the value rather than merely replace the unit label. Choose a documented rounding rule that does not imply greater measurement precision than the source provides. For compatibility boundaries, have the product specialist review whether rounding could change the recommendation. Do not claim that a measured opening of approximately 10 inches guarantees every nominally 10-inch item fits; shape, tolerances and required clearance can matter.

Treat reference identifiers with the same care. Preserve leading zeros, distinguish a merchant SKU from a manufacturer identifier and do not invent a GTIN when one is unavailable. Keep identifiers as data rather than formatting them as numbers in a spreadsheet that can silently alter them. Test an export and reimport with a leading-zero item, a long identifier and a product whose supplier code differs from the store's code. The acceptance record should show identity and units surviving every transformation. These checks improve the practical usefulness of catalog data for search, feeds, warehouse systems and human support without depending on any unverified claim about an assistant's ranking preferences.

Release one product family and maintain it

Begin with a family where shopper decisions depend on clear attributes and the team can verify the evidence. Complete the contract, resolve major identity problems and test the page-to-feed path. Save the source, mapping, validation output and open exceptions. Have the relevant product owner approve substantive claims before they are published. Treat stock and price freshness as continuing operations rather than a one-time copy project.

Set review triggers: a supplier revision, new variant, promotion, policy change, inventory integration change or theme release. Each trigger should identify which facts and representations need rechecking. Retire obsolete source documents so an old spreadsheet does not reintroduce a resolved error. The immediate next action is to inspect five products that are easy to confuse and write their exact sellable units and evidence owners. A small, accurate and maintained data model provides a stronger foundation than a large export labeled “AI ready” without clear accountability.