Most product structure problems aren’t caused by bad data or the wrong platform. They’re caused by a blurred line between two things that should never be confused: categories and attributes.
Once that line blurs, the consequences compound. Trees become unmaintainable. Filters break. Reporting gets brittle. And every time someone needs to add a new product type or extend the range, the whole structure has to be renegotiated from scratch.
The fix isn’t a new taxonomy. It’s understanding what each structural element is actually for.
Categories and attributes aren’t interchangeable
The failure starts with a basic confusion between definitions:
- Categories (taxonomy) answer: What type of thing is this? They create browsable hierarchy and stable groupings.
- Attributes (metadata) answer: What is this product like? They power filters, comparison, and precise search.
The boundaries blur because both can, technically, group products. You can build a category called “Waterproof Jackets,” and you can filter jackets by a “Waterproof” attribute. But only one of those choices scales cleanly as your range grows.
Where structures start failing
1. Category creep: forcing detail into the tree
The classic failure mode is taxonomy becoming a dumping ground for variation.
- B2C example: “Women’s Shoes > Trainers > Black > Size 6 > Leather”
- B2B example: “Power Tools > Drills > Cordless > 18V > Brushless > Hammer”
This looks organised until the range expands. Add new colours, voltages, materials, or form factors and the tree explodes. Maintenance becomes continuous, onboarding slows, and products end up in arbitrary places because they can’t feasibly live everywhere they belong.
There’s a less obvious cost too. If “black” is embedded in category names, you can’t reliably ask “how many black items sold?” without exposing brittle string logic and a growing list of exceptions.
2. Attribute overload: capturing noise instead of choice
The opposite extreme is a sprawling attribute model where everything becomes a field, regardless of whether it’s useful or consistent. Common offenders:
- “Occasion,” “Lifestyle,” “Theme”
- “Recommended room”
- Free-text “features” fields with mixed terminology
These attributes tend to be subjective, inconsistently populated, and rarely used in filtering. They increase governance burden without adding navigational or commercial value.
3. Universal schemas: forcing one definition across unrelated categories
A universal “material,” “power,” or “compatibility” field sounds efficient until it meets reality. “Power” means volts for drills, watts for vacuums, and nothing useful for hand tools. “Compatibility” in B2B might mean thread size, connector type, or approved standards depending on the category.
Force one attribute definition across unrelated categories and you get nonsensical values, broken filters, and an exception queue that never shrinks.
The missing piece: a shared structural backbone
A shared backbone doesn’t mean one taxonomy for everything. It means a combination of:
- A stable taxonomy that groups by type and purpose — what something is
- Category-level attribute schemas that define what something is like, including:
- which attributes are relevant per category
- which are required for discoverability
- which sit at variant level vs parent level
- which use controlled vocabularies and validated units
When that backbone exists, extending the catalogue — new product types, new ranges, new requirements — becomes a governed process rather than a structural negotiation every time.
A practical litmus test
When someone requests a new category or field, ask them to answer two definitional questions:
| Question | Answer |
| Does it describe what the product is? | → Category |
| Does it describe what the product is like? | → Attribute |
Then two operational questions:
- Can we populate it consistently at scale, including from supplier feeds?
- Will it help a customer choose, filter, compare, or comply?
If the answer to either is no, it’s noise dressed up as structure.
Example schema
Here’s how a well-structured category schema looks in practice for a single category — Cordless Drills:
| Attribute | Level | Type | Required |
| Voltage | Parent | Controlled list (18V, 24V, 36V) | Yes |
| Chuck size | Parent | Controlled list (10mm, 13mm) | Yes |
| Max torque (Nm) | Parent | Numeric + unit | Yes |
| Brushless motor | Parent | Boolean | Yes |
| Compatible battery platform | Parent | Controlled list | Yes |
| Colour | Variant | Controlled list | Yes |
| Included accessories | Variant | Multi-select | No |
Notice what isn’t here: “Occasion,” “Theme,” “Features” as free text, or voltage buried inside the category name. The tree places the product; the schema describes it.
Stop paying the structure tax
When categories and attributes are doing each other’s jobs, every range extension becomes a structural problem. Establishing a clear boundary — and governing it — is what lets your catalogue grow without constant renegotiation.
If you’re not sure where your current structure is breaking down, we can show you. Share a category from your own catalogue and we’ll build you an example schema — a working proof of concept that shows exactly how taxonomy and attributes should sit relative to each other for your products, not a generic template.
It’s a fast, low-risk way to see what a clean structural backbone looks like before committing to anything larger. Get in touch with Start with Data to get started.