How to Add Conversational Attributes to Your Google Merchant Center Feed
Google's conversational attributes are the new Merchant Center feed fields that let AI shopping assistants understand your products the way a good salesperson would. We have already covered what they are and why they matter for agentic commerce. This is the hands-on companion: the exact format for every field, a real example of each, and precisely how to get them into your feed.
There are six fields, they are optional, and adding them never affects your existing product approval status. The hard part is not the concept, it is the formatting and the scale. Everything you need to set each field correctly is below, along with the supplemental-feed workflow Google recommends and we use every day.
First, decide how you will submit them
You can add conversational attributes through your primary feed, a supplemental feed, or the Merchant API. Google recommends a supplemental feed, and so do we, for three reasons:
- It is additive. A supplemental feed layers new columns on top of your primary feed without changing it. Your existing data is left alone.
- It is reversible. If something looks wrong, you remove the supplemental source and your catalog reverts to baseline. Nothing about your live, selling products is at risk.
- It joins on one key. The supplemental source matches your primary feed by product
id(the same value as youroffer_id), so each row only needs the SKU plus the attributes you are adding.
Because these fields are optional, a formatting mistake never costs you Shopping eligibility. Google simply ignores a malformed value. That makes it safe to start with your top sellers and expand.
Why this feed is a direct line into Google's AI
Most of what Google knows about your products it has to infer. It crawls your pages, parses your markup, and fills in the rest. Your Merchant Center feed is different. It is one of the few places where you hand Google structured, first-party product data directly, in fields Google defined, with no interpretation in between.
That matters more in the agentic era than it ever did for blue-link shopping. When an assistant in AI Mode or Gemini shops on a buyer's behalf, it has to answer questions, compare options, and recommend with confidence, and it leans on machine-readable data to do it. The conversational attributes are a purpose-built input to exactly that system: question and answer feeds the answers, related product feeds the comparisons, variant option feeds the choices. Google introduced them alongside its broader push into AI-driven commerce, and the feed is the supply line. Fill these fields and you are speaking to the AI in its own format. Leave them blank and you are trusting it to guess, or to pick the competitor who filled them in.
1. Question and answer [question_and_answer]
FAQ-style pairs that answer what a shopper actually asks before buying. This is the highest-leverage field of the six, because it feeds conversational answers directly, and it had nowhere to live in a standard feed before.
Format. Quoted question and answer pairs, separated by commas:
"question":"answer","question":"answer"
Example.
"Does it have a headphone jack?":"This version does not have a headphone jack.","Is it water resistant?":"Yes, it is rated IPX7 for splashes and brief submersion."
Tips. Write the questions the way buyers actually phrase them, pulled from your support inbox, reviews, and on-page FAQs. Keep answers factual and specific. Do not keyword-stuff; an assistant is reading this to decide whether to recommend you.
2. Document link [document_link]
URLs to product documents: manuals, spec sheets, care guides, ingredient lists, size charts. Net new, and a quiet credibility signal, because an assistant can point a shopper to the real documentation.
Format. A single URL, or several separated by commas:
https://example.com/manual.pdf, https://example.com/care-guide.pdf
Tips. Link the actual document, not the product page, and make sure the files are publicly accessible.
3. Related product [related_product]
Structured links to accessories, required parts, substitutes, or bundles, so an assistant can answer "what works with this?" or "is there a cheaper option?" This field has real structure.
Required sub-attributes. Each related product needs three parts:
[relationship_type], such asaccessory,required_part,substitute, orbundle[identifier_type], eitherid(your own product id) orgtin[identifier], the actual id or GTIN value
Format. relationship_type:identifier_type:identifier, with multiple entries separated by commas:
required_part:id:AZ7B,accessory:gtin:811571013579
Tips. Pull these from your merchandising or frequently-bought-together logic, and make sure every identifier matches a real product in your catalog.
4. Item group title [item_group_title]
The product family name, kept separate from the SKU-level title. Where [title] is the full variant name ("Organic Cotton Men's T-Shirt, Navy, Large"), [item_group_title] is the family name. Use it alongside your existing [item_group_id].
Format. A plain text string:
Organic Cotton Men's T-Shirt
Tips. Keep it free of variant detail. The size, color, and material belong in variant option, next.
5. Variant option [variant_option]
Structured variant detail (size, color, storage, and so on) as name and value pairs, so an assistant can reason about the choices. Used with [item_group_id] and [item_group_title].
Required sub-attributes. [name] and [value].
Format. name:value,name:value:
color:moonstone,storage:512GB,display:6.3 inch
Tips. Use consistent option names across the catalog (always "color," never sometimes "colour" or "shade") so the data is machine-comparable.
6. Popularity rank [popularity_rank]
How a product ranks for popularity inside your own catalog, expressed as a percentage. It helps an assistant surface your stronger sellers.
Format. A number, where higher means more popular:
95.5
Tips. Derive it from real sales or revenue, ranked across your catalog, and refresh it on a schedule as bestsellers shift. A static guess decays fast.
A worked supplemental feed
Here is what a supplemental feed looks like with several of these fields populated. Each row needs only the id plus the attributes you are adding; everything else stays in your primary feed.
| id | item_group_title | variant_option | popularity_rank | question_and_answer |
|---|---|---|---|---|
| SKU-DW-6PL | Countertop Dishwasher | color:stainless,capacity:6 place settings | 95.5 | "Is it quiet?":"Yes, it runs at 42 dB." |
| SKU-DW-4PL | Countertop Dishwasher | color:white,capacity:4 place settings | 61.0 | "Does it need plumbing?":"No, it fills from a built-in tank." |
Illustrative values; the structure is exactly what lands in the feed.
An XML supplemental feed, the nerdy version
A spreadsheet is the friendly on-ramp, but most automated feeds are XML. Google's product feeds use RSS 2.0 with the Google namespace (xmlns:g="http://base.google.com/ns/1.0"). In a supplemental feed, each <item> carries the <g:id> that matches your primary feed, plus only the attributes you are adding. The sub-attributed fields, related product, variant option, and question and answer, nest their sub-attributes as child elements instead of the colon-delimited string a spreadsheet uses.
<?xml version="1.0"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
<channel>
<title>Conversational attributes supplement</title>
<item>
<g:id>SKU-DW-6PL</g:id>
<g:item_group_title>Countertop Dishwasher</g:item_group_title>
<g:popularity_rank>95.5</g:popularity_rank>
<g:document_link>https://example.com/dishwasher-manual.pdf</g:document_link>
<g:variant_option>
<g:name>color</g:name>
<g:value>stainless</g:value>
</g:variant_option>
<g:variant_option>
<g:name>capacity</g:name>
<g:value>6 place settings</g:value>
</g:variant_option>
<g:related_product>
<g:relationship_type>accessory</g:relationship_type>
<g:identifier_type>gtin</g:identifier_type>
<g:identifier>811571013579</g:identifier>
</g:related_product>
<g:question_and_answer>
<g:question>Is it quiet?</g:question>
<g:answer>Yes, it runs at 42 dB, about as quiet as a library.</g:answer>
</g:question_and_answer>
</item>
</channel>
</rss>A few things the spec is strict about: you can submit up to 30 question-and-answer pairs per product, each question and answer capped at 1,000 characters; every related_product needs all three sub-attributes; and within one item group, every variant must use the same set of variant_option names, so if one variant carries color and capacity, they all do. Repeat the <item> block per SKU, and host the file where Google can fetch it on a schedule.
How to add a supplemental feed in Merchant Center
The Google Sheets route is the fastest way to start:
- In Merchant Center, open Data sources and click Add supplemental data source.
- Choose Google Sheets, then either generate a new template or connect an existing sheet.
- Add an
idcolumn that matches your primary feed, then one column per conversational attribute you are submitting, using the exact attribute names above as headers. - Link the supplemental source to your primary feed so Google joins them by
id. - Set a fetch schedule so updates pull automatically.
Submitting a file feed? Turn on Advanced Data Source Management first
The Google Sheets route works out of the box. But if you want to submit an XML or TSV file, which is the usual choice for automated and larger feeds, Merchant Center Next hides that option behind an add-on you switch on once:
- Open Settings and tools, then Add-ons.
- On the Discover tab, find Advanced Data Source Management and click Activate. It moves to your Active add-ons.
- Back under Data sources you will now see Supplemental sources. Click Add supplemental product data and choose to add product data from a file (a hosted URL with a scheduled fetch, or a direct upload), from Google Sheets, or through the API.
- Set the feed matching strategy so Google joins the supplement to your primary feed by
id, pick the primary feed to link, and create the data source.
For thousands of SKUs that change often, the Merchant API is the cleanest path. It writes the same attributes programmatically, which is how an automated pipeline keeps a catalog current without anyone touching a file. Whichever method you choose, the attribute names and formats are identical to everything above.
Doing this across a real catalog
Setting one product is easy. A real catalog is thousands of SKUs times six structured fields, several with required sub-attributes and strict formats, and the highest-value fields, question and answer and related product, take genuine research per product. Filled by hand in a spreadsheet, that is a multi-month project that is stale the day it ships.
That is the work our Merchant Center Enrichment service does: an AI agent operates our Merchant Center connector, reads your own site and data to ground every value in a real source, writes the structured attributes per SKU, validates them, and publishes through a supplemental feed with a human approving the work. We walk through that pipeline in our overview of the conversational attributes, and the broader playbook lives in our ecommerce SEO and AI search guide.
However you do it, the opportunity is the same. These fields are optional, so most catalogs will not have them filled for a while. Brands that enrich well and early get a head start in AI shopping while everyone else waits. Start with your top sellers and the question-and-answer and related-product fields, since those carry the most weight in a conversation.
Want this done for your catalog, grounded in your data and validated before it goes live? Book a call and we will run a coverage read on your products.
