Map Supplier Attributes to Your Schema: A Step-by-Step Playbook

Every supplier sends product data in its own shape. One furniture vendor calls it Color, another calls it Finish. A CPG supplier ships net_weight_g, and an MRO catalog buries the same value inside a free-text spec string. When dozens of these feeds converge on a single PIM or ERP, the result is attribute chaos: the same product characteristic in twenty field names, three unit systems, and no consistent vocabulary. Claro eliminates that chaos by resolving attribute identity across supplier feeds, normalising values to your standard, and writing clean, attributed records back into your existing systems — so the mapping work you do once keeps working as catalogs grow and feeds change.

The goal of this playbook is to map supplier attributes to a single internal schema so that records from any source land in the same fields, with the same units, and with a clear record of where each value came from. Run it whenever you onboard a new supplier, ingest a new feed format, or notice that the same attribute is arriving under three different column names.

A good mapping is reusable. Done once per supplier and versioned, it turns every future file from that vendor into a near-automatic load instead of a manual cleanup session. Below is the workflow product-data teams use to get there.

1. 1
   Define the target schema first

   Before touching supplier files, write down your canonical schema: the exact field names, data types, allowed units, and which fields are required versus optional. Group them — identity, commercial, physical, compliance, media — so reviewers can reason about coverage. If you do not have a documented target schema, that is step zero. See What Is Schema Mapping? for the underlying concept.

2. 2
   Profile the incoming supplier file

   Open the raw file and inventory every column: name, sample values, fill rate, and obvious type (string, number, enum, date). For a furniture supplier you might find 40 columns where only 26 are populated. Profiling tells you which source fields actually carry data worth mapping and exposes encoding or delimiter problems early. If the file is malformed, clean it with the CSV Encoding and Delimiter Fixer before mapping.

3. 3
   Draft the field-to-field mapping

   Create a mapping table: each source column maps to one target field, plus a transform note. Capture the obvious matches and the tricky ones together.

   Supplier column	Target field	Transform
   Color / Finish	color	Lowercase; map to your colour vocabulary
   net_weight_g	weight_value + weight_uom	Split numeric value from unit (g)
   Manuf Part No	mpn	Trim whitespace; strip leading apostrophe
   UNSPSC	category_code	Validate against standard; classify from description if invalid

   One source column can feed two target fields — a packed 5x3x2 cm dimension splits into length, width, height, and unit — and several source columns can collapse into one. Document each decision so the next person understands the intent.

4. 4
   Normalise values, not just field names

   Mapping the column is half the job; the values still need to agree. Convert lbs to your standard kg, expand Y/N flags to booleans, and collapse Stainless, SS, and Stnls Steel into one canonical term. For industrial distribution this is where most rework hides — wire gauge, thread pitch, and IP ratings all arrive in inconsistent notation. See What Is Data Normalization? for the patterns.

5. 5
   Reconcile classification and taxonomy

   Supplier categories rarely match yours one-to-one. Map their taxonomy to your standard — ETIM, UNSPSC, or an internal tree — rather than copying their labels verbatim. The Taxonomy Mapper cross-walks ETIM, UNSPSC, and Google categories so a CPG vendor’s hierarchy lands in the right node of your own tree.

6. 6
   Attach provenance to every mapped value

   Record where each value originated: source file, column, row, and any transform applied. Data provenance lets you trace a wrong weight back to the exact supplier cell and prove a value was not invented. It is also what makes a mapping auditable when a buyer disputes a spec months later.

7. 7
   Validate the output and save the mapping as a reusable profile

   Run the mapped records against your required-field rules and type checks. Spot-check 20–30 rows by hand across categories. Then save the mapping as a named, versioned supplier profile so the next file from that vendor loads with little to no manual work — and so you can diff it when their format changes.

Before and after: messy feed versus trusted catalog record

Common pitfalls when you map supplier attributes

Other recurring traps: mapping a column but ignoring its units — a furniture vendor in centimetres loaded as inches — treating one-off manual fixes as the mapping instead of encoding the rule, and over-trusting a supplier’s category codes without validation. A clean field name with dirty values still produces a bad record. Mapping and normalisation are one job, not two.

When mapping logic grows beyond what spreadsheets can manage — hundreds of suppliers, conflicting units, derived fields, and write-back into PIM and ERP — Claro handles the field resolution, normalisation, provenance, and validation as a persistent data layer. Every supplier feed runs through your versioned profiles; every write-back is clean and traceable. See why supplier onboarding takes weeks without tooling for the failure mode this avoids.

Related

FAQ