Deconstructing E-Commerce Search: The 12 Query Types

This is the first in a series of articles on e-commerce search that draw on findings from our recent search usability report and benchmark.

In this article we’ll introduce 12 types of search queries identified during our large-scale usability study of e-commerce search. While not exhaustive they reflect the main types of queries that users rely on when searching in an e-commerce context.

During the usability study, the test subjects were observed to rely heavily on e-commerce search queries that included a theme, feature, relation, or symptom – yet most of 19 tested sites had poor support for these query types. Even among the 50 e-commerce giants we’ve benchmarked the support for most query types is meager at best, as should be evident from the graph above.

These benchmark results reveal surprisingly dismal support for essential e-commerce search query types. For example, among the top 50 grossing US e-commerce sites:

  • 16% of the e-commerce sites do not support that users search by product names (which appear on the product page).
  • 18% handle phonetic misspellings so poorly that users will have to pass a spelling test to be presented with results (e.g. 0 results for “Kitchen Aid Artysan” when looking for the “KitchenAid Artisan” mixer).
  • 70% require users to search by the exact same product type jargon the site uses, failing to return relevant products for a search such as “blow dryer” if “hair dryer” is used on the site, or “multifunction printer” vs “all-in-one printer”.
  • 22% of the sites don’t support search queries for a color variation (despite the product searched for being available in multiple colors).
  • 60% don’t support thematic search queries such as “spring jacket” or “office chair”.
  • 84% don’t handle queries that specify a subjective qualifier, such as “cheap” or “high quality”.
  • 60% don’t support symbols and abbreviations, resulting in users missing out on perfectly relevant products if searching for inch when the site has used or in.

In this article, we’ll go over each of 12 query types of e-commerce search – with plenty of query samples, tips on how to best support each query type, and examples from the test sessions.

Note: This is the longest article we’ve published to date – a cup of coffee is advised. You may also download the article as a PDF or ePub.

Deconstructing the Search Query: Spectrum, Qualifiers, and Structure

When users search in an e-commerce context, they are mostly looking for products. This prompts users to search differently than they do when performing generic web searches. In particular, users will often include one or more criteria in their search which the product must meet.

The test subjects would commonly combine the 12 query types when devising their search queries, with certain components of the query “setting the range” of the search while other components are included to refine and delimit that range. Indeed, the 12 query types may be divided into 3 functional groups that map to those intents:

  • Query Spectrum, i.e. “setting the search range” – The query spectrum defines the range of the search, specifying the domain of products that are of interest. It thus provides the base of the search query.
  • Query Qualifiers, i.e “delineating the search boundaries” – Query qualifiers are used to refine the boundaries of the query spectrum by specifying various conditions that the products should meet.
  • Query Structure, i.e. “constructing the query” – The structure of the query determines how it should be interpreted by the search engine and includes the syntax and context of the query.

Here one of the test subjects has searched for ‘sleeves 11”’ when wanting to find a computer bag for her 11” laptop. Notice how ‘sleeves’ represent the Query Spectrum by specifying the domain of products that should be searched (i.e. laptop sleeves), while ‘11”’ is a Query Qualifier used to refine which laptop sleeves that should be returned (i.e. only ones that fit an 11” laptop). Finally, the Query Structure imply that it is “laptop” sleeves in 11-inch sizes that the user is interested in.

In short, the Query Spectrum is the user’s ways of “setting the search range”, and they then use Query Qualifiers to “delineate the boundaries” of that range, while the Query Structure determines the syntax and context of the query.

Keep these different functional aspects of the 12 query types in mind as you read through each of them below, as it will help you better understand how users approach search on e-commerce sites. By deconstructing the functional aspect of each query type, its role in the user’s query as a whole becomes clearer, which can be immensely helpful when looking to design search logic and interfaces that align with user behavior and expectations.

I) Query Spectrum – “Setting the Search Range”

Users rely on the query spectrum to indicate the range of what should be searched. Sometimes users want to see a broad collection of products, in which case they will typically set a wide Query Spectrum by, for example, submitting a generic #2 Product Type query such as “Laptops”. Other times users are looking for something very specific, and will therefore define a very narrow Query Spectrum, typically in the form of an #1 Exact Search like “Grado Prestige SR325” (a pair headphones).

The query spectrum is the user’s way of “setting the search range” and includes 4 query types:

#1. Exact Searches
#2. Product Type Searches
#3. Symptom Searches
#4. Non-Product Searches

#1. Exact Searches

When users know the exact product they are looking for, they will typically rely on #1 Exact Search, entering the product’s title or model number, such as “Keurig 45” (a coffee maker).

While this may at first seem like an easy case of keyword matching against those two product attributes, the search engine must be a little smarter than that. For instance, good handling of phonetic misspellings is crucial since the user may only have heard the product title spoken and not know how to spell it, e.g. “Keurick 45”.

Furthermore, some products have alternative titles, such as Nestlé Quik vs Nesquik or AT&T Wireless vs Cingular Wireless vs AT&T Mobility – all of which should invoke their respective product. This is particularly important for global e-commerce sites where products may be localized, such as movies that are called one thing in the US and another in Germany and something entirely else in Argentina.

Another reason it’s important to support local and alternate product titles in addition to phonetic misspellings is that users often don’t type out the product title themselves. During testing, the subjects were often observed to copy-paste product titles from external sites into the search field. Any misspellings (common when copy-pasted from user-generated content, such as social media posts), or localized or alternate spellings (common when copy-pasted from industry databases, such as IMDb, Goodreads, CarQuery, etc), will therefore be pasted into the search and must therefore be handled gracefully to provide a good search experience.

Acquiring all these local and alternate spellings can prove quite the challenge and vendors may not necessarily input this data on their own. Partnering with relevant industry databases can therefore be a good way to acquire this product information – especially if they are public and users are copy-pasting from them in the first place.

Great support for #1 Exact Searches proved crucial during testing, as the test subjects were observed to quickly conclude that a site didn’t carry the product if it didn’t show up for a request as specific as a model name or number (as opposed to more open-ended queries, such as #2 Product Type Searches). Yet, of the benchmarked top 50 grossing US e-commerce sites, we found that only 66% are capable of producing decent results for #1 Exact Searches; with 16% being incapable of searching by product names which appear on the product page (like Kohl’s example above) and 18% handling misspellings so poorly that Exact queries are significantly hampered (e.g. 0 results for “Kitchen Aid Artysan” when looking for the “KitchenAid Artisan”). In other words, one third of the top 50 grossing US e-commerce sites don’t fully support “simple” Exact Searches.

#2. Product Type Searches

“I had expected some cameras to appear,” a test subject muttered after searching for “cameras” on Tesco. She had initially tried finding the category via the site’s main navigation, but when she couldn’t spot it, she tried searching for the product type instead – but to no avail, as Tesco’s search engine clearly doesn’t support Product Type searches.

When users aren’t looking for a specific product but rather a type of product, they will rely on #2 Product Type Searches, querying for a whole category of products, such as “Sandals”. When used on their own, product type searches are generally an attempt by the user to quickly access a category on the site – either because it’s more convenient to search for it or because they are having difficulties finding the category on the site.

A very important aspect of supporting #2 Product Type Searches is to return relevant results regardless of whether the searched-for product type exists as a category on the site or not. This not only requires detailed categorization and labelling of products, but also proper handling of synonyms and alternate spellings of those groupings. A search for “t-shirt” should yield the exact same results as one for “tee shirt”, regardless of how it happens to be written in each product’s title or description. Other examples include “hair dryer” where the user might search for “blow dryer”, or users may type “multifunction printer” or even “copy machine” when looking for an “all-in-one printer”.

From a user’s point of view these everyday descriptions are just as correct as the industry jargon, and most of the test subjects never thought of trying another synonym but instead simply assumed that 0 results for a search such as “copy machine” meant the site didn’t carry such products. Despite the severe impact on the user’s search experience 70% of the major e-commerce sites do not return all the relevant results, if any at all, when users search by a synonym, e.g. “blow dryer” instead of “hair dryer”.

Since #2 Product Type Searches are performed by users who are looking to browse a whole category of products, it’s crucial that such queries enable relevant filtering and sorting options so the user can easily narrow down the list and compare products. Ideally such filters and sorting options are available directly from the search results (via faceted search filters), although an acceptable alternative is to guide users towards a relevant category scope where such options are available.

#3. Symptom Searches

On Chemist Direct, a test subject searched for “dry cough” only to have hand cream, lip balm, and deodorant returned. Clearly, Chemist Direct’s search engine doesn’t support Symptom searches and instead returns any item with “dry” in the description.

As we’ve seen thus far, when users know the specific product they are looking for, they will use Exact search. And if they don’t know the exact product or aren’t sure about which one they want, they will rely on Product Type searches. However, sometimes users don’t even know the type of product they are looking for – all they know is the problem which they are experiencing and that they want a solution to it. In these cases, they will rely on #3 Symptom Searches, entering the problem they are experiencing, such as “stained rug” or “dry cough”, in hopes of being presented with viable solutions and products to this problem.

Symptom search is important because it will often be the user’s last recourse. If users don’t know what solution to look for and can’t search for products by entering their problem or symptom, it’s going to be awfully difficult for them to find a relevant product on the site. This is especially true if categories on the site aren’t problem- or symptom-based (which they often aren’t).

Integrating or interlinking any help guides available on the site directly on the search results page is essential too, so that users can learn more about the differences between the different solutions available. Although Symptom searches won’t be applicable to every e-commerce industry, they are vital to some, such as drugstores, health & beauty, tools & supplies, cleaning & housekeeping, etc. For sites where Symptom searches are particularly important, it may be a good idea to suggest its usage in the placeholder text of the search field to let users know that they can search by symptom as it isn’t all users who think of it.

#4. Non-Product Searches

When the test subjects made searches such as “return items” on Amazon, they were greeted by a short one-line description of Amazon’s return policy along with a set of links to relevant help sections.

The final type of Query Spectrum is #4 Non-Product Searches, where the user is searching for something that isn’t a product, such as the return policy or shipping information. While the primary function of search in an e-commerce context is obviously to find relevant products, the search engine shouldn’t be limited to just searching the product catalog, as users will sometimes be looking for other “non-product” content too (help guides, company information, etc).

During testing the subjects would often search for this type of auxiliary content when they had difficulties finding navigational links to it. This is a logical consequence of the content being secondary, and links to it therefore tend to be relegated to the page footer or nested deep within help sections.

Supporting #4 Non-Product Searches enables users to quickly and easily find this information without having to hunt around the site for it. In practice, support for non-product queries is widespread, with 86% of the e-commerce sites either taking the user directly to the relevant page for a search such as “return policy” or presenting the page as a top search result.

‘Query Spectrum’ Summary

With the Query Spectrum, the user indicates the “range” of what should be searched.

Depending on their particular needs and available information, this can go from highly specific #1 Exact Searches, to broader #2 Product Type Searches, to the inquiry-like #3 Symptom Searches. Finally, users may be looking for non-product pages, in which case they will perform a #4 Non-Product Search.

A summary of the 4 query spectrums can be found in the table below:

I) Query Spectrum
Used to indicate the range of what should be searched
#1. Exact Search
“Keurig K45”
Searching for specific products by title
#2. Product Type Search
Searching for groups or whole categories of products
#3. Symptom Search
“Stained rug”
Searching for products by querying for the problem they must solve
#4. Non-Product Search
“Return policy”
Searching for help pages, company information, and other non-product pages

II) Query Qualifiers – “Delineating the Search Boundaries”

Users rely on query qualifiers to refine and delimit the boundaries of the Query Spectrum. These qualifiers are typically used when the user has a set of criteria that they want the product to meet. For example, the user may try to limit the type of TVs returned by submitting a #5 Feature query such as “Plasma TV” or perform a #8 Compatibility search like “Lens for Nikon D7000” to filter out any lenses incompatible with their camera.

Query qualifiers are the user’s way of “delineating the search boundaries” and includes 5 query types:

#5. Feature Searches
#6. Thematic Searches
#7. Relational Searches
#8. Compatibility Searches
#9. Subjective Searches

#5. Feature Searches

On Hayneedle, searching for “manual espresso machine” sends the user to an “Espresso Machines” category with a “Manual Espresso Machines” filter applied, resulting in a list of highly relevant search results.

Users often have a set of criteria that they want the product to meet, and very often these criteria relate to features of the product. #5 Feature Searches is when the user includes one or more features in their search query that they want the product to have. For example, a user may not want just any “jacket” but will often be looking for something slightly more specific such as a “leather jacket”, or a “red vase” rather than simply a “vase”.

The term “Features” should be understood in a rather broad sense referring to any type of product aspect or attribute. Features can thus be the product’s color (“red dresses”), material (“fabric sofas”), performance specs (“100000 IOPS hard drive”), or format (“Hobbit DVD”), not to mention price (“$100-$200 backpacks”) or brand (“Nike running shoes”). The list goes on, and all significant attributes should be searchable, even if they don’t apply to all products on the site. For example, even if all products on the site don’t have a “format” attribute, movies on the site should still be searchable by it.

During testing, #5 Feature Searches were the by far most common Query Qualifier, making it a definite “must have” of the 12 Query Types. Among the top e-commerce sites 46% support that users search by a wide range of features (e.g. color, material, brand), while 32% only have proper support for color searches, with the remaining 22% not even supporting color searches (for the products in multiple color variations).

In terms of implementation, the ideal solution is to dynamically apply the features searched for as filters on the results page, as this increases transparency and user control – with the user being able to see what is and isn’t included and being able to quickly toggle related filters on/off. For instance, in the above Hayneedle example, the “Manual” aspect of the “Manual Espresso Machine” query is applied as a filter, with the user being able to see and toggle the other available types of espresso machines (semi-automatic, stove top, etc).

#6. Thematic Searches

A test subject searching for “spring jacket” on Gilt, was awarded with zero results, jovially commenting, “That wasn’t exactly impressive. Haha. It didn’t give me a damn thing.”

What exactly constitutes a “living room rug” or an “extreme weather sleeping bag”? While these are certainly concepts we can easily recognize, defining their exact boundaries can be a challenge. #6 Thematic Searches are often a little difficult to define because they are inherently vague in nature – they often include fuzzy boundaries (e.g., “living room”) or categories of intended usage (e.g., “spring”, “cold weather”). Nonetheless, they are very real notions to users who – in certain industries such as apparel – include thematic qualifiers liberally in their searches.

A great deal of interpretation is generally required to support Thematic searches, both in terms of the meaning of the actual query itself but also in the internal tagging of products, as it’s vital that a query for e.g. “spring jacket” presents all the relevant products, not just the handful of products which happen to have those keywords in their title or description. This will often require some sort of thematic tagging of the product catalog to determine, e.g. which jackets would be suitable for spring (and which wouldn’t). Meanwhile, a search for a “Mother’s Day bouquet” requires products to be tagged with an occasion (a social concept). Despite thematic product browsing being a common browsing pattern and product arrangement in physical retail, 60% of the top e-commerce sites do not support thematic search queries.

Typical Thematic searches include seasons (e.g., “spring”), intended usage (e.g., “office” or “outdoors”), occasions (e.g., “birthday” or “wedding”), events (e.g., “Olympics” or “NBA”), etc. Unsurprisingly, these more or less map to thematic categories, and they may therefore even have their own custom category pages. This is yet another case where good product categorization and labelling will get you half the way there.

#7. Relational Searches

Here a test subject has searched for “Steven Spielberg” to get a list of the movies he’s been involved with – luckily, Amazon supports relational searches and were able to present the user with a highly relevant list of movies by the prolific movieman. (Notice how the user is also presented with a list of related directors to switch between in the sidebar.)

Sometimes users care more about the people affiliated with a product than the product itself. This is especially true of entertainment products such as books, music and movies, although it extends beyond these to other domains such designer items (furniture, jewelry, etc). In these cases, users will often rely on #7 Relational Searches, where they enter the name of entities involved with or related to the product.

In some cases, users will also add an additional “role” qualifier to their #7 Relational Search, specifying the nature of the entity’s relationship to the product. For example, searching for “James Franco” could meaningfully bring up the books he’s authored, the blockbuster movies he’s acted in, or the art films he’s directed – meanwhile, the user likely had only one of those product types in mind.

#7 Relational Search is the Query Qualifier that is most commonly submitted as a standalone query. However, this is typically because the person is only known for one thing (or the user only knows them for one body of work) and the Query Spectrum is therefore #11 Implicit – the user takes it for granted that movies are going to show up when they search for “Tom Hanks”.

#8. Compatibility Searches

Here a test subject has searched for “charger lenovo ideapad yoga” in hope of finding a new power adapter for her Lenovo IdeaPad Yoga laptop. Unfortunately, Best Buy doesn’t support compatibility searches, and so instead of returning “chargers” (i.e. power adapters) the site returns a bunch of Lenovo IdeaPad laptops.

Users often don’t know the name of the accessory or spare part they need – instead they know the details of the product they already own. It’s therefore not uncommon to see users perform #8 Compatibility Searches where they input the name or brand of a product they own along with the type of accessory or spare part they are looking for, such as “sony cybershot camera case”.

Compatibility search is similar to #7 Relational Searches, except it requires strict compliance – it’s two or more products that must work together, with the user trying to find products that are specifically compatible with a product they already own (or are about to buy).

Users who know the exact model of their product will typically submit this, and #8 Compatibility Searches should therefore obviously work with product models. In fact, sometimes compatibility can only be ensured if the exact product model is provided. However, users don’t always know or recall their specific product model, and support for more generic product types and brand names is therefore important as well, so that users can enter generic queries like “13in laptop sleeve” rather than specifying the exact laptop they own. Generic compatibility queries are among the most supported query types, with 62% of the sites that sell compatibility items supporting basic compatibility queries.

Integration with product finders and help content is often a good idea, especially for more generic queries that don’t include sufficient information to fully determine compatibility.

#9. Subjective Searches

Like 84% of the major e-commerce sites, Wayfair doesn’t support subjective qualifiers, as is evident from this search for “high-quality kettle” which returns items with either no or poor ratings. This is despite Wayfair having plenty of kettles with 4.5+ star averages and numerous reviews, and while the first two results aren’t cheap, they are far from Wayfair’s most expensive kettles.

What exactly constitutes a “high-quality” product? Or a “nice-looking” or “cheap” one? Answers to such questions will necessarily be subjective in nature, yet these are exactly the types of qualifiers that some users have in mind when looking for products – and it’s therefore not uncommon for users to perform such #9 Subjective Searches.

When dealing with subjective qualifiers, the site must often try to approximate the user’s intent by using one or more attributes as a proxy for the subjective term(s). For example, if presented with the earlier #9 Subjective Search for “high-quality kettle”, one could reasonably favor products with high scores across a wide range of product attributes, such as user reviews, number of sales, and price, and use those to calculate the most relevant matches. Similarly, if a user wants to find a “cheap wine”, one could compute the total price range for “wine” and then select the bottom 15% (i.e., the cheapest) of those bottles. Or the search could simply return the “wine” category sorted by price.

Taste-based #9 Subjective Searches are by far the trickiest to program a response to. How do you programmatically identify “nice-looking” products? While, in some cases, there won’t be any good ways to answer such questions, there are some valid solutions to certain types of taste-based queries. For example, if a user searches for “beautiful tables” on a furniture site, it’s true that “beautiful” may be difficult to pinpoint, but as a response the user could be asked to select from different styles of tables available (modern, antiques, glass, Asian, etc). In effect, asking the user to self-select what “beautiful” means to them.

A good way to identify an attribute that may serve as a useful proxy for a given taste-preference is to deconstruct what the taste is really about. In the case of “beautiful”, we’re dealing with aesthetics, and any product attributes related to the product’s aesthetic may therefore be viable proxies. We can see how this works for “delicious” too. Say a user searches for “delicious snacks”. While “delicious” is very subjective to each individual user, it has to do with flavor, and the user could therefore be asked to identify the type of flavor they are interested in (sweet, savory, salty, etc).

Despite subjective qualifiers often being vital to the user’s purchase decision the vast majority of the top grossing e-commerce sites (84% to be exact) don’t handle queries that specify even a basic subjective qualifier such as “cheap”.

‘Query Qualifiers’ Summary

With Query Qualifiers, the user refines the boundaries of the Query Spectrum range by including various conditions that the products must meet.

Query Qualifiers almost never make sense as standalone queries and therefore tends to be combined with a Query Spectrum (with the possible exceptions being #6 Thematic and #7 Relational searches).

Depending on the user’s approach and knowledge about the product domain, they may specify certain #5 Features that the product must have, or describe a #6 Thematic context in which it must be used. Users may similarly try to find products by their #7 Relation to other objects, or define technical #8 Compatibility requirements. Finally, some users will inject #9 Subjective criteria that must be met (or approximated).

While especially thematic, compatibility and subjective searches are somewhat “advanced” query types from a technical perspective, they are trivial requests in physical retail (“cheap spring jacket” or “nice leather case for my Nikon camera”) and were used frequently by the subjects during testing.

A summary of the 5 query qualifiers can be found in the table below:

II) Query Qualifiers
Used to delimit the Query Spectrum, specifying conditions for what should and/or shouldn’t be included
#5. Feature Search
“Waterproof cameras”
Searching for products with specific attributes or features
#6. Thematic Search
“Living room rug”
Searching for categories or concepts that are vague in nature or have “fuzzy” boundaries
#7. Relational Search
“Movies starring Tom Hanks”
Searching for products by their affiliation with another object
#8. Compatibility Search
“Lenses for Nikon D7000”
Searching for products by their compatibility with another item
#9. Subjective Search
“High-quality kettles”
Searching for products using non-objective qualifiers

III) Query Structure – “Constructing the Query”

The structure of the query determines how it should be interpreted by the search engine. It involves both the linguistic syntax of the query and the circumstances under which it was conceived.

For instance, users may take certain aspects of their search for granted and leave them out of their query, resulting in #11 Implicit Searches such as “Pants” when what the user is really interested in is “Women’s Pants”. The syntax of the user’s query can be highly important too, with a symbol such as ‘-‘ taking on significantly different meanings and functions in #10 Slang, Abbreviation, and Symbol Searches like “$10-100 sleeping bags” and “-10 deg. sleeping bags”.

The query structure deals with how the query is constructed – the context in which it was written and the syntax of the query itself – and includes 3 query types:

#10. Slang, Abbreviation, and Symbol Searches
#11. Implicit Searches
#12. Natural Language Searches

#10. Slang, Abbreviation, and Symbol Searches

Users rely on a wide range of linguistic shortcuts when they search. This quickly became evident during testing as several of the subjects frequently relied on #10 Slang, Abbreviation, and Symbol Searches, writing slang-based queries such as “RayBan shades”, or including abbreviations like “13in laptop sleeve”, or relying on symbols such as “sleeping bag -5 degrees”.

Slang and abbreviations are by far the easiest to support technically as it essentially just requires mapping between different terms, pairing slang words like “kicks” with “shoes” and “fixie” with “fixed-gear bike”; similarly abbreviations must be mapped so “ml” pairs up with “millilitre” and “HP” with “Hewlett-Packard”.

Symbols can prove a little tricker since they may act as more than mere synonyms and may change meaning depending on the word arrangement of the query. For example, the “-“ symbol could be used to denote both a minus (e.g., “sleeping bag for -10 deg.”) and a range (e.g., “sweaters $50-$100”). In these instances, not only does the meaning of the symbol change, but the symbol also acts as a filtering instruction.

When benchmarking the top 50 sites, we tested perhaps the most simple size-related symbol search possible – inch versus the character – yet a whopping 60% of the e-commerce sites showed different results depending on whether a symbol, text or abbreviation was used. In other words, on 60% of the top grossing US e-commerce sites, users will miss out on perfectly relevant products because they search for either inch, or in.

#11. Implicit Searches

Here a test subject simply searched for “adventure” without including “action figure”, even though it was this particular type of toy she was looking for. The Entertainer could have inferred this implicit component of the user’s query from the category page where she conducted the search as well as the many previous product pages she had visited during this session on the site.

From time to time, users will leave out certain aspects of their search query. The omission is often not a conscious decision, but rather happens because the user takes the aspect for granted due to their current context or frame of mind. Dealing with such #11 Implicit Searches requires the site to make use of all available environmental data in order to accurately infer any implied aspects of the user’s query.

The most obvious variable is the page the user searches from – for example, if a user is in a “Women’s Dresses” category and searches for “pants”, it is reasonable to assume that the user is looking for women’s pants and not men’s or children’s pants. Other such variables include past pages the user has visited on the site, products in the user’s shopping cart, demographic information (either approximated or from any available account data), purchase history, how the user entered the site, duration since last visit, duration of current visit, and so on. Of course, if the user has an account and is signed in, information from their profile may also be used to inform #11 Implicit Searches.

Once an implied component has been detected, there are a few ways the search experience may be altered. One approach is to bias the search results towards the implied aspects – following our earlier example, the site may bias pants from the women’s scope when a search is performed from one of the women’s clothing categories. This makes for a very seamless user experience although it lacks transparency. Alternatively, continuing our women’s pants example, the results page may suggest relevant search scopes or query clarifications, such as “Did you mean ‘women’s pants’?”

Finally, in the case of a very high confidence in the user’s intent, the site may go as far as auto-refining the user’s search query – that is, the site auto-corrects the user’s query to include the implied component(s). In this scenario, it’s extremely important to state the change very clearly to the user and offer them a way to “force” through their original query, so the auto-correction doesn’t become restrictive.

#12. Natural Language Searches

Being able to enter search queries using everyday sentences, such as “Photos of my friends in New York”, give users an incredibly simple and straight-forward way to perform highly advanced searches.

#12 Natural Language Search is when a user submits a query that uses regular spoken language. Ideally, the search engine is able to interpret the meaning of this query and return highly relevant results, going well beyond simple keyword matching.

At its core, Natural Language search is about understanding the semantics, context, and relationships of the query, rather than approaching the search query as a simple set of keywords. When done right, this allows the user to articulate a question or request, such as “women’s shoes that are red and available in size 7.5”, and ideally this returns a list of red women’s shoes in size 7.5.

What’s striking here is how complex that query actually is when you break it down – it includes filters for the category (“women”), product type (“shoes”), and two types of product variations (“red” and “size 7.5”). Normally, applying all these filters would require a fairly advanced interface and lots of clicking on part of the user – yet with #12 Natural Language Search, the interface is as basic as it gets: just say what you want and you’ll get it. (In fact, with the increasing support for voice input the query may literally be spoken.)

While Natural Language searches are still far from being commonplace, recent years have shown increasing application. Google’s search, Apple’s Siri, and Facebook’s Graph Search, are perhaps some of the most well-known cases. These companies have upped the ante and can properly interpret a wide range of Natural Language queries and offer the user a meaningful response in return.

‘Query Structure’ Summary

The Query Structure deals with how the user has put together their query, and consequently how it should be interpreted by the search engine. It’s about the syntax of the query and the context in which it was written. For instance, the user may apply various linguistic shortcuts in the form of #10 Slang, Abbreviations, and Symbols when they devise their search query. Other times, users may leave certain parts of their query #11 Implicit, typically because they take it for granted given their current context.

Finally, as online search matures and voice input proliferates, #12 Natural Language searches will grow increasingly common – requiring search engines to take on a new level of linguistic intelligence but potentially also helping e-commerce sites approximate the level of support offered in physical retail outlets by human salespeople.

A summary of the 3 query structures can be found in the table below:

III) Query Structure
How the query is constructed by the user and interpreted by the search engine
#10. Slang, Abbreviation, and Symbol Search
“Sleeping bag -10 deg.”
Searching for products using various linguistic shortcuts
#11. Implicit Search
“[Women’s] Pants”
Forgetting to include certain qualifiers in the search query due to one’s current frame of mind
#12. Natural Language Search
“Women’s shoes that are red and available in size 7.5”
Searching in full sentences rather than bundles of keywords

Improving Support for the 12 Query Types

After testing 19 major sites and auditing the search experience of the 50 top grossing US e-commerce sites, we can confidently say that support for the 12 query types presented in this article is lackluster at best.

Let’s take another look at the graph presented earlier to see the level of support for each query type. (Note: #11 Implicit and #12 Natural Language Search were omitted as support for these query types couldn’t be reliably tested across different sites and industries.)

In the free, publicly available part of the E-Commerce Search Usability benchmark database you can also see how each of the 50 major e-commerce sites ranks when benchmarked on their entire search experience (and not just their query support).

When e-commerce sites with millions of dollars in revenue show this low level of support for essential query types such as #2 Product Type and #7 Relational searches, you know the current state of e-commerce search is dire. And since e-commerce search engines are nearly always reused across platforms (different interfaces accessing the same search engine API), query support will be similarly poor on tablet and mobile sites / apps too.

The good news is that this means plenty of opportunity to rise above the competition. Creating a (comparatively-speaking) superior search experience only requires proper support of 6-7 query types. In fact, supporting the right handful of the most essential query types is enough to create a decent search experience. We recommend that you start out by making sure that your search engine supports these 5 essential query types: #1 Exact, #2 Product Type, #5 Feature, #6 Thematic, and #7 Relational Searches (where applicable). Users can get by with basic e-commerce searches when these 5 query types are support. Conversely, failing to support any of these core query types will result in a defective search experience.

To create a truly great search experience, 8-10 of the query types must be supported. This is not done overnight and often requires more than simply investing in good search logic – detailed and structured product data is often just as important. The good news is that the investments can pay significant dividends as users begin finding (and thus are able to buy) the products they are looking for. Also, since the same search engine tends to be accessed by all platforms, any investments will typically pay off universally across those platforms – improving the search experience of your e-commerce desktop website and native mobile apps alike.

During testing we observed how the test subjects were greatly influenced by prior experience with the site. If they had previously had success searching for something on the site, they were much more likely to use search on that site even if they generally preferred category navigation. And vice-versa: prior poor search experiences steered otherwise search-happy subjects towards category navigation. Thus, not investing in good search usability can not only cost sales in the short- and mid-term, it can also set flawed user expectations for future use of your site. Expectations which can be difficult to shake off even if the search experience is eventually improved down the road.

We therefore urge e-commerce owners not to post-pone investing in improvements to their e-commerce search experience, lest they be haunted by faulty user perceptions for years to come. Instead, take advantage of the dismal state of e-commerce search and turn it into a competitive advantage.

It’s time to improve the state of e-commerce search – and that starts by improving your search engine logic with support for the 12 query types:

I) Query Spectrum
Used to indicate the range of what should be searched
Query Type User behavior How you can support it
#1. Exact Search
“Keurig K45”
Searching for specific products by title Basic keyword matching, along with support for multiple title variations and intelligent handling of misspellings
#2. Product Type Search
Searching for groups or whole categories of products Support for synonyms as well as categories that aren’t part of the site’s navigation / hierarchy
#3. Symptom Search
“Stained rug”
Searching for products by querying for the problem they must solve Symptom database mapping “symptoms” to “cures” (i.e. problems to solutions)
#4. Non-Product Search
“Return policy”
Searching for help pages, company information, and other non-product pages Search engine must index the entire website, not just products
II) Query Qualifiers
Used to delimit the Query Spectrum, specifying conditions for what should and/or shouldn’t be included
Query Type User behavior How you can support it
#5. Feature Search
“Waterproof cameras”
Searching for products with specific attributes or features Intelligent parsing of product specifications (i.e. structured product data)
#6. Thematic Search
“Living room rug”
Searching for categories or concepts that are vague in nature or have “fuzzy” boundaries Interpretive labelling of products and categories
#7. Relational Search
“Movies starring Tom Hanks”
Searching for products by their affiliation with another object Association data linking products and objects, ideally specifying the nature of the relationship too
#8. Compatibility Search
“Lenses for Nikon D7000”
Searching for products by their compatibility with another item Compatibility database mapping compatible products to one another
#9. Subjective Search
“High-quality kettles”
Searching for products using non-objective qualifiers Handling of quantifiable single-attribute degrees (e.g. “cheap”), quantifiable but multi-attribute mix (“value for money”), and tasted-based (“delicious”) qualifiers
III) Query Structure
How the query is constructed by the user and interpreted by the search engine
Query Type User behavior How you can support it
#10. Slang, Abbreviation, and Symbol Search
“Sleeping bag -10 deg.”
Searching for products using various linguistic shortcuts Synonym mapping of slangs, abbreviations, and symbols, as well as interpretation of symbol intent (ranges, modifiers, etc)
#11. Implicit Search
“[Women’s] Pants”
Forgetting to include certain qualifiers in the search query due to one’s current frame of mind All available environmental variables must be used to infer any implicit aspects of the user’s query
#12. Natural Language Search
“Women’s shoes that are red and available in size 7.5”
Searching in full sentences rather than bundles of keywords Intelligent parsing and deconstruction of the user’s query

This article presents the research findings from just one of the chapters in our On-Site Search study — get full access to learn more about the other findings required to create a “State of the Art” on-site e-commerce search experience.

Post a comment or Share:

User experience research, delivered twice a month

Join 17,000+ readers and get Baymard’s research articles by RSS feed or e-mail:

Due to spam, you need JavaScript to do that.

(1-click unsubscribe at any time)

Article Series

  1. Deconstructing E-Commerce Search: The 12 Query Types
  2. 8 Design Patterns for Autocomplete Suggestions
  3. E-Commerce Sites Should Include Contextual Search Snippets (96% Get it Wrong)
  4. E-Commerce Search Field Design and Its Implications
  5. E-Commerce Sites Need Multiple of These 5 ‘Search Scope’ Features
  6. Faceted Sorting - A New Way of Sorting Search Results

Related articles

More ‘On-Site Search’ Research

Free Research Content:

Products & Services:

All Research Topics

richard thomas June 18, 2014 Reply to this comment

thx for the post – really interesting article – never fails to amaze me how big online brands don’t pay attention to what users want

Jamie, Baymard Institute June 18, 2014 Reply to this comment

Thanks Richard, much appreciated. And hopefully we will see more of the big online brands paying closer attention to their users’ wants and search experience going forward..

Guy Sir Dude June 23, 2014 Reply to this comment

This is a really helpful article. Much better than overly scientific researches. Did you consider writing a follow up article on how different eCommerce software products handle these queries?

Andrew June 23, 2014 Reply to this comment

I think the key point here is the non-product information. A lot of ecommerce searches only show products, and never show vital information like returns or contact us pages

Pallav Tandon June 23, 2014 Reply to this comment

Great article. What you demonstrated is a huge issue as you have rightly pointed out. My team did some research in the same area and had similar findings. Common queries such as “gift for dads” or “pregnancy coats” on large online retailers are not still supported.
It will be great to know from you your opinion on how you see the solution and technologies such as natural language search and text analytics playing in this area.

Jamie, Baymard Institute June 24, 2014 Reply to this comment

Thanks Pallav,

This is the first in a series of articles on e-commerce search, so we’ll definitely be sharing more on search design and solutions in the near future.

Natural language search will have a major role going forward, especially as more and more people use an even wider range of devices, many of which prominently feature voice input. Furthermore services from Google, Apple, and other major players, will gradually “teach” users to search this way, so users will increasingly come to expect natural language queries to be supported. It won’t happen overnight but I definitely think this is where we are heading.

Text analytics already plays a major role in search and will continue to do so. Especially in terms of parsing and interpreting unstructured product information (anything from product descriptions and features to user reviews and even external 3rd party content).

Lee Reynolds June 24, 2014 Reply to this comment

Very interesting article…though I’m curious about the implementation…for example if you have a simple Product table how best would it be structured or enhanced to support searches, do you have a field in the table with possible keywords for each product?

And similarly how would the SQL queries work? For example would you first query on the easy stuff (name, ID, description), then perform a second query for more obscure results? And integrating phonetic variations, I don’t know but it sounds like the DB would have a meltdown…

Jamie, Baymard Institute June 24, 2014 Reply to this comment

Hi Lee,

SQL is designed for structured parsing and traversing of tabulated content, making it ideal for a relational database management system. Search is a very different beast, so while your search engine may integrate with your SQL database (to grab content from it), you’ll definitely want to have a dedicated search database / index that is designed to handle the types of queries outlined in this article.

Jonathan June 25, 2014 Reply to this comment

Very insightful. Thanks.

Peter Rieger June 25, 2014 Reply to this comment

Thanks for the interesting post. I appreciate your efforts to bring some light into the darkness, which site search still is for many online shop operators. What I’m missing is some quantification of the actual occurrences of query types. In my experience up to 30% to 50% of actual queries are brand searches, which you don’t treat separately (why?). Spending a lot of effort to support eg compatibility searches might be the wrong step to improve search experience in a shop, if only less than 1% of queries actual are of this type.

Jamie, Baymard Institute June 25, 2014 Reply to this comment

Hi Peter,

Query type occurrence will tend to be rather site-specific (or at least industry-specific) and therefore doesn’t make a lot of sense to touch upon in a general overview such as this one. But I wholly agree with your general sentiment, that one should evaluate the individual query types and their relevance to one’s site and audience to determine which queries are the most important to support first.

With regards to “Brand searches”, this is covered in the article under #5 Feature Searches, which include brand (among many other product “attributes”).

Joana_JW June 30, 2014 Reply to this comment

My goodness, I never knew this much about the E-Commerce Search. I think most of the E-Commerce business strives for only ‘keyword oriented search’. There understanding lacks the other detailed aspect of searching. Thanks for sharing complete insight and thorough information. This is excellent.

Jamie, Baymard Institute June 30, 2014 Reply to this comment

Thank you very much for the kind words Joana – we’re happy you found it useful!

Ryan July 8, 2014 Reply to this comment

Hopefully this will help illuminate some of the problems out there with site search. Much of the issue is that for a long time, On Site Search has sat largely ignored. There could be entire teams devoted to SEO and SEM, while On Site Search was either a developer problem or the responsibility of a single person, and often only a portion of their job.

Thankfully, this has begun to change as more and more companies devote more people to tuning On Site Search. Now the struggle is less about people and more related to dealing with a bad search reputation or issues obtaining funding for real search enhancements.

The great thing about working in search is there truly is so much opportunity if you can get the right buy-in.

Craig Sullivan July 30, 2014 Reply to this comment

Well I remember a while back, when I worked at John Lewis – and we optimised for searches like conceptual stuff (customer services related queries, for example) and I remember well our weekly tune of the grocery search in the early 2000s. One example was finding 27 different spellings for the word ‘humous’ and three different ways in our own product catalogue of spelling it ourselves. We ended up with a rather nifty thesaurus system but it was love and effort that made it good, not the technology.

This mapping and continual working of search analytics wasn’t new but it seems poorly worked these days on many sites – leaving you with poor conversion from the results set pages. Sad but true – a big missing opportunity for many sites.

Christian, Baymard Institute July 30, 2014 Reply to this comment

Hi Craig, thanks for sharing your experience.

Manual tagging will often be a good way to start improving the support for the different search query types. Although it can also be somewhat automated (with the sufficient resources and prioritization), e.g. based on semantic analysis combined with machine-learning (search success rate as the feedback loop).

Simon Schabel August 12, 2014 Reply to this comment

Wow, thank you for this great and interesting post!

This is exactly what we figured out about e-commerce search engines two years ago when we did our analysis on that topic. The problem current product search engines face is the fact that the underlying technology still works like any other search algorithm: it’s index based.

Of course there were a lot of optimizations made by very smart people but there was never a fundamental shift of technology.

Since two years now the Germany-based company SEMFOX GmbH works on its Smart Semantic Product Search which solves a lot of the problems you mention in our post. Check out for more information on that.

We will see semantic search engines in the near future because the algorithms of machine-learning fast evolve. I hope to read more from you on this topic.

Rory Carlyle August 18, 2014 Reply to this comment

Great post! Working for an ecommerce site search solution provider, I can tell you these points are all spot on. It’s critically important to set up onsite search as a revenue enhancing tool, but also to learn from clients behavior and website usage.

Site search sits at the junction of customer service and sales rep within a website. It’s a must to think about how those roles play out in a use case and how each merchants site search needs to be configured in order to improve business. Simple changes like synonyms, redirects, and rich auto complete can improve the shopping experience dramatically for customers, but aren’t offered within most implementations.

Looking forward to more information from you guys! Thanks!

Adrian Durow August 25, 2014 Reply to this comment

Extremely useful and interesting article Jamie, provides a great framework for testing site search effectiveness.

I’ve configured analytics alerts / reports to send weekly summary lists of new keywords entered into site search (i.e. queries not previously seen in site search data reports). These reports also contain performance metrics (i.e. exits and conversions), as well as the search results URLs.

It basically gets me into the habit of monitoring site search activity, and getting new ideas for internal tagging.

AJ September 3, 2014 Reply to this comment

Hi Jamie! Thanks for the analysis – very insightful. I’m curious to learn what query types were the most popular and common in your usability study? In other words, what was the breakdown by percentage of the different query types used by your users?

colmcq September 10, 2014 Reply to this comment

wow! some article. I’m writing a review for a large engineering application and am wondering whether some of the concepts here can be applied there.

I’ve posted the question here

for anyone interested

InfiniteS October 17, 2015 Reply to this comment

Great detailed explanation and examples….

Tushar Goswami February 26, 2016 Reply to this comment

Wonderful research. We like your work so much – that we got ourselves your ‘Pro report’. It is useful. However do you have stats on “how much popular each query type is?” ? Like how many subjects performed ‘Feature search’ and how many preferred to perform ‘Thematic search’ ?

ravi February 28, 2017 Reply to this comment

Nice artical thanks for sharing very use ful

Lokendra December 4, 2017 Reply to this comment

Brilliant article. I like how you were able to classify an open-ended problem. Any pointers to someone who can implement this for us? Email:

Post a comment!

Close overlay