Episode 22: Structured Attributes Matter More Than Content

You cannot fill in a field that does not exist.

That sentence explains most of what goes wrong with product data and AI discovery. Teams run enrichment programmes, hit high completion rates, and still do not get recommended, because the attributes that would have made them findable were never created in the first place.

The conversation in this industry remains heavily weighted towards content. Better descriptions, richer copy, more of it. Content does matter. But the early evidence coming out of research into how LLMs cite and recommend products points somewhere else. Structured attributes matter more.

There is also a reversal buried in that. The standard advice used to be to streamline your attribute set so you only carried what was relevant. What we now recommend after AI readiness audits is closer to the opposite: the more attributes you hold that answer a real buyer question, the better.

Take a blanket

A deliberately unglamorous product, and a useful one, because buying a blanket online is nothing like picking one up in a shop. You cannot feel it through a screen, so every judgement a customer would normally make by hand has to be made from data.

It is also more technical than it looks. Run an audit on a blanket product page and the attributes worth holding include type, GSM, pile height, and how the edge is finished. There is a surprising amount of specificity available.

Run that same audit across most retailers selling blankets and nearly all of it is missing. What you find instead is size, colour and material. Possibly a comfort level, which is usually inferred rather than measured.

Then go and look at the brand or manufacturer that made the blanket. Their site is almost always far richer, because they hold the source information and always have. The data exists. It just stops at the point where the product changes hands.

The model is a decade old

The reason those fields are absent is rarely a decision anybody made. It is that the attribute model behind most retail websites is roughly ten years old and was built off the ERP data model in the first place.

In an ERP, introducing a product needs about five fields. That is all the ERP was ever asked for. Everything beyond it became an ad hoc job, done when somebody had time, category by category, with no owner.

Content escaped that fate because content is easy. It is a field, or an HTML block, and in plenty of businesses somebody can bypass IT entirely and push it straight into the ecommerce platform. Adding a new structured attribute means touching the model, which means a ticket, which means a queue.

So structure gets treated as IT plumbing with a legacy source, and copy gets treated as marketing. One of those has a budget and a fast route to production. The other does not.

Rewriting descriptions is not an enrichment project

This produces a genuinely circular problem. A business notices its product data is thin, commissions an enrichment programme, and enriches the fields it already has. The missing fields stay missing, because nobody scoped creating them.

A prospect told us recently they had just completed a big enrichment project. What they had done was rewrite all their product descriptions. That is a content project. It is worth doing, and it is not the same thing.

The measurement makes this easier to miss. Completion rate is simple to report and pleasant to look at, and a 100% fill rate against an inadequate model tells you nothing about whether a customer can make a decision. It is a vanity metric.

It is also genuinely hard to measure the right thing, because what one category manager believes a customer needs to know can differ sharply from the next one's view. Coverage is easy to count. Sufficiency is not.

The attributes you need are not all technical

Here is where building the model gets difficult.

Nobody shopping for a blanket asks what GSM they need. They ask whether they want a thick one, a medium one or a thin one, and where they are going to use it. Cool summer evenings, or something closer to arctic conditions.

Those are not technical attributes in the conventional sense. They are inferred, use-case-led, and in a category like this frankly emotive. But they are the terms in which the purchase is actually decided, which makes them exactly the attributes an answer engine needs in order to match a product to an intent.

Building a model that captures that, category by category, is hard work. It is also the work, and no amount of description writing substitutes for it.

Reverse engineer from the question

The most reliable method we have found is to start from the buyer rather than the schema.

Ask what a customer would want to know about this product if they were standing in front of you, mid-decision, with the thing in their hands. Write those questions down. Then build attributes that answer them.

The version of this fitted to how discovery now works is to write the prompts. For a given category, what would somebody actually type into an answer engine? What is the best blanket for this use case, in this room, at this budget. Take those prompts and work backwards into the fields that would let a model answer them from your page.

Shop in their shoes, then build the model that survives it.

The takeaway

The thing to hold onto is that AI does not infer what you have not stated. If the information is absent, you are not ranked lower. You are simply not recommended, and you do not get a second look.

The same shortfall breaks your filters, so you lose customers on your own site as well, and it undermines any AI assistant you deploy on that site, because those depend on structured data to function at all.

One comparison we came across recently set a very large US apparel retailer, billions in revenue, against a mid-size own-brand competitor, and measured their relative share of voice across answer engines. The large retailer's share was close to zero. The smaller brand's was around a third. Some of that was social content. A lot of it was simply the depth of product information on the site.

So run the test this week. Prompt an answer engine with a real buying question from one of your categories and see whether you appear. If you do not, go and look at whoever did, then go and look at the manufacturer, and compare their product pages with yours.

The gap you find will not be prose. It will be fields.

Listen to the full episode

Episode 22 of Product Data Weekly is available now. For more episodes and the weekly newsletter on operational issues inside product data and ecommerce teams, visit productdataweekly.com.