Product attributes: how to extract, normalize, and map them

What product attributes are (and what they are not)

A product attribute is a named property with a value: material = stainless steel, capacity = 1.5 L, color = black. Attribute extraction research calls these attribute–value pairs. Attributes describe the product itself and stay true wherever it is sold, which is why they belong in structured fields rather than only in description prose.

Three neighboring concepts are easy to confuse with attributes, and mixing them up causes most schema problems later:

Define the attribute schema before you extract anything

An attribute schema is the contract every value has to meet. Without it, extraction produces whatever the source happens to say, and normalization becomes guesswork. For each attribute, decide the name, the data type, the canonical unit, the allowed values or validation rule, whether it can hold several values, and where it is required.

Keep the schema per product family rather than one giant list: a kettle needs capacity and rated power, a T-shirt needs fiber composition and size. Start with the attributes your channels require and your shoppers filter on, then add the technical attributes your datasheets reliably provide.

Where attribute values come from, and which source wins

Values usually arrive from several sources that do not always agree. Set a source priority per attribute so conflicts are resolved consistently, not by whoever edits the record last.

A practical default: technical documents beat marketing copy, and the specific document beats the general one. When equal sources disagree — datasheet and packaging giving different weights, say — do not average or pick one; ask the supplier which is current.

• Datasheets and spec sheets: the most reliable source for dimensions, ratings, materials, and performance values, usually in tables.
• Packaging and label artwork: authoritative for what is printed on the pack, such as net quantity, warnings, and markings.
• Safety data sheets: hazard classification, composition, and physical properties for chemical products; not marketing attributes.
• Supplier product descriptions: useful for attributes that never appear in a table (style, intended use, compatible models), but the least precise.

How to extract attributes from product descriptions

Free-text descriptions are the hardest source because values are wrapped in sentences, qualified by marketing language, and sometimes negated. Whether you use rules, a dictionary of known values, or a language model, the procedure that keeps the output trustworthy is the same:

1. List the target attributes for the product family, with their allowed values and units, before reading any text.
2. Split the text into sentences and bullets, then find candidate values: numbers with units, known vocabulary terms, and patterns such as “compatible with …”.
3. Check the context of each candidate for qualifiers (“up to”, “approx.”, “from”), negations (“BPA-free”, “not suitable for”), and conditions (“with lid”, “at 20 °C”).
4. Assign each value to exactly one attribute; when a number could belong to two attributes, leave it unassigned for review instead of guessing.
5. Normalize the value and unit using the rules in the next sections, keeping the original text alongside.
6. Mark every attribute that came only from marketing copy, so a reviewer can confirm it against a datasheet before it is used in a spec table or declaration draft.

Map datasheet headers to canonical attribute names

Every manufacturer labels the same attribute differently, often in its own language. Build a synonym table that maps the header text you actually encounter to your canonical attribute name; it grows quickly at first, then stabilizes, and becomes your most reusable normalization asset. Record the unit printed in the header too: under “Weight (lbs)”, no cell repeats the unit. Table layouts, scans, and OCR are covered in the guide on extracting product data from PDFs.

Normalize numbers and units

Store every quantitative attribute as two fields: a number and a unit code. UN/CEFACT Recommendation No. 20 (“Codes for Units of Measure Used in International Trade”) provides three-character common codes for this, and schema.org uses the same codes in its unitCode property, for example a QuantitativeValue of 25 with unitCode CMT. Using these codes instead of free-text units (“cm”, “cms”, “centimetres”) removes a whole class of mismatches.

Choose one canonical unit per attribute, usually the SI unit or a decimal multiple of it, and convert at import so values compare correctly across suppliers. Keep the original value and unit as printed for traceability, and convert back to channel units at export: a Shopify product CSV expects weight in grams, while WooCommerce uses the weight and dimension units configured in the store.

Watch the details that cause silent errors. Decimal and thousands separators depend on the document’s locale: on a German datasheet “1.000 W” is one thousand watts. Split ranges into minimum and maximum fields, store tolerances apart from the nominal value, and keep qualifiers such as “approx.” or “max.” in their own field. Imperial conversions use exact definitions (1 inch = 25.4 mm; 1 lb = 0.45359237 kg); round once, at display time.

Use controlled vocabularies for text attributes

A controlled vocabulary is the list of values a text attribute may take, plus the synonyms that map onto each. It lets a “Color: black” filter catch products described as “blk”, “Black”, and “schwarz”.

Keep two fields where marketing and filtering pull in different directions: a normalized base value for filters and feeds, and the manufacturer’s own name for display. “Midnight Graphite” is a good product page detail and a useless filter value; “gray” is the reverse. For multilingual catalogs, store vocabulary values as language-neutral codes and translate their labels, so the same product filters correctly in every storefront language.

Map attributes to taxonomies and channel schemas

A taxonomy decides which attributes apply to a product and what they are called. You rarely get to pick one: a retailer may ask for GS1 GPC, a wholesaler for ETIM, Shopify for its Standard Product Taxonomy, and search engines read schema.org markup. Keep your own attribute schema as the master and maintain a mapping to each external taxonomy.

In GS1 GPC the brick is the building block, and brick attributes carry details such as whether a milk is animal or non-animal. ETIM gives each class a predefined set of features with fixed value lists and units, and publishes its model in 17 languages. Shopify asks for one category chosen by the product’s main function; setting it unlocks category metafields. schema.org Product has dedicated properties such as gtin, mpn, brand, color, material, size, and weight.

Handle variants without duplicating attributes

Variants are products that share most attributes and differ on a few. Model them as a parent record holding the shared attributes and child records holding only the variant axes and the values that change with them, such as color, size, capacity, and their own identifiers. GS1’s GTIN rules treat each style, color, and size variation as a unique product with its own GTIN, so the identifier always lives on the child.

Multi-model spec tables cause most variant errors. Split a table with one column per model into one record per column, and copy any value printed once across columns — a merged cell, or “all models: 230 V” under the table — to every child it applies to. In Shopify, the Option1 LinkedTo CSV column links a variant option to a category metafield; a product can have up to three options and 2,048 variants.

Validate attributes with rules and QA sampling

Validation rules catch mechanical errors: wrong type, wrong unit, impossible value, missing required attribute. Run them on every import and route failures to a reviewer instead of silently dropping values.

Rules cannot catch a plausible but wrong value — a capacity copied from the neighboring model column passes every check. QA sampling can: compare sampled records with the source documents field by field. There is no universal sample size or error threshold; set them by risk.

1. Draw a sample of records per supplier, weighted toward new suppliers and new document layouts.
2. Compare every sampled attribute with the source, recording matches, wrong values, and missing values separately.
3. Calculate error rates per attribute, not just per record, to find the attributes or header mappings that cause trouble.
4. Check safety-relevant and legally required attributes on every record, not on a sample.

Running attribute normalization at scale

The schema, synonym tables, vocabularies, and rules are the durable part of this work; the extraction method can change underneath them. Version them, give each an owner, log manual corrections with a reason (repeated corrections show a missing rule), and review the synonym table whenever a new supplier is onboarded.

If your attributes start life in supplier PDFs, Doc2Shelf can do the extraction step: it reads uploaded datasheets, spec sheets, SDS, and catalogs, keeps values and units exactly as printed with the page and a short quote as evidence, and flags missing required data. Your normalization rules then apply during review, before the record feeds listings or declaration drafts.