Client
The client is an international company specializing in the production and sale of sanitary ware and bathroom furniture. The company's portfolio includes 30,000 items across 10 brands. It manufactures products at six plants in Europe, CIS, Belarus, and China.
The company's products are sold through its own online store, on five marketplaces, and through a distributor network in CIS and Europe. The company works with dozens of partners, from large chains of plumbing and home improvement stores to small sole proprietors.
The client plans to scale the business by multiples, expanding the assortment by about 100,000 SKUs every three months.
The Problem
As of the end of 2022, the client's product information was spread across Excel spreadsheets and files in Google Docs. In this format, it was not possible to track:
At the same time, preparing a commercial offer and export for each new partner (or updating the assortment for a long-standing partner) became a task that had to be done manually every time: the manager would sit down and create a new Excel file with the assortment and set of attributes required by the partner. This process was the same whether working with large marketplaces like OZON or with any sole proprietor.
Even with an assortment of 30,000 items, the client incurred significant organizational costs.
- who changed the data in each file, when, and how;
- whether the data in each individual file was up to date (the product information had to be checked again every time);
- how data packages are formed for each new counterparty.
Goal: ensure sales scalability and reduce the effort required to maintain high-quality data even as the assortment grows
The client's team planned to expand the product range and sales geography. The previous approach to storing, collecting, and sending product information did not match the company's growth plans. A multiple increase in the assortment would have forced a proportional increase in the team of specialists responsible for working with product information.
Costs would grow exponentially, and so would the risk of errors.
As a solution, the KT.Team team proposed implementing and configuring the PIM system Pimcore, which was expected to:
- store product information centrally;
- ensure transparent and controlled data quality in every product card (it is clear what was changed, by whom, and when);
- reduce manual work through computed attributes, reference values, and automatic exports;
- ensure simple links between product cards and media files;
- provide tools for upselling and increasing the average order value (product bundles).
Result 1: 100,000 new products can be added to the system in an hour and a half
Pimcore supports bulk import of product information in Excel spreadsheets.
This makes it possible to create new product cards quickly: 100,000 new items take only an hour and a half. At the same time, both product descriptions and reference values such as colors, materials, dimensions, and so on are pulled from spreadsheets.
Further refinement of product cards is no longer a black box for the whole team. Pimcore keeps a change history, so it is always possible to find out who made edits to product cards, reference data, and product categories.
We'll curate materials for your task
We'll reply within 30 minutes and send relevant cases, diagrams, or analyses tailored to your context.
Result 2: the product export for a partner is generated in 10 seconds
Each dealer or marketplace that sells the client's products has its own requirements for product information.
OZON needs a standardized name, description, overall dimensions, color in a specific format and standard, and hundreds of other parameters. A hypothetical sole proprietor Ivanov only needs the product name, series, and dimensions: he sells plumbing offline, and his customers can see the color of the items they buy themselves. A hypothetical LLC Santekhnolog does not take collections into account when forming its assortment...
Previously, the client's employees stored all product data in spreadsheets and Google Docs. And every time, they recreated the export for a partner from scratch, taking that partner's requirements into account.
In Pimcore, you can set up an unlimited number of exports, that is, rule sets used to generate the database for a partner. A new export can be created as follows:
This makes it possible to skip the repeated process of collecting and adapting data whenever the need arises again. It is enough to create a rule for a specific partner once: define the set of attributes and the rules for writing them. All subsequent exports will be generated according to that rule with one click. 10 seconds, and the file is ready.
- configure a custom template using standard and custom operator templates (these operators determine how information from a specific product card field will be written into the table);
- create a mapping table, for example for colors (say the brand catalog includes snow white, milky white, and neutral white, while the marketplace standard allows only plain white; with a mapping table, you can standardize color values in the export for the marketplace).
Result 3: system performance does not depend on the number of media files linked to products
Each item in the client's catalog has at least 10 media files: photos from different angles and with different backgrounds, certificates, and videos. These media files are updated regularly: new content is added, and some items are refreshed.
At one time, the client's managers can upload up to 100 GB of files!
The client had requirements for optimization and a faster, more progressive media workflow. If the entire volume were stored inside Pimcore, every upload would significantly reduce system performance. In addition, standard procedures such as preview and thumbnail generation would consume additional resources.
As an alternative, we suggested the WebDAV protocol. It allows media to be uploaded through an interface similar to the familiar file explorer.
WebDAV makes it possible to send media content to the service's own storage, link files to product cards in Pimcore, and avoid overloading Pimcore itself.
Pimcore automatically links files uploaded via WebDAV to product cards. For this, we developed a media binding rule. The file link must contain the product SKU and the file sequence number. So for SKU 3485794, all links will look like 3485794-1, 3485794-2, and so on.
At the same time, using WebDAV does not prevent users from seeing thumbnails of all media files related to a specific item in Pimcore. These thumbnails are generated directly in the file storage and then pulled into the PIM card ready-made.
Result 4: the client can sell both individual products and linked sets of up to 12 items, increasing the average order value
Customers often choose plumbing and bathroom equipment as a package: they buy shower enclosures, sinks, toilets, faucets, and furniture at the same time. For a buyer, assembling a set by picking one item from each category is time-consuming, costly (they have to maintain a consistent design concept themselves), and risky, because the same white color can vary significantly between collections and, even more so, between manufacturers.
The client, in turn, wanted to offer sets of matching items to help customers choose, and as a result increase the average order value and sales.
The set creation function is not part of Pimcore's out-of-the-box solution. So, at the client's request, we customized the ability to combine items into sets of 2 to 12 products.
The set composition is assembled manually, but the same sets can be added to exports for different dealers, helping them increase sales as well.
Classification Store: an option that lets you work with a catalog of any complexity without slowing down Pimcore
The client has a complex catalog with many categories and subcategories.
For example, the company sells not just "sinks," but "wall-mounted sinks," "countertop sinks," and "built-in sinks." Each of these categories has unique characteristics: colors, materials, faucet hole placement, sink shape, depth, and so on. When a category is transferred into Pimcore, each such unique characteristic is converted into a new class, that is, a reference set of available values.
When designing Pimcore for the client's needs, the KT.Team team determined that around 300 reference classes would be needed to transfer the catalog correctly. At the same time, Pimcore can handle no more than 30 classes without performance loss.
We suggested using the Classification Store option. It is one of Pimcore's out-of-the-box options that stores existing reference data separately, without burdening the system core. The content of each reference set is loaded only when needed, not at the moment of logging into Pimcore. The system remains fast, and there is no need to re-enter recurring values for new products every time.
The out-of-the-box version of Classification Store was also not enough, as it did not meet all of the client's needs. For example:
The KT.Team team adapted these options to the client's needs.
The Classification Store option was introduced after the client's users had already started working in the system and become accustomed to using classes. Adapting to the new functionality took several weeks, but by the time the system was fully rolled out, users appreciated how convenient this approach was.
This is what the Pimcore interface looked like when working with classes (reference lists):
And this is what it looks like with Classification Store.
- did not support filtering by multiple attribute values at once - out of the box, only single-value filtering is available;
- did not allow custom field width configuration;
- did not display hints for correctly filling in attributes;
- did not output Classification Store attributes into a predefined cell and did not allow bulk editing of products by these attributes;
- did not provide a consistent way to format media file links for product classes, Classification Store, and so on.
Long class creation and mapping with Classification Store
Implementing Classification Store also led to a long transition period during which the client's team learned to work by the new standards. With Classification Store, creating each new class and setting up the mapping takes several dozen minutes, while using standard classes took almost no extra time.
This process itself will not become significantly faster over time, because each time the mapping will require logic to be worked out.
