The 8 Conversational Attributes for AI Shopping Visibility

What Conversational Attributes Are, and Why Google Added Them

Google’s conversational attributes are a set of optional product fields, introduced with the new Merchant API, that feed Google’s AI shopping surfaces directly. They do not affect whether your products get approved. They will not fix a disapproval or change your Shopping eligibility. What they do is hand Google’s AI the structured, machine-readable facts it needs to understand a product and put it in an answer.

That distinction is the whole point. The reason Google built these fields is that shoppers stopped typing keywords. They now ask full questions: “waterproof hiking boots for wide feet under $150 that ship in two days.” To answer that, an AI cannot guess from a marketing paragraph. It needs to read explicit facts, in a form it can match against the question. Conversational attributes are how you supply those facts instead of hoping the model infers them.

There are eight of them. Most merchants have filled in zero. That gap is exactly why they are worth understanding now, one field at a time.

The 8 Conversational Attributes, Field by Field

1. product_highlight

Short benefit bullets, up to 150 characters each. Google recommends four to six per product. These are selling points, not specs: “Stays waterproof to 5m,” “Wide toe box for all-day comfort,” “Vibram sole grips wet rock.” AI answer cards often lift a highlight straight into the “why this product” line, so this is the field that most directly shapes how your product gets pitched.

2. product_detail

Structured technical specs, expressed as an optional section name plus an attribute name and value: Material / Full-grain leather, Waterproof rating / 5 meters, Sole / Vibram. Where a highlight sells, a detail answers. When a shopper drills into specifics, this is the machine-readable table the AI reads from instead of parsing your description and hoping.

3. question_and_answer

FAQ pairs carried inside the feed itself, up to 1,000 characters per pair. Google states these are “primarily intended for conversational experiences such as AI Mode,” which is about as direct a hint as the documentation ever gives. Q&A is powerful because it mirrors the exact shape of a shopper’s query. “Is it true to size?” paired with “Runs half a size large; size down for a snug fit” is a match the model barely has to work for.

4. variant_option

Explicit variant differentiators, given as a name and value, repeatable across a family of products. Instead of leaving the AI to work out that six near-identical listings are one shoe in six colors, you state it: Color / Sapphire Blue, Size / 11 Wide. This is how an assistant answers “do you have it in blue in a wide?” without guessing.

5. item_group_title

A shared, generic title across a variant family, up to 150 characters. If variant_option says how the variants differ, item_group_title says what they all are: “Men’s Waterproof Leather Hiking Boot.” It gives the AI a clean parent concept to group the family under, so it talks about the product, not fifteen separate SKUs.

6. related_product

Declared relationships between your products: this battery is required for that camera, this filter is an accessory, this is the substitute for a discontinued model. Once those links are explicit, an AI can build baskets and answer follow-ups. “What else do I need to use this?” becomes answerable from your own data rather than a guess.

7. document_link

HTTPS links to PDFs the AI can read, such as manuals, spec sheets, and sizing guides. A lot of the most useful product knowledge lives in a datasheet nobody put in the feed. Pointing to it lets an assistant answer detailed questions, like “what’s the power draw?”, from the document instead of admitting it does not know.

8. popularity_rank

A relative sales-performance signal, on a 0 to 100 scale, that tells Google which of your products are the strong sellers. It exists for the queries shoppers actually ask, “what’s your most popular” or “best-selling under $50,” where the AI needs a way to rank your own catalog against itself.

Why These Fields Decide AI Shopping Visibility

Step back and the pattern is clear. Every one of these fields converts product knowledge you already have into a form an AI can read without guessing.

An LLM does not see your product. It reads text. A title like “Erkek Deri Bot” or “Blue Shirt Men” gives it almost nothing to match against a real question. A product carrying five highlights, a spec table, and three Q&A pairs gives it unambiguous facts, in roughly the shape of the query, so the model can retrieve the product as relevant and justify recommending it. That is the difference between being synthesized into the answer and being skipped.

It also settles a common tie. When two merchants sell the exact same GTIN, the one with complete identifiers and rich, question-shaped attributes is the more discoverable and more citable of the two. Increasingly, data quality rather than ad spend is what decides who the AI names. Filling these fields is how you win that tie on the merits.

These attributes are optional today and don’t affect approval. That is exactly why filling them early is an edge, before they quietly become table stakes.

The catch is scale. Hand-authoring product_highlight, product_detail, and question_and_answer for a few hundred SKUs, in the right language, inside Google’s character limits, without wandering into a policy-violating claim, is a project most teams never finish. The fields reward you, but only if every product has them, and that is precisely where the manual approach falls down.

How to Fill Them Without Hand-Writing Thousands of Fields

The practical path is not to type these fields by hand. It is to generate them from the product data you already have and deliver them as a supplemental feed that merges onto your primary feed inside Merchant Center, matched by product id. Your primary feed keeps owning price, availability, and identifiers. The supplemental layer adds the conversational attributes on top, so your live Google feed gets AI-enriched without you editing a single product by hand or rebuilding your export.

This is what UCP Radar automates. It reads your existing product data, generates the benefit highlights, structured spec details, variant options, and Q&A pairs, and emits them as a Google-spec supplemental feed you register in Merchant Center. The same enrichment that structures a product for Google’s Merchant API also travels to the other AI shopping surfaces, since they converge on the same structured, question-shaped data. You connect once; the conversational attributes stay generated and fresh instead of frozen the day you wrote them.

Worth being precise about the boundary: a tool like this hosts and serves the enriched feed, but you register and control it in your own Merchant Center. Nobody pushes data to Google on your behalf, and none of this promises a ranking. What it promises is that when Google’s AI reads your catalog, it finds real answers instead of blanks.

Conclusion

Conversational attributes are the part of the new Merchant API that most merchants will ignore precisely because they are optional. That is the opportunity. They do not change approval, so they are easy to skip, and skipping them is exactly why so many catalogs will stay invisible to AI while a few well-structured ones get recommended. The eight fields, highlights, details, Q&A, variant options, item group titles, related products, document links, and popularity rank, are simply your own product knowledge written in a form an AI can read. You can fill them by hand, or you can let a tool generate and maintain them across your whole catalog. Either way, the merchants who fill them now are teaching Google’s AI to understand their products while everyone else is still shipping blank fields. UCP Radar is one way to make that automatic, so your feed answers the question before a competitor’s does.