Most attribute models we inherit have between 1,200 and 4,000 product attributes, and fewer than 200 of them are doing any work. The rest are duplicates, supplier leftovers, free-text escape hatches and fields that were mandatory for a project that finished four years ago. Nobody deletes them, because nobody can prove they are unused. This is how a data model that was supposed to make products findable ends up making enrichment impossible.
Here is how we define, scope, level and govern an attribute model that stays the size it should be.
What a product attribute is, and what it is not
A product attribute is a named, typed property of a product, with one meaning, one value domain and a defined scope. Four things have to be true or it is not an attribute yet:
- It has a single meaning that a supplier and a category manager would write down the same way.
- It has one data type.
- It applies to a defined set of products, not to the whole catalogue by default.
- It has a defined domain of permitted values, even if that domain is “any positive number in millimetres”.
Several things get filed as attributes and should not be. The taxonomy node says what the product is. Identifiers say which product it is. Relationships say what it works with. Assets say what it looks like. Marketing copy says how it is described. Each of those has its own model, its own governance and its own failure modes. Pushing them all into the attribute model is the first step towards four thousand fields.
Six classes of product attributes are worth separating explicitly, because they behave differently:
| Class | Examples | What it drives |
|---|---|---|
| Identifier | SKU, GTIN, MPN | Matching and syndication |
| Physical | Length, weight, material, colour | Filters, logistics, comparison |
| Technical | Voltage, IP rating, thread size, torque | Filters, selection, fitment |
| Commercial | Pack quantity, unit of sale, minimum order | Pricing, checkout, availability |
| Compliance | RoHS, REACH, UN number, declaration of performance | Legal exposure |
| Marketing | Features, applications, benefits | Copy and merchandising |
Physical and technical attributes are what customers filter on. Compliance attributes are the ones that carry legal risk. Marketing attributes are the ones that should almost never be a select list. Treating all six the same way is the root of most sprawl we see.
The four decisions that define every product attribute
Every attribute needs four decisions made once, written down, and enforced. Get these right and the rest of the model mostly looks after itself.
Data type
Text, number, boolean, single select, multi select, measurement, date, URL or asset reference. The test is simple. If the value repeats across products, it is a select. If it repeats and a product can have more than one, it is a multi select. Free text is correct only when the value is genuinely unique to the SKU.
We audit catalogues where colour is free text. That single decision costs a distributor every colour facet on every category page, and it cannot be fixed by writing better descriptions.
Unit and value separation
Store a magnitude and a unit code. Never store “240v” or “1.5 metres” as a string. Define one base unit per attribute, convert on ingest, and display in whatever unit the locale needs.
This is the single highest-value decision in an industrial catalogue. Length stored as text makes range filters impossible, makes comparison tables meaningless and makes every downstream feed a parsing exercise. It matters most in technical specification data, where a category might carry twenty measured values per SKU.
Permitted values
The value list is an asset in its own right, with its own owner and its own change process. Scope the list to the nodes that use it. A Material list for cable glands is not the Material list for garden furniture, even though both contain “Stainless Steel”.
Lists rot faster than attributes do. Ours get reviewed on the same cycle as the attributes that use them.
Cardinality and level
Single or multi valued. Product level or variant level. Global or locale-specific. Whether a channel can override the value at export. Four small decisions that determine how expensive the attribute is to populate for the next ten years.
Scoping: which product attributes belong to which nodes
Product attributes do not belong to a catalogue. They belong to nodes, through an assignment matrix. This is the part teams skip when they are in a hurry, and it is the part that decides whether enrichment is possible.
Three tiers work in almost every catalogue we build:
- Global attributes. Fifteen to thirty of them. Identifiers, brand, country of origin, gross weight, packed dimensions, unit of sale. Every SKU carries them.
- Group attributes. Assigned to a branch. Everything under electrical carries voltage and IP rating. Everything under fasteners carries material and finish.
- Node attributes. Assigned to the leaf. Thread size on cable glands. Nominal bore on pipe fittings.
In the catalogues we work on, a healthy leaf node carries roughly fifteen to forty attributes. Six to twelve of those are worth exposing as filters. If a leaf node is carrying ninety attributes, one of two things is true. Either the node needs splitting, or attributes have been assigned to the branch that only apply to part of it.
That relationship runs both ways, which is why we do not treat attribute design and taxonomy and attribution as separate exercises. A node is only correct if the products under it share an attribute set. An attribute set is only correct if it fits every product under the node.
The same logic applies when you are mapping to an external standard. ETIM, eCl@ss and UNSPSC each impose their own attribute sets at their own levels. Reconciling those with your own model is a design decision, not an import job. We cover that in more depth in our piece on B2B product classification.
Product attributes at product level and at variant level
An attribute sits at variant level only if two SKUs of the same product differ on it. The customer has to be choosing between those SKUs on that basis. Colour and size on a workwear jacket. Length and thread form on a bolt. Capacity on a battery.
Everything else sits at product level, inherited by every variant.
Two mistakes, both expensive.
Putting an attribute at variant level just in case. Enrichment cost multiplies by the number of variants. A product family with forty variants and twelve unnecessary variant-level attributes creates 480 values that all have to be sourced, checked and maintained. That cost never shows up in the design review, only in the enrichment backlog eighteen months later.
Putting a true variant axis at product level. The variant picker on the product page becomes impossible to build. The thing the customer needs to choose between is not held as structured data. Merchandising then works around it by splitting the family into separate products, and comparison breaks.
Decide the variant axes per node, before you decide the attributes. The axes are usually one, sometimes two, rarely three. If a node needs four variant axes, look hard at whether it is really one node.
Where product attribute models sprawl
Product attributes multiply for six reasons, and we have seen all six in the same catalogue.
Supplier feeds loaded as-is. A supplier sends 700 columns, and 700 attributes appear. Do this with thirty suppliers and the model is unrecoverable. Supplier columns map to your attributes. They do not become your attributes.
Per-channel duplication. Amazon wants one shape, Google wants another, the trade site wants a third. Teams create three parallel sets of fields instead of holding one internal value and mapping it at export. Channel shapes belong in the export layer.
The free-text escape hatch. “Additional Information”. “Other Specifications”. “Notes”. Every one of these is a place where structured data goes to hide, and they always fill up.
Synonym drift. Colour, Product Colour, Finish, Finish Colour, plus the American spelling that arrived in a supplier feed. All live, all populated, all slightly different. This happens when creation is open and naming is not enforced.
No retirement path. Nothing is deleted because nobody can prove it is unused. So the model only grows.
Governance by ticket queue. Anyone can request an attribute and nobody has the authority to refuse one. Requests get approved because refusing is a conversation and approving is a click.
The admission test: what earns a place in the schema
Every proposed attribute answers five questions. All five have to pass.
- Does something need it? A customer filters, compares or searches on it. Or a channel requires it. Or a regulation requires it. Or an internal process depends on it. If the answer is “it would be nice to have”, the answer is no.
- Can it be populated? We use eighty per cent of the SKUs in the nodes it is scoped to as the bar. Below that, either the scope is wrong or the data does not exist in the market. Both are reasons to stop.
- Is it already expressible? If an existing attribute plus a new list value covers it, add the value. Most attribute requests are really list value requests.
- Does it have one meaning? Write the definition in one sentence without using the word “or”. If you cannot, it is two attributes.
- Does it have an owner? A named person who owns the definition and the value list. Not a team. A person.
That test is deliberately hard to pass. A model that grows by five attributes a quarter is healthy. A model that grows by fifty is not being governed.
Governing the model after go live
Attribute governance is four mechanisms, and they are not complicated.
One owner per domain. Electrical attributes have one owner. Fasteners have one owner. That person approves new attributes, owns the value lists and answers definition questions.
A request path with a standard form. Proposed name, data type, unit, value list, nodes it applies to, and a written answer to each of the five admission questions. Requests that arrive without the form go back.
A change log. Every addition, rename, retype and retirement, dated, with the reason. When someone asks in two years why Finish Colour exists, the answer is in the log.
A retirement review, twice a year. Pull fill rate and filter usage. Anything at zero fill across all live nodes is deleted. Anything under fifty per cent fill goes to its owner with a question. Anything nobody has filtered on in six months moves from facet to specification table.
Deleting attributes feels risky and almost never is. In a decade of doing this we have never had to reinstate a field that failed both the fill rate and the usage test.
Measuring whether your product attributes earn their keep
Four metrics tell you almost everything about the health of a model.
Fill rate per attribute per node. Not per catalogue. A catalogue-level fill rate of sixty per cent hides the fact that one node is at ninety-eight and another is at four.
Distinct value ratio. Count distinct values against populated values within a node. One distinct value means it is a fact about the node, not an attribute, and it belongs in the node definition. Nine hundred distinct values across a thousand SKUs means it is free text wearing a select list costume.
Filter usage. Which facets get clicked, by category. Attributes nobody uses over a full quarter are not filters. They may still be good specification data, which is a different job with a different cost.
Orphans. Attributes scoped to zero live nodes. There are always more than you expect, and they are free to delete.
Run all four every six months. The report takes a day and it is the only evidence you will ever have for deleting anything.
What good looks like
A model we would be happy to hand over looks like this. Twenty to thirty global attributes. Group attributes assigned by branch, not sprayed across the catalogue. Leaf nodes carrying fifteen to forty attributes each. Every measured value stored as a number with a unit code. Every repeating value on a governed list. One or two variant axes per node. A named owner per domain, and a change log with entries in it.
Sectors with heavy technical data, such as electrical distribution, sit at the top of those ranges rather than the bottom. That is fine. What is not fine is a leaf node with ninety attributes and a fill rate of eleven per cent.
Key takeaways
- A product attribute needs one meaning, one data type, a defined scope and a defined value domain. Anything short of that is a text box.
- Separate identifiers, physical, technical, commercial, compliance and marketing attributes. They behave differently and need different governance.
- Store measured values as a number plus a unit code. Never as a string.
- Attributes belong to nodes through an assignment matrix, not to the catalogue.
- An attribute is variant level only if customers choose between SKUs on it.
- Apply a five-question admission test to every request, and make it hard to pass.
- Measure fill rate by node, distinct value ratio, filter usage and orphans. Then delete.
Attribute models do not usually need rebuilding from scratch. They need scoping properly to the taxonomy, levelling correctly, and then governing so they stay that way. That is the work we do in taxonomy and attribution, and it is usually the fastest route out of an enrichment backlog. If your model has more fields than your team can populate, book a thirty-minute call and we will look at your top twenty nodes together.