How to Cut the Cost of Keeping Marketplace Product Data Up to Date Using ESB

Product characteristics may change. For example, in 10 tea sets you might replace tieguanyin with luin lo.

You will have to update the descriptions and listings for these bundles, upload new media files, attach new instructions, adjust prices, and so on. The marketplace may also change its requirements for product listings or media files. For example, instead of 3:4 images, it may now require only 1:1 images.

Or product dimensions must be entered not in one general field, but in three separate ones for length, width, and height.

You would have to manually review every product card and check it against the new standards. The systems responsible for some aspect of marketplace operations may change or be updated. For example, the WMS system may be updated, and the related integrations will have to be fixed.

While integrations are being refined and debugged, stock information on the marketplace will be inaccurate. The marketplace itself may change or update its systems, and you will have to adjust the integrations again.

The task becomes even more expensive if your digital assets and product marketing data are stored in a decentralized way.

The brand's products are sold through retail chains, its own online store, and on four marketplaces: OZON, Yandex Market, Wildberries, and AliExpress.

Before Polaris turned to KT.Team for an IT solution, the data was entered manually through marketplace seller accounts. For each platform, the product manager filled out the listing information according to the standards set by that specific marketplace, then the marketplace manager checked the submitted data 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 became overcomplicated, overloaded, and was performing PIM system functions that were not its own.

Imagine that the residents of five neighboring apartments give different descriptions of a birch tree, for example.

Some say it has green leaves, others say emerald ones.

Some specify height in meters, others in centimeters.

All these descriptions are consistent, but none of them can be called a source of truth.

The same was true of Polaris product data at the start of the project: there were at least five parallel versions of information for each product.

None of the options was a source of truth, so all changes were made in parallel by five content managers based on five inputs from product managers.

To reduce the number of manual operations, the first step was to create a single repository for the golden source of product information. We chose the Pimcore PIM system for this purpose.

Each product in Pimcore now has only one, but the most complete, listing.

This is where all product details are stored, from color and dimensions to package contents and technical specifications.

A product card is a master record.

It contains both universal fields required across all sales channels and unique fields whose data is needed only for Wildberries, Yandex Market, or some other marketplace. For example, multicooker control options for a product card on OZON are described using four fields, while on Wildberries only one is needed.

In substance, these records do not conflict, but each one meets the requirements of its own marketplace.

A separate set of attributes is created inside the PIM system for each marketplace.

It also checks, enriches, and validates the information for compliance with requirements.

By implementing a PIM system, we eliminated the problem of multiple sources of truth.

But even from a single source, the information still has to get to marketplaces somehow. And the “Ctrl + C, Ctrl + V” option still did not look optimal: it was too time-consuming and prone to errors.

That is why the KT.Team team suggested that Polaris set up product data transfer to marketplaces through a middleware system, ESB.

Why did we not suggest direct integration?

At first glance, building a direct integration between systems takes not much more time than developing in an ESB graphical studio.

The same applies to designing the logic, converting the information into the required format, and mapping it to the correct fields.

But in the long run, maintaining direct integrations is more labor-intensive.

Any change in the requirements, structure, or code of connected systems triggers lengthy refactoring. ESB has an advantage, first of all, during development.

Mature ESB products such as WSO2 use a graphical interface for building integrations. They already include ready-made connectors to IT systems and modules for converting information into various formats.

In addition, ESB systems include built-in and pluggable monitoring services that track whether information was delivered to the right destination and, if not, at which stage the error occurred. Second, during support, WSO2, like other ESBs, helps save developers' time and respond to changes faster. For example, if the recipient system’s requirements change, the ESB team only needs to update the marketplace connector.

The logic of all the other integration components does not need to be changed.