How to reduce the cost of maintaining relevant product information on marketplaces using ESB

‍

According to research by Data Insight, almost all online shoppers (more than 60% of Russians) prefer marketplaces to shop. Among the advantages of marketplaces are the price level, the breadth of the range, the convenience of receiving orders, the speed of delivery, etc.

However, each new platform for manufacturers and sellers means not only new opportunities, but also additional costs: studying site documentation, additional integrations, constantly monitoring changes in marketplace policy, monitoring the relevance of information, etc.

In this article, Andrey Putin, Managing Partner at KT.team, explains how to reduce the cost of working with marketplaces and improve information accuracy using IT tools. We consider the use of these tools using the example of the case of KT.team's client, the manufacturer of household appliances Polaris.

How routine manual operations make it difficult to master new marketplaces and make it more difficult to work with existing ones

Let us omit the purely legal aspect of the issue of concluding contracts and focus on the technical aspect of cooperation.

The minimum required from a seller is to fill out the product card correctly and provide media files of the correct formats and sizes (provided that you transfer all logistics issues to the marketplace). At most, you will have to set up integrations of your systems with marketplace systems in order to provide them with information about current prices, inventory balances, and delivery conditions.

It looks like a costly, but still one-time event. Actually...

• Your product specifications may change. For example, in 10 sets of tea, you'll replace “teguanyin” with “luinlo”. You will have to change the descriptions and cards of these sets, upload new media files, add new instructions, adjust prices, etc.

• The marketplace may change its requirements for product cards or media files. For example, instead of images with a 3:4 aspect ratio, we now need only images with a 1:1 ratio. Or the dimensions of the product should not be specified in one general field, but in three separate fields — for length, width and height. You'll have to manually sort through all product cards and check them for compliance with new standards.

• You may change or update the systems responsible for some aspect of working with the marketplace. For example, the WMS system will be updated and related integrations will have to be fixed. When finalizing and debugging integrations, information about marketplace balances will be incorrect.

• The marketplace itself may change or update systems, and you will have to adjust integrations again.

Lots of routine manual tasks. And their number increases in proportion to how many marketplaces you place your product range on.

The task becomes even more expensive when your digital assets and product marketing data are not centrally stored.

How Polaris optimized its work with marketplaces through two implementations

Polaris is a Swiss home appliance brand. The company's active matrix contains more than 700 items (the range is more than 1,000. SKU). Polaris is at the top of the Russian popularity rating in the small household appliances segment.

The brand's equipment is sold in retail chains, through its own online store, as well as on four marketplaces: OZON, Yandex.Market, Wildberries, AliExpress.

Before Polaris contacted by KT.team for an IT solution to the problem, the data was filled in manually through personal accounts on marketplaces. In the case of each platform, the product manager wrote down information for the card according to the standards dictated by that particular marketplace, then the marketplace manager checked the data received and entered it. Each marketplace needed its own team.

All information was stored in 1C in five formats: for its own online store and for four marketplaces. As a result, 1C was overcomplicated, heavier and performed the functions of the PIM system that were unusual for it.

Step one: putting data in order with a PIM system

Imagine that residents of five neighboring apartments give different descriptions, for example, of a birch tree. Some say it has green leaves, others say it has emerald leaves. Some indicate the height in meters, others in centimeters. All these descriptions are consistent, but none of them can be called a standard.

The same thing happened with Polaris product data when the project started: at least five different types of information about each product existed in parallel. None of the options was a benchmark, so all changes were simultaneously made by five content managers based on five signals from product managers.

To reduce the number of manual operations, first of all, it was necessary to create a single gold standard storage center for product information. We have chosen such a center Pimcore PIM system.

Each product in Pimcore now corresponds to only one, but the most complete card. All product information is stored here: from color and dimensions to configuration and specifications.

A product card is a master record. It contains both universal fields that are required on all sales channels and unique fields that only need data from Wildberries, Yandex.Market, or any other marketplace. For example, the multicooker control options for a card on OZON are described using four fields, and on Wildberries, only one. These records are consistent in meaning, but each of them meets the requirements of its “own” marketplace.

Each marketplace has its own set of attributes within the PIM system. These are daughter cards within the master record. The content manager of a particular marketplace does not work with all the information about the product, but only with data for its “own” sales channel. He also checks, supplements and controls information for compliance with requirements.

‍

Step two: automating data transfer to marketplaces

By implementing the PIM system, we have eliminated the problem of multiple standards. But even from a single source, information must somehow reach marketplaces. And the “Ctrl+C, Ctrl+V” option still didn't look optimal: it was too time-consuming and vulnerable to errors.

Therefore, the KT.team suggested that Polaris customize transferring product information to marketplaces through integration through an intermediary system — ESB.

Why didn't we offer direct integration? At first glance, developing direct integration between systems does not take much longer than developing at an ESB graphics studio. In the same way, you will have to think through the logic, convert information into the right format and upload it to the right fields.

But in the long run, supporting direct integrations is more labor-intensive. Any change in the requirements, structure, and code of related systems provokes lengthy refactoring.

First of all, ESB wins at the development stage. Advanced ESB products, such as WSO2, use a graphical interface for building integrations. They already have ready-made connectors with IT systems and modules for translating information into various formats. In addition, ESB systems provide built-in and connected monitoring services that monitor whether information has been transferred “to the address” and, if not, at what stage the error occurred.

Secondly, during the support phase, WSO2, like other ESBs, saves developers time and responds more quickly to changes. For example, if the requirements of the receiving system (marketplace) change, the ESB team only needs to finalize the marketplace connector. The logic of all other integration elements does not need to be edited.

Therefore, we have built integrations between the Polaris PIM system and marketplaces through the ESB layer. WSO2 system:

• retrieves product information from PIM;

• if necessary, converts it to the format required for the marketplace;

• according to mapping (specified rules), it distributes information from the product card fields in PIM to the product card fields on the marketplace.

Bonus: reduced investment in integrations

The introduction of an ESB system means not only reducing the amount of manual work for content managers today, but also working with sales channels more transparently and economically tomorrow.

If the product characteristics change on the Polaris side, it will be enough for the content manager to update it in the PIM system. ESB will collect the updated information, deliver it to the marketplace and distribute it into the product card fields.

If the product card structure or the system itself changes on the marketplace side, developers won't have to rewrite hundreds of lines of code. In the ESB system's graphical interface, it will be sufficient to correct one or two blocks and replace the connector. According to KT.team's experience, the time gain is at least four times.

If Polaris decides to sell products on another marketplace or online store, the IT team can easily develop a new integration using the logic of ready-made WSO2 integrations.

‍

Status as of 2023

Polaris has now moved to the stage of working independently with ESB and technical support. Key managers have been trained to work with the new systems. New product categories are posted on marketplaces through the PIM system and service bus. All changes in product specifications are automatically displayed on marketplaces within a few hours after publication in PIM.