Designing a Product Attribute Schema AI Can Use

Every catalog enrichment project produces two outputs: the filled fields and the schema that defined what "filled" means. The fields decay — products change, suppliers change, new SKUs arrive half-described. The schema is what keeps the catalog AI-ready after the project team moves on. We made this point in the catalog enrichment playbook: the schema is the durable asset. This article is the field guide to building one.

A schema sounds like an IT artifact. It isn't. It's a merchandising decision expressed as a contract: for this category, these are the facts a product must carry before a shopper — or a shopping agent — is allowed to meet it. Getting it right takes roughly an afternoon per category. Getting it wrong quietly caps what Brand Agents, on-site AI search, and off-site assistants like ChatGPT and Perplexity can ever say about your products.

What a product attribute schema actually is

Product attribute schema

The per-category contract that names every attribute a product must or may carry, its data type, its allowed values, its unit, and whether an empty value blocks publishing. It defines what "complete" means for that category.

The schema answers four questions for every attribute in a category: what is it called, what values can it hold, what unit does it use, and does an empty value stop a product from going live. That last one is the difference between a schema and a spreadsheet of good intentions. A schema without an enforcement rule is documentation, and nobody reads documentation while bulk-importing 400 SKUs at 6 p.m. on a Friday.

Scope matters as much as content. Schemas are per category, not per catalog. Sofas need seat depth and upholstery material; coffee grinders need burr type and hopper capacity; neither cares about the other's fields. A single global schema either bloats to hundreds of mostly-irrelevant columns or thins out to a lowest common denominator that answers nothing. Category-level scope keeps every field earning its place.

How to design the schema: start from shopper questions

The wrong way to design a schema is to export your current product table and tidy the columns. That approach ratifies whatever you already have — and what you already have was built for humans skimming photos. The right way starts from demand: the questions shoppers actually ask about this category. An attribute that answers a real question is worth ten that describe something nobody asked about.

The question sources are already sitting in your stack:

• Support tickets and chat transcripts — the raw feed of questions your PDP failed to answer.
• On-site search queries, especially zero-result searches and repeated refinements.
• Review content and Q&A sections — what buyers wished they had known before purchase.
• Marketplace customer questions on your Amazon listings, or competitors' listings in your category.
• Return reasons — a return reason is a question the product page answered too late.

1. 1

   Pull 90 days of questions

   Per category, from the sources above. Volume matters less than coverage — most categories converge on a surprisingly short list, with the top questions repeating in dozens of phrasings.

2. 2

   Cluster questions into facts

   "Will this fit under my desk?" and "how tall is it?" are the same fact: height. Each cluster becomes one candidate attribute. Resist the urge to keep both a general and a specific version of the same fact.

3. 3

   Name and type each attribute

   A stable machine name, a data type (enum, number, boolean, text), allowed values where the type is enum, and a unit where the type is number. This is the moment vocabulary and unit decisions get made — not later, SKU by SKU.

4. 4

   Assign a tier

   Required, recommended, or optional, based on question volume and purchase impact. High-volume questions that gate a purchase decision are required. Everything else fights for the lower tiers.

5. 5

   Pressure-test on hero SKUs

   Hand-fill the schema for your top ten products in the category. Wherever you hesitate or improvise, an agent will be wrong at scale. Fix the ambiguity in the schema before it multiplies across the catalog.

Which product attributes matter for AI

The attributes that matter for AI are the ones that resolve a purchase decision. In practice they fall into four groups: identity facts (what it is, what it's made of, how big it is), fit and compatibility facts (what it works with), constraint facts (care, safety, compliance, allergens), and comparison facts (the specs that decide between two candidates). Agents lean hardest on whichever facts shoppers filter on.

• Identity: material, dimensions, weight, capacity. These sit behind the two most common questions in commerce: "is this real leather?" and "will it fit?"
• Compatibility: works-with, fits, replaces. The hardest data to assemble and the highest-intent to serve — we cover it separately in compatibility data for AI agents.
• Constraints: care instructions, certifications, age grading, dietary flags. The facts an agent must never guess, because a confident wrong answer here costs more than a decline.
• Comparison specs: battery life, thread count, burr size, load capacity. When an assistant weighs your product against an alternative, it compares fields, not adjectives.

Notice what's missing: brand storytelling, lifestyle adjectives, tone. Those still matter to humans on the PDP, and Brand Agents will quote your prose when a shopper asks how something feels. But when an agent filters, compares, or verifies, it uses fields. Prose is for delight; structure is for answers. The schema's job is to make sure the answers exist.

Required vs optional: tier every attribute

Not every attribute earns the same enforcement. A flat schema where all forty fields are "important" is a schema where none are: teams fill what's easy and skip what's hard, and the hard fields are usually the valuable ones. Tiering fixes the incentive by attaching a different consequence to each level.

The required tier should be short and strict. Every attribute you add to it is a promise that someone will populate it for every SKU, forever — including the vendor drop that lands the week before a launch. A long required tier doesn't produce a complete catalog; it produces workarounds, junk values typed to satisfy the gate, and a team that resents the schema. Keep required tight and let recommended absorb the ambition.

Controlled vocabularies vs free text

Controlled vocabulary

A fixed, finite list of allowed values for an attribute — e.g. material: cotton | linen | wool | leather — maintained centrally, so every SKU spells the same fact the same way.

The rule we apply: if an agent will ever filter, facet, or compare on an attribute, it needs a controlled vocabulary. Free text is reserved for attributes whose values are genuinely unbounded — a model number, a scent description, a fit note. Everything else gets a list.

The reason is what free text does to a catalog at scale. Four SKUs enter "genuine leather", "Genuine Leather", "100% leather", and "full-grain" — one fact, four values. A human shrugs; a machine sees four different materials. Filters split, comparisons miss, and an agent asked for "leather bags" returns three of your four. Controlled vocabularies are how one fact stays one value across two thousand SKUs and six data-entry hands.

Maintaining a vocabulary is lighter than it sounds. Seed it from your data — export the distinct values an attribute currently holds, collapse the duplicates, and keep the survivors. New values enter through a review step, not free typing. Map known synonyms at import so "fuchsia" lands as "pink" without a human touching it. A vocabulary that takes more than a page per attribute is usually two attributes wearing one name.

Units: one per attribute, stored as a number

Units are where schemas fail quietly. A catalog with depth values of "32", "32 in", and "81 cm" holds three formats for one fact, and every consumer of that data — agent, search index, comparison table — has to guess which is which. Guessing is exactly what you built the schema to eliminate.

• One unit per attribute, catalog-wide. Pick it once and convert on entry, not on display. The database never holds a mix.
• Store numbers as numbers, not strings. As strings, "32" sorts before "8" and every range filter silently breaks.
• Keep the unit out of the value. Put it in the attribute name or its metadata — depth_cm, weight_kg — so the value stays purely numeric.
• Ranges get two fields. min and max as separate numbers, never a hyphenated string an agent has to parse and might not.

Governance: how the catalog stays complete

You keep a catalog complete by making completeness a publishing condition, not a cleanup project. The mechanism is blunt: a new SKU that is missing required attributes cannot go live. Everything else in catalog governance is elaboration on that one gate.

1. 1

   Gate publishing on required fields

   Enforce it where products enter — an import validation, a workflow rule, a pre-publish check in your PIM or on Shopify. The gate must be automatic; a gate that depends on someone remembering is a suggestion.

2. 2

   Push the schema upstream

   Vendor and supplier templates should carry the schema's fields, vocabularies, and units, so data arrives shaped instead of being reshaped after the fact. Every attribute you collect at the source is one you never chase again.

3. 3

   Run a weekly coverage report

   Coverage percentage per category, per tier, with a named owner. Required should read 100% by construction; the report exists to keep recommended honest and to surface categories drifting as they grow.

4. 4

   Review the schema quarterly

   New shopper questions from support and search feed new candidate attributes; attributes nobody asks about get demoted. A schema that never changes is a schema nobody is checking against reality.

Without the gate, entropy wins on a predictable schedule — an enriched catalog decays back toward half-empty within a quarter or two of normal product velocity. With it, every new SKU arrives at the standard the enrichment project set, and the asset compounds instead of eroding. If you want a baseline before building any of this, the Agentic Commerce Readiness Score grades your current attribute coverage and structured data in about three minutes.

Where the schema lives

The schema is a decision before it is a tool. Shopify metafields with per-category definitions carry this model comfortably into the thousands of SKUs; a PIM earns its keep when multiple channels, many vendors, or approval workflows enter the picture. We work through that tradeoff in Shopify metafields vs a PIM. The mistake to avoid is buying a PIM as a substitute for making schema decisions — the tool stores the contract; it doesn't write it.

Design the schema once, enforce it at the door, and the enrichment work you do this quarter is still paying for itself in two years. Skip it, and you'll re-run the same cleanup project every year with a little less patience each time. The fields are the interest; the schema is the principal.