NL
Google Merchant Center8 min read

Google Merchant Center conversational attributes: fields and examples

Written by Jesse Franken · Updated September 7, 2026

Google has added a new set of Merchant Center attributes designed to help AI systems and conversational agents understand products in more detail.

They are optional, but the direction is important. Product data is no longer only about getting products approved in Merchant Center. It is becoming part of how products are understood, matched, compared, recommended, and explained across AI-driven shopping experiences.

For ecommerce brands, the practical next step is improving the quality, structure, and context of product information so Google, AI systems, and customers can understand products more clearly.

What are Google Merchant Center conversational attributes?

Conversational attributes are additional product data fields that help Google understand more specific product information. Google describes them as optional attributes that complement the primary Merchant Center product data specification and help AI systems and conversational agents understand product nuance.

The new attributes include question_and_answer for product-specific questions, document_link for PDFs such as manuals or size guides, related_product for accessories or alternatives, item_group_title for clearer variant group naming, variant_option for structured variant details, and popularity_rank for showing how popular a product is compared to the rest of the catalog.

The important part is that these fields do not replace the normal Merchant Center foundation. Product titles, descriptions, images, GTINs, prices, availability, product details, and product highlights still carry the main product setup. Conversational attributes add a context layer on top.

  • question_and_answer: product-level questions and answers.
  • document_link: manuals, size guides, assembly instructions, or specification PDFs.
  • related_product: accessories, required parts, bundles, or alternatives.
  • item_group_title and variant_option: clearer product families and variant differences.
  • popularity_rank: a relative popularity signal inside your own catalog.

Platform references: Google Merchant Center conversational attributes.

Attribute examples: what to submit and when it helps

Google defines the available fields and their accepted structure in its conversational-attributes documentation. These fields are optional additions to product data. The purpose and prioritization below are ChannelBoosters’ practical interpretation, not extra Google eligibility requirements.

Illustrative catalog: a Northline oak table lamp, SKU LMP-240-OAK, has a walnut sibling, a confirmed compatible E27 bulb and an assembly PDF. These example values explain the intended data; use the exact formatting required by your selected data source.

Conversational attributes applied to an illustrative lamp catalog
AttributeExample valuePurposeWhen it matters
question_and_answer"Is a bulb included?":"No. This lamp requires a compatible E27 bulb."Resolve a specific purchase questionCustomers repeatedly ask what is included; answer from verified specifications.
document_linkhttps://example.com/manuals/lmp-240.pdfConnect the correct product documentAssembly or installation details help the buying decision. Replace this illustrative URL with the real PDF.
related_productaccessory:id:BULB-E27-01Identify a confirmed compatible accessoryThe accessory is in the catalog and the relationship is verified for this model.
item_group_titleNorthline 240 table lampName the product familyOak and walnut finishes belong to the same genuine group; keep the associated item_group_id consistent.
variant_optionfinish:oakDescribe the selected optionThe shopper needs to distinguish this finish from sibling variants.
popularity_rank85.0, illustrative onlyExpress relative catalog popularitySubmit only when a documented calculation supports the value; omit rather than guess.

Why conversational attributes matter for AI-driven shopping

AI-driven shopping depends on product understanding. A normal Shopping result can lean heavily on keywords, category, bid, title, and standard feed structure. A conversational shopping experience needs to answer more specific questions.

A customer might ask which version fits a small bedroom, whether a product needs an extra adapter, which size is right for a toddler, what the difference is between two variants, or whether a manual is available before buying. Those questions are rarely answered well by a short product title alone.

This is the real shift: product data is becoming less flat. It is moving from simple product facts toward product context. The richer and cleaner that context is, the easier it becomes for platforms, customers, and AI systems to understand what the product is and when it is the right fit.

Being approved in Merchant Center is not the same as being understood

Many ecommerce teams treat product data as a compliance task. The product is approved, the feed is running, the price is correct, and the image is accepted, so the setup feels done.

Merchant Center approval is the starting point. Strong discovery, comparison, filtering, recommendation, and conversion depend on richer product context after approval.

A title like Wooden bed frame oak 160x200 can be technically acceptable while still leaving out the context shoppers and AI systems need: whether slats are included, what mattress size fits, whether storage drawers are part of the product, which bedside tables match, or whether assembly instructions are available.

For a shopper, that missing context creates doubt. For an AI system, it limits what the system can confidently understand and answer. That is the difference between a product being technically available and commercially understandable.

Which ecommerce brands should care first?

The biggest opportunity is for brands with products that need explanation. This includes furniture, baby products, electronics, tools, home improvement, kitchen equipment, sports equipment, fashion with sizing complexity, automotive parts, and any catalog where compatibility, accessories, manuals, variants, or customer questions matter.

Simple products with little nuance may not need much extra structure immediately. But if customers regularly ask questions before buying, compare variants, need size guidance, look for accessories, or depend on manuals, the catalog probably contains valuable information that is not yet structured well for Google.

The commercial point is practical. If the information already exists in PDFs, customer support replies, product specifications, size guides, product pages, reviews, or internal knowledge, it can often be turned into stronger product context instead of staying disconnected from the feed.

How to use question_and_answer without creating generic FAQ noise

The question_and_answer attribute is most useful for product-specific questions that clarify a buying decision. It should not become a dumping ground for generic store policies or broad FAQ content.

Good questions are the ones customers already ask before buying: does this table need assembly, is the cover removable, does this fit model X, is this suitable for outdoor use, does this variant include the battery, or what is the difference between the regular and XL version.

The value is not only that the answer exists. The value is that the answer is connected to the specific product. A general FAQ can help customers, but product-level Q&A gives Google clearer context about the item itself.

Using document_link for manuals, size guides & documentation

The document_link attribute connects product data to useful PDFs such as manuals, size guides, assembly instructions, specification sheets, or product documentation.

This is especially useful for products where customers need confidence before buying. Think flat-pack furniture, appliances, tools, baby gear, electronics, lighting, machinery, or technical products where a short product description cannot carry the full context.

The mistake is adding every possible PDF without thinking. A better approach is to connect documents that genuinely improve product understanding: size guides where size choice matters, assembly instructions where setup affects the buying decision, and manuals where technical detail matters before purchase.

How related_product can make product relationships clearer

The related_product attribute is commercially interesting because ecommerce catalogs are often too product-by-product. The feed explains each product separately, but not always how products work together.

A lamp may need a specific bulb. A camera may have compatible lenses. A baby seat may need a matching base. A machine may require replacement parts. A clothing item may belong to a matching set. A product may have a cheaper or premium alternative.

When those relationships are only visible in the webshop layout, they depend on manual merchandising. When they are structured in product data, shopping systems get a clearer view of how the catalog connects.

Why item_group_title and variant_option matter for cleaner variants

Variant structure is one of the places where product feeds quietly lose quality. Products can be technically grouped, while the parent product, item group ID, title, color, size, material, and variant-specific values do not line up cleanly.

The item_group_title attribute helps describe the overall product group. The variant_option attribute explains the actual variant-defining properties, such as size, color, width, memory, display type, or another variant dimension.

Customers do not only need to know that variants exist. They need to understand the meaningful difference between them. If someone asks for the narrow version, the oak finish, the toddler size, the larger memory version, or the left-facing model, the product data needs to make that difference clear.

When popularity_rank is useful and when it becomes risky

The popularity_rank attribute lets merchants indicate how popular a product is compared to the rest of their catalog. That can be useful when the underlying performance data is reliable.

Popularity can help identify bestsellers, strong products, or products that deserve more attention. But weak data makes the attribute misleading. Old sales patterns, short-term promotions, stockouts, or manually guessed priorities can create a popularity signal that does not reflect real demand.

For most brands, popularity_rank should come after the basics are in order. The practical question is whether you have a clean enough view of product performance to submit this consistently.

What to check before adding conversational attributes

The worst way to approach this is to blindly add new fields because Google released them. Conversational attributes sit on top of the existing product foundation. If the foundation is messy, the new layer becomes another place for inconsistency.

Start by checking where the catalog actually lacks context. Look at repeated customer questions, disconnected manuals or size guides, weak variant groups, known accessory relationships, unclear product differences, and whether product performance data is reliable enough to support popularity signals.

If the basics are weak, fix titles, descriptions, identifiers, categories, required attributes, images, availability, and product detail first. If the foundation is clean, conversational attributes can make the catalog richer and easier to understand.

  • Do customers ask repeated product questions before buying?
  • Are manuals, size guides, or specification PDFs available but disconnected from Merchant Center?
  • Are variants grouped correctly and clearly?
  • Are accessories, bundles, required parts, or alternatives already known?
  • Is performance data reliable enough to use as a popularity signal?

How to prepare and validate the lamp example

Our practical sequence starts with the product record: confirm that LMP-240-OAK identifies the oak finish, the bulb is genuinely compatible and the PDF covers that model. Write the answer from the specification, then have the product owner check it. Do not infer bulb compatibility from a similar lamp’s image.

Google supports adding these fields through a supplemental data source, a primary source or the Merchant API; its submission guidance explains those options. Choose the path your integration supports. A column added to a source spreadsheet still needs to reach the final submitted field.

For a small test, match the extra data to the existing item ID and inspect the submitted record. Check the oak variant, the walnut sibling and an unrelated product. The unrelated item should not receive the lamp answer or accessory. Confirm that the bulb identifier resolves to the intended catalog item and that the real PDF opens without sign-in.

After processing, inspect Merchant Center’s received product data and any reported issues, then recheck after the next scheduled sync. Preserve the verified source facts and mapping so later imports do not erase the enrichment. Acceptance of a field does not establish that an AI surface will recommend the product.

ChannelBoosters would prioritize the verified bulb answer and useful manual before a popularity score. That choice addresses buying doubt; it is an implementation recommendation, not a Google ranking formula. For the core feed checks, use our Google Shopping feed optimization or feed-error diagnostic guide.

What this means for ecommerce product data strategy

The bigger takeaway is simple: product data is becoming a product intelligence layer. For years, many brands treated feeds as a technical requirement for Google Shopping, marketplaces, comparison sites, and paid campaigns. That view is becoming too small.

Product data now influences how products are found, how they appear, how they are filtered, how they are compared, how they are explained, and how confidently customers can choose them.

The practical move is to treat product context as part of channel performance. Brands that do this well build catalogs that are easier for platforms, customers, and AI systems to understand.

How ChannelBoosters looks at conversational attributes

At ChannelBoosters, we see this as part of a wider shift in ecommerce. The winners are not only the brands with more products or bigger ad budgets. The winners are the brands whose products are easier to understand, match, compare, buy, and manage across every channel.

That starts with the practical layer behind performance: product pages, product data, feed structure, attributes, variant logic, related products, documents, listings, and sync flows.

The opportunity is to make the product catalog clearer, richer, and more useful for the systems and customers that decide what gets seen, clicked, recommended, and bought. Explore our Google Shopping feed optimization for hands-on support.

Product data

Is your Merchant Center data ready for the next phase of shopping?

ChannelBoosters can review whether your product data only meets the minimum requirements, or whether it actually gives Google, customers, and shopping systems enough context to understand your products.