Turn customer language into searchable meaning.
Ranking can only order the candidates it receives. This framework shows how to decompose ecommerce queries, connect them to catalogue data and preserve uncertainty when more than one interpretation is credible.
Use it with lexical, semantic or hybrid search. The concepts stay the same even when the implementation changes.
Interpret first, retrieve second, rank third. A perfectly ordered list of products for the wrong meaning is still a failed search.
Decompose compound queries
Separate the product the customer wants from the conditions it must satisfy.
Compound searches compress several decisions into a few words. The safest interpretation identifies the head product concept first, then attaches attributes, brand, audience, use case and exclusions. Treating every token as equal text often rewards products that match many words while missing the requested product type.
women’s red waterproof hiking jacket size M
Weak readingSeven independent keywords competing across titles and descriptions.
Useful readingJacket = product; women’s = audience; red, waterproof and M = constraints; hiking = activity context.
Questions to ask
- What is the head product concept?
- Which words narrow eligibility and which only add preference or context?
- Can one token belong to more than one field in this catalogue?
Evidence to inspect
- Parsed tokens, detected entities and generated filters
- Result composition when each term is added or removed
- Reformulations that simplify a long query into shorter searches
What to try
- Define an entity schema that matches the catalogue’s strongest fields
- Test compositional queries rather than only single product terms
- Keep soft preferences distinct from filters that can cause zero results
Map attributes to catalogue truth
Customer vocabulary and product data must meet in the same field.
Shoppers rarely use the exact labels in a product information system. They search for ‘navy’, ‘midnight’ or ‘dark blue’; ‘sofa bed’ or ‘sleeper sofa’. Interpretation should connect those terms to controlled catalogue values without pretending that weak or missing data is precise.
oak dining table for six
Weak readingMatches ‘oak effect’ copy and any page mentioning six, including sets of six chairs.
Useful readingDining table = product; oak = material requirement; six = seating-capacity intent, verified against structured fields.
Questions to ask
- Is this value stored consistently and completely for the category?
- Is the shopper expressing a strict requirement or a preference?
- Do local-language terms map to the same controlled value?
Evidence to inspect
- Attribute completeness and value distributions by category
- Examples of customer terms that lead to the same product family
- False positives caused by matching descriptions instead of attributes
What to try
- Normalise high-value attribute families and their customer vocabulary
- Use category-aware mappings so a term keeps the right meaning
- Fall back gracefully when structured data is incomplete
Normalise without erasing meaning
Small text-processing choices can split brands, sizes and product codes into the wrong pieces.
Case folding, punctuation removal, stemming, typo tolerance and token boundaries shape every later match. The right behaviour depends on the catalogue: a hyphen may be noise in one query and essential in a model number; a short token may be a stop word in prose but a clothing size in retail.
New Balance 530 / EU 39.5
Weak readingDrops ‘new’, splits the decimal size and fuzzily matches unrelated model numbers.
Useful readingPreserves the multi-word brand, identifies 530 as a model and normalises 39.5 within the EU size system.
Questions to ask
- Which punctuation and token boundaries carry meaning in this category?
- When should typo tolerance be reduced for brands, SKUs or short queries?
- Are stemming and stop-word rules appropriate for every supported language?
Evidence to inspect
- Raw and analysed token streams for representative queries
- False matches around short terms, codes, units and multi-word brands
- Zero-result queries differing only by punctuation, accents or inflection
What to try
- Create field-specific analysis instead of one analyser for every value
- Protect product codes, model names, units and known multi-word brands
- Test each language with native examples rather than translated English probes
Use vocabulary, not synonym sprawl
Equivalence, relatedness and substitution are different relationships.
Synonyms are useful when two expressions genuinely denote the same concept in context. They are dangerous when used as a general rescue tool. Related categories, accessories, broader terms and style associations can widen retrieval without being interchangeable—and should be represented differently.
trainers
Weak readingA global synonym equates trainers, shoes, running shoes and sneakers in every market and category.
Useful readingTrainers and sneakers are market-aware vocabulary for a product family; running is an activity refinement, not a universal equivalent.
Questions to ask
- Are the terms interchangeable in this market and category?
- Should expansion work in both directions?
- Could the rule introduce accessories, substitutes or broader categories?
Evidence to inspect
- Results with each expansion enabled separately
- Query pairs customers use before and after reformulation
- Synonym rules ranked by traffic reach and number of affected categories
What to try
- Label vocabulary relationships: equivalent, broader, narrower or related
- Scope expansions by category, locale and direction
- Retire rules that solve isolated examples but create broad false positives
Resolve ambiguity with context
Some queries have more than one valid interpretation; choosing silently is still a product decision.
Ambiguity can come from language, catalogue overlap or missing context. Behavioural popularity may provide a prior, but it does not make the minority intent invalid. The interface can preserve useful branches through mixed results, suggestions, categories or clarifying controls instead of forcing one brittle interpretation.
apple
Weak readingAssumes the globally popular brand even in a catalogue that also sells groceries.
Useful readingUses catalogue and market context, preserves both credible branches and helps the shopper choose when confidence is low.
Questions to ask
- What are the credible intents in this catalogue and market?
- Which signals change the probability: category, session, locale or season?
- Can the results page expose both intents without becoming confusing?
Evidence to inspect
- Click distribution and refinements for the ambiguous query
- Previous browsing context, selected category and current market
- Abandonment after one interpretation dominates the first page
What to try
- Use confidence thresholds rather than forcing a single intent every time
- Offer category suggestions or balanced result groups where useful
- Review ambiguous high-volume queries as a distinct evaluation class
Evaluate the interpretation layer
Judge the meaning produced by the system before judging the ranked list.
Result relevance alone cannot reveal whether the system understood the query or merely produced an acceptable answer by accident. A durable evaluation records the expected entities and constraints, the system’s interpretation, candidate-set effects and final results separately.
green dress not silk
Weak readingMarks the search as successful because several green dresses appear, even though silk products dominate.
Useful readingChecks product=dress, colour=green and material exclusion=silk before reviewing candidate coverage and order.
Questions to ask
- What interpretation would a reviewer expect before seeing results?
- Which extracted parts should filter, boost, exclude or remain contextual?
- Did the right result appear for the right reason?
Evidence to inspect
- A labelled set of queries with expected entities and relationships
- Per-stage traces from raw query to filters and candidates
- Error rates by interpretation pattern, language and category
What to try
- Score entity detection and relation handling separately from ranking
- Add real production failures to a versioned regression set
- Review changes across query classes, not only the examples they target
Build interpretation as an observable layer.
The aim is not an ever-growing rule list. It is a small, explicit model of customer language that can be tested against catalogue truth and improved without hiding regressions.
- 1
Create a query grammar
List the concepts customers combine in your catalogue: product types, brands, attributes, audiences, use cases, quantities, units and exclusions. Add market-specific language.
Output: A practical taxonomy of query parts grounded in the catalogue.
- 2
Label real and deliberate queries
Sample production searches, then add probes that exercise composition, ambiguity, typos, punctuation and local inflection. Label expected entities before looking at the result page.
Output: A balanced interpretation set instead of a list of favourite examples.
- 3
Trace meaning into retrieval
Compare expected and observed tokens, entities, filters, expansions and exclusions. Then inspect how each choice changes candidate coverage.
Output: An error map connecting language failures to catalogue consequences.
- 4
Choose the least brittle intervention
Prefer improvements that generalise across a query class: cleaner attributes, scoped vocabulary, better analysis or explicit parsing. Treat one-off rules as temporary and owned.
Output: A prioritised backlog with a test, owner and rollback path for each change.
A small worksheet is enough to begin.
Capture one row per query. The discipline is separating what the customer asked for, what the system did, and what evidence would justify a change.
| Field | What to capture | Why it matters |
|---|---|---|
| Raw query | Exact text, language, market and any session context | Interpretation begins with what the system actually received. |
| Expected structure | Product, brand, attributes, constraints, context and relationships | Separates human expectation from the current implementation. |
| Observed structure | Tokens, entities, expansions, filters, exclusions and confidence | Shows precisely where meaning changed. |
| Candidate effect | Products added, removed or unexpectedly retained | Connects a language decision to a shopper-visible consequence. |
| Intervention | Data, analyser, vocabulary, parser, UI or ranking change | Points the fix at the layer that created the error. |