Attribute mapping
Attribute mapping is the process of connecting a product attribute in one system to its corresponding field in another — matching an ERP's ITEM_DESC_LONG to a PIM's "Marketing Description," or a brand's "Material" field to the "Composition" field a marketplace expects — including any transformation the value needs along the way, such as a unit conversion or a value-list lookup. It is the field-level counterpart to taxonomy mapping, which translates category structure rather than individual attributes.
What attribute mapping actually does
No two systems in a product data pipeline name or structure the same specification identically. An ERP might store a long description as ITEM_DESC_LONG; a PIM holds the same content as "Marketing Description." A brand's internal system tracks "Material"; Amazon's flat file wants "Composition"; a GDSN data pool wants a GS1 attribute code entirely. Attribute mapping is the rule set that says which source field feeds which target field, so the value travels correctly instead of landing in the wrong place or not at all.
Mapping is often more than a rename. Common transformations include converting units (inches to millimeters), translating free text into a controlled vocabulary's exact values ("Zinc-Plated" to "Zinc Plated"), splitting one field into several (a single "12 x 8 x 4 in" dimension string into separate length, width, and height fields), or concatenating several source fields into one target field a channel expects as a single value.
Attribute mapping vs. taxonomy mapping
The two get grouped together in PIM implementations, but they map different axes of the same catalog.
| Attribute mapping | Taxonomy mapping | |
|---|---|---|
| Maps | Individual fields (Material, Voltage, Weight) | Category structure (which node a product sits under) |
| Answers | Which source field feeds which target field, and how the value transforms | Which category in the target system corresponds to this product's category in the source |
| Determines | Whether a spec lands correctly on the page or feed | Which attribute template, and therefore which required fields, apply to the product at all |
| Breaks when | A channel renames or restructures a field | A source and target taxonomy don't align one-to-one |
In practice they're sequential: taxonomy mapping decides which category — and therefore which attribute template — a product belongs to in the target system; attribute mapping then decides how each required field in that template gets filled from the source data.
Import mapping, channel mapping, and where it breaks
PIM implementations typically split attribute mapping into two directions. Import mapping brings data in — connecting a supplier feed's or ERP's field names to the PIM's internal attribute model. Channel (or export) mapping sends data out — deciding how each PIM attribute translates into the field names and formats a specific marketplace, syndication partner, or storefront expects. A product's "Voltage" attribute might need one mapping to populate a GDSN attribute code and an entirely different one to populate an Amazon flat file column for the same spec.
Mapping breaks in a few predictable ways: a structural mismatch where the source stores something as one field and the target needs several (or vice versa); a missing value with no default defined, which either blanks the target field or fails the import outright; and drift, where a channel changes its own field names or requirements and the mapping silently stops matching anything. Keeping a stable, generic internal attribute model in the PIM — rather than naming attributes after any one channel's convention — limits the damage: a channel change only requires updating that channel's mapping, not the underlying attribute model every other mapping depends on.
Frequently asked questions
What's the difference between attribute mapping and taxonomy mapping?
Taxonomy mapping translates category structure — which node in a target system's hierarchy corresponds to a product's category in the source. Attribute mapping translates individual fields within that category — which source field feeds which target field, and what transformation the value needs. Taxonomy mapping determines which attribute template applies; attribute mapping fills it in.
Does attribute mapping require a controlled vocabulary?
Not strictly, but it's far more reliable with one. Without a controlled vocabulary, free-text values like "Zinc-Plated" and "Zinc Plated" look identical to a human but are two different strings to a mapping rule, and a value-lookup transformation has nothing authoritative to map against. A controlled vocabulary gives the mapping a fixed, known set of target values to translate into.
What happens if a source system has no value for a mapped attribute?
The mapping needs an explicit rule for the gap — a default value, a flag that routes the record for manual enrichment, or an accepted blank — rather than leaving it undefined. An undefined gap either blanks the target field silently or, for a required attribute on a marketplace feed, fails the entire row on import.
How often do attribute mappings need to be updated?
Whenever a connected system changes its field names, data types, or required attributes — which happens routinely as marketplaces revise templates and ERPs or PIMs get upgraded. A mapping maintained against a stable, channel-agnostic attribute model inside the PIM only needs updating on the channel side when this happens; one built directly around a single channel's field names needs rework everywhere that channel's naming is assumed.