Product Research AI: How to Verify Merchant Matches and Prices

A shopper asks for a particular laptop and an assistant returns a lower price from another merchant. But the listing may describe a different memory configuration, older processor, region variant or refurbished unit. A convincing-looking product card is not evidence that two offers represent the same item. Product research systems must solve identification and price verification as separate steps. This matters particularly when the application is trying to recommend a cheaper equivalent for a user's current browsing page.

Extract stable identifying attributes from the page or user request: brand, model family, exact model or SKU, processor, memory, storage, screen size, generation and other category-specific attributes. For smartphones, colour and storage variant may change price. For appliances, capacity and energy ratings matter. Use product-specific rules rather than assuming every category has the same matching attributes. The assistant should also preserve optional preferences such as seller reputation and delivery region.

Search engines, merchant catalogues and affiliate APIs can help discover possible listings. That is only a candidate set. The system should then check the specific product page or authorised structured feed to confirm the identifying attributes, variant, seller, condition and current advertised price. If access to a merchant's live page is blocked or an API imposes limits, the result should say that verification is incomplete. It should not convert a search snippet into a claim of live verified pricing.

A label such as 'exact match' should be tied to evidence, not just model output confidence. A system may classify an item as confirmed when identifiers and critical variant attributes agree, likely when some data is missing, or not comparable when important attributes conflict. If the merchant page provides a price but the variant cannot be confirmed, the assistant should not claim a verified deal. Showing the reason is more valuable than a cryptic green checkmark.

Product prices change with inventory, coupon eligibility, location, payment methods and sales events. Store when a price was checked and whether it came from a merchant API, page content or a cached feed. Treat shipping, taxes and promotional eligibility separately when they materially change the total. A cached price can still be useful, but it should be clearly labelled as last seen rather than live. Never invent a current price because an earlier listing seems plausible.

At scale, ten thousand users requesting simultaneous comparisons could overwhelm a merchant or get an IP blocked. Prefer approved APIs and affiliate feeds, cache product identifiers and time-bounded prices, deduplicate identical research jobs and apply per-source concurrency limits. Queue longer research tasks and resume server-side when appropriate, but keep ownership and consent rules clear. A system that cannot retrieve a source should degrade gracefully instead of creating uncontrolled retries.

Show a meaningful product title, identifying specifications, merchant name, link, advertised price if verified, and the time or conditions of that verification. Group uncertain candidates separately from exact matches. If no exact match is found, explaining the limitation is preferable to silently substituting something else. The user should be able to open the actual listing and make their own final purchase decision.

Zylo includes product-research and comparison engineering work involving browsing context, model selection and merchant searches. Individual development-branch features and verification reliability should be checked before describing them as shipped in the public Play Store version. The principles here are architectural guidance, not a claim of measured price savings.