iMarketplace
Intent Search vs Keyword Search: Understanding Real Needs
From finding a suitcase nearby to arranging an airport journey, intent-based search turns fragmented keywords into an understanding of the user’s practical goal.
Keyword search tries to match the words a person types; intent understanding tries to identify what that person is actually trying to achieve. This changes search results by taking account of context, constraints, location and the desired outcome, rather than treating every query as a collection of isolated terms.
Keywords remain useful for precise requests such as a known product model or clothing brand. They become less reliable when real needs cross categories, use informal language or leave important details unstated.
Intent understanding is therefore not simply a more sophisticated search box. It is a different approach to discovery, particularly within an AI marketplace or conversational marketplace designed to ask questions and connect several parts of an everyday need.
Why keyword search works, and where it struggles
Traditional marketplace search has genuine strengths. Large established platforms combine familiar search habits with extensive catalogues, seller activity, category structures, filters and, in some cases, substantial liquidity. If someone knows exactly what they want, a short phrase followed by several filters can be efficient.
A query such as “Canon EOS 250D body” is comparatively easy to process because its terms identify a recognisable product. The user can then filter by price, condition, delivery method or location.
The difficulty begins when the request reflects a situation rather than a product name. This is one reason semantic search differs from filters: filters narrow known attributes, whereas semantic systems attempt to interpret meaning.
Real needs contain more than nouns
Consider this request:
I need a medium suitcase under £40, no more than five kilometres away, and I need it by tomorrow evening.
A conventional search engine may focus primarily on “medium suitcase”. Yet the distance, budget and deadline are not incidental. They determine whether the result is useful.
The user may also be open to buying second-hand, renting or asking someone to deliver the suitcase. A category-led interface often requires separate decisions before searching: choose “luggage”, decide between buying and renting, select a location radius, and perhaps open another service to organise delivery.
Intent-based search starts with the whole statement. It attempts to extract:
- the object required: a suitcase;
- suitable size: medium;
- maximum budget: £40;
- geographical limit: five kilometres;
- deadline: tomorrow evening;
- possible fulfilment methods: collection, delivery, purchase or rental.
The distinction is explored more broadly in Intention: The Second I of the iMarketplace, where intention means the outcome around which the interaction is organised.
People do not speak in catalogue language
Users may describe the same need in many ways: “cheap luggage nearby”, “a case for a four-day trip” or “something cabin-sized I can collect tonight”. Misspellings, colloquial phrases and incomplete sentences are normal.
Keyword systems can address some variation through synonyms, spelling correction and ranking models. Intent understanding goes further by considering how the different elements relate. “A case for a four-day trip” does not explicitly name a size, but it provides useful context from which the platform can ask a sensible question.
How intent understanding changes the interaction
An intent-based system normally combines language interpretation, contextual signals and dialogue. The purpose is not to pretend that the system understands everything immediately. It is to recognise uncertainty and resolve it efficiently.
It identifies entities, constraints and relationships
A request may contain products, services, places, dates, budgets, preferences and exclusions. These elements must be interpreted together.
For example:
I need a driver to the airport for four people at 5am, with enough room for three large bags.
Matching only “driver” or “airport” would produce broad results. Intent understanding recognises that vehicle capacity, collection time, passenger count, luggage and route are all connected. If the departure airport or collection address is missing, the system can ask for it.
This dialogue is central to how conversational search actually works. A useful conversational marketplace does not merely return a more attractive results page; it uses questions to turn an incomplete request into a workable one.
It distinguishes requirements from preferences
Not every detail has the same importance. “Must arrive before Friday” is a hard constraint. “Preferably blue” is usually a preference. “Near me” depends on the location being viewed and the distance the user considers reasonable.
An intent-aware system can rank exact matches first, then explain sensible alternatives. If no blue second-hand bike is available within three kilometres, it might show a black one nearby and a blue one slightly farther away. The platform should make that trade-off visible rather than quietly ignoring the original request.
It can connect several universes
Everyday plans rarely fit within one catalogue. Planning a weekend might involve accommodation, transport, an event, pet care and rented equipment. Moving into a flat could involve housing, a van, gardening help, furniture and a local craftsperson.
A multi-universe platform treats these as connected parts of one intention. This principle is examined in why universes work better together. It does not mean displaying unrelated offers in one feed; the connection must arise from the user’s stated goal.
Keyword search and intent understanding compared
| Aspect | Keyword-led search | Intent-led search | |---|---|---| | Starting point | Product or category terms | A goal expressed in ordinary language | | Main mechanism | Word matching, ranking and filters | Meaning, context, constraints and dialogue | | Best suited to | Known items and precise queries | Situational, ambiguous or multi-part needs | | Missing information | User usually adjusts terms or filters | System can ask a clarifying question | | Category boundaries | Search commonly remains within one category | Relevant results may span several universes | | Location | Often a filter applied separately | Can be interpreted as part of the request | | Alternatives | Usually ranked by catalogue relevance | Can be ranked by suitability and explained trade-offs |
The two approaches need not be mutually exclusive. Users who know exactly what they want may prefer direct search and filters. Others may benefit from conversation. The practical question is whether the platform can move appropriately between both modes, a distinction considered in Catalogue or Conversation?.
What native AI contributes
Intent understanding depends on more than attaching a chatbot to a catalogue. In an iMarketplace, AI is intended to be part of the architecture from the outset: interpreting requests, helping create listings, recommending across universes and supporting moderation.
The term iMarketplace is not yet an industry standard. It is a category WEVONE is proposing and documenting publicly. As defined here, the “i” represents Intelligence, Intention, Interaction and Individualisation.
A native AI system can maintain context across an exchange. If a user says, “I need a private tutor for my daughter”, the assistant might ask for the subject, age or level, preferred schedule, location and whether online lessons are acceptable. A later statement such as “Tuesday evenings are best” can be interpreted within the same conversation rather than as a new, isolated query.
This architectural distinction is discussed in Native AI vs Added AI. Added AI features can still be valuable, especially on platforms with mature catalogues and established user habits. The structural difference concerns how deeply interpretation and dialogue are connected to the platform’s data and workflows.
WEVONE as a practical illustration
WEVONE is one concrete, early illustration of the iMarketplace idea, not evidence that the proposed category has already prevailed. Public since 2026, it is a young platform with a few hundred registered members and is far smaller than Vinted, Leboncoin, eBay or Facebook Marketplace. Those established platforms offer considerably greater scale, habit and liquidity.
WEVONE takes a different approach by bringing several universes into one application: Tutus for second-hand goods and fashion, Nest for housing and space rental, Mission for services and local gigs, Events, and Pilote for transport and parcel delivery. Further universes are planned.
Available today, its built-in AI assistant, Mia, accepts natural-language requests such as “a black T-shirt with an eagle on it”. It also assists with listings through photo analysis, title and price suggestions, supports moderation of listings and photos, and can make cross-universe recommendations. How Mia guides users on WEVONE explains these functions in more detail.
The platform is local-first: discovery is map-based and filtered by the area the user is viewing. That matters when someone wants to sell second-hand locally, find gardening help near me or arrange a parcel journey. Availability still depends on local supply, and AI cannot create a suitable offer where none exists.
Limits and responsibilities
Intent understanding is probabilistic. The system may misunderstand irony, ambiguous wording, local terminology or an unstated priority. A user asking for a “cheap weekend rental” might mean accommodation, a car or equipment. Asking one concise question is safer than making a confident but incorrect assumption.
Privacy also matters because contextual systems may use location, conversation history and preferences. Platforms should make clear what information is being used and give users practical control over it.
Safety-sensitive requests require additional safeguards. Finding pet care, a babysitter, housing or a driver involves more than linguistic relevance. Identity, listing quality, suitability, availability and applicable platform checks remain important. AI can support review, but AI moderation and trust are broader operational responsibilities, not problems solved by search alone.
Users should also be able to inspect and correct the interpreted intent. A concise summary such as “second-hand bike, adult size, under £150, within ten kilometres” lets the user confirm that the system has understood correctly.
Conclusion
Keyword search remains efficient for known products and clearly defined categories. Its limitation is that everyday needs often contain deadlines, distances, preferences, dependencies and several possible ways to achieve the same outcome.
Intent understanding changes the result by treating the request as a goal rather than a string of words. In an iMarketplace, that interpretation can be followed by clarification, contextual ranking and connections across goods, services, housing, mobility, missions and events.
The most useful model is not necessarily the one that removes keywords or filters. It is the one that recognises when direct search is enough and when the user’s real need requires a conversation.
FAQ
What is intent-based search?
Intent-based search interprets the goal, context and constraints behind a request instead of relying only on matching keywords.
Is intent search the same as semantic search?
They overlap, but intent search is broader. Semantic search interprets meaning, while intent search may also use dialogue, location, timing, preferences and the desired outcome.
Why not simply add more filters?
Filters work well when users know which attributes matter and how the catalogue is organised. They are less convenient when a need is ambiguous, crosses categories or requires clarification.
Does an AI assistant marketplace replace the search bar?
Not necessarily. Direct search can remain useful for precise requests. Conversation is most valuable when the request is complex, incomplete or expressed in ordinary language.
Can intent understanding guarantee relevant results?
No. Relevance depends on correct interpretation and the availability and quality of suitable offers. The system should disclose uncertainty and allow users to revise the interpreted request.
Is an iMarketplace an established platform category?
No. It is a category WEVONE is proposing. As defined here, it describes a native-AI, conversational and multi-universe platform organised around intentions rather than categories.
Further reading
- Why AI Changes Everything for a Marketplace — how AI affects discovery, assistance and marketplace operations.
- Search Bars vs Assistants — a direct comparison of two ways to begin a marketplace journey.
- I Am Looking for a Suitcase — a practical example involving location, budget and timing.
- The Four I of the iMarketplace — an introduction to Intelligence, Intention, Interaction and Individualisation.