PIM Classification: A Practical Guide

Product data management fails quietly. Catalogues grow, teams multiply, channel exports break. In most, cases the root cause is the same: nobody defined a clear classification structure early enough.

What Is PIM Classification?

In a product information management system, classification is the process of assigning products to a defined product taxonomy so each product carries the right set of attributes, units of measure, and validation rules for its type.

Classification is structural. It answers one question: what kind of thing is this product? A power drill belongs to a class that requires voltage, torque, chuck size, and safety certifications. A t-shirt belongs to a class that requires material composition, fit type, and care instructions. The class determines which data fields are relevant and which are mandatory.

Most PIM systems implement classification as a dedicated object layer, separate from the product record itself. A product is linked to one or more classes; those classes define which attributes the product inherits. Change the class, and the attribute set changes with it. The product data model stays clean and avoids the sprawl of hundreds of product-level custom fields added over time by different teams. The classification system is what gives that model its structure.

In projects we implemented for industrial equipment manufacturers, uncontrolled field growth was one of the most common problems we encountered. Products had accumulated 200-plus attributes at the record level, many of them duplicates or near-duplicates added by different business units. Moving to class-based attribute inheritance cut that to roughly 40 to 60 class-defined fields per product type, with full audit coverage and consistent completeness scoring across the catalogue.

Classification vs. Product Category

These two concepts are frequently confused, even by experienced PIM users. They look similar in a tree view but serve entirely different purposes.

A product category is a commercial construct. It structures how customers browse, how buyers manage assortments, and how channels organise listings. The same product can appear in multiple categories at once. A cordless drill might sit under "Power Tools" and "Father's Day Gifts" simultaneously.

A product classification is a data governance construct. It defines which attributes a product needs to be complete and comparable with other products of the same type. A product should have one primary classification class. That class is stable. It reflects the physical and technical nature of the product and does not shift with marketing calendars or channel strategies.

Teams that conflate the two end up with one of two problems. Either their attribute sets are inconsistent, because categories change frequently and drag attribute assignments with them. Or their navigation structure is rigid, because it is locked to the data model rather than business logic. Treating them as separate concerns, with separate owners and separate governance, is what prevents both.

The clearest signal that a team has confused the two: their classification tree has a node called "Sale Items" or "Seasonal."

Classification Models

Flat Classification

All product classes sit at one level with no hierarchy. Simple to implement, appropriate for small homogeneous catalogues with a stable, narrow product range. Flat classification breaks down once product diversity increases, because there is no way to share common attributes across related classes without duplicating them. A safety certification field required by all power tools has to be added manually to every individual class. Once a catalogue reaches 20 to 30 distinct product types, the duplication overhead outweighs the simplicity benefit, and hierarchical classification becomes the better fit.

Hierarchical Classification

Classes are organised in a tree. Parent classes carry shared attributes. Child classes add type-specific ones. All "Power Tools" inherit a safety certification field from the parent. A "Drill" class adds chuck size; a "Circular Saw" class adds blade diameter and kerf width. When a regulatory requirement changes, you update the parent class once, and it propagates to every child automatically.

Hierarchical classification is the standard model in mid-market PIM deployments. It maps well to industry classification standards and scales to several thousand product classes. The product hierarchy can grow as the catalogue grows. Manufacturers and distributors can run their full catalogue on a well-designed structure without hitting structural limits.

Faceted Classification

Products belong to multiple classification dimensions at once: material, function, application, and technology standard. Faceted models handle complex technical products well but require careful governance. Without it, the number of valid class combinations grows faster than teams can manage. This model is more common in MDM contexts and in sectors such as electrical wholesale and industrial components, where a single product may need to be described along three or four independent axes.

For most B2B manufacturers and distributors, hierarchical classification is the right starting point. Faceted models increase expressive power but bring real governance overhead. Start hierarchical and layer facets only where the business has a concrete need for them.

How to Build a Classification Structure

Step 1: Define the Scope and Purpose

A classification built only for internal reporting will look different from one built to drive channel exports and data completeness scoring. The most durable approach covers both. It defines the attribute set each product type requires, is granular enough to map to the channel-specific schemas teams use (e-commerce, print catalogues, EDI), and stable enough that it does not need to be rebuilt every time a channel requirement changes.

Before designing anything, audit the most populated product types in the existing catalogue. Those are the classes that need to be right first. A wrong structure in production with thousands of products assigned to it is expensive to correct. Classification debt compounds.

Step 2: Choose a Reference Standard

Building a classification from scratch is rarely necessary and usually a mistake. Industry standards exist for most sectors, maintained by industry bodies and already supported by major trading partners and marketplaces:

• ETIM: electrical, mechanical, and HVAC components; dominant in European wholesale distribution
• GS1 GPC: global product classification for consumer goods and industrial products; common in retail supply chains
• eClass: widely used in the DACH region for industrial goods and engineering components; well-supported in procurement and ERP systems
• UNSPSC: procurement-focused; common in public sector and enterprise purchasing contexts

Using a reference standard reduces build time significantly. It also ensures compatibility with trading partners and simplifies certification workflows, because the class identifiers and attribute definitions already match what downstream systems expect. The practical approach is to map your internal class names to the standard identifiers rather than replacing them. Internal teams work with familiar terminology while the system outputs standard-compliant codes for external exchange.

Step 3: Define Attributes per Class

For each leaf class, define the complete attribute set: mandatory fields, optional fields, units of measure, controlled vocabularies, and validation rules. A product assigned to the wrong class will be missing required fields. The PIM system surfaces this as a data completeness gap rather than letting it pass silently into an export or a customer-facing feed.

One practical principle: separate attributes that describe what a product is from attributes that describe what a product does. For a pump, the class-defining attributes are flow rate, inlet size, and pressure rating. Application-specific attributes, such as recommended use environments, belong to a separate enrichment layer rather than the classification structure. Mixing the two inflates class attribute counts and makes completeness scoring unreliable.

Step 4: Set Inheritance Rules

Attributes should be defined as high in the hierarchy as they actually apply. Shared regulatory fields belong at a category or family level. Product-type-specific fields belong at the class level, typically organised into attribute groups by subject area (technical specs, logistics data, sales content). Variant-level fields (colour, size, packaging unit) sit on the product or SKU record, not the class. Getting this right is also what makes the classification system reusable as a master data foundation across systems.

Inheritance design pays off most clearly during channel readiness work. When a new export template requires a field that all products in a family need, one change at the parent class covers the entire family. In a catalogue of 50,000 products, that distinction is not academic. The same change applied class by class or product by product takes weeks and introduces inconsistencies.

Step 5: Build a Reclassification Workflow

Products get reclassified. Engineering changes, acquisitions, new product families, and regulatory updates all trigger class changes. Reclassification without governance creates orphaned attribute data: fields that existed in the old class but have no mapping in the new one, silently lost during the move.

Define the workflow before the first reclassification request arrives. Define who proposes a change, who approves it, and how the attribute delta is handled when a product moves from a class with 45 fields to one with 60, or one with a different mandatory field set. Teams that skip this step tend to avoid reclassification entirely, and the classification gradually diverges from the actual product portfolio.

AtroPIM supports class-based attribute inheritance with configurable completeness scoring per class. Products not meeting the mandatory field threshold for their assigned class are flagged at the point of data entry. Approval workflows and audit trails cover reclassification events, so attribute deltas are tracked rather than silently dropped.

Common Mistakes

Confusing classification with navigation is the most damaging one. If the classification tree mirrors the website menu, what you have is a category structure. They can share similar names, but they serve different purposes and must be maintained independently by different owners.

Granularity errors run in both directions, but too many leaf classes is the more common problem. A classification with thousands of narrow classes is difficult to maintain and rarely improves data quality. In one distribution project we reviewed, the client had over 3,000 leaf classes covering a catalogue of 80,000 products. Most classes had fewer than 10 products assigned. The overhead of maintaining attribute sets for each class far exceeded the benefit. Consolidating to 400 well-defined classes with richer attribute sets improved completeness scores and cut the time spent on classification governance by roughly half.

Proprietary classification models create mapping overhead every time a new trading partner, marketplace, or procurement system comes online. Aligning with ETIM, eClass, or GS1 GPC from the start eliminates that work.

And without a designated owner, classification drifts. Teams add classes ad hoc to solve immediate problems. Within two years, a well-designed structure can become unrecognisable. Assign ownership to a product data manager or MDM team and give them the authority to reject ad hoc additions.

What Classification Makes Possible

Data completeness becomes measurable once each class defines what "complete" means for its product type. Completeness scores can be tracked per class, per product family, and per channel target. Product enrichment effort goes to the gaps that actually matter for the next export or campaign, not to whichever fields happen to be most visible. Faster, better-targeted enrichment also shortens time-to-market for new product launches.

For channel readiness, the same principle applies. A product correctly classified in ETIM can generate a standards-compliant data sheet for electrical wholesale with minimal additional mapping. Products that are misclassified or unclassified create manual work at export time, every time.

Search and filtering performance in B2B catalogues depends heavily on attribute consistency across comparable products. Classification-driven attribute sets produce that consistency. Faceted search, faceted filtering, comparison tables, and parametric search all require that products of the same type carry the same fields with the same units and controlled vocabulary values. Enforcing that manually, product by product, does not scale. Classification is the only mechanism that makes it systematic.

Classification is the structural decision that determines how much manual work every downstream process requires. Most teams only discover that when they try to fix it retroactively.