Data modelling

In brief: In PIM, data modelling is the process of defining the product data model: categories, classes, attributes, values, variants and relationships. It is the most demanding part of any PIM implementation in terms of domain expertise, requiring experience in data modelling and a sound knowledge of the products.

Creating a product data model: Step by step

Creating a product data model can be a laborious task. The more different types of products you have, the more work is needed before you can actually start entering data.

The challenge is that creating an efficient, well-structured product data model requires considerable experience in data modelling. It also requires industry and product knowledge. Both areas of expertise are rarely found in one person.

We therefore recommend that clients take the following (simplified) approach:

First, identify all relevant product categories and organise them into an intuitive tree structure. Product categories may already have been defined in the ERP system. These can serve as a starting point. It is important that the product categories are intuitive for internal users. The tree structure must also be unambiguous. Product categories should not overlap, and each product should be assigned to only one leaf category.

• Beispiel Bettenhändler Boxspringbetten und Bettgestelle:

• Boxsprings
• Bettgestelle
• Erwachsene Bettgestelle
• Kinderbettgestelle
• Schlafsofas

The next step is to list all relevant attributes for the lowest category level (the leaves of the product category tree). Some attributes apply to all products in the range (product ID, description, size, dimensions, etc.). These can be listed at the top level. All remaining attributes should be listed by category. The next step is to turn the category tree and its attributes into a classification tree. This is done by moving duplicate attributes up the relevant branch, one level at a time, until each attribute appears only once. Each attribute needs enrichment to improve product data quality.

Attribute enrichment can also address channel-specific requirements, for example for a website:

Likewise, attribute-specific enrichment (i.e. whether or not an attribute should be displayed) can be carried out for other channels, such as print or mobile.

The contents of all three bottles are exactly the same. The bottles are also made from the same material. They differ only in size. The following information needs to be stored for each container:

The same information could be entered three times. However, this means a lot of duplicated effort (in fact, triplicated effort). And if, for example, the product description or ingredients change, the information has to be updated three times. This not only creates extra work but is also prone to errors and goes against the principle of a PIM system, where each piece of information is stored only once.

Information is then stored at two different levels. The data for “product description” and “ingredients” is stored at product level. The “item ID”, “product name” and “volume” are stored at variant level. In short, all shared attribute values should be maintained at product level. Values that differ are stored at variant level.

Here, too, the PIM administrator may decide to move the “product name” to product level. In retail, you might want to refer to the product as a “1,0 l Bluna bottle”. However, this can also be achieved by displaying the value “1,0” first, then the unit “l”, followed by the product name “Bluna bottle”. The administrator may even decide to create a separate attribute called “Container” with the value “Bottle”.

The example above is, of course, quite simple. However, if you have a T-shirt in six sizes and ten colours, distinguishing between the product and its variants becomes much more interesting for several reasons:

Unfortunately, there are no universal golden rules for grouping different SKUs into a product and its variants. Typical attributes maintained at variant level include: Here are a few tips, however: From the customer’s perspective, would it make more sense to see all products in a product listing in an online shop? If so, the attribute should not be a variant-defining attribute.

From the customer’s perspective, would it make more sense to see the attribute as a selection option (a drop-down field in our example) on a website’s product detail page? If so, the attribute should be a variant-defining attribute.

Why data models fail

Common mistakes include too many free-text fields instead of predefined value lists, attributes without clear definitions, duplicate attributes with different names, and overlapping category trees. These issues often only become apparent when filters in the online shop do not work or exports to retailers fail. Fixing them later is expensive because thousands of products have already been populated with data.

See also

• Data model / Product Data Model
• Product categories
• Categorisation rules
• Properties / Attributes
• PIM implementation