How to map supplier and seller catalogs to one unified taxonomy

Every supplier and every marketplace seller arrives with its own idea of where products belong. One sends "Valves & Fittings", another "PVF > Ball Valves > Threaded", a third a flat list of 40 internal codes, and a fourth no categories at all. Your catalog has one taxonomy, and every one of those products has to land on the right leaf of it before search, filters, feeds and attribute templates work.

The usual approach is to classify SKU by SKU. It works, but it throws away the most useful thing a seller gives you: its own category assignments, which are consistent within that seller even when they disagree with yours. Mapping categories to categories first, then making SKU-level calls only where a source category genuinely splits, cuts the work by an order of magnitude and makes the next feed from that seller nearly free.

This guide covers that method end to end: the crosswalk, the four relationship types, the worked example, the SKU-level fallback, and the maintenance loop. For the single-product version (one title, one target node) see taxonomy mapping.

Map categories first, SKUs second

A seller's category tree is a compressed statement about thousands of products at once. If a supplier files 1,800 SKUs under BV-SS-THD, and a sample of those SKUs shows they are all threaded stainless ball valves, one decision maps 1,800 products. Classifying each SKU independently makes 1,800 decisions, and some of them will disagree with each other for no reason a buyer would accept.

So the unit of work is the crosswalk: a table with one row per source category per seller, holding the target node, the relationship type, the evidence, and a confidence. SKU-level classification still happens, but only for the rows where the crosswalk says a source category cannot be mapped as a whole.

This is also why a crosswalk is per seller, never global. "Fittings" from a plumbing supplier and "Fittings" from an apparel brand are different categories that share a word. The key is always (seller, source category), not the label.

Infer what each source category means from its SKUs, not its name

Source category labels are unreliable on their own. They are abbreviated (HVAC-ACC), generic ("Misc", "New Items"), legacy (a category named after a product line discontinued in 2019), or organised by something other than product type: by brand, by warehouse zone, by price tier, by season.

Before mapping a source category, read a sample of what is actually inside it:

Pull 10 to 30 SKUs per source category, more for large ones, chosen at random rather than the first rows (first rows are often the oldest, most typical products).
Extract the head noun and function of each sampled product, the same way you would for a single product.
Check homogeneity. If the sample collapses to one product type, the category maps whole. If it shows two or three distinct types, the category is a split (see below). If it shows ten, the category is not a product category at all; it is a brand, a promotion or a dumping ground, and every SKU in it gets classified individually.
Note attribute evidence. Shared attributes across the sample (all have Port Size and Pressure Rating) are strong confirmation of what the category is; attributes that conflict with the proposed target's template are a warning.

The four relationship types in a crosswalk

Every row in the crosswalk is one of four types, and each is handled differently:

Type	Example	How to handle
One to one	Seller's "Ball Valves - Threaded" to your "Valves > Ball Valves > Threaded Ball Valves"	Map the whole category. Spot-check a sample.
Many to one	Seller has "Brass Ball Valves" and "SS Ball Valves"; you have one "Ball Valves" leaf with `Material` as an attribute	Map both whole. Carry the source distinction into the attribute value, so the information is not lost.
One to many (split)	Seller's "Valves" holds ball, gate, check and butterfly valves; you have a leaf for each	Do not map the category. Route its SKUs to SKU-level classification, constrained to the candidate leaves under your "Valves" branch.
No match	Seller's "Clearance" or "Kits & Bundles"	Classify every SKU individually against the full tree. Flag if the volume suggests your taxonomy is missing a node.

Two rules keep the crosswalk honest. First, a split is never mapped to the shared parent node to save time; that is the shallow-node default that makes 3,000 SKUs invisible to filters. Second, a many-to-one row always records which attribute the collapsed distinction moves into. If it moves nowhere, you have discarded data the seller gave you.

Worked example: three suppliers, one valves branch

Target branch in the unified taxonomy:

Plumbing & PVF > Valves > Ball Valves, > Gate Valves, > Check Valves, > Butterfly Valves

Three suppliers send their own structures:

Seller	Source category	SKUs	Sample says	Crosswalk
Supplier A	`PVF > Ball Valves > Threaded`	640	All threaded ball valves	One to one, Ball Valves; `End Connection` = Threaded
Supplier A	`PVF > Ball Valves > Flanged`	210	All flanged ball valves	Many to one, Ball Valves; `End Connection` = Flanged
Supplier B	`VLV`	1,150	Ball, gate and check valves mixed	Split; SKU-level within Valves
Supplier C	`BRASS-PROD`	3,400	Valves, fittings, nipples, unions	No match (material, not type); SKU-level against full tree

Result: 850 of Supplier A's products are mapped with two decisions. Supplier B's 1,150 go to SKU-level classification, but only across four candidate leaves, which is a far easier and more accurate problem than the full tree. Supplier C's category turns out to be a material grouping, so it contributes the attribute Material = Brass to every SKU but no category signal at all.

The first feed from these three suppliers costs real effort. The second costs almost none, because new SKUs in Supplier A's two categories inherit their mapping automatically, and only new source categories need a decision.

SKU-level classification for splits and orphans

For the products that cannot ride a category mapping, the method is the single-product one, applied with two constraints that make it much more accurate at scale:

Constrain the candidate set. A split of a seller's "Valves" category only needs to choose among your valve leaves. Narrowing the candidates before classification, whether by the crosswalk, by attribute signals or by retrieval of the nearest nodes, is the biggest single accuracy gain available. This applies with extra force to AI classification: give the model the provided taxonomy (the relevant leaf paths, with their IDs) and require it to choose one of them or abstain. Never let it invent a node.
Require evidence and a confidence for each call. Store the chosen leaf, the runner-up, and the reason ("function: prevents backflow; has Cracking Pressure"). Calls below your threshold go to a review queue instead of falling back to the parent node.

Use the layers in order of cost: exact lookups first (a GTIN or manufacturer part number you have already classified), then rules for unambiguous patterns, then a model for the judgment calls, then people for the low-confidence and high-revenue remainder.

Validate the mapping against attribute templates

A category node in a PIM or marketplace is a promise about which attributes a product carries. That makes the attribute template the best automatic check on a mapping, and it catches errors no text classifier will:

Template fit. After mapping, how many of the target node's required attributes can be filled from the product's own data? A ball valve mapped correctly has a port size, pressure rating and end connection to put somewhere. A product that fills none of its new node's attributes is probably in the wrong node.
Sibling outliers. Compare each newly mapped SKU with the products already in that node. A SKU with Voltage and Amperage sitting among check valves is a mapping error, not an unusual valve.
Channel feedback. Marketplace and Merchant Center rejections that cite category or missing required attributes are free, labelled evidence. Route them back to the crosswalk row that produced the mapping, so the fix applies to every SKU from that source category, not just the one that was rejected.

The same crosswalk works in the other direction

Most teams have two mapping problems and treat them separately: inbound (seller catalogs into your taxonomy) and outbound (your taxonomy into each channel's required taxonomy: Google's product taxonomy, Amazon's browse nodes, a retailer's item types, UNSPSC for a procurement customer).

The outbound side is a crosswalk too, keyed on your leaf nodes instead of a seller's categories, and it uses the same four relationship types. The difference is that splits on the outbound side are usually resolved by attributes you already hold: if a channel separates "Threaded" and "Flanged" ball valves into different nodes, the End Connection value you preserved on the inbound many-to-one mapping now decides the outbound split. Data discarded inbound cannot be recovered outbound, which is the strongest argument for never collapsing a seller's distinction without moving it into an attribute.

Keep it current: a crosswalk is a living asset

Mappings decay. Sellers add categories, rename them, and reuse old codes for new products. Your own taxonomy gets new leaves. Channels publish new taxonomy versions. A crosswalk built once and never revisited quietly turns into the miscategorization backlog described in fixing miscategorized SKUs.

Three habits keep it healthy:

Treat unknown source categories as events. When a feed contains a (seller, source category) pair the crosswalk has not seen, that is a mapping task, not an error to default around. Route it before the SKUs publish.
Re-sample high-volume rows periodically. A one-to-one row can drift into a split when a seller starts using a category for new product types. A quarterly sample of the largest rows catches it.
Version the crosswalk with the taxonomy. When you add or split a leaf in your own tree, every crosswalk row pointing at the old node is a candidate for re-mapping. Recording the evidence for each row is what makes that re-mapping a review rather than a restart.

Taxonomy design itself, the tree you are mapping into, is covered in how to build a product taxonomy that scales.

Step-by-step checklist

Key every mapping on (seller, source category), never on the category label alone
Sample 10 to 30 random SKUs per source category before mapping it, and judge by product type, not by the category name
Classify each crosswalk row as one to one, many to one, split, or no match
Map one-to-one and many-to-one rows whole, and move any collapsed distinction into an attribute value
Never map a split to the shared parent node; send its SKUs to SKU-level classification constrained to the candidate leaves
Give any AI classifier the provided taxonomy paths and IDs, and require it to pick one or abstain
Store the target, runner-up, evidence and confidence for every mapping decision
Validate mappings against the target node's attribute template and against sibling products
Route channel rejections back to the crosswalk row that produced them
Treat unseen source categories in a feed as tasks to map before publishing, not errors to default around
Re-sample the largest crosswalk rows quarterly and re-review rows when your taxonomy changes

Frequently asked questions

How do you map seller catalogs to a unified taxonomy?

Build a crosswalk per seller that maps each of the seller's source categories to a node in your taxonomy, using a sample of the SKUs inside each source category to decide what it really contains. Map categories that correspond one to one, or many to one, as a whole. Send categories that mix several product types, and categories that are not product types at all, to SKU-level classification constrained to the plausible target nodes.

What is a category crosswalk?

A category crosswalk is a mapping table from one taxonomy to another. In catalog operations it usually has one row per seller and source category, holding the target node, the relationship type (one to one, many to one, split or no match), the evidence for the decision and a confidence score. It lets new products from a known source category inherit their mapping automatically.

What is the best way to map supplier categories to my taxonomy?

Do not trust the supplier's category names; sample the products inside each category and map on what they actually are. Map homogeneous categories whole, carry any distinction you collapse into an attribute, classify mixed categories product by product within a narrowed set of candidate nodes, and validate every mapping against the attribute template of the node it lands in.

Can AI map product descriptions to a provided taxonomy?

Yes, and it handles ambiguous and abbreviated product titles better than keyword rules. It works reliably only with guardrails: give the model the actual taxonomy paths and IDs to choose from, narrow the candidates first, require a reason and a confidence for each choice, let it abstain instead of guessing, and send low-confidence results to human review rather than to the parent node.

How do you handle a seller category that maps to several of your categories?

Treat it as a split. Do not map the category itself, and do not park its products in the shared parent node. Classify each product in it individually, but only against the target leaves that the source category could plausibly contain, which makes each decision faster and more accurate than classifying against the full tree.

How often should taxonomy mappings be reviewed?

Continuously for new source categories, which should be mapped before their products publish, and periodically for existing ones. A quarterly re-sample of the highest-volume crosswalk rows catches sellers who start using a category for new product types, and any change to your own taxonomy should trigger review of every row pointing at the affected nodes.