Product feed enrichment: when complete is not the same as rich

There is a specific and frustrating state a catalog can get into. Every required field is present. Merchant Center is quiet. The feed validates. And the products still lose, quietly, to competitors selling the same thing. Nothing is broken, so nothing tells you what to do next.

That state has a name. The feed is complete but not rich, and the two are not the same measurement. Completeness asks whether a field exists. Enrichment asks whether what is in it says enough for anything downstream to act on. A row reading title: Kids Jacket Blue with every mandatory field filled is perfectly valid and almost useless.

This page is about that gap. If your feed is actually failing checks, start with what to fix and in what order instead; enrichment is the work that comes after the errors are gone.

Where the gaps actually come from

Thin data is almost never a decision. It accumulates, and it does so through a small number of recognisable routes. Knowing which one produced your gaps tells you where to go looking for the missing values.

• Supplier feeds imported as-is. A distributor’s file is built for ordering, not for selling. It carries a code, a price and a pack size, and none of the attributes a shopper searches on. Whatever the supplier omitted, your catalog omits.
• Platform migrations. Custom fields are the first casualty. A move that preserves products, prices and images will routinely drop material, fit, age group and everything else that lived in a bespoke attribute.
• Variants that inherit from a parent. The parent has the description; the variants have the size. Which is fine in the store, and produces one usable row and forty thin ones in the export.
• Fields nobody owns. The person adding a product optimises for the product page looking right. Nothing on the page breaks if material is empty, so it stays empty, for years.
• Categories filled once, at speed. Somebody mapped a thousand products in an afternoon, and the ones that did not obviously fit went into whatever was closest.

The useful thing about that list is that four of the five are historical. The gaps are not being created on purpose today, which means filling them is a one-off recovery followed by a rule, rather than a permanent tax.

Which attributes are worth the effort

Not all of them, and this is where enrichment projects go wrong. Filling every optional field in the spec is a lot of work with a flat return. The attributes that pay are the ones a buyer would say out loud when describing what they want, and they differ by what you sell.

• Apparel: size, colour, material, fit, age group, gender. Six fields that carry almost the whole category.
• Electronics: brand, model number, capacity, compatibility. Model number more than anything else, because it is how people search once they know what they want.
• Home and furniture: dimensions, material, colour. Dimensions decide purchases and are missing more often than any other field in the category.
• Consumables: quantity, unit size, flavour or variant. A price without a unit size cannot be compared, and comparison is the whole game.

A quick test that costs nothing: write down how you would describe one of your products to a friend on the phone. Every noun and adjective you used is an attribute that should be in the feed. Then check whether it is. If you have not seen a per-field breakdown of your own catalog, a free scan reports coverage field by field, read only.

Four honest sources for a missing attribute

An attribute has to come from somewhere real. In practice there are four places, in descending order of reliability, and it is worth exhausting them in that order.

1. Another field you already publish. The most under-used source by a wide margin. Material is frequently sitting in the description. Size is often in the SKU. Colour is regularly in the product name. This is extraction, not creation, and it is both the cheapest and the safest.
2. A pattern across the catalog. If every product in one collection is cotton twill, that is a rule rather than a thousand edits. Patterns are how a large catalog gets enriched at all.
3. The supplier, asked again. Unglamorous and often effective. Distributors frequently have a richer file than the one you were given, because the one you were given was built for ordering.
4. A person, for the long tail. After the first three there is a residue that genuinely needs somebody to look at the product. It is usually far smaller than it looked at the start, which is the point of doing the other three first.

And the fifth source, the one that backfires: a model asked to fill the field from general knowledge. It will produce a plausible material for a product it has never seen, and that is worse than leaving the field empty. The reason is worth stating precisely, because it is the opposite of intuitive.

An empty field fails a check, so somebody notices. An invented value passes every check, so nobody does. It flows into the feed, into the channel, into the listing, and eventually into a returned parcel. Generation is useful for enrichment, but only when it is constrained to attributes already present in your data and reviewable before it ships.

Data quality is a set of numbers, not one number

A single quality score is good for deciding whether to care. It is useless for deciding what to do, because it averages away the only actionable information: which field is thin, and across how many products.

The measurement worth keeping is coverage per field: what percentage of products have a non-empty, plausible value for each attribute that matters in your category. That produces a table you can work down, and it makes the size of each job visible before you start it. Ninety-four per cent coverage on colour and eleven per cent on material are two completely different afternoons.

Two refinements that stop the number lying to you. Count a value as missing when it is present but meaningless, because colour: assorted and material: mixed are empty fields wearing a value. And weight coverage by how much each product actually sells, since eighty per cent coverage that excludes your best sellers is worse than sixty per cent that includes them.

Why thin data costs more than it used to

For an ad auction, thin data means fewer matched queries. You lose impressions you never see, which is a real cost and an invisible one.

For an AI shopping assistant the cost is sharper, because there is no listing grid and no photograph to compensate. An assistant handling “a warm waterproof jacket for a toddler under fifty pounds” has to satisfy four separate clauses from the data alone, and a product missing the material and the age group cannot satisfy two of them. It is not ranked lower. It is not a candidate. How assistants pick products goes through that mechanism.

Which is the strongest argument for enrichment available right now: the same work pays twice, and the second payment is growing.

Keeping it enriched

An enrichment project that ends produces a catalog that decays. Products added next month arrive with the same gaps, because whatever produced the gaps is still in place.

Three habits that hold. Express each recovered pattern as a rule so it applies on every sync rather than once. Do the work in the export layer rather than in the store catalog, so a rule can be revised or reverted without a data migration and your product database keeps meaning what it meant. And put coverage per field on whatever weekly report you already read, because a field that quietly drops from ninety-four per cent to sixty is invisible until someone is looking at the number.

If a feed row is still an abstract thing at this point, one real row field by field is the shortest way to make it concrete.

Frequently asked questions

Is feed enrichment the same as feed optimization?

Optimization is the whole job, including fixing what is broken and structuring what is there. Enrichment is the specific part that adds information the feed did not previously carry. You can optimise a feed without enriching it, by fixing errors and rewriting titles from attributes you already have, and for many catalogs that is the first and larger win.

How much coverage is good enough?

There is no universal number, which is why a single score is unsatisfying. A workable target is full coverage on the three or four attributes that decide purchases in your category, on the products that account for most of your revenue, and whatever falls out for the rest. Chasing a hundred per cent on every optional field is how enrichment projects stall.

Can AI do the enrichment for me?

For extraction, yes and well: pulling a material out of a description or a size out of a SKU is exactly the kind of work it is reliable at, because the answer is already in the text. For invention, no, and a tool that offers it is offering you a liability. The distinction to ask any vendor about is whether generation can only use attributes already present in your data.

Should I enrich the store catalog or the feed?

Both are defensible, and they have different costs. The store catalog gives one source of truth and makes every change a migration. The export layer keeps the catalog untouched, makes rules revisable, and means the enrichment lives in the tool rather than in your data. Where a tool writes the fix is the first question worth asking about that.

How long does it take to see a difference?

Impressions and matched search terms move within days of the export refreshing, because a newly complete attribute makes a product eligible for queries it was previously invisible to. Revenue takes longer and is harder to attribute cleanly, since the feed refresh, the landing page crawl and the campaign learning do not finish on the same day.