Conversational Attributes in Merchant Center 2026

Shoppers increasingly stop typing “running shoes size 10” and start asking “what should I buy for my first marathon if I have flat feet and about $150 to spend”. A classic product feed cannot answer that. It has a title, a price, a GTIN and a category — nothing an answer can be assembled from. Conversational attributes in Merchant Center close exactly that gap: six optional feed fields that give the system something substantive to say about your product on conversational surfaces.

Below: what the six fields are, how they are formatted, what the limits are, which ones pay off in a day and which take weeks of catalogue work, and the order to roll them out so the project does not stall.

Why the feed suddenly has to answer questions

Conversational surfaces behave differently from a results page. In search results it is enough to match the query and show a card; the shopper does the rest on your site. In a conversation the system composes an answer — it compares, explains, rules options out, recommends. For your product to appear in that answer, the system needs grounds to say something specific about it.

A standard feed answers “what is this product”. Conversational attributes answer “is it right for me”, “how does it differ from the one next to it”, “what else do I need with it” and “how popular is it”. Without them a product stays in the catalogue but drops out of the conversation — there is simply nothing to compare it on. How ads reach those answers in the first place is covered in advertising in Google AI Mode, and the flip side — purchases that never touch your site — in AI Mode native checkout.

Conversational attributes are not another SEO field. They translate your catalogue from the language of inventory into the language of shopper questions.

The six attributes and their limits

Attribute	What it carries	Format and limit
`question_and_answer`	Question-and-answer pairs about the product	Structured pairs, up to 30 per product
`document_link`	Links to PDFs: manuals, specifications, certifications	Up to 5 files per product, 50 MB each
`related_product`	Relationships to other products, with a relationship type	Product ID or GTIN, up to 30 per product
`item_group_title`	Shared name for a family of variants	Text field, shared across the group
`variant_option`	What distinguishes this variant: colour, size, material, storage	Variant characteristic
`popularity_rank`	Relative popularity of the product	Numeric 0–100 scale, decimals allowed

All six are submitted the same way: through feeds or the Merchant API. That matters, because there is no dedicated bulk interface — the work sits with whoever owns product data. If you have not finished the API move yet, start there: details in the Merchant API migration.

question_and_answer — the most underrated of the six

Up to 30 pairs per product is effectively a chance to pre-answer everything a shopper would ask a chat agent or a shop assistant, and the system can reference your answer directly.

Where to find real questions instead of inventing them:

Support tickets and chat logs. The most honest source: real phrasing rather than the phrasing you assume is correct.
Returns. Every return reason is a question that went unanswered in time. “Wrong size” means your page never tied the item to a sizing reference.
Low-star reviews. Not to argue with, but to harvest the expectations the product failed to meet.
Your search terms report. Long question-shaped queries are a ready-made topic list — see negative keywords and search terms for how to mine it.

One rule: do not turn answers into marketing copy. “The best choice for professionals” carries no information anyone can decide on. “Machine washable up to 60°C, does not shrink; not suitable for tumble drying” does.

related_product — the connections no algorithm can guess

This is the least-used attribute because it requires product knowledge that exists nowhere in your database. The supported relationship types are specific:

part_of_set — belongs to a set;
required_part — a mandatory component without which the product does not function;
often_bought_with — commonly purchased together;
substitute — an alternative when the item is unavailable;
different_brand — an equivalent from another brand;
accessory — an add-on.

The two with the highest payoff are required_part and substitute. The first prevents returns: the shopper learns about the mandatory bracket or cartridge before buying rather than after. The second keeps the sale inside your catalogue when an item is out of stock — instead of losing the shopper, the system has grounds to offer your alternative. For segmenting all of this by margin, the mechanics are in custom labels in your product feed.

item_group_title and variant_option — the cheap, fast win

This pair fixes the classic variant problem. Without them, twelve colourways of one t-shirt look like twelve unrelated products with near-identical titles. The system does not know it is one model, so it either repeats near-duplicates in an answer or picks a variant at random.

item_group_title names the family; variant_option states what makes this variant different. Implementation usually takes a day because the data already exists — it just needs to be exposed as separate fields instead of being concatenated into the title. If your titles are assembled by rules, you can do this without developers; the approach is in feed rules in Merchant Center.

popularity_rank — an honest signal that is easy to ruin

A 0–100 score tells the system which of your products actually sell. The temptation to give everything a 95 is understandable and self-defeating: a rank only means something as a differentiating signal. If every product is a bestseller, there is no signal at all.

Compute it, do not hand-assign it. A workable formula: share of units sold over 90 days, adjusted for availability and return rate. Recalculate weekly, more often in peak season. Check separately that the rank does not contradict your own economics — a high-volume, zero-margin item should not top the scale. The margin-first logic is covered in Product Value Optimization.

document_link — where the spec sheet decides the sale

Up to five PDFs per product, 50 MB each: manuals, data sheets, certificates, compatibility tables. Close to useless for fashion; frequently decisive for electronics, building materials, auto parts and B2B equipment, where buyers compare specifications rather than descriptions.

Two practical notes. The PDF must contain a real text layer — a scanned image offers nothing to extract. And keep documents current: an outdated specification is worse than none, because it generates returns and complaints.

Rollout order: cheapest effort first

Attacking all six at once is a reliable way to ship none. Sequence by effort-to-impact.

Stage	What you do	Effort	What you get
1	`item_group_title` + `variant_option`	Low: the data exists	Variants stop competing with themselves
2	`popularity_rank` by formula	Low: one sales export	The system learns your bestsellers
3	`question_and_answer` for the top 200 SKUs	Medium: needs content	Products enter answers to substantive questions
4	`related_product` for categories with sets	Medium: needs expertise	Fewer returns, higher order value
5	`document_link` for technical categories	High: collecting and vetting files	Spec-sheet comparison works in your favour
6	Extend Q&A across the catalogue	High: a process, not a task	Long-tail coverage

A note on stage 3: two hundred products with twenty meaningful Q&A pairs will outperform the whole catalogue with three token ones. Start where revenue concentrates and where shoppers hesitate most.

Conversational attributes change the process, not just the feed

The technical part is deceptively easy — any team can add fields to a feed. The difficulty is that these fields cannot be filled once and forgotten, and the person who normally owns the feed is not the person who knows what goes in them.

A classic feed is a mechanical export of what already sits in your ERP: title, price, stock, category, GTIN. Conversational attributes require knowledge that is not in the ERP at all: which questions shoppers ask, what is compatible with what, how variants differ in substance rather than SKU. That knowledge is spread across support, category management and the warehouse.

So the first decision is organisational, not technical. Name an owner per attribute:

Attribute	Who actually owns the data	Update cadence
`item_group_title`, `variant_option`	Category / content manager	At product creation
`popularity_rank`	Analyst, automated calculation	Weekly, more often in peak
`question_and_answer`	Support plus category manager	Monthly review of top categories
`related_product`	Category manager	Whenever the assortment changes
`document_link`	Supplier / purchasing	On product revision

Without that ownership map the project lives exactly until the end of the sprint: fields ship, go stale in a quarter, and nobody notices. It is the same class of problem as data changing underneath you automatically — see Merchant Center automatic improvements.

One category, worked through

Take wireless earbuds: variants, compatibility questions and a high “not what I expected” return rate. What changes:

Variants. Before: six separate products, “Earbuds X black”, “Earbuds X white” and so on. After: item_group_title = “Earbuds X”, variant_option = colour. The system knows it is one model and does not spend an answer listing six near-identical rows.
Questions. Pulled from support: “do they work with a laptop”, “battery life on calls”, “can I use one earbud alone”, “is there noise cancelling in transparency mode”. Each becomes a pair with a concrete answer and a number where a number belongs.
Relationships. accessory for the case and adapter; substitute for the tier-below model when the main one is out of stock; often_bought_with for the cable if it is not included. This is usually where order value growth lives.
Documents. Manual and compatibility table as text PDFs, for the spec comparers.
Rank. Computed from 90-day sales adjusted for availability: in stock and selling scores high, backordered scores lower.

In a category like this the biggest single effect usually comes not from Q&A but from substitute plus popularity_rank: when the hero SKU is out of stock, the system has grounds to offer your alternative instead of someone else’s. That is revenue that otherwise disappears silently — much like disapprovals or a bad price position, covered in price competitiveness and best sellers.

Common mistakes

Copying the description into the answers. If “how do I care for it” repeats a paragraph from the description, you added zero new facts.
Uniform popularity rank. A signal that does not differentiate is not a signal.
Relationships for their own sake. Tagging often_bought_with on arbitrary pairs teaches the system bad recommendations and buys you returns.
Scans instead of text PDFs. The file uploads; the value is zero.
Treating it as a one-off. Attributes go stale with the assortment. Without recalculation you will be answering questions about products you no longer sell.
Skipping feed hygiene. These fields do not fix disapprovals or weak imagery — see product disapprovals and feed diagnostics and the 500×500 image requirement.

One adjacent development worth noting: the conversational agent that now sits beside YouTube video ads also answers from your feed — that is, from exactly these fields. Format details in one-tap Demand Gen and 9:16 Shorts creatives.

How to measure the effect

This is the awkward part: there is no native “impressions in AI Mode answers” report in the familiar sense, and part of the journey happens off your site. Measurement has to be indirect.

Roll out in stages. Apply the attributes to half of a set of comparable categories, not the whole catalogue. The other half is your control group.
Compare at category level, not product level. Product-level data is far too noisy, especially in season.
Watch the right metrics. Category impression share, click-to-order conversion, return rate and average order value. The last two respond to related_product and question_and_answer most visibly.
Use a 4–6 week window at minimum. Product data is reprocessed on its own schedule, and early readings are almost always wrong.
Cross-check Merchant Center reporting. Part of the shift surfaces there — see Merchant Center cross-platform reporting.

For wider context: 2026 shifted reporting across the board toward “what the system assembled on its own” — the same thing happened in Search, covered in AI Max reporting and the unified journey view.

Who should prioritise this

Honestly, not everyone equally. Treat it as high priority if at least two of these apply:

a wide catalogue with variants (apparel, footwear, furniture, electronics);
products with compatibility and components (tech, automotive, tools);
a high return rate driven by “wrong item / not as expected”;
a long consideration cycle and a high average order value;
heavy price competition, where you need to win on fit rather than on price.

If you sell five SKUs in one category, do question_and_answer and stop — the rest will not repay the effort. If the catalogue is large and the real question is scaling media buying behind it, look at Google Ads agency account rental and the wider PPC Rebels services, plus the broader guide to product feeds in Google Shopping.

Checklist for the next month

Confirm the feed goes through the Merchant API and supports the new fields.
Expose item_group_title and variant_option as separate feed fields.
Compute popularity_rank by formula and schedule weekly recalculation.
Collect 15–30 real questions for the top 200 SKUs from support and returns data.
Tag required_part and substitute in categories with components.
Check PDFs for a text layer and currency, then wire up document_link.
Record your control-group categories and the start date so you can compare later.

FAQ

What are conversational attributes in Merchant Center?

Six optional product feed fields that give the system material to answer questions about your product on conversational surfaces: Q&A pairs, document links, product relationships, a variant family name, the variant distinction and a popularity rank.

How are they submitted — through the interface or the feed?

Through feeds or the Merchant API only. There is no bulk interface, so the work belongs to whoever owns product data.

How many Q&A pairs can one product have?

Up to 30. Quality beats quantity: twenty substantive answers beat thirty token ones.

How many documents can I attach?

Up to five PDFs, 50 MB each. The file needs a real text layer — a scanned image is useless.

Which relationship types does related_product support?

part_of_set, required_part, often_bought_with, substitute, different_brand and accessory. Up to 30 relationships per product, referenced by product ID or GTIN.

How should popularity_rank be calculated?

By formula, not by hand: for example 90-day unit share adjusted for availability and returns, on a 0–100 scale. Giving everything the same rank cancels the field out.

Are these attributes mandatory?

No, all six are optional. But without them your product enters conversational answers on minimal data — there is nothing for the system to describe or compare it on.

Will this help ordinary Shopping campaigns?

There is no stated guarantee, but richer, better-structured product data has consistently helped relevance and matching. Basic feed hygiene remains a prerequisite either way.

Where should I start with limited resources?

With item_group_title and variant_option — the data usually exists already and implementation takes about a day. Then popularity_rank by formula.

How do I know whether it worked?

Stage the rollout with a control group of categories and compare impression share, conversion, return rate and average order value over 4–6 weeks. Product-level readings are too noisy to judge on.

Do these fields need regular updating?

Yes. Assortment, popularity and specifications change, and stale answers or documents work against you by driving returns. Minimum cadence: rank weekly, Q&A and documents whenever the product changes.

What happens if I fill the fields in superficially?

Nothing good and nothing catastrophic: token data simply gives the system no reason to pick your product, while inaccurate data raises returns. This is a case where fewer and more precise beats complete and vague.

Conversational Attributes in Merchant Center 2026: Six Fields That Get Products Into AI Mode Answers