What is the difference between field mapping and value mapping?

Field mapping matches the column to your attribute (“Farbe” → colour). Value mapping normalizes the content within it (“rot”, “Rot”, “RED” → red). Doing only the first leaves you with one field full of inconsistent values, which is why filters still break.

Why not just rename the columns each time?

Because it doesn't persist. A one-off rename fixes one import; a stored mapping applies automatically to every future delivery from that supplier — which is what makes the data stay clean as the assortment changes.

How does this relate to units?

Units are part of value mapping: “50 cm”, “0,5 m” and “500mm” describe the same length. Without normalization they end up as three different values and any filter or comparison built on them is wrong.

Can mapping be automated?

Largely. Recurring supplier structures can be mapped once and reused, and AI can propose mappings for new or unmapped fields. A review step keeps a human in control before rules are applied to the catalog.

What is Attribute Mapping? Simply Explained

Attribute mapping is one of those terms that sounds technical and turns out to describe something very ordinary: translating what a supplier calls things into what you call things. It is the least glamorous step in product data management and probably the one that decides quality more than any other.

The problem it solves

Three suppliers send you the same information about colour. One uses a column called “Farbe”, one “colour”, one “Color-Code”. Inside those columns you find “rot”, “Rot” and “RED”. Without mapping, you end up with three fields and half a dozen values describing one property — and a shop filter that offers your customers three versions of red.

Two levels — and the one people skip

1. Field mapping

Which incoming column corresponds to which of your attributes. “Farbe” → your colour attribute. This is the part everyone does.

2. Value mapping

Which incoming values correspond to which of your canonical values. “rot”, “Rot”, “RED” → rot. This is the part that often gets skipped — and it's why data still looks wrong after a careful import. Matching the column alone gives you one tidy field full of untidy values.

Units belong here too: “50 cm”, “0,5 m” and “500mm” are the same length written three ways. Any filter or comparison built on unnormalized units is quietly wrong.

Why a stored mapping matters

You can rename columns by hand for one import. The problem is the next delivery — same supplier, same quirks, same manual work. A mapping that is stored per supplier applies automatically every time that source delivers again. That's the difference between cleaning up once and staying clean.

What good mapping looks like in practice

One canonical model first. Decide what attributes a product in each group must have, before mapping anything onto it.
Mapping per supplier, reused every time. New delivery, same rules.
Unmapped fields kept, not discarded. Data you can't place today may be useful context later — including for AI enrichment.
A review step. Proposed mappings get checked before they're applied across the catalog.

Where automation helps

Recurring structures only need mapping once. For new or unfamiliar fields, AI can propose the likely match, which a person confirms. In Productbay this is part of the import path: supplier data comes in, field and value mapping is applied, gaps are enriched, and everything generated goes through a review queue before it reaches your channels.

What is attribute mapping? The step that makes supplier data usable