How AI Shopping Assistants Actually Pick Which Products to Recommend
AI shopping assistants do not browse; they retrieve. When a shopper asks for a two-person three-season backpacking tent under 2.5 kg that pitches freestanding, for a wet October in Scotland, under $400, an assistant matches that description against structured product records it has indexed (feeds, merchant data, retailer catalogs, crawled pages) and can only recommend products whose records answer the question. A product that never states packed weight, pitch type or wet-weather performance is not ranked lower; it is not a candidate. Visibility in AI is a symptom; the product-language record is the lever.
That is the mechanism. The rest of this page is the detail behind it: what the retrieval chain actually does, what each surface is known to read, and (the section most articles on this subject skip) which parts of the system are genuinely opaque and cannot be controlled by anyone, including us.
How do AI shopping assistants go from a question to a recommendation?
The assistant decomposes the question into constraints, retrieves candidate products whose structured records can satisfy those constraints, and only then compares the survivors. Two of those three steps happen before your product is ever weighed against a rival's.
Take the query above and break it the way a retriever has to break it. "A two-person three-season backpacking tent under 2.5 kg that pitches freestanding, for a wet October in Scotland, under $400" is not one request. It is eight separate constraints, each of which has to be checked against something written down.
Now take the product record most outdoor catalogs actually ship. Title: 2-Person Dome Tent - Alpine Green. Category: Sporting Goods > Outdoor Recreation > Camping & Hiking > Tents. Product type: Tents > Dome. Color: alpine green. Capacity: 2 person. Price: $379. Availability: in stock. (A constructed example, not a real SKU, but nothing has been left out of it to make the point.) That is a complete, healthy, non-erroring record. It will pass every feed diagnostic you run.
Here is that same record measured against the question the shopper actually asked.
One shopper question, broken into the eight constraints a retriever has to satisfy, and whether a typical tent record can answer each one.
| Constraint in the question | The field that would answer it | Present in the record? | What the retriever does |
|---|---|---|---|
| Tent | google_product_category, product_type | Yes | Passes |
| Two-person capacity | capacity, title | Yes | Passes |
| Under $400 | price | Yes | Passes ($379) |
| Three-season rating | product_type: "Tents > Dome" | Ambiguous | A dome is a pole geometry, not a season rating; no rating is stated anywhere |
| Packed weight under 2.5 kg | No field; absent from the description | No | Cannot be evaluated |
| Freestanding pitch | No field; no pitch-type guidance anywhere | No | Cannot be evaluated |
| Wet-weather performance | No field for waterproof rating or fly coverage | No | Cannot be evaluated |
| October / shoulder-season use | No field | No | Cannot be evaluated |
Four of eight, and one of the four is ambiguous. The physical tent behind a record like that is in stock, priced correctly, and would satisfy this shopper completely if they could pick it up and read the spec panel on the box. The assistant has no way to know that, because the record never says it.
Is it ranking, or is it retrieval?
Retrieval decides whether you are a candidate at all; ranking decides the order of the candidates. Nearly everything written about brand visibility in AI addresses the second problem, and nearly every product that loses, loses at the first.
This is the part that breaks a decade of search intuition. In classic organic search, a thin page is still on the list, just lower down, and the remedy is to grind upward. Retrieval against structured records does not work that way. If the query carries a constraint your record cannot answer, you are not a weaker match: you are outside the set being compared. An absent attribute is not a neutral omission. It is a silent disqualification from the consideration set.
Silent is the operative word. There is no rejection notice, no impression log, no diagnostic in any console that says excluded: occasion not stated. Feed health tooling will report the record as perfect, because by the standards of feed health it is perfect. The gap only becomes visible when someone sits down with a real query and reads the record against it.
The same logic runs one level up, at the category. If your hierarchy files a backpacking tent under a buying-team label rather than something a shopper would say, the retrieval step can miss you before any attribute is even consulted. That is a product taxonomy problem disguised as an attribute problem.
What each surface reads
Every assistant assembles its answer from some combination of three inputs: a merchant-supplied product feed, the crawled product page and its structured markup, and third-party sources it can cite. The mix differs by surface, and the mix decides which of your fixes reaches which assistant.
The same product record, read four different ways, plus the paid surfaces reading it this quarter. Only the last column contains a lever.
| Surface | What it reads | What it does with it | What an operator controls |
|---|---|---|---|
| Google AI Mode and the Business Agent | Merchant Center product data, including the conversational attributes added on 20 May 2026; the crawled product page and its Product markup; the Shopping Graph | Answers the shopper inside the results surface, serves Direct Offers in AI Mode, and (through the Business Agent) holds a brand-voice sales conversation on the retailer's behalf | Feed coverage and accuracy, population of the conversational attributes, page markup, category mapping |
| ChatGPT and ACP | Crawled product and category pages, structured markup, merchant-supplied product data where a merchant participates, and third-party editorial and review sources | Composes a recommendation set inside the conversation. The Agentic Commerce Protocol, launched with Stripe in September 2025, is the checkout rail, not the retrieval mechanism | What the page and the record state, whether the page is crawlable, whether an independent source can verify the claim |
| Perplexity | The live web, restricted to pages it can cite: retailer product pages, editorial roundups, review sites | Answers with sources displayed, which means a citable third party can outweigh your own page in the answer | The specificity of your own page, plus what a reviewer can factually state because your record stated it first |
| Amazon's Alexa for Shopping | Amazon's own item catalog: submitted attributes, bullets, browse-node placement, enhanced content, customer reviews and Q&A | Answers in-app and completes an agentic purchase inside Amazon, following the May 2026 folding of Rufus into Alexa for Shopping | The completeness of the item record you submit to Amazon, and nothing outside it |
| Google Shopping, Performance Max, Meta Advantage+ (paid, same record) | The same Merchant Center or commerce catalog feed | Machine-matches the record to auctions, queries and audiences | The same fields. This is why the work pays before the assistant referrals arrive |
Two honest notes on that table. First, the entries describe what each system is known to consume, drawn from the platforms' own announcements and documentation, not from any privileged access. Second, none of these companies publishes its retrieval function, its weighting, or its candidate-set size, and none exposes an impression log. Anyone presenting a ranking-factor list for these surfaces is describing a black box from the outside and calling it a schematic.
Where the systems are genuinely opaque
You control what your record says. You do not control what happens after it is read. The split is worth writing down, because the second column is where most budgets go to die.
In your control: whether an attribute is stated at all; the vocabulary it is stated in; which structured fields are populated and how completely; the markup on the page; feed freshness and coverage across the whole catalog rather than the top sellers; and what a third party can truthfully say about the product, because you gave them the material.
Not in anyone's control: the retrieval function and its weighting; candidate-set size; whether an answer cites you, paraphrases you, or links to a roundup that mentions you; personalization by user, session and location; which model version answered; and whether the same prompt returns the same set tomorrow. It generally will not.
That second list is not a caveat we are adding for modesty. It is the reason the first list is the only place to spend.
Why do "AI visibility" dashboards not move the number?
A visibility dashboard samples prompts and reports whether you were mentioned. That is a thermometer: genuinely useful for noticing that something changed, structurally incapable of causing the change.
The measurement is also weaker than it looks. Assistant answers vary by user, session and model version, so a sampled mention rate is an estimate of an estimate. Worse, mention is not the outcome anyone is buying. A brand can be named in an answer and still not have a single product retrieved into the recommendation set, because those two things are decided by different mechanisms: one by what the web says about you, the other by what your product record can answer.
This is where answer engine optimization for ecommerce diverges from its content-marketing cousin. The content version is about being cited as a source. The commerce version is about being retrievable as a product, and no amount of authority substitutes for a packed-weight field that does not exist. If a dashboard number moves and you cannot say which change moved it, you have a reading, not a result. Our position on that is the same everywhere: a change is only real when it is measured against a control.
Why fix this now, when AI referrals are still a rounding error?
Because the record you fix for the assistants is the same record the paid surfaces read this quarter, and because the discovery behavior has already moved even though the checkout behavior has not. AI-referred traffic is still a small fraction of retail sessions. That is an argument about timing, not about direction.
In March 2026, OpenAI stepped back from in-chat checkout and moved toward Apps, and the consensus that formed across the industry was discovered in AI, buy on site. That is the load-bearing point on this page. The assistant is turning into the place where the consideration set is built, while the transaction stays on the retailer's own property. Semrush's data points the same way: 50% of US shoppers bought elsewhere after researching inside an AI tool. That is the behavior you would expect from a surface that assembles the consideration set and then hands the transaction back to the retailer, and from traffic that arrives having already been filtered against eight constraints.
Three things follow, and they are why this is a rational spend now rather than a 2028 bet.
- The input work compounds. An attribute written today is read by every surface that arrives afterwards. Merchant Center conversational attributes did not exist before May 2026, and the retailers who could populate them in week one were the ones whose records already carried occasion and fit language for other reasons.
- The same record pays this quarter. In a matched-spend A/B test with a 28-day holdout, rewriting the product-language input produced a 28% increase in Google Shopping revenue against the untouched control. In a statistically significant A/B test, the same class of change produced a 28.3% increase in onsite revenue. We do not publish an equivalent controlled figure for assistant-referred revenue, because the surfaces do not yet expose the attribution needed to build one honestly. When they do, we will show the method first.
- It decays. Catalogs churn: new SKUs land weekly, seasonal assortments rotate, suppliers rewrite their own descriptions, and the surfaces keep adding fields. A one-time enrichment project is a snapshot of a catalog that has already changed underneath it, which is why this has to run continuously rather than as a Q3 initiative.
How do you audit your own product record this week?
Run it by hand on twenty SKUs before you buy anything. The exercise takes an afternoon and it is the only diagnostic that surfaces the failure described on this page, because every automated feed check will pass a record that is silently unretrievable.
- Pull your twenty highest-revenue SKUs and export the full record for each: title, description, category, product type, every populated attribute.
- For each SKU, write the five questions a real shopper would say out loud. Not keywords. Spoken sentences, with constraints in them.
- Mark every constraint in every question as present, absent, or implied in the record.
- Apply the scoring rule that makes this honest: implied counts as absent. A retriever cannot infer that a dome tent pitches freestanding, that a listed weight is the packed weight rather than the trail weight, or that a fly reaches the ground in wind. If a human has to reason from the photo, the constraint is absent.
- Count the absences. That count is a measure of how many of the shopper's stated constraints your record cannot answer, and each absent constraint is a query the record cannot be matched against.
The five questions that generalize across most catalogs: what occasion or use is this for; how does it fit or size; what is it made of and how is it constructed; what are the care and durability constraints; and what does it work with, fit into, or sit beside. If your export cannot answer those, the fix is in the record, not in the campaign.
From there the work is ordinary and unglamorous: get the attribute set right, get it delivered, populate the fields the newest surface asked for, and keep the whole library in one place.
The platforms built every pipe: UCP, ACP, Universal Cart, conversational attributes, AI Mode, Alexa for Shopping. Not one of them supplies the quality of what flows through. That is the operator's lever, and it is the only part of this system that answers to a budget. Judge any spend against it on four things: does it fix the input rather than the layer above it, does it run continuously because catalogs churn, does it cover the surfaces that pay this quarter as well as the interesting ones, and does it prove lift against a control. Or, compressed into the question a CFO will ask anyway: would it survive a finance review?
Frequently asked questions
How do AI shopping assistants decide which products to recommend?
AI shopping assistants break a shopper's question into constraints, retrieve products whose structured records can satisfy those constraints, and then compare only the products that survived retrieval. A product whose record does not state an attribute the question depends on is not ranked lower; it is excluded from the comparison entirely.
Does ChatGPT read my product feed?
ChatGPT composes product recommendations from crawled product pages, structured markup, third-party editorial and review sources, and merchant-supplied product data where a merchant participates in a shopping integration. The Agentic Commerce Protocol that OpenAI launched with Stripe in September 2025 governs checkout rather than retrieval, so participating in it does not by itself make a product findable.
How do I get my products recommended by AI?
State every attribute a shopper would name in the question inside the product record itself, using the words the shopper would use rather than internal merchandising vocabulary. Then keep doing it, because catalogs turn over continuously and the surfaces keep adding fields, such as the Merchant Center conversational attributes that did not exist before May 2026.
Is optimizing for AI shopping assistants the same as SEO?
Search engine optimization mostly improves position among pages that already qualify, whereas AI shopping assistants decide qualification first, at the level of the product record. Tactics aimed at the ranking layer cannot repair a record that never stated the attribute the shopper asked about.
Can I track whether my products appear in AI shopping assistants?
Sampling tools can report whether a brand or product was mentioned across a set of prompts, which is a useful change detector but not an attribution method. None of the major assistants publishes impression, candidate-set or ranking data, so the only claim that survives scrutiny is a change measured against a control on a surface that does report.
Is this worth doing while AI-referred traffic is still small?
The same product record that AI shopping assistants read is the record Google Shopping, Performance Max and Meta Advantage+ read today, so the work pays on the paid surfaces in the current quarter regardless of assistant volume. Waiting also forfeits compounding, because a record enriched now keeps earning as each new surface arrives, while a record fixed in 2028 starts from zero in 2028.
Product attributes: which ones each discovery sur…

See Lily in action
Book a personalized demo and see how Lily can grow your retail revenue.
Related Blogs
Agentic commerce: what it is, what changed in 2026, and what a brand actually has to do
Agentic commerce is AI agents buying on a shopper's behalf. What changed in 2026, what an agent reads from your catalog, and what to fix before Q4.
By Lily AI
Does feed optimization increase sales? The anatomy of a controlled test
Does feed optimization increase sales? Yes, against a control. Get the full test design: matched spend, 28-day holdout, difference-in-differences.
By Lily AI
What actually goes in Google Merchant Center conversational attributes
What actually goes in Google Merchant Center conversational attributes: worked before-and-after values for apparel and home, plus where to mine them.
By Lily AI