Product attributes: which ones each discovery surface reads, and what a good one looks like

Product attributes are the structured facts that describe a product (material, fit, occasion, color family, compatibility) and they are the unit of language every discovery surface reads. Google Shopping matches queries against them, Meta Advantage+ builds audiences from them, onsite search filters on them, and AI shopping assistants use them to decide whether your product answers a shopper's question. The attributes that drive discovery are usually not the ones in the PIM, because merchandisers catalog by SKU logic and shoppers search by use.

This page is a working spec, not an introduction. It lists the six attribute types, the 32 fields that decide whether a product is retrievable at all, what each surface does with them, what a well-formed value looks like next to a badly formed one, and why the whole set decays on a schedule nobody at the retailer controls. It is written to be kept open in a tab while you audit a category.

What is a product attribute, exactly?

A product attribute is a single structured fact about a product, stored as a named field with a value: material: linen, size_system: US, occasion: wedding guest. One fact, one field, one value: that constraint is the whole discipline, because a field holding two facts is a field no machine can filter on.

Three things get called attributes and are not. Taxonomy is where the product sits in a hierarchy, not what it is made of; it decides which queries you are eligible for, and it gets its own treatment in product taxonomy. Description is prose, and prose is read but not filtered. Specification is the manufacturer's version of an attribute, written for a spec sheet rather than a shopper, which is why so many catalogs contain fabric: 100% CO where the shopper typed "cotton."

The practical test for whether something is a real attribute: could a shopper narrow a result set with it, and could a machine sort on it without guessing? If both answers are yes, it belongs in a field. If not, it belongs in the description.

What are the six types of product attributes?

There are six types, and they fail in six different ways: identity, physical, descriptive, contextual, style, and compatibility. Most catalogs are strong on the first three (those are the fields a PIM was built to hold) and close to empty on the last three, which is exactly where discovery is decided.

Identity attributes

Identity attributes establish that this record refers to a specific, real, buyable product: id, gtin, mpn, brand, item_group_id, condition, google_product_category, product_type, gender, age_group. When they are wrong the item is not ranked badly, it is disqualified: duplicate GTINs, missing item_group_id on a variant family, and a google_product_category that does not match the item are three of the most common quiet suppressors in Merchant Center.

Physical attributes

Physical attributes describe the object itself: size, size_system, size_type, color, material, pattern, plus dimensions and capacity. These are the ones onsite facets are built from, which means an unpopulated physical attribute does not just lose a query, it removes the product from a filter a shopper has already chosen.

Descriptive attributes

Descriptive attributes are the written surface of the record: title, short_title, description, product_highlight, product_detail. The product_highlight field in Merchant Center is one of the most under-used fields in retail: it takes short, benefit-shaped bullets and it is the cheapest place to put the facts that have no dedicated field of their own.

Contextual and occasion attributes

Contextual attributes state when, where and why a product is used: occasion, season, use case or activity, room or setting, weather suitability. Almost no catalog carries them as fields, and almost every natural-language shopping query contains one ("wedding guest," "for a small apartment," "for humid weather") which is why this is the highest-yield gap on this list.

Style attributes

Style attributes describe how a product reads aesthetically: style or aesthetic, silhouette or shape, fit and drape. Size and fit attributes deserve their own attention in apparel because they carry two jobs at once, retrieval and returns: "true to size, relaxed through the hip" is both a match signal and a returns-prevention signal.

Compatibility attributes

Compatibility attributes answer whether the product works with something else the shopper already owns: works-with, and substitutes. These were homeless until May 2026, when Google added conversational attributes to Merchant Center covering compatibility and alternatives.

Which product attributes does each discovery surface read?

Every surface reads the same record, but each one does a different job with it. That is the reason attribute work compounds across channels and formatting work does not: one improvement to the product-language input is read four times.

This table maps each attribute type to what the four discovery surfaces actually do with it.

The uncomfortable part of this table is the last column. AI assistants do not browse a catalog and form an opinion; they retrieve against records, so a product whose record never states occasion or fabric weight is not ranked lower, it is not a candidate.

Which 32 attributes actually decide whether you show up?

These are the 32 fields we check first on any catalog audit, grouped by type, with a note on whether the field exists natively in the Merchant Center. Twenty-one of the 32 map to a long-standing Merchant Center attribute, two arrived as conversational attributes in May 2026, and the remaining nine have no field of their own, which is precisely why they get skipped, and precisely why they are available.

This is the reference list: every field, its type, whether Merchant Center has a native home for it, and the surface it moves the hardest.

The nine homeless attributes do not stay homeless. They go into product_detail as name/value pairs, into product_highlight as short bullets, and into the description in shopper phrasing, which means the retailer who does this deliberately is populating fields the rest of the category is leaving blank. Delivery mechanics for all of it sit in product feed optimization.

What does a well-formed attribute value look like?

A well-formed attribute value holds exactly one fact, in the vocabulary a shopper would use, in a unit a machine can parse, with no marketing language attached. A badly formed value usually fails on one of four things: it is internal shorthand, it bundles two facts, it is missing its unit or system, or it is a null dressed up as a string.

Same product, same field, two versions: the left column is what audits usually find, the right is what the surfaces can actually use.

Two rules that catch most of it. First, if a value would need a glossary to interpret, it is a code, not an attribute. Second, if a value could be pasted onto any product in the catalog without becoming false, it carries no information: "great for any occasion" is the canonical example.

Product attribute examples by category: apparel, beauty, home

The gap between catalogd and searched looks different in every category, and the fix is category-specific. Here is what the missing layer usually is in three.

Apparel

Catalogd: style number, season code, fabric composition, colorway name, size run. Searched: garment type, fabric in plain words, occasion, weather, sleeve length, rise or hemline, fit. The attributes that move apparel are the size and fit attributes plus occasion, "wedding guest," "true to size," "midweight linen", and none of them arrive from the vendor.

Beauty

Catalogd: SKU, shade code, volume, ingredient list, product family. Searched: shade in plain description, undertone, coverage level, finish, skin type, skin concern, whether it is fragrance-free. Shade code to shade language is the single highest-yield mapping in beauty, because N-24 retrieves nothing and light neutral with a golden undertone retrieves the query the shopper actually typed.

Home

Catalogd: item number, dimensions, material, collection name, vendor. Searched: room, style, size in relatable terms, washability, pet and child suitability, assembly requirement. Home is where dimensions need translation: 243 x 152 cm is a fact, and fits under a queen bed with 18 inches of walking space is a fact a shopper can act on, so the record needs both.

What are Merchant Center conversational attributes, and what goes in them?

Conversational attributes are Merchant Center fields Google introduced at Marketing Live on 20 May 2026, four months after the Universal Commerce Protocol, the Business Agent and Direct Offers in AI Mode, that let a product record answer the questions a shopper would ask a salesperson rather than only state specifications. They exist because the standard attribute set was written for keyword matching, and the surfaces reading it now hold conversations.

What actually goes in them is shopper-question language, not catalog language. Compatibility answers take specific model names and explicit exclusions. Alternatives take the honest answer to "what should I get instead if this is out of stock or out of budget." The rest take the answers your support team already types every week, which is where the content comes from, and it is free. Google has not published the full field names yet, so carry that language in product_detail and product_highlight until it does. The field-by-field version is in Merchant Center conversational attributes.

Where do the attributes in your PIM and the attributes shoppers use diverge?

They diverge almost completely, because the two systems were built by different people for different jobs. A PIM record is organized so a business can buy, price, allocate and reconcile a product; a query is organized around what a person wants to do with it.

One worked example, not a survey: a single linen midi dress, its populated PIM fields against the attributes its queries depend on.

Three attributes appear on both lists: garment type, fabric and color. All three fail on the value rather than the field: garment type is implied by a taxonomy node rather than stated, fabric is a composition code, and the color is "Cypress." The record is complete and unusable at the same time, which is the failure mode covered in product data enrichment.

Nothing in that list is the merchandiser's mistake. The fields were filled in exactly as the system asked; the system was designed to move stock through a warehouse, not to answer a question typed into a search bar at 11pm.

Why do product attributes decay, and what does product attribute management involve?

Attributes decay because a catalog is a population, not a project: SKUs churn, vendors change, and every drop arrives with vendor-supplied data written in vendor vocabulary. A one-time enrichment pass is accurate on the day it ships and less accurate with every drop, vendor swap and rename that lands after it, which is why attribute quality decays rather than completes.

Four decay sources, in the order they usually bite:

1. 1.New SKU intake. Every new item lands with supplier data. Unless enrichment runs on intake, the newest products (the ones with the most demand) have the worst records.
2. 2.Vendor and colorway changes. The same product returns next season with a different composition string and a renamed colorway, and every mapping built against the old value quietly stops matching.
3. 3.Platform change. Field requirements move. Google's 2026 additions created fields that did not exist when most catalogs were last enriched, and a field that does not exist cannot be populated retroactively by a project that ended in 2024.
4. 4.Shopper vocabulary drift. The words people use for style, fit and occasion move faster than any catalog process. Values that matched last year's language stop matching this year's.

Product attribute management, done properly, is therefore a running process with a trigger on catalog change, not a quarterly initiative. That is criterion (b): it has to run continuously, because catalogs churn.

How do you know attribute work moved revenue?

You know because you held out a control group, matched the spend, and read the difference: anything else is attribution, not evidence. Platform-reported lift is not a control; the platform is grading its own homework.

In a matched-spend A/B test with a 28-day holdout, rewriting the product-language input produced a 28% increase in Google Shopping revenue against the untouched control group. On Meta Advantage+, the same input change returned +21.4% ROAS against a holdout, cross-validated with Meta's own Conversion Lift. Onsite, a statistically significant A/B test returned +28.3% onsite revenue. We ran 1,000-plus controlled tests before publishing the benchmark those figures come from.

The reason attribute work is measurable at all is that it is upstream of every surface: the same record change can be read on Shopping, on Advantage+, on the search box and in an assistant's answer. Set the test up before the rewrite, not after, and keep a slice of the catalog untouched for the full window even though it will feel wasteful. The surface-level version of this measurement is in product feed optimization.

One market number worth holding next to all of this: Semrush found that 22% of US shoppers have bought inside an AI tool while 50% bought elsewhere after researching one. The assistant is mostly a discovery surface, not a checkout, and the thing it discovers you by is the attribute record.

What to ask before you buy attribute work

Ask four questions, and ask them in this order. They are the same four that decide whether the work survives contact with a finance team.

1. 1.Does it fix the product-language input, or the layer above it? A dashboard that reports attribute coverage is not attribute work.
2. 2.Does it run continuously? A one-time pass is accurate the day it ships and decaying from the next catalog change onward.
3. 3.Does it cover the surfaces that pay this quarter? Paid surfaces read the same record. If the work only touches onsite, most of the value is left on the table.
4. 4.Is the lift proved against a control? Ask for the holdout design, the window, and what the result does not prove.

Compressed to one sentence: would it survive a finance review? Start by pulling one category, running the 32-field table against ten SKUs, and counting how many of the nine homeless attributes are populated anywhere in the record. The number you get is your ceiling on every surface at once. Delivery sits in product feed optimization, placement in product taxonomy, and the upstream job in product data enrichment.

Primary sources: *Google's Merchant Center product data specification* and the *Google product taxonomy*.

Frequently asked questions

What are product attributes in ecommerce?

Product attributes are the structured facts stored about a product in named fields, such as material, color, size, occasion and compatibility. They are what discovery surfaces read to decide whether a product matches a query, so a fact that is not in an attribute field is a fact no machine can filter, match or quote.

What are the different types of product attributes?

There are six practical types: identity, physical, descriptive, contextual or occasion, style, and compatibility. Most catalogs are well populated on identity, physical and descriptive attributes because those are the fields a PIM was built to hold, and thin on contextual, style and compatibility attributes, which is where natural-language demand now sits.

What is the difference between a product attribute and a product taxonomy?

An attribute is a fact about the product, and a taxonomy is the position of the product in a hierarchy. Taxonomy decides which queries a product is eligible to appear for at all, and attributes decide whether it wins among the products that are eligible.

Which product attributes matter most for Google Shopping?

Identity attributes decide eligibility, so gtin, brand, item_group_id, google_product_category and condition have to be correct before anything else matters. After that, the title, short_title, product_highlight and the physical attributes (color, size with its size system, material and pattern) do the most work on impression share for high-intent queries.

How many product attributes should a product have?

There is no target count, because a catalog can be 100% populated and still fail to retrieve if the values are internal codes. A more useful test is whether the record can answer the six or eight things a shopper would actually specify for that category, including occasion, fit and compatibility, in the words a shopper would use.

How often should product attributes be updated?

Attribute quality decays continuously because catalogs churn, so the useful cadence is triggered by catalog change rather than by calendar. New SKU intake, vendor or colorway changes, and platform field changes each need enrichment to run at the moment they happen, not at the next quarterly project.

Google's AI Performance Insights: how to read you…