Product attributes decide what a customer can filter, compare, and eventually find. Categories get people to roughly the right place. Attributes are what let them choose, and they are the part most businesses define once, informally, and never govern again.
The result is predictable. Three years in, the model holds several thousand attributes, half of which are variations on each other, and nobody can say which ones matter.
Why product attributes decide what customers can find
Filters, comparison tools, and configurators all read structured values. Prose is invisible to them. A specification mentioned in a description exists for a human who has already found the product and for nobody else. Merchants routinely hold the information a customer wants and give them no way to use it.
The same is increasingly true upstream. Marketplace ranking, on-site search, and the AI surfaces now answering buyers directly all need something machine-readable. A category with thin attributes is absent from the places customers start.
There is also an internal effect that shows up later. Product attributes are what make automated validation possible. A catalogue with a defined model can be checked continuously. One without it can only be reviewed by eye.
Four types of product attributes worth separating
Grouping matters because each type has a different owner and a different quality standard.
Physical. Dimensions, weight, colour, material. Objective, verifiable, and usually the ones customers filter on first.
Technical. Performance figures, capacities, ratings, tolerances, compatibility. These carry the most risk, because a wrong value here has consequences beyond a disappointed customer.
Compliance. Certifications, standards met, safety classifications, regulatory declarations. Their distinguishing feature is that they expire, which almost no attribute model accounts for.
Marketing. Titles, descriptions, feature statements, brand positioning. Subjective, owned by a different team, and governed differently from the other three. These are the attributes people think of first and the ones that matter least for findability.
Separating them means you can apply strict validation where accuracy is critical and leave room for judgement where it is not. Compliance product attributes in particular need a review date and an owner. A certificate that lapsed last quarter is worse than one never published. A single undifferentiated attribute list forces you to treat a marketing strapline like a pressure rating.
Defining product attributes properly
Four decisions per attribute, and skipping any of them creates work later.
Data type. Text, number, boolean, date, or a list. Storing a number as text is the most common early mistake, and it removes your ability to filter by range or sort.
Unit, held separately from the value. Store 500 and millimetres as distinct fields, never “500mm” as a string. Combined values cannot be converted, compared, or normalised, and they break the moment a supplier sends inches.
Permitted values. Anything with a finite set of answers gets a picklist. Free text is where filtering goes to die. “Stainless Steel”, “stainless steel”, and “S/Steel” become three filter options describing one material, and the customer concludes your range is smaller than it is.
Where it is mandatory. Mandatory by category and by channel, never globally. A field made compulsory across the whole catalogue produces junk values in every category it does not apply to. Those are harder to clean than blanks.
Whether something should be an attribute at all rather than a category is a separate question. That is the category or attribute decision, and it comes first.
Why product attribute models get out of control
Three failures, and they compound.
Nobody can create an attribute except everybody. Each new category arrives with its own set, defined by whoever onboarded it. Nothing checks whether an equivalent already exists.
The same property acquires several names. Weight, Product Weight, Net Weight, and Shipping Weight all appear, holding overlapping data with no defined relationship. Filters then return partial results and nobody trusts them.
Nothing is ever retired. Attributes created for a discontinued range, a former channel, or a project that ended stay in the model indefinitely. The list grows monotonically because deletion feels risky and addition feels free.
The symptom is a model too large for anyone to hold in their head. People stop consulting it and create new attributes instead, which accelerates the problem.
Governing a large set of product attributes
Governance here is unglamorous and it is the whole difference between a model that holds and one that sprawls.
Split the model in two. A small set of global attributes that apply everywhere, and category-specific sets layered on top. Most businesses need fewer global attributes than they think and more discipline about the category sets. A useful test for the global set. Pick a product at random from any category. If you cannot state a value, the attribute does not belong there.
Make creating an attribute require a decision. One named owner approves new attributes, checks whether an equivalent exists, and can say no. This is the same governance discipline that keeps a taxonomy coherent, applied one level down.
Map rather than duplicate, always. When a supplier sends OD and you hold Outer Diameter, the answer is a mapping applied during supplier data onboarding, not a second attribute. Normalise on the way in, always, because normalising on the way out means doing it once per channel forever.
Review and retire annually. Any attribute below a low fill threshold is either badly defined, unnecessary, or unknown to the people filling records. All three warrant a conversation, and retirement is usually the honest outcome.
Measuring whether your attributes earn their place
Two numbers tell you most of what you need.
Fill rate per attribute per category shows where the model and reality disagree. An attribute mandatory in a category and filled on a third of products is a governance failure. One filled on two per cent of products across the catalogue is a candidate for deletion. Getting this right depends on being able to measure fill rates properly rather than by sampling.
Filter usage tells you which attributes customers actually care about. A well-populated attribute nobody filters on is effort spent in the wrong place. A heavily used filter with poor coverage is your highest-return enrichment target.
Between them these two numbers give you a priority list, which is more useful than a general instruction to improve data quality.
One caution on interpreting fill rates. A low figure is not automatically a gap to close. Sometimes the attribute genuinely does not apply to most products it was assigned to. That is a scoping error, not an enrichment task. Check which of the two you are looking at before commissioning work.
Where this leaves you
An attribute model is a design that needs maintaining, not a list that needs completing. The businesses that keep theirs usable made three choices. A small global set with category-specific extensions. One person who approves additions. Annual retirement of what nobody uses.
If your product attributes have grown past the point where anyone can explain them, book a thirty-minute discovery call. We will talk it through against your catalogue. Our taxonomy and attribution service covers exactly this work, alongside wider product data services and PIM and PXM services.