Product data: feed and schema as the foundation

The audit in the previous chapter almost always ends with the same diagnosis: the assistant does not so much fail to know your store as fail to find reliable facts about its products. So before you plan new content, close the gap at the foundation. Visibility in AI answers starts with product data, not with the blog. According to industry sources, shopping recommendations from assistants rely heavily on structured product data and a complete shopping feed. A catalogue described well for humans but poorly for machines loses to a competitor that stated price, currency, availability and identifier outright. This chapter covers what to set up, and in what order.

An assistant needs a fact, not a description

A model assembling a shopping recommendation has to settle four things in one pass: what the product is, what it costs, in which currency, and whether it is available right now. A line such as "PLN 349 in a bundle, last units, ships today" is perfectly readable to a person, but to a machine it is three facts to interpret and to get wrong. The same information stored in separate, named fields needs no interpretation at all. Your first job is therefore not better copy. It is getting the catalogue to a state where every product carries a complete set of unambiguous fields, and that set is identical in every place it can be read from.

One point is worth stating early, because it tends to surprise boards: according to industry sources, advertising spend does not influence what an assistant recommends. Media budget buys exposure in ads, not a place in a generated answer. For a smaller store that is good news, because entry into the comparison is won on data quality rather than on bids. For a large one it is bad news, because a neglected catalogue cannot be bought back with budget.

GTIN: the same product across many stores

GTIN is the Global Trade Item Number from the GS1 standard, known in Europe mostly as the thirteen digit EAN barcode printed on the box (UPC in the United States, ISBN for books). It does one job: it establishes that "Sony WH-1000XM5 black" in your store and "Sony WH1000XM5 wireless headphones, Black" in another store are one and the same product. Without a shared identifier a system has to compare names, and product names in eCommerce almost never match. A product with no GTIN is not worse, it is simply harder to connect to the rest of the market, so it drops out of comparisons more easily.

In practice: fill in the GTIN wherever the manufacturer assigned one, and publish it in two places at once, in the feed and in structured data (the gtin property, and gtin13 for EAN codes). The identifier belongs to the variant, not to the parent product: every size and colour carries its own code. For own brand products that never received a GTIN, use the brand and mpn pair plus a stable SKU, and keep those values identical in the store, the feed and the schema. What not to do: never invent a code, never copy one that belongs elsewhere and never reuse a code from a discontinued item. A wrong identifier is worse than a missing one, because it merges your offer with a completely different product.

Product and Offer: complete, not partial

On the structured data side, two objects carry the foundation. Product handles identity: name, image, brand, sku and gtin, plus the description. Offer handles the buying decision and has to be complete: price as a bare number, priceCurrency as an ISO code (PLN, EUR), availability written as a full schema.org address, for example https://schema.org/InStock or https://schema.org/OutOfStock, and url pointing to the product page. The full URL instead of the word "available" is not a formality: it points at a single concept from a vocabulary identical for every store in the world, so the comparison happens without translation. If the price has an expiry, add priceValidUntil. If shipping and returns are part of your sales argument, express them as offer fields rather than as a sentence in the description.

We break down the types, properties and typical mistakes in detail in our piece on structured data for AI, and a ready made JSON-LD generator for Product and FAQ sits in the AI Library. For this chapter one rule is enough: if any of the four offer fields is empty or approximate, the product stops being countable.

Shopping feed hygiene

A product feed is the same catalogue exported in a format that external systems read. Treat it as a production interface of your store, not as a file owned by the marketing team. Three control questions: does the feed contain every product you actually sell, are the required fields filled in for every item, and is the data in it as fresh as the data on the page. Below are the defects that in practice push products out of the comparison most often.

Defects ordered from the single product to the consistency of the whole catalogue. Field names are given as you write them in structured data and in the feed.

Consistency as the condition of trust

The same facts appear in three places: on the page, in structured data and in the feed. They have to match to the cent and to the status. A contradiction has two consequences and both are expensive. First, a system that finds two different prices for one product has no reason to treat your offer as the reliable one, and skipping an ambiguous source is cheaper for it. Second, a mismatch between the JSON-LD and what the user sees is structured data spam and a real risk of a Google manual action, which means losing visibility in classic results too. The reward for consistency is not a bonus. It is the absence of a penalty and the right to enter the comparison.

In engineering terms this comes down to two decisions. Generate the JSON-LD from the same fields that render the product page, instead of maintaining a separate template with values typed in by hand. And add an automated comparison between the feed and the live store, triggered after every larger price update: a simple diff report for price, availability and identifier is enough to catch most drift before an external system catches it for you.

Where to start with a large catalogue

Do not work through the catalogue alphabetically or category by category from the menu. Start with the products that carry most of your revenue and bring the four offer fields plus the identifier to completeness for them. Then move to variants, because that is where GTIN and availability go missing most often. Only after that go into the long tail, where fixes are cheap but the effect is spread over time. The order matters, because the first two steps usually cover a small share of the index and take days rather than a quarter.

Product data on its own will not make an assistant recommend your store; nobody can guarantee that, and offers that promise it are worth turning down. What it does is make your offer countable and comparable, which is the price of entry to any recommendation at all. Only on that foundation does it make sense to work on content a model can quote, and that is what the next chapter is about.