Enriching product feeds with conversational attributes for conversational queries
Learn how to prepare your product feed for conversational queries in AI Mode with Merchant Center’s Q&A, variant, related product and document attributes.
Conversational attributes are optional fields added to product data in Google Merchant Center that help SI systems better understand a product’s details. These fields bring question-and-answer pairs, documents such as user manuals, related products, variant information and a product’s popularity within the store into the feed. Google states that these attributes support product discovery on SI-driven shopping surfaces, especially AI Mode, while also contributing to traditional search experiences. According to test results shared in September 2026, conversational attributes submitted by lululemon were used in half of relevant product recommendations in AI Mode. This rate shows that a few new fields added to a feed can directly affect how a product is described in SI answers. While classic feed optimisation focuses on title, description and category mapping, these fields aim to answer in advance the questions a user might ask about a product. In this guide, we cover what each field does, what data it should be filled with and what to watch out for in practice.
Which fields make up conversational attributes?
Conversational attributes consist of six fields that are part of the Merchant Center product data specification. Each field carries a different layer of information about the product and corresponds to a different type of question a user might ask during a conversation. All fields are optional, but used together they allow SI to understand the product far more completely.
| Field | Information It Carries | User Question It Answers |
|---|---|---|
| question_and_answer | Product-specific question and answer pairs | “Is this product dishwasher safe?” |
| document_link | PDF documents such as user manuals and installation instructions | “How is it installed, and which parts are needed?” |
| related_product | Accessories, required parts or products bought together | “What else do I need to buy with this?” |
| item_group_title | The shared name of a product family with multiple variants | “Are there other options for this model?” |
| variant_option | Properties that define a variant, such as size, colour or capacity | “Is there a wide fit or a size 42 of this?” |
| popularity_rank | The product’s popularity ranking within the store | “Which one is most popular in this category?” |
The right-hand column of the table explains why these fields are called “conversational”. Each field prepares a structured answer to a question a sales assistant often hears in a store. When SI finds these answers, it can respond to the user’s question directly and accurately without sending them to the product page.
Which questions should go into the question-and-answer field?
The question-and-answer field should contain questions customers genuinely ask before buying that are not answered in the product description. Google’s own note points in the same direction: there is no need to repeat in conversational attributes the information already provided in the description, product highlight or product detail fields. The value of this field comes from adding information that is not in the feed at all.
The most reliable sources for finding the right questions sit inside the company:
- Customer service records: The questions asked most often per product in live chat, email and the call centre.
- Return reasons: The expectation gaps behind “not what I expected” returns show which questions need answering before purchase.
- Product reviews: Advice users give each other and questions they ask in reviews.
- Sales team notes: Compatibility, certification and technical specification questions for B2B products.
- Marketplace Q&A sections: The questions the same product receives on marketplaces are a direct data source.
Answers should be short, meaningful on their own and precise. An answer such as “Yes, it is machine washable up to 60 degrees” is far more useful than a general phrase like “It lasts long when care instructions are followed”. The information in the answer must match the product page exactly; otherwise, SI may notice the contradiction between the two sources.
Why does it matter to present variants as a single product family?
Presenting variants as a single product family allows SI to match the option with the feature a user wants to the right product. In many feeds, different colours and sizes of the same model appear as if they were independent products. When a user asks “does this shoe come in a wide fit?”, SI needs to know that the variants belong to a common family to make that connection.
Google builds this relationship by using three fields together. The existing item_group_id field groups variants, while item_group_title gives that group a shared name. variant_option carries the properties that define each variant as name and value pairs; for example, shoe width and size can be specified together. This structure is critical in fashion, footwear, electronics and furniture categories in particular, because users’ questions are often about a specific combination rather than the product in general. When variant information is missing, SI can tell the user that the product exists but cannot say whether the requested feature is available, and this uncertainty can send the user to another brand.
How do related product and document links enrich answers?
Related product and document links allow SI to describe not just a single product, but a complete solution that meets the user’s need. The related_product field also lets you specify the type of relationship between products: a required part, an accessory or a product often bought together can each be defined separately. A descaler for a coffee machine, a compatible bit set for a drill or the right cartridge for a printer can be linked to the product this way.
This relationship becomes decisive in questions such as “what else do I need for this to work?” A product without its required part specified can lead users to make an incomplete purchase and then enter a return process. The document_link field connects PDF documents such as user manuals and installation instructions to the feed, and multiple documents can be added separated by commas. For technical products, the answers to users’ detailed questions often sit in these documents. Documents should be text-readable PDFs, not scanned images, and should belong to the current product version.
What should you watch out for when sharing popularity rank data?
Popularity rank is a value that expresses a product’s performance as a percentage of the store’s total inventory and should be based on real sales data. The higher the value, the better the product performs compared with other products in the store. This field helps answer the user’s question “which one is most popular?” with the store’s own data.
Two points need attention when filling in this field. The first is defining consistently within the company which period and which metric the value is based on; unit sales, revenue or conversion rate can produce different rankings. The second is updating the value regularly. For seasonal products, a popularity rank from a few months ago may not reflect today’s demand. Giving high values to products you want to push artificially during a campaign may bring short-term visibility, but it damages credibility when it contradicts user reviews and sales data.
Supplemental data source or primary feed?
The method Google recommends for conversational attributes is to send these fields through a supplemental data source without touching the existing primary feed. The fields can also be added to the primary data source or submitted through the Merchant API, and Google states that adding them does not affect the approval status of existing products. The TSV template Google shares can also serve as a guide during initial setup.
The practical advantage of the supplemental data source approach is that responsibilities can be separated. The primary feed is usually generated automatically from the e-commerce platform and managed by the technical team. Question-and-answer, document and related product data, however, rely on the knowledge of content, product and customer service teams. Keeping this data in a separate source lets the content team make updates without the risk of breaking the primary feed. Starting with a pilot limited to the best-selling and most-asked-about product group keeps the workload manageable and makes it easier to measure impact.
Does the same data work on other SI surfaces?
Data prepared for conversational attributes also works on other SI surfaces when reused correctly. Question-and-answer pairs can be moved into the FAQ section of the product page, related product relationships into on-site recommendation modules and variant information into structured data markup, all from the same source. This way, the Google feed, the website and other platforms’ product data carry the same information; even if different SI systems read the product from different sources, they encounter a consistent picture.
In its GEO consulting projects, Webtures treats the product feed not as a standalone technical file, but as the source of the brand’s product narrative in SI answers; questions drawn from customer service and return data are placed into both the feed and site content in the same language. The impact of these changes can be measured by tracking which attributes the brand is mentioned with in product-focused prompts using a GEO tool such as Brantial. Tracking how long it takes, and on which platforms, for an attribute to become visible in SI answers after an answer is added to the feed also determines where to start with the next product group.
