Product Discovery Is a Metadata Problem, Not an AI Problem
When shoppers cannot find the right product, the failure is usually described as a search problem. The retailer changes its search provider, adds synonyms, tunes ranking or introduces an AI assistant. Those changes may improve how a query is interpreted, but they cannot retrieve a product fact that the catalog does not represent consistently.
Discovery begins before a shopper types anything. It begins when the business decides which attributes define a product type, how supplier values become canonical values, and whether those facts are complete enough to filter and compare.
That is why product discovery is primarily a metadata problem.
Most discovery questions are product facts
A shopper may phrase a request conversationally—“a quiet washing machine for a small flat” or “a waterproof jacket for winter walking”—but the useful constraints resolve to structured facts.
The washing machine needs dimensions, noise level, capacity and perhaps installation type. The jacket needs waterproof rating, insulation, activity and fit. A search system can infer which constraints matter. The catalog must still provide dependable values for them.
If noise level appears as a number for some appliances, marketing prose for others and not at all for the rest, no interface can produce a complete comparison. A language model may infer a likely answer from descriptions, but that answer is probabilistic, difficult to audit and inconsistent with deterministic filters.
Discovery is a chain of governed decisions
Product template → Canonical attributes → Search index and facets → Shopper result
The quality of the result is bounded by the weakest upstream contract.
Search, navigation and filters do different jobs
Discovery is often treated as one feature, but its components have distinct responsibilities.
- Navigation gives shoppers stable starting points and familiar product groupings.
- Search interprets terms and retrieves relevant products.
- Filters narrow a result set using comparable attributes.
- Ranking orders valid candidates according to relevance and business rules.
Categories should not be deepened to simulate every possible filter. Search should not parse descriptions to compensate for absent product fields. Filters should not maintain a separate list of values from the catalog. Ranking should not promote a product that fails explicit constraints.
These components work together when they consume the same governed model. The category establishes context, the template establishes which attributes matter, and the result set provides the values from which useful facets can be generated.
Why filters reveal catalog quality
Filters are an unusually honest diagnostic. A filter needs a stable attribute, comparable values and sufficient coverage. When any of those conditions is missing, the interface exposes the problem immediately.
Suppose a colour facet contains Navy, Navy Blue, dark-blue, Midnight and Blue. Some values may be meaningful distinctions; others may be supplier language for the same colour. If the catalog has no canonical colour model, the filter either shows clutter or relies on a search-specific mapping that other systems cannot reuse.
The durable fix is to govern colour at intake. Preserve supplier values for traceability, map them to canonical values for comparison, and allow a deliberate merchandising label where presentation needs nuance. The search index then receives a clean product fact rather than owning the correction.
The fragmented source-of-truth problem
Many retailers do not have one authoritative product record. The ERP knows procurement data, the PIM knows enriched descriptions, ecommerce owns storefront fields, POS owns store identifiers, and marketplaces introduce channel-specific requirements.
Each system’s local model may be reasonable. Discovery breaks when there is no governed layer that reconciles the shared product meaning between them.
A catalog contract prevents channel models from becoming competing truths
Supplier and internal sources → Governed catalog contract → Search index → Web, store and agent experiences
The catalog does not have to replace every system. It has to own the facts that must remain consistent across them: identity, product type, attribute definitions, canonical values and variant relationships.
Why AI is attractive—and where it falls short
Modern models are good at interpreting ambiguous language, finding semantic similarity and extracting facts from text. That makes them useful in discovery. It does not make them a substitute for governed metadata.
If an agent answers “yes, this part is compatible,” the retailer needs to know which product relationship supports that answer. If it recommends an allergen-sensitive product, structured and current ingredient data matters more than linguistic plausibility. If the model reconciles conflicting capacity values at runtime, two shoppers may receive different answers to the same factual question.
AI adds value when it translates shopper language into catalog constraints or explains differences between valid candidates. It becomes risky when it is expected to reconstruct the catalog’s truth on every request.
| Discovery problem | Structural response | Useful role for AI |
|---|---|---|
| Supplier values use different terms | Canonical mapping at intake | Propose likely mappings for review |
| Important facts live in prose | Add governed attributes and backfill | Extract candidate values with evidence |
| Shopper language differs from catalog terms | Maintain concepts and synonyms | Interpret intent into known constraints |
| Filters are incomplete | Improve template coverage | Identify likely completeness gaps |
| Products are duplicated | Govern identity and variants | Suggest potential duplicates |
The pattern is consistent: AI helps maintain or navigate structure. It does not become the owner of meaning.
Measure discovery upstream
Click-through and conversion are important outcomes, but they do not explain why discovery failed. Catalog teams should also observe:
- attribute completeness for the fields used in filters;
- the percentage of searches that map to known product concepts;
- zero-result queries caused by value mismatch;
- duplicate and near-duplicate facet values;
- products excluded because required facts are absent;
- contradictions between indexed values and source contracts.
These measures connect customer behaviour to correctable catalog conditions. They also prevent endless relevance tuning around a structural defect.
The architecture of dependable discovery
Reliable discovery follows a clear sequence. Products inherit governed templates. Supplier fields are mapped and validated. Canonical attributes are indexed. Categories provide navigation context. Filters are generated from applicable attributes and actual inventory. Search and AI interpret requests against those known facts.
This architecture is less spectacular than asking a model to reason over messy product descriptions. It is also faster, cheaper, reproducible and useful to every channel. Once the catalog can state what its products are, more sophisticated discovery becomes an extension of product truth rather than an attempt to recover it.