The Feed Attributes That Decide Your Visibility in Google's AI Shopping Results

Your product feed stopped being a Shopping ads file. Google confirmed at Google Marketing Live this year that it reads feed data into AI Mode and its other AI surfaces, which means the same file now decides whether an LLM can describe your product to a shopper who never types a keyword.

I have audited over 1,300 Shopify stores since 2015, and nearly every feed I open is still poorly optimized for the old shopping engine. Titles not tuned for query matching, descriptions treated as filler, and nothing anywhere that answers questions that a shopper might have.

What Shopify sends in Google feeds out of the box has not moved to meet this industry change, and it will not.

Instead, it's up to advertisers to make sure your product feed fills this gap. 

What new attributes did Google add?

Feeds were built for classic Shopping search. Someone types "red running shoe size 10" and Google matches it. That still happens, and it still matters. But shoppers on AI surfaces ask whole questions, full of constraints your feed has no field for.

Google's answer is six optional fields called conversational attributes. They do not affect your approval status, they sit alongside your existing data, and they exist so AI systems can understand nuances the standard spec was never designed to carry.

Three of them are worth your time this week. Three can wait, and I will explain why.

Specs tell Google what it is, use cases tell it when it matters

This is the distinction the whole update turns on, and it is where most feeds fail.

"Breathable mesh upper fabric" is a spec. "Long-distance trail running in warm weather" is a use case. A shopper asking an AI surface for a shoe they can wear on a hot forty-kilometre run is describing the second thing. A feed carrying only the first has nothing the model can match against.

Specs are still useful, and Google now gives you a better home for them. But a catalogue full of specifications and no context is exactly the catalogue that disappears from conversational results while its data looks perfectly healthy in Merchant Center.

Fix #1: Write the use case down

There is no "use_case" attribute. Instead, you can put it in [product_highlight], [product_detail], [description], and now [question_and_answer].

The Q&A field takes up to 30 pairs per product, each question and answer capped at 1,000 characters and 10,000 characters in total. Use it for the questions your support inbox actually receives. Sizing, care, compatibility, these are the objections that stop the sale.

Google is unusually direct about what not to do with it:

• No keywords or search terms.
• No prices or dates.
• And do not duplicate what you already submit in [title], [description], [product_detail] or [product_highlight] because repetition adds nothing for a model that has already read those fields.
• Write one line per product covering when to use it and why to choose it. That line is your use case, and most catalogues do not have it anywhere.
  

The difference between a useful question and answer pair and a wasted one is easy to see side by side.

Take these two questions and answer sets for example: 

"Is this a good quality shoe? Yes, our shoes are made from premium materials" tells a model nothing it could not assume.

vs.

"Can I wear these for a marathon on pavement? Yes. The 8mm drop and 34mm heel stack suit road distances over 30km, though runners who prefer ground feel usually choose our lower-stack model" gives it a constraint, a number and a reason to rule the product in or out.

Tip: Pull the ten questions your team answers most often and start there. You are writing for a system that has to decide between your product and a competitor's, not for a page that has to look complete.

Fix #2: Name the buyer

The same fields carry your ideal customer, and the same discipline applies. Be specific enough that the description excludes someone.

"First-time marathon runners who want cushioning over speed" works because it fuses the buyer with the use case. "Great for runners of all levels" describes nobody, which means it matches nobody when a model is trying to decide which of forty shoes to put in front of a particular person.

Fix #3: Map what goes with what

The [related_product] attribute answers two questions your feed has never been able to answer. What does this go with, and what does this customer usually need next.

You get six relationship types, covering accessories, substitutes, required parts, part of a set, often bought with, and a different brand version. Each entry needs three sub-attributes, the relationship type, the identifier type, and the identifier itself, matched by product ID or GTIN. You can add up to 30 related products per item.

For a trail shoe, that means the socks, the hydration vest and the anti-blister balm, assuming they exist in your feed. What you are giving Google is genuine relationship data rather than a collection page full of links it has to infer meaning from.

If you resell branded stock, match by GTIN rather than your own IDs wherever you can, since the barcode survives a catalogue restructure and your internal IDs usually do not.

This is also the attribute most likely to earn its keep quickly, because it puts your catalogue into answers about the second and third product rather than only the first. A shopper who asks what else they need for their first trail race is describing a basket, and the merchant whose feed already knows the answer is the one that gets recommended.

Where do the specs go now?

[Document_link] allows up to five PDFs per product at 50 MB each.

You can add:

• Manuals

• User guides

• Size charts

• Care instructions

• Assembly steps

• Package inserts.

If you sell anything technical, anything with various sizes, or anything a customer has to put together, this is the cheapest depth you will ever add. It lets an AI surface answer a detailed question about your product using your own documentation instead of guessing from a 200-character description.

The three attributes that can wait

[Item_group_title] and [variant_option] work with [item_group_id] to present a product and all its variants as one thing. Most Shopify feed setups already emit [item_group_id] and the core variant attributes, so the marginal gain here is smaller than the gain from a product that has no use case anywhere in its data.

[Popularity_rank] ranks a product against the rest of your inventory. It is self-declared, so it will not rescue a product a model cannot describe. Add it once the first three are live.

None of these are wasted work. They are just the wrong place to start.

Ship it without touching your theme

The implementation is less painful than it sounds, and this is where a feed tool does the heavy lifting.

Leave your primary feed alone. Add the new attributes through a supplemental data source, which is a second spreadsheet matched to your products by id. No theme edits, no app migration, no rebuilding a feed that already works. Use Google's exact attribute names and formatting, because “close enough” silently does nothing.

None of this arrives on its own. These fields exist for merchants who choose to fill them, which is most of the advantage on offer right now.

Tip: Start with your ten best sellers rather than the whole catalogue. Ten products with real use cases, real questions and mapped relationships will teach you more in a month than 4,000 products with a template applied to them.

Get the basics right first, or none of it lands

Conversational attributes enrich a product Google has already identified. They do not fix a product it cannot place.

So before any of this, clear every disapproval and warning in Merchant Center, because most of what you find will be one of the common errors catalogued on this blog. Then check your identifiers.

You can use DataFeedWatch's AI-powered optimization to quickly clean up and make improvements to your feed. It will also go through an automatic feed errors review before being sent off to Google. 

In my audits roughly a third of Shopify stores have GTIN problems, usually a blank barcode field or an internal SKU pasted where the barcode belongs, and a correct gtin inherits everything the Shopping Graph already knows about that product.

Titles still carry the most weight of any text field, and the Blue Bungalow work we published on this blog is a fair reference for what restructuring them is worth. The mechanics that lifted classic Shopping matching are the same ones feeding retrieval now.

What metrics to watch, and for how long

Push the feed, then leave it alone for 30 days and read:

• Product-level impressions

• Clicks

• Click-through rate

• Search themes

• Sales

Impressions and search themes move first. If the products you enriched start appearing against questions you never used to show for, the extra context is working. If nothing shifts in a month on your best sellers, the problem is upstream in identifiers or titles rather than in the new fields.

The feed is the product now

For ten years the feed was plumbing and setting up Google Ads for Shopify was the craft. That has inverted. Campaign types are automated and increasingly identical between competitors, and Google is standardising how catalogues are read across its AI surfaces through work like the Universal Commerce Protocol. The differentiated asset left is the data.

Treat every attribute as an answer to a question a shopper will ask an AI. Most of your competitors have not filled a single one of these fields yet.