Blog
November 9, 2022
A consistent product data model is fundamental to sales success. Only a comprehensive product data model can offer customers the filters they need to quickly find the product they want and compare different items.
This presents retailers with the major challenge of mapping more comprehensive product data models to the PIM system that is suitable for their company. Product data models specify how products are best described by which attributes, contain all the value lists required for consistent search filters, and facilitate the setup of comprehensive product data governance, i.e., they contain the category tree. In addition, the model indexes what information suppliers should provide about the products and items. Thanks to continuous migration, new product data models can be tested quickly, practically, agilely, and, above all, iteratively, and adjusted if necessary. How this works and why this approach is so important is explained below.
When is the continuous migration approach needed?
There are essentially two use cases that necessitate the rapid review of a new data model. Firstly, when the entire existing product data model needs to be redesigned because previous structures are no longer sufficient, or when a PIM system is newly introduced.
PIM systems have become indispensable in the modern world for several reasons: On the one hand, PIM serves as a central database for all product-related information and, on the other hand, it facilitates the further processing of this data, for example for web shops or catalogs. In order to take full advantage of all the possibilities offered by the PIM system, a corresponding product data model must be stored in the PIM. But how do you set this up correctly?
The creation of a product data model takes place in two phases. In the first step, categories are refined or newly created, thereby creating or revising the category tree. Next, each category or product family must be described using a uniform set of attributes. Finally, the metadata (data types, value lists, units, etc.) must be defined for each attribute.
How does Continuous Migration work?
A major hurdle in introducing a new product data model is checking it for completeness and testing whether it can be mapped well with the existing product data. In the classic approach, the plausibility of the new product data model is verified by means of a full migration followed by one or two iterations. This is cumbersome in several respects: everything has to be considered on paper and far away from the actual product data, discussed theoretically with a long lead time, described, and, if possible, implemented in its entirety. This involves a great deal of personnel effort and tied-up resources. In addition, adapting and refining the product data model is time-consuming, costly, and comprehensive.
Continuous migration, or the 2.0 approach, skillfully leverages the cumbersome nature of the classic IT migration approach: instead of one large and cumbersome migration, many small iterations are used. Because feedback is received quickly, adjustments can be made and reviewed on a selective basis. This significantly increases the quality of the product data model quickly, agilely, and iteratively, iteration by iteration. After all, only those who can work quickly with the available data and its mappings can quickly see where improvements are needed.
In practice, implementation works as follows: The new data model is created on the Onedot product data platform and the desired PIM test system. The existing product data from the live system is also loaded into the product data platform. With this information, Onedot’s AI-supported software can map existing product data to the new model. In a clearly structured process, the product information is automatically mapped to the structures specified by the product data model.
Once this process is complete and the product data has been mapped to the model accordingly, it quickly becomes apparent whether any adjustments to the product data model are necessary. After any necessary adjustments have been made, the product data is remapped to the improved product data model structure. Of course, the product data is continuously exported from the live system. This process is repeated until the product data looks correct in the new structure, i.e., is displayed correctly.
Benefits of continuous migration via the Onedot product data platform
The fine-tuning of a product data model can only be done with the product data itself. The faster you can test the product data model against the existing product data, the smoother the introduction of a new PIM system or product data model will be. However, there are even more advantages to using Onedot’s product data platform.
Thanks to Onedot’s AI-powered product data platform, companies need to deploy fewer human resources and do not need to involve their own IT departments in the migration, as category or product managers can assist with this. In addition, once continuous migration is complete, the AI is already trained on the company’s own product data model. This enables very fast ramp-up of automated supplier onboarding.
This enables companies to ensure the desired product data quality across a broad and deep product range. This very approach 2.0 is needed to make adjustments to the product data model quickly, agilely, and sustainably. Only in this way can a consistent product data model be introduced that is also future-proof.