Key Takeaways
- Product classification operates at two levels: marketing strategy and data architecture. Most catalog problems live in the second one.
- Standard systems like eCl@ss, ETIM, GS1 GPC, and UNSPSC define not just product groups but also which attributes belong to each class. Choosing the wrong standard for your industry creates ongoing data friction.
- Many manufacturers run a proprietary classification alongside one or more external standards. A PIM makes this manageable. A spreadsheet does not.
- Attribute inheritance is the core benefit of proper classification: assign an attribute to a class once, and every product in that class gets it automatically.
- The most common classification mistake is treating it as a navigation problem. Category trees for webshop browsing and classification structures for data management serve different purposes and should be built separately.
- Flat, undifferentiated product lists are the most expensive classification failure. They push attribute management to the product level, where it cannot scale.
What Product Classification Actually Is
Product classification is the decision of which group a product belongs to. It sounds simple. In practice, it determines what attributes a product carries, how it gets found and filtered, whether it can be exported to a partner system without manual rework, and whether variant logic holds up at scale.
The terms product taxonomy, product category, and product classification get used interchangeably, but they refer to different things. Product taxonomy is the full hierarchy of groups and subgroups. A product category is a specific node within it. Product classification is the act of assigning a product to the right node. Problems in a product catalog almost always trace back to one of these three being poorly defined or confused with another.
In marketing, classification tells you how customers buy a product and what that means for pricing, promotion, and distribution. A high-consideration industrial component gets marketed and sold differently than a consumable maintenance item, even if both come from the same manufacturer.
In data management, classification determines what information a product needs, how it gets structured in your catalog, and whether it can be exchanged with partners, marketplaces, or procurement systems without manual rework. A product classified as a "circuit breaker" in eCl@ss inherits a specific set of technical attributes. If you assigned it to the wrong class, those attributes are wrong too, and every downstream export reflects that.
This article focuses on both sides, but weighted toward the data architecture side, because that is where most of the practical decisions happen for manufacturers and distributors managing large catalogs.
Standard Product Classification Systems (Standards)
Several industry-maintained classification standards exist to solve a specific problem: if your company and your trading partners use different internal groupings, data exchange requires manual translation at every handoff. Standard classification eliminates that and makes interoperability between systems possible without custom mapping at each connection point.
eCl@ss is a cross-industry standard for classifying and describing products and services, ISO/IEC compliant and maintained by the non-governmental eCl@ss association. It is structured hierarchically across four levels: segment, main group, group, and commodity class. Each class defines a set of properties: specific attributes a product in that class must or can carry. eCl@ss is widely used in manufacturing, industrial supply, and process industries, and is increasingly referenced as a common language for Industry 4.0 data exchange.
ETIM (European Technical Information Model) originated in the Dutch electrical engineering sector in 1991 and has since expanded across HVAC, plumbing, construction, and related trades. Unlike hierarchical systems, ETIM organizes products into classes with precisely defined technical features and permitted values. A product classified as a specific type of circuit breaker carries a defined set of measurable features: rated current, number of poles, breaking capacity, as specified by the standard. ETIM is the dominant classification system in European technical wholesale.
GS1 GPC (Global Product Classification) was created in 1999 to support product data synchronization across GS1's Global Data Synchronization Network. It is distinct from UNSPSC despite both being managed by GS1 US. GPC operates at the brick level, where products share a defined set of four to seven attributes. It sees the most adoption in consumer goods, retail, and grocery supply chains.
UNSPSC (United Nations Standard Products and Services Code) is a global, multi-sector standard originally developed for spend analysis and procurement. Its five-level hierarchy covers segment, family, class, commodity, and business function. It does not define product attributes at the class level, which makes it useful for procurement and spend management but less suited to technical product description. It is commonly required for public tenders and B2B marketplace listings.
Choosing between them depends on your industry, your trading partners' requirements, and what you need the classification to do. A manufacturer of electrical components selling to European wholesalers almost certainly needs ETIM. A company selling industrial MRO products across sectors may find eCl@ss more appropriate. Some companies need both.
Other Classification Frameworks
Beyond catalog-focused systems, a broader set of classification frameworks exists for regulatory, statistical, and trade purposes. These are not catalog management tools; they exist for compliance, reporting, and cross-border trade:
- CPC (Central Product Classification): UN standard for statistical reporting across all goods and services
- CPA (Classification of Products by Activity): the EU equivalent, aligned with the NACE industry classification
- HS (Harmonized System): governs international customs, determining duties and documentation for cross-border shipments
- SITC (Standard International Trade Classification): used for international trade statistics
- IEC Common Data Dictionary: maintained by the International Electrotechnical Commission, defines product descriptions based on electrotechnical standards
For a complete overview of the full landscape, Wikipedia's product classification article covers all major systems with their scope and origin.
Individual Classification Systems: Building Your Own in a PIM
Standard systems do not always map cleanly to a company's product range. A manufacturer of custom industrial safety equipment may find that eCl@ss classes exist for some of their products but not for proprietary configurations. A building materials company with a product range spanning structural, thermal, and surface categories may need a classification logic that reflects their own engineering taxonomy, not a generic cross-industry one.
In these cases, companies build a proprietary classification alongside any external classification standard they are required to support. The internal structure typically reflects how the company's own engineers think about the product range: product families, sub-families, and classes defined by shared technical characteristics rather than by external taxonomy conventions.
In projects we implemented for manufacturers of industrial components and electrical equipment, the most functional approach was to define product classes based on shared technical structure: products that carry the same core attributes, need the same completeness rules, and follow the same variant logic belong to the same class. The classification is then built from the product up, not from a standard down.
A PIM makes this tractable. In AtroPIM, each product class carries its own attribute set. When a product is assigned to a class, it automatically inherits all attributes defined for that class: mandatory fields, optional fields, measurement units, permitted value lists. A new product in the "pneumatic cylinder" class gets the right fields without anyone configuring them manually. That inheritance logic is what makes classification worth doing in the first place. Without it, attributes accumulate at the product level and catalog consistency degrades fast.
The more important capability is running multiple classification schemes simultaneously. A manufacturer may maintain their own internal product hierarchy, export to trading partners in eCl@ss, and comply with ETIM requirements for wholesaler catalogs, all from the same product record. AtroPIM handles this by assigning multiple classification references to a single product, each with its own attribute mapping. The source data stays centralized. The output adapts to the channel.
Our customers come to us after trying to manage this in spreadsheets or inside their ERP. The breaking point is usually the same: someone has to maintain parallel columns for each classification standard, and the moment one gets updated, the others fall out of sync. Product information management built around proper classification removes that burden by treating classification as a structural property of the data, not a column in a table. For distributors managing products from dozens of suppliers across a fragmented supply chain, this is not a minor efficiency gain. It is the difference between a usable catalog and one that requires manual intervention at every handoff.
How Product Classification Works in a Catalog
Product classification is not the same as navigation. This distinction causes real catalog problems when ignored.
A category tree in a webshop is designed for browsing: broad at the top, specific at the bottom, organized to match how customers think about products. A classification structure in a PIM is designed for data integrity: products share a class because they share attributes, not because they share a customer search path. The two can look similar and serve different purposes. Building one to do both usually means it does neither well.
Variant logic depends on classification being right. If a pressure sensor is classified correctly, its variant dimensions (range, output signal, process connection) are defined at the class level and inherited by every variant. If it is misclassified or unclassified, variant attributes get added manually per product, and the catalog accumulates inconsistencies over time.
Channel-specific publishing adds another layer. A product record may need to export with eCl@ss codes for one partner, ETIM codes for another, and a simplified attribute set for a marketplace. None of that is possible if the underlying product classification is wrong or missing. The classification is what the export logic reads.
In AtroPIM, the separation between classification structure and navigation structure is explicit. You maintain one canonical product classification that drives attribute inheritance, completeness rules, and export mappings. Separately, you configure the category trees used for webshop navigation or print catalog structure. The two reference each other without being the same thing.
Where this breaks without proper tooling: product classification exists in name only: a field on the product record that carries a label but drives no attribute inheritance, no completeness rules, and no export logic. That is a label, not a classification system. The practical value of classification is entirely in what it enforces and automates downstream.
Common Product Classification Mistakes
Flat category trees. A single-level or two-level product grouping with no attribute inheritance forces attribute management to the product level. At any meaningful catalog scale, that becomes unmanageable. Products end up with inconsistent attribute sets, missing values in some places and redundant entries in others. The catalog looks functional until you try to filter, export, or compare across it.
Mixing classification with navigation. Using the same structure for both data management and webshop browsing creates a structure optimized for neither. A webshop tree is built for how customers search. A classification structure is built for what attributes products share. Forcing one to serve both produces a hierarchy that is too granular for browsing and too shallow for data management. Build them separately and map between them.
Ignoring attribute inheritance. Classification without inheritance is taxonomy without function. The whole point is that the class defines the attributes, not the other way around. If you assign a product to a class and then still configure its attributes manually, the classification is doing nothing. Every attribute added manually is a future inconsistency waiting to appear.
Choosing the wrong granularity. Classes that are too broad group products with genuinely different technical structures, which forces attribute compromise: either some products carry irrelevant fields, or relevant fields get omitted to keep the class clean. Classes that are too narrow create maintenance overhead with no real benefit. The right granularity is the level at which all products in a class legitimately share the same attribute set.
Per-channel classification. Maintaining separate classification structures for each sales channel instead of a single canonical classification with channel-specific mappings multiplies the maintenance burden with every new channel added. When the internal classification changes, every channel-specific version needs updating separately. The correct approach is one source classification with mapped outputs per channel or partner standard.
Late-stage classification. Treating classification as something to add after the catalog is built means reworking attribute assignments retroactively. In large catalogs, that is months of work. Products entered without a class carry no inherited attributes, so someone has to assign fields product by product. Classification should be defined before product data entry begins, not after it is already in trouble.
Most of these mistakes share a root cause: product classification gets treated as an organizational convenience rather than a data architecture decision. Getting it right early costs little. Fixing it later, with thousands of products already entered, exports already broken, and channel-specific workarounds already in place, costs considerably more.