Product Attributes: The Fields Every Channel Expects and What Happens When They Are Missing

Product attributes are the structured facts that describe a product: brand, size, material, voltage, finish, pack quantity. They are the difference between a product a buyer can find, filter and compare, and a product that only surfaces when someone types its exact title. On most storefronts it is the attributes, not the descriptions, that decide whether a product sells.

What product attributes are

An attribute is a named field with a value, and usually a unit: Voltage = 18 V, Colour = Anthracite, Pack Quantity = 50. The value is stored as structured data, not as a sentence. "Powerful 18V motor" in a description paragraph is information; Voltage = 18 V in a field is an attribute. Only the second one can drive a filter, a comparison table or a marketplace feed.

The terminology overlaps in practice. Specifications usually means the technical subset of attributes. Features usually means the marketing framing of them. Underneath both words sits the same thing: a field, a value, a unit, held consistently across every product in the category.

The five types of product attributes

Identifiers. SKU, GTIN, MPN, supplier code. They make a product unambiguous across systems, and they are what deduplication and marketplace matching run on.

Descriptive attributes. Brand, colour, material, style, range. The vocabulary buyers browse with.

Technical attributes. Dimensions, weight, voltage, capacity, ratings, standards conformity. The bulk of the schema in trade and industrial categories, and the hardest to source.

Commercial attributes. Pack size, unit of measure, warranty, country of origin. The fields that make a price comparable.

Channel and compliance attributes. Energy class, safety certifications, marketplace category requirements. The fields that are optional right up until a listing is rejected or a regulation applies.

What product attributes do on a storefront

Search runs on them: buyers query "18v combi drill 2 batteries", and a product whose voltage lives only in a description paragraph does not come back. Filters are built from them, which is why faceted search quietly fails on incomplete data: a voltage filter that only 60 per cent of drills carry hides the other 40 per cent from anyone who uses it. Comparison tables read them. And AI shopping assistants lift them: an answer engine recommending a product quotes its structured attributes, not its adjectives.

Why attribute completeness fails

Supplier data arrives as prose, PDFs and inconsistent spreadsheets, so the values exist without being usable. Requirements are category-specific, a drill needs thirty attributes and a paint tin needs a different twenty, so a single generic template both over-asks and under-asks. And when no one owns the schema, every team adds fields independently until the same fact lives in three places.

The visible symptom is a category that needs 30 attributes averaging 18 filled. What that costs, from dead filters to rejected listings, is set out in incomplete product data, but the summary is: every missing value is a query the product cannot answer.

How to define the attributes each category needs

Completeness only means something against a definition, and the definition is an attribute schema: per category, which fields exist, which are required, what units and permitted values they take. Build it per category, not per catalogue. Mark required against the category's real selling behaviour, not aspiration.

Standards save schema work where they fit. ETIM defines attribute sets per product class for electrotechnical and building products (covered in what is ETIM), and marketplace category templates do the same job for Amazon and eBay. Adopting one where your categories overlap converts schema design from invention to selection.

How product attributes get populated at scale

Manual entry has a ceiling of roughly a few dozen SKUs per person per day, falling fast as the schema grows. Past a few thousand SKUs the arithmetic stops working, which is where extraction takes over: reading supplier spreadsheets, PDFs and images, locating the values, normalising units and terms, and writing them into the schema fields. This population step is the core of product data enrichment, and it is measurable: completeness per category, before and after.

The practical loop for an existing catalogue: define the schema for the top revenue categories, measure completeness against it, extract from the supplier files you already hold, and only then chase suppliers for the values that genuinely exist nowhere. Most teams that run this loop find the majority of missing values were in their inbox all along, in a format no one could use.

Key takeaways

• A product attribute is a named field with a structured value. Information trapped in prose does not count.
• Five types: identifiers, descriptive, technical, commercial, and channel or compliance attributes.
• Search, filters, comparison and AI answers all run on attributes. Incomplete attributes fail all four at once, silently.
• Completeness only means something against a per-category schema with required fields, units and permitted values.
• Past a few thousand SKUs, attributes get populated by extraction from supplier files, not by typing.