Mapping your catalog to every marketplace’s categories with AI.

A merchandiser lists a new range on a marketplace, and half of it comes back rejected: wrong category, a required attribute missing. The other half goes live under a category shoppers rarely browse. The next channel has a different tree and different rules, and the mapping spreadsheet grows another tab.

Each marketplace has its own category tree and required attributes, and a wrong category hides a product or gets it rejected. AI can propose the category and fill required attributes from your data, with confidence flags. People approve each new mapping once, and it is reused from then on.

Why is category mapping such a manual job?

Because nothing lines up. One marketplace sorts furniture by room, another by material, a third by style, each to a different depth and in its own words. Required attributes differ by category and by marketplace, and many accept only values from a fixed list: “gray” may be allowed where your data says “antrasit”. Your own categories were built for your store and your ERP, not for anyone else’s tree. And the work repeats with every new product type, every new channel and every change a marketplace makes.

How can AI propose categories?

Map product types, not products. A “three-seat fabric sofa” is mapped once per marketplace; every product of that type inherits the mapping. That turns one decision per product into one decision per product type, and people review only new product types or low-confidence proposals.

For each product type, the system searches the marketplace’s current tree and proposes the best few categories, each with a confidence score and a reason. The model chooses only from category IDs that exist, so it can’t invent a path. When two leaves look alike, the proposal says what separates them, such as one being meant for sofa beds, so the reviewer can decide in seconds. Trendyol, Hepsiburada and Amazon are typical examples; they are systems a mapping connects to through the interfaces each provides, not partnerships.

Here is an illustrative example, with three fictional marketplaces whose trees are invented and follow no real marketplace’s rules:

The sofa’s record holds width, depth, fabric, color and seat count, but no frame material or maximum load. The proposal maps it to all three trees, fills what the data supports, converts “antrasit” to marketplace B’s allowed “gray” with a note for the merchandiser to confirm, and flags frame material and maximum load as missing.

How do you fill required attributes without guessing?

Start from the target category’s list of required attributes and allowed values, read from the marketplace’s own current data. Fill each one from your product information system, ERP or supplier sheets, converting units where needed. Where a marketplace accepts only listed values, the model picks from that list or flags that nothing fits. A missing value is flagged for the merchandiser, never guessed. Derived values are allowed only by written rule: seat count can follow from the product type, but a maximum load can’t be inferred from a photo. Our note on structured output explains how to hold a model to closed lists like these.

Gaps found this way are worth fixing at the source. If frame material is missing for every sofa, the product data needs a new field, not a thousand manual entries; our note on cleaning master data covers that side.

Where should people review?

Approve each mapping once, reuse it everywhere, and check it again when the tree changes.

• New product-type mappings, approved once per marketplace by the merchandiser or channel manager.
• Low-confidence proposals and value conversions seen for the first time.
• Every flagged missing attribute.
• Sensitive categories, such as electrical goods or children’s products, whatever the confidence.
• A sample of reused mappings, so a quiet error doesn’t spread across a whole range.

Descriptions are a separate step; our note on AI product descriptions covers them.

How do you keep mappings current when marketplaces change?

Category trees and attribute rules change: categories split, merge or retire, new attributes become required, allowed values move. So re-validate on a schedule. The system fetches each marketplace’s current tree and rules, compares them with the stored version, and sends affected mappings back to review: a retired category, a new required attribute, a value no longer allowed. Keep every version of the mapping table, so reports and audits can see what was live when. Between scheduled checks, a sudden rise in rejections for one category is often the first sign of a change, so treat it as a trigger for an early re-check.

How do you measure accuracy?

Before launch, test proposals against an evaluation set of product types with approved mappings: how often the first proposal is right, and how often the right category is among the few shown. Check filled attributes against a reviewed sample. After launch, track rejections by marketplace and reason, listings corrected after going live, and time to list a new product type. Report by marketplace and product type: a good average can hide one channel where a whole range sits in the wrong place.

Approve the big mappings first

Start with one marketplace and your highest-volume product types, and approve those mappings first. The commerce intelligence page shows how listing work fits with product content and customer answers, and the product data and mapping tables underneath are data and AI foundations work.