

Product recommendations can help or interrupt an AI conversation. Get the timing, explanation and presentation right so offers help users choose.

A user asks for headphones for work calls. The assistant returns a broad promotional link. The user lowers the budget and explains a connection requirement, but the same option appears again. After they decline, another answer repeats it.
The problem is visible before anyone clicks: the recommendation ignores the details, interrupts the task and keeps returning after it has stopped helping.
Recommending products in an AI chatbot starts with the decision the user is making. A recommendation earns its place when it helps resolve that decision, arrives at a useful moment and leaves the person in control of what happens next.
AON connects buying intent with highly structured merchant offers. Those commercial details help the application move from broad advice to specific choices it can explain. Attribution links qualifying outcomes to the recommendation, so helping the user act can also support the product’s revenue. The design challenge is to make the offer part of good assistance without letting the commercial objective rewrite the task.
A user can mention a product while learning, troubleshooting, comparing or buying. Those are different moments.
An assistant explaining why a laptop overheats should first help diagnose the problem. Recommending a replacement immediately can make the entire answer feel like a sales pitch. If the user later decides the repair is not worthwhile and asks about replacements, the commercial context has changed.
Before rendering an offer, ask three questions:
These questions belong in the recommendation logic as well as the writing brief. Polished language cannot repair a poorly timed trigger.

A useful clarifying question changes which option the assistant should recommend.
If a user wants a coffee machine for a small kitchen, available counter space may change the shortlist. Their favorite color might not. Ask for the missing detail that would most affect the choice. When the user supplies it, update discovery and the explanation; a follow-up question should lead to a more specific choice.
The same principle applies when the tool response is sparse. Do not turn the conversation into an intake form to compensate for unavailable supply. If the current options cannot answer the request, explain what remains open and keep the task moving.
Keep the user’s actual requirements in the offer request. If the user changes the budget, the search should change with it. A commercial objective should never silently replace that requirement.
A commercial recommendation should make its reasoning clear.
| Weak pattern | Why it disappoints | A stronger approach |
|---|---|---|
| A product appears because its category matches the page | The actual question may be unrelated to buying | Trigger on the current decision |
| “Perfect for you” without supporting detail | The user cannot inspect the claim | Name the requirement the offer meets |
| A large card interrupts an explanation | The commercial element takes over the task | Finish the necessary reasoning, then offer a next step |
| Missing information becomes confident prose | The answer invents certainty | State what is known and what remains unresolved |
| Every response ends with a purchase link | The assistant stops feeling selective | Show an offer when it has a useful job |
For a desk buyer, an explanation might say: “Your width limit is the deciding factor. I would compare compact models first, then check height adjustment and the supplied dimensions.” A specific recommendation should follow only when the returned information supports those checks.
Short explanations are often enough. The point is to make the basis for the choice clear, rather than repeat a merchant’s marketing description.
Different interfaces can serve different stages:
If the conversation has established a particular option, a clear provider and action may be enough. Tell the user what the next step does. “View the merchant’s offer” is more accurate than “Buy now” when the destination still requires selection or confirmation.
A card can help someone inspect a supplied price, merchant and key condition together. Organize the card around the buying question. A large image and a bright button do not replace an explanation of fit.
Two or three options can be useful when each answers the request differently. Compare on the deciding criteria. Do not manufacture differences just to fill table cells, and do not imply an exhaustive market search when you are presenting a limited set of returned offers.
These are design choices for an application you build. With AON, builders choose how the offer fits their own components. This approach is called native rendering. The hosted Content Assistant has its own interface and supported entry styles; it should not be confused with a custom renderer.
A useful recommendation makes the next decision easier. It should leave the user free to compare another option, ask a follow-up question or continue without buying.
Keep any required disclaimer clear and brief. The main design work is helping the user understand whether the product fits.
If someone hesitates, find out what remains unresolved. They may need a lower price, a different feature or a better explanation of the trade-off. Use that response to improve the choice rather than push the same offer again. If they decline to shop, continue with the original task without repeating the commercial invitation.
An offer is often the start of the final comparison. The user may add a budget, explain a compatibility need or decide that a trade-off is unacceptable. Each detail should help narrow the choice.
AON supports multi-turn discovery with compact conversation context. Your agent passes the refined request with connected session context, so the next turn can build on earlier requirements and use the new detail to find more suitable offers. Your product can keep the conversation moving without treating every message as an unrelated search.
Consider the small-kitchen coffee machine request. The first options may fit the budget. The user then explains that the machine must sit beneath a low cabinet and that they prefer capsules. Those details give AON a more specific request to match against structured merchant offers. The next recommendation can focus on the refined need, while your assistant explains what makes the new choice more suitable.
AON’s multi-turn discovery flow also supports follow-up suggestions grounded in available supply. That gives the conversation useful directions to explore, rather than asking questions that cannot lead to a relevant option.
Your application can show a closer match, compare the options or ask one question that helps the user choose. The value is in turning what the user adds into a better choice.
If the user wants to keep learning instead of buying, return to that task. Good follow-up assistance should make progress possible without making a purchase feel compulsory.
Click-through rate alone can reward an intrusive design.
Review whether users complete the task, ask productive follow-up questions, dismiss offers or return to the assistant. Pair those signals with qualifying outcomes, approved revenue and serving cost. Look at the conversations behind the numbers before interpreting a change as an improvement.
If you experiment with timing or presentation, change one meaningful choice at a time. You might compare a card shown before the explanation with a card shown after it, while holding the offer-selection criteria constant. Decide in advance which user and business outcomes would justify the change.
Return to the headphones request. The next recommendation should reflect the lower budget and connection requirement. The user should see progress in the decision they asked for help with.
AON gives the agent highly structured merchant offers to compare against those requirements. Product information, the provider, supplied prices and terms make the choice more concrete than a broad promotional link. As the user adds detail, connected multi-turn discovery helps refine the options without starting the task again.
With native rendering, your team presents that comparison in its own interface. A short explanation and a suitable offer can be part of the same answer. Your application controls the timing. If the user declines an offer, the assistant can continue helping with the task.
That is how the commercial step earns its place: it resolves the user’s question and fits the existing conversation. AON connects the tracked referral to qualifying outcomes, giving the developer a way to earn from that useful assistance. Connect AON’s shopping MCP server to bring the flow into your agent.
Include an offer when it helps resolve the buying decision the user is already making. Remove the commercial incentive and ask whether the option still earns its place in the answer. AON’s structured offer information gives your assistant concrete facts to compare with the request. Explain the relevant fit, and leave the offer out when ordinary assistance would serve the user better.
Show the smallest set of offers that lets the user make a useful choice. One option can suit a narrow request; a short comparison can expose a real trade-off. If AON returns several relevant offers, your application can choose which to present and how much detail to show. The number returned is not a display target. Let the decision and the user’s response guide the next step.
Clarify why the recommendation failed, then refine discovery or stop recommending as the user’s response requires. A new budget or compatibility requirement can inform the next AON request while the conditions that still matter are retained. A simple refusal to shop calls for ordinary assistance. The conversation should move forward because the assistant understood the response, rather than because it repeated a commercial prompt.
User fit should determine which offers are eligible, and any commercial influence on their order should be clear to users. A higher commission does not establish compatibility, value or suitability. Your application controls how AON offers are presented. Explain the supported reasons for each recommendation and assess whether the ordering helps users choose, alongside its contribution to product revenue.
Lead with the requirement it meets, then add the one trade-off most likely to affect the choice. Put secondary details in a compact card or comparison the user can inspect. For work-call headphones, the connection requirement and relevant call features may deserve attention before a long list of general specifications.
Try live offer search without an account or API key. Start building today — go live when you are ready.