How to Make AI Product Recommendations Fit Your Users’ Market

Your agent recommends a compact keyboard. The user follows the suggestion and discovers that the seller does not deliver to their country, the layout is wrong or the price belongs to another regional offer. They return to search results and restart their shopping research.

The recommended keyboard may be suitable. The offer is still unsuitable for this buyer. For a developer serving several markets, a product name and a generic link leave too much of that work unresolved.

AON connects the user’s request to structured merchant offers, with supported viewer context contributing to eligibility. Provider information, supplied prices and applicable conditions give the agent a basis for comparing specific options in the user’s buying situation.

The product can do more of the work before sending the person to a merchant. Start with the user’s market, then compare the prices, versions and terms that matter there.

The Product Fits. The Offer Doesn’t.

An agent can know a great deal about a product and still give an incomplete buying answer.

An international retailer can sell the same product at different prices on its UK and US sites. The brand and model name may match, while the local quote, currency and delivery terms differ.

The product itself can differ too. A keyboard sold under one brand and model family may have a UK layout in one market and a US layout in another. A recommendation based only on the model name misses a detail the user will notice every day.

For a compact-keyboard request, the regional comparison could look like this:

These differences explain why a recommendation that works for one market may need a different offer in another. The user’s own preferences still matter: living in the UK does not mean they must want a UK layout.

Digital services have their own version of the problem. An option that meets a workflow requirement may also have regional availability or activation conditions. Finding a product page does not establish that the particular offer serves this user.

Structured commercial supply gives the agent more useful information to work with. AON connects requests to specific merchant offers, so provider and applicable conditions can enter the comparison alongside product preference. Supported viewer targeting helps shape which offers are eligible for discovery.

Market eligibility and delivery to a particular address are different questions. Base shipping and regional-version claims on the merchant information supplied for that offer. The agent can then explain a buying option for this person’s situation, rather than leave the commercial work for later.

Give the Agent the User’s Market

An agent serving UK and US users should not send everyone to the same regional offer. It needs the user’s market alongside the product request.

Populate viewer country from trusted device, account or network context. An English conversation does not tell you whether the user is in the UK or the US. A product preference does not establish their location either.

Keep the user’s specific requirements in the buying request. A UK user might ask for a US-layout keyboard; that changes the preferred version while their country remains GB. The agent needs both facts to make a useful recommendation.

AON uses supported viewer context in offer eligibility and the buying request in discovery. Together, they help the agent move from a generally suitable product to a relevant commercial option for this user.

Send Country and Budget Currency Separately

The current AON MCP tools accept viewer country under context.user_profile.country. If you have trusted AON Location Registry IDs, pass them in context.user_profile.location_ids; resolvable IDs take precedence over country-level context.

A numeric budget signal needs both a maximum amount and an explicit currency.

For a user in the UK who asks for a compact keyboard, specifies a UK layout and sets a budget of GBP 100, the arguments to aon_search_offers can include:

{
  "intent": {
    "content": [
      {
        "type": "input_text",
        "text": "Compact keyboard with UK layout, delivered in the UK, under GBP 100."
      }
    ],
    "signals": {
      "budget": { "max": 100, "currency": "GBP" }
    }
  },
  "context": {
    "user_profile": { "country": "GB" }
  }
}

Use your actual placement and session configuration around that request. The example illustrates three distinct inputs: the user’s buying requirements, the budget currency and the viewer’s country.

The MCP tools reference describes their current request semantics. Country is not a shortcut for currency. If the user has not specified the currency for a numeric budget, clarify it before adding both budget fields. Treat the budget as an input to discovery, then explain how each quoted option fits it using the returned price and terms.

Keep product-version and delivery requirements in the expressed intent. Country describes the viewer’s market; it does not replace the details of what they want to buy.

Show the Regional Terms That Change the Choice

The answer should make the commercial context easy to understand.

For the keyboard buyer, explain the relevant supplied layout information, identify the provider and show the price in its stated currency. Include delivery or other applicable conditions when they affect the decision and are supported by the offer information. These details can come from the offer’s descriptions and commercial information; each attribute does not need its own dedicated field.

For a UK user looking for a UK-layout keyboard under GBP 100, the following comparison uses illustrative prices and terms.

Offer A matches the requested layout. Its quoted price includes UK delivery and is within budget. Offer B has a lower product price, but its layout differs and UK delivery is not stated. The explanation shows why the cheaper listing may be a weaker fit.

In your application, build the comparison from the actual returned offer information. Market eligibility alone does not establish shipping terms, tax treatment or a regional version. The Offer Query reference describes the commercial information available for presentation.

Do not make currency conversion look like a merchant quote. If your application provides a converted estimate, label it as an estimate and keep the original commercial price clear. The user should know which amount belongs to the offer.

Similarly, a product-family description should not become a claim about a particular regional version. Use the information attached to the offered option. If a decisive detail is unresolved, keep that detail visible instead of burying it beneath a confident overall recommendation.

AON provides the structured commercial starting point. Your product turns the relevant differences into a buying answer the user can act on.

One Agent, Relevant Offers Across Markets

For developers, the goal is straightforward: give UK users useful UK-market choices and US users useful US-market choices, while respecting what each person actually wants.

The same AON discovery integration can serve users across supported markets by carrying the appropriate viewer context and buying requirements. Connected merchant offers give your agent concrete prices, versions and supplied terms to compare. Your team controls how those differences appear in the product.

That can reduce referrals to unsuitable regional listings and the need for users to restart their research on another site. The agent helps with the local buying decision before the merchant handoff, while returned tracked actions connect recommendations to reported qualifying outcomes.

When a preference needs clarification, ask the question that changes the choice. The value comes from connecting that answer to an offer the user has a reason to choose in their market.

FAQ

How does AON use country information when finding offers?

AON uses supported viewer-country context to help determine which merchant offers are eligible for that user. The buying request separately describes where the product must be delivered or the service used. Keep those inputs accurate rather than replacing the viewer’s country with a preferred shopping destination. Your agent can then compare eligible options against the user’s actual buying requirements.

Does AON require a separate integration for each shopping market?

No, the same AON discovery integration can serve users in different countries. The same discovery integration can carry the appropriate viewer context and buying request for different users. Relevant options depend on connected merchant supply and applicable conditions. Your application can use that shared capability across markets without building a new merchant connection for each conversation.

Why can one global product link fall short for AI shopping recommendations?

A global product link can help users reach a brand, but it does not explain the local buying choice. The same product may have different prices, versions or availability across regional stores. AON brings specific merchant offers into discovery so your agent can explain those differences before the user leaves.

Can an AON shopping request use a different currency from merchant prices?

Yes, the user’s budget and the merchant’s offer can use different currencies if you keep each currency explicit. Preserve the user’s explicit budget currency and the merchant’s quoted currency as separate information. If your app adds a conversion, label it as an estimate and keep the original offer price visible. Country alone does not establish the currency the user intends for their budget.

Can AI shopping recommendations show an AON offer’s regional terms?

Yes, supplied regional terms can be shown beside the offer when they affect the buying choice. Show the provider, quoted price and currency, then the supplied regional conditions that change the choice. For a keyboard, that might mean layout and delivery. Use the actual offer information for each comparison; market eligibility alone does not confirm shipping terms or a regional version.

How should an AI shopping agent handle a preferred regional product version?

Include that preference in the buying request and keep the viewer’s actual country accurate. For example, a UK user asking for a US-layout keyboard still has viewer country GB. The agent should compare offers against both the requested version and the relevant market conditions.