In this article you will find the answer to what the data model in PIM really consists of (manufacturers, categories, attributes and the relationships between them), why categories need to be built based on a stable number and not by name, how the data model in B2B differs from the model in B2C (price lists, discounts, trade credit depending on the customer type), and what it looks like in practice to build and maintain such a model after the system launch.
What is a data model in PIM?
Many companies embarking on a PIM implementation think of a data model as a series of fields describing a product: name, price, color, and dimensions. In practice, a data model is a system of four elements that must be consistent: manufacturers, categories, attributes divided into groups, and the relationships connecting all of these to a specific product. Only together do these elements provide a structure that allows for filtering, comparing, and importing products without manually correcting each record. Let's see why omitting one of these elements can block the entire import before anyone even notices the error.
What does a data model really consist of?
During one implementation for a lighting client, the entire data model was reduced to five files: a list of manufacturers, a list of categories, a list of attributes, a list of attribute groups, and a list of attribute values. Each product in the system must have an assigned manufacturer, an assigned category, selected attributes from the appropriate groups, and selected values for those attributes. This is the core that informs subsequent steps: mapping supplier files, enriching descriptions, and exporting to the sales system. If this core is incomplete, each subsequent step must be performed manually, as the system has nothing to rely on when adapting new data. More information about this process in our Akeneo-based implementations can be found in the Akeneo PIM module overview.
Why do categories need to be built by number and not by name?
During a product data migration for one client, a simple but costly error came to light: category matching in the export was based on the name, not the category identification number in the system. Polish characters in the names caused the same match to differ between files, even though both names appeared identical to humans. The fix required a redesign: each category must have a stable number, and the hierarchy, i.e., the information about which category is superior to which, should be based on the parent category numbers, not on text. The same number also allows for assigning more than one category to a single product, which in B2B is more common than the default PIM templates assume.
What is different about this model in B2B than in B2C?
In a consumer store, the data model typically ends with attributes and categories. In B2B, a layer must be added to this core that responds to the buyer. During the implementation of a platform for a client in the construction industry, it turned out that a single product could have a different price depending on three related arrangements: the price list assigned to a specific customer, the discount negotiated for that customer, and whether the buyer is a verified business customer or a regular guest using standard access. Furthermore, there's the trade credit limit, which is the amount a customer can purchase without paying upfront. A data model without space for these elements will work fine in a demo and will fail the moment the first salesperson asks why customer X sees a different price than customer Y.
What does building and maintaining this model look like in practice?
Building a data model is a one-time effort, but maintaining it is not. In one implementation, each attribute change in the client's system—a new value, a new category, or a new manufacturer—required exporting five files from the source system and re-uploading them to the import tool to rebuild the model. The team leading this process implemented column validation at the input so that file errors would be caught before import, rather than afterward, when the active product database would need to be cleaned up. This is the difference between a data model that runs once, for presentation purposes, and one that endures hundreds of catalog changes without returning to square one. We describe this step in more detail in the PIM implementation roadmap for manufacturers and distributors.
What this article doesn't address
There's no single, universal data model that fits every industry. The number of attribute groups and how they're linked to categories depend on the diversity of a particular customer's catalog—a company with a single product type needs a simpler structure than one selling dozens of technically distinct product categories.
What to remember about building a data model in PIM
The PIM data model doesn't end with a list of attributes. It's a system of manufacturers, categories, and attributes based on stable identifiers, to which, in B2B, an additional layer is added: pricing and availability based on the buyer. Companies that build this model with the initial presentation in mind, rather than hundreds of catalog changes, sooner or later find themselves back where they started.
Before you start building your data model, check:
- Do categories and manufacturers have a stable identification number in the source system, not just a name?
- Is it known who on the client side is responsible for completing and organizing attributes after implementation?
- Does the model take into account that the same product may have different prices and availability depending on the type of customer?
- Is there a way to validate data before import, rather than just correcting errors afterward?
If you see the same chaos today at the level of attribute values only, and not the entire model, see also our article on why attributes block PIM implementations , or write to us - we will check how to design a data model for your catalog.
