Deconstructing E-Commerce Search: The 8 Most Common Query Types
In this article, we’ll introduce 3 functional groups of user search, along with 8 types of search queries identified during our large-scale usability study of e-commerce search:
-
Query Spectrum
1. Exact Searches
2. Product Type Searches
3. Symptom Searches
4. Non-Product Searches -
Query Qualifiers
5. Feature Searches
6. Thematic Searches
7. Compatibility Searches
Our usability testing reveals that these 3 groups and 8 types of queries represent the main principles behind how users think of and construct their search queries when searching in an e-commerce context.
During our usability studies, beyond the common keyword search for a specific product, users were observed to rely heavily on search queries that included a product type, a theme, or a feature. Yet surprisingly, our 3 rounds of search UX benchmarking of 60 of the world’s largest sites in 2014, 2017 and late 2019, reveal a still surprisingly poor support at e-commerce sites for these query types - as is evident in the graph above (late-2019 results).
An analysis of the more than 8,400 manually set UX performance ratings from our search UX benchmark reveal a surprisingly weak support for essential e-commerce search query types, with 61% of all sites performing below an acceptable search performance that will directly misalign with user’s actual search behavior and expectations. To make matters worse, 15% of sites were found to have a downright “broken” search query type performance.
Most of the site improvements we’ve observed since we first benchmarked this in 2014 have largely been offset by users’ increasing expectations for what type of search queries they can perform online (expectations likely carried over from their general web and social media search, that generally tends to be a lot more capable).
Fundamental E-Commerce Search UX Issues
While there has been a steady improvement in some of the search query types over the past 5 years, there are still fundamental search UX issues. For example, among 60 top grossing US and European e-commerce sites in late-2019:
- 61% of sites require their users to search by the exact same product type jargon the site uses, e.g. failing to return all 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”, etc..
- 46% of sites don’t support thematic search queries such as “spring jacket” or “office chair”.
- 32% of sites don’t support symbols and abbreviations for even the most basic units, resulting in users missing out on perfectly relevant products if searching for inch when the site has used “ or in in their product data.
- 27% of sites won’t yield useful results if users misspell just a single character in a product title.
- 25% of sites don’t support non-product search queries, like “returns” or “order tracking”.
In this article, we’ll go over our large-scale UX research findings for each of the 8 query types most common for e-commerce search — showing you the observed user behavior, where and how it causes UX issues for e-commerce search, query samples, and the principled needed for how to best support each query type.
Note: Some eagle eye readers may notice that a previous version of this article covered 12 query types. While the other 4 query types that we found during our testing (Relational, Subjective, Implicit, and Natural Language query types) are still valid, they are much less frequently used by users and are often industry-specific. For this reason, we have omitted them from the article. To find out more about these query types, as well as more about the covered 8 here, you will need Baymard Premium access.
Deconstructing the E-Commerce 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.
Users will commonly combine the 8 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 8 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 a user searches for ‘sleeves 11”’. Notice how ‘sleeves’ represents 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 implies that it is “laptop” sleeves in 11-inch sizes that the user is interested in.
In short, the Query Spectrum is the user’s way 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 8 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.
1) 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 a #1 Exact Search like “Grado Prestige SR325” (a specific pair of 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
At Costco, an “Exact Search” for the model number of a mixer is unsuccessful (first image), even though the product is sold at the site and findable via browsing (second image). Note that the model number data is even shown on the product details page (third image), so it’s not because Costco doesn’t have the data - it’s because it’s not utilized by the search engine. This is highly problematic for all those users who copy-paste product titles and model numbers from external sites (e.g. review or manufacturer sites).
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). “Exact Searches” are typically the easiest to support technically, and most of the tested sites fared reasonably well.
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 and there are a few conditions to take into account — refinements that will take the “Exact Search” query implementation from acceptable to great. 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 product naming may be localized.
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, users were often observed to copy-paste product titles from external sites into the search field.
“This is good,” a user explained, during one of our first rounds of search usability testing, when finding the “Filmography” section on IMDb . “This I can use.” Some users during testing would look up information on external sites such as review sites, and then paste product titles into the e-commerce 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 (movies), Goodreads (books), Projector Central (projectors), DPReview (cameras), etc.), will therefore be pasted into the search and must 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 users 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 #6 Thematic Searches).
When we look at the benchmarked top 60 grossing US and European e-commerce sites, we find that 29% of sites are incapable of producing decent results for #1 Exact Searches as of late-2019. More specifically 27% of sites are incapable of handling misspelling of just a single character in the product title, and 2% don’t allow searching on model names (as seen as Costco). (This have only improved marginally, with 34% of sites not supporting Exact Searches all the way back in 2014).
#2. Product Type Searches
At B&H Photo, a search for “multifunction printers” displays 65 results (first image), while a query for “all-in-one printer” shows 347 results (second image). When users search for product types that aren’t an exact match for a site’s category labeling, only a fraction of the results display, which presents a missed opportunity, since users aren’t presented with as many relevant (nor full-breadth) results.
Similar issues can be found at 61% of all e-commerce sites, here seen at Williams-Sonoma, Macy’s, and Urban Outfitters, where product type searches for e.g. ”baking tools”, ”trolley”, and ”dress shirt” do not return a fraction of the relevant products that the site carries.
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 via the main menu. During our most recent mobile testing, 60% of mobile users turned to search as their first product-exploration strategy when landing on the homepage of a new site.
When the site can be sure of a 1:1 match with a product type search and an existing category, it’s worth autodirecting the user to the relevant matching intermediary category page, if one exists, as discussed in our article Autodirect or Guide Users to Matching Category Scopes — 46% Get It Wrong.
Still, 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 user at Target searches for ”ladies hoodies” and is presented with multiple ”women’s hoodies”. In this case, the use of ”ladies” has been well mapped to women’s products, making for a smooth experience where the user is unaware that these mappings are even occurring. Using synonyms for common “Product Type” queries speeds product exploration by presenting relevant results without requiring any user effort.
Users will not necessarily know what specific product type the site uses to identify a product. At H&M synonyms like “maternity” and “pregnant” have been mapped, meaning that users who search for “dress pregnant” will also see all the “dress maternity” results.
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 users never thought of trying another synonym when they received poor search results but instead simply assumed that the poor or limited results for a search such as “copy machine” meant that was then the site’s full selection for such products.
Despite the severe impact on the user’s search experience 61% of major e-commerce sites do not return all the relevant results, if any at all, when users search by a product type or synonym, e.g., “blow dryer” instead of “hair dryer”. This is virtually no change from 2014 that found 64% and 2017 that found 61% of sites not returning all relevant results when searching by common product type synonyms.
The Product Type query is largely a missed opportunity within the industry and should always be one of the first things considered in any search UX improvement project due to the severe combination of Product Type searches being frequently used by users, the likelihood of users getting stuck and ultimately abandoning if synonyms aren’t well supported, with the fact that 61% of e-commerce sites currently don’t have proper synonym support.
A few key types of synonyms to consider when auditing or trying to improve a sites Product Type search capabilities are:
- Near-identical word meanings, i.e., ”multifunction printers” vs. ”all-in-one printer”
- Regional dialect synonyms, i.e., ”spanner” vs. ”wrench”
- Regional spelling variations, i.e., ”fibre” vs. “fiber”
Since #2 Product Type Searches are performed by users who are looking to browse a whole category of products, it’s also 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 — which 51% of sites still don’t have. See guideline #376 for more on this), although an acceptable alternative is to guide users towards a relevant category scope where such options are available (as discussed in our article E-Commerce Sites Need Multiple of These 5 ‘Search Scope’ Features).
#3. Symptom Searches
At Home Depot, a search for “drafty window” returns many results for entirely new windows, failing to address the user issue indicated in this “Symptom” search.
The same symptom query at Amazon for “drafty window” presents dozens of potential solutions (e.g., “window insulator kits”, “window shrink film”, “foam insulation tape”, “cold blocking drapes”, etc.) giving users a range of options to help resolve the problem.
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 often 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 almost impossible to find the relevant products on the site. Or as one user during our testing reasoned, “You must be able to search on anything. I’m used to that from Google”. This is especially true if categories on the site aren’t problem- or symptom-based (which they often aren’t).
Furthermore Symptom Searches often also have multiple different product types as relevant solutions, making it both difficult and inconvenient for users to find the best solution for them, if the Symptom Search query type isn’t supported. For example, a symptom query for “knee pain” at a sports equipment site should provide users with an array of different product types such as knee pads, knee sleeves, supporting socks, pain-relieving products, sports tape, shock-absorbing shoe insoles, etc. If search teams need inspiration for the complete range of possible solutions to a problem relevant for your industry, consider going to physical store in your same product vertical and actually talk to the in-store experts as users in physical retail will have the same product exploration approach.
At Chemist Direct, the search bar reads, ”Search by product, brand or condition”, encouraging users to search by condition (or symptom) and that it will be supported.
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.
The user can also be guided during search query formulation with the help of autocomplete scope suggestions (see our articles on E-Commerce Sites Need Multiple of These 5 ‘Search Scope’ Features and 13 Design Patterns for Autocomplete Suggestions — 27% Get It Wrong for more about scope and autocomplete functionality). Scope suggestions are a good complement to “Symptom” query keywords because they begin to reveal hints at possible solutions (i.e., categories) that can help guide users to a related query path.
Integrating or interlinking any help or buying 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 and beauty, tools and hardware supplies, cleaning and housekeeping, specialty electronics, B2B, etc.
Our current UX benchmark shows that only 25% of sites within industries where Symptom Searches are even relevant, actually have decent support for it. On most sites, searching for a symptom like “knee pain” will return any products related to the keyword “knee”, and predominantly show irrelevant “knee” related products first, with the actual solutions to the “knee pain” symptom scattered throughout the following hundreds of partial matches – in practice rendering it impossible for users to get an overview of their relevant options.
#4. Non-Product Searches
At Wayfair, a search for “return policy” directs users to the “Returns Center” where numerous return-related FAQs are available.
Searching for “return policy” on Amazon yields returns center links, as well as a short description of the 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 we consistently observe that users expect the search field to search the entire website (not just the product catalog) - after all that is typically what a search field does on any other non-ecommerce website. Indeed, during our Accounts & Self-Service usability testing 34% of users tried to search for non-product content (e.g., “return policy”, “unsubscribe”, “cancel my order”, etc.).
During testing users would often search for this type of auxiliary content when they had difficulties finding navigational links to it. This is a logical consequence of this auxiliary content being secondary, and links to it therefore tend to be relegated to the page footer or nested deep within help sections. On mobile, finding “Non-Product” content via on-page links or navigation can be even more challenging as these options are often even harder to find compared to desktop sites.
You can read more about our findings on non-product search that we’ve covered in detail in our article E-Commerce Search Needs to Support Users’ Non-Product Search Queries - 15% Don’t.
‘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:
| 1) 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 “Sandals” |
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 |
2) 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 “OLED TV” or perform a #7 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 the 3 following query types:
#5. Feature Searches
#6. Thematic Searches
#7. Compatibility Searches
Note: Relational Searches and Subjective Searches are not covered here (see guidelines #338 and #337, respectively).
#5. Feature Searches
On Sephora, a search for ”$30 shampoo” automatically applies a $25–35 price range filter to the search results. Applying an ever-so-slightly relaxed price range is sensible as the $30 figure can arguably be interpreted as a price indicator — a user asking for shampoos that cost $30 will likely consider a shampoo that costs $29.50 or $30.5 to be a good match.
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”.
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”), brand (“Revlon lipstick”), or size (”size 8 sneakers”). The list goes on, and all significant product attributes should be searchable, even if they don’t exist for all products sold 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.
“Feature” searches are nearly always used as a qualifier for another search type — a way to filter the results of a certain search. For example, the user may perform a “Product Type” search and then combine it with a “Feature” search to only get a subset of those products (e.g., “volumizing paraben-free shampoo” or “blue breathable north face jacket”). During our testing, users also combined “Feature” searches with “Thematic”, “Symptom”, and “Compatibility” searches.
Users are becoming more and more accustomed to the robust features of major web and social media search engines and their almost uncanny ability to intelligently interpret and yield relevant results to complex search queries — an expectation that users increasingly carries over to e-commerce search.
A search for “red sofa” at Wayfair returns sofas with the “red” color filter preapplied, allowing users to quickly begin browsing products that are most relevant to their query.
In terms of implementation, the ideal solution is if to dynamically apply any features searched for as filters on the results page (if a filtering value for the feature exists), 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 Wayfair example, the “red” aspect of the “red sofa” query is applied as a color filter, with the user being able to see and toggle the other available colors of sofas.
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 86% support that users search by a wide range of features (e.g. color, material, brand), which is a great improvement from the 46% seen in 2014 and 73% in 2017.
#6. Thematic Searches
Similarly, thematic queries aren’t supported that well at Marks & Spencer, where e.g. a query like “retro dress” return the same table set in 4 colors, and show none of the more than 180 dresses sold at the site.
“Two items, and these aren’t even lipsticks”. A user at Sephora expressed disappointment when her search query for “sale lipsticks” presented her with only two product results, both of which were lip liner pencils (and neither appeared to be on sale). In this case, a “Thematic” and “Product Type” search were combined, yielding limited results that discouraged the user.
What exactly constitutes a “living room rug”, an “extreme weather sleeping bag”, or a “retro dress” ? 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 of usage locations (e.g., “living room furniture”), seasonal or environmental conditions (e.g., “spring jacket”, “cold weather sleeping bag”), occasions and events (e.g., “wedding gift”), or even promotional attributes (“sale lipsticks”). Nevertheless, they are very real notions to users who — in certain industries, such as apparel and furniture — include thematic qualifiers liberally in their searches.
At Kohl’s there’s a clear support for thematic queries. Here a query for “winter jacket” returns the “Coats & Jackets” category, with the “Weather: Midweight” and “Weather: Heavyweight” filters preapplied.
Clearly, a great deal of interpretation is required to support “Thematic” searches, both in terms of the meaning of the actual query itself and 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). Similar to Feature Searcher the ideal support for most Thematic Searches is often achieved by having these themes as actual filtering values that are then pre-applied when users search by them, as this gives users direct insights into how the site have interpreted their thematic query and an easy way to narrow or broaden the thematic qualifier. (this also improves the general navigation based filtering experience greatly)
Meanwhile, a search for a “Mother’s Day bouquet” requires products to be grouped by an occasion (a social concept). Similar mappings may be necessary for abstract queries such as “macbook power” — an actual search query one of the users in our testing submitted when looking for an adapter for his MacBook Pro laptop.
Because users will sometimes think in these “Thematic” terms when typing into the search field, their product exploration is disrupted when results don’t meet their expectations — forcing users to refactor their queries in order to start a new search.
This is especially difficult on mobile devices because it sometimes requires placing the cursor in a precise position in the middle of query text and often requires backspace deleting many characters (one-by-one) to replace a word or words. During testing, this was observed to be challenging to users, some of whom simply abandoned their search or tried to find products through category navigation instead.
When “Thematic” search queries aren’t supported, users are left with absent, few, or irrelevant results, which costs users extra time to rethink (and retype) query wording, and sometimes gives the impression that the products sought simply aren’t available at the site. In fact, 46% of our benchmarked sites have problems handling “Thematic” search queries, if the thematic identifier doesn’t happen to be part of the product title. This is fairly consistent with the performances from 2014, where 54% did not handle thematic queries well, and 55% in 2017.
#7. Compatibility Searches
A search at Dell for “Vostro 2420 adapter” displays irrelevant products at the top of the results (a handset adapter, a camera adapter, and an incompatible battery). Users have no clear way to identify appropriate products in the first place since compatibility details are excluded in the results, meaning that users must click into each product page to determine compatibility and relevance.
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 #7 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 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). Compatibility searches therefore tend to either
- combining the brand name and specific model or series of the primary product (e.g., “Dell XPS 13 Touch Laptop”) along with an accessory type (e.g., “adapters”).
- combining the brand name and “Product Type” of the primary product (e.g., “dell laptop”) along with the type of accessory they’re trying to find (e.g., “screen protector”).
- using only the primary product name (e.g., “macbook pro”) and expecting to find supported accessories amongst the results.
- using only the accessory or part name (e.g., “laptop adapter” or “vacuum cleaner belt”).
Users who know the exact model of their product will typically submit this, and #7 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 are therefore important as well, so that users can enter generic queries like “13in laptop sleeve” rather than specifying the exact laptop they own.
At B&H, a compatibility search for “hp ink” (first image) offers faceted compatability filters to narrow by “Hewlett-Packard Model” (second image), helping users restrict results only to accessories compatible with their specific printer model.
It’s useful to note that some users deliberately exclude the accessory type in their search and only search for the product they own, as they expect accessory products will be available next to the product. Other users simply forget to include the accessory product type. In both cases, displaying an option to see accessory products for such searches will prove incredibly useful for these users, giving them a way to access compatible products from the product they already own.
At Crutchfield, when users search for e.g. “Subaru WRX speakers”, the site detects the car brand and model and presents users with all the car stereos that are compatible with this specific car model. This allows users to quickly begin exploring products, rather than having to refine their search or try to find relevant products through category navigation.
Compatibility relationships can be very complex and have numerous dependencies that can be difficult to capture in a free text search. It may therefore be a good idea to integrate Compatibility searches with any product finders or wizards available on the site. For example, if a Compatibility search is detected for “Dell laptop adapter”, it could send the user to a “Laptop Adapter” wizard, ideally with “Dell laptop” preselected. Or the wizard could be displayed as an option among any autocomplete suggestions or on the search results page.
Generic compatibility queries are among the most supported query types, and we’ve seen a steady increase of the sites that sell compatibility items supporting basic compatibility queries since our 2014 benchmark at 62%, growing to 68% in 2017, and 70% in late 2019.
‘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 exception being #6 Thematic 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 defining technical #7 Compatibility requirements.
A summary of the 3 query qualifiers discussed above can be found in the table below:
| 2) 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. Compatibility Search “Lenses for Nikon D7000” |
Searching for products by their compatibility with another item |
3) 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.
The syntax of the user’s query can be highly important, 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.
Below we discuss one of the most important query structure–type queries:
#8. Slang, Abbreviation, and Symbol Searches
Note: Implicit Searches and Natural Language Searches are not covered here (see guidelines #347 and #398, respectively).
#8. Slang, Abbreviation, and Symbol Searches
If all abbreviations, symbols, and fully spelled versions are not mapped to each other users are likely to miss out — as seen here where searching for “11 ft. paddleboard” and “11 foot paddleboard” leads to 0 results, as REI only supports the symbol query “11’ paddleboard”. The vast majority of users who don’t have a technical understanding of search engine logic will naturally conclude that REI then doesn’t carry “11 foot” or “11 ft.” paddleboards online.
Users rely on a wide range of linguistic shortcuts when they search. This quickly became evident during our testing as several of the users frequently relied on #8 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”.
A slang search for “shades for men” at Kohl’s yields many irrelevant results including sun shades, pants, polo shirts, and even t-shirts with sunglass prints, on the first page of results.
At Amazon, the same slang search for “shades for men” is well mapped to sunglasses, offering over 30 men’s and unisex sunglasses on the first page of results.
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”.
A query at Target for “20°F Sleeping Bag” strips out the degree symbol by default, making the query “20f sleeping bag” and prioritizes several irrelevant products at the top of the list (first image). However, selecting the small link “search instead for 20°F Sleeping Bag” reprioritizes the results, bringing several relevant “20 Degree Sleeping Bag” products to the top of the results (second image). Although Target does offer the option to revert to the query as typed with the symbol, it might not be obvious to all users.
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.
Users often copy-paste search queries from various sources during activities like research and comparison shopping. Considering that many copy-pasted product titles include symbols (e.g., “Men’s Levi’s® 511™ Slim-Fit Stretch Jeans”), it’s important that search properly interpret these symbols when generating results — or risk giving users the perception that a product simply isn’t available if it doesn’t appear at or near the top of search results.
Our late 2019 search benchmark shows that 33% of sites do not support even the most basic symbol or abbreviation searches for units common to the site (e.g. “13 cubic feet fridge” vs “13 cu ft fridge”, “3 ounce” vs “3 oz”, “200 GB” vs “200 gigabyte”) – for this reason, we’ve even benchmarked slag and more complex symbols. That said the support for this support for the most basic symbol and abbreviation of units has doubled since 2017.
‘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 #8 Slang, Abbreviations, and Symbols when they devise their search query.
A summary of the query structure can be found in the table below:
| 3) Query Structure How the query is constructed by the user and interpreted by the search engine |
|
|---|---|
| #8. Slang, Abbreviation, and Symbol Search “Sleeping bag -10 deg.” |
Searching for products using various linguistic shortcuts |
Improving Support for these 8 Query Types
Ever since our first round of e-commerce search UX benchmarking back in 2014, we’ve observed surprisingly poor support at e-commerce sites for even these most common types of search queries that users are indeed observed to search by on e-commerce sites.
Let’s take another look at the graph presented earlier to see the level of support for each query type.
In the free, publicly available part of our e-commerce UX benchmark database you can also see how each of the 60 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, #6 Thematic and #8 Symbol searches, you know the current state of e-commerce search is still problematic. And since e-commerce search engines are nearly always reused across platforms (different interfaces accessing the same search engine), query support will be similarly poor on tablet and mobile sites/apps, too. What the exemplified version of this graph means for end-users is that:
- 61% of sites require their users to search by the exact same product type jargon the site uses, e.g. failing to return all 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”, etc..
- 46% of sites don’t support thematic search queries such as “spring jacket” or “office chair”.
- 32% of sites don’t support symbols and abbreviations for even the most basic units, resulting in users missing out on perfectly relevant products if searching for inch when the site has used “ or in in their product data.
- 27% of sites won’t yield useful results if users misspell just a single character in a product title.
- 25% of sites don’t support non-product search queries, like “returns” or “order tracking”.
The current overall lacking state of e-commerce search shouldn’t be understood as “users cannot use search at all on these sites”. However, it is a clear indication that e-commerce search isn’t nearly as easy to use as it should be and that users’ search success and search conversion rates can be improved dramatically on most sites – even when looking at these 60 major e-commerce sites.
The good news is that this also 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 4 essential query types: #1 Exact, #2 Product Type, #5 Feature, and #6 Thematic. Users can get by with basic e-commerce searches when these 4 query types are supported. Conversely, failing to support any of these core query types will result in a defective search experience.
To create a truly great search experience, all 8 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 our testing we observed how the users 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 users 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 postpone 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 these 8 query types.
This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” on-site e-commerce search experience.
User experience research, delivered twice a month
Join 25,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
Related Articles
More E-Commerce Research
Free Research Content:
- Popular Articles · a listing of our most popular research-based articles on e-commerce UX
- UX Benchmark · benchmark with case studies of 93 major e-commerce sites ranked by e-commerce UX performance
- Page Designs · navigate 8,400+ manually annotated full-page screenshots categorized by page type
Products & Services:
- Baymard Premium · full access to all 582 research-based design guidelines, UX case studies, page designs, and review tool ($720-$3,000 / year, based on plan)
- UX Audit · get an in-depth analysis of your site’s UX, conducted by a Baymard researcher ($1,900-$9,700 based on scope)
Comments
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 info@baymard.com
richard thomasJune 18, 2014
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 InstituteJune 18, 2014
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 DudeJune 23, 2014
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?
AndrewJune 23, 2014
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 TandonJune 23, 2014
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 InstituteJune 24, 2014
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 ReynoldsJune 23, 2014
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 InstituteJune 24, 2014
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.
JonathanJune 25, 2014
Very insightful. Thanks.
Peter RiegerJune 25, 2014
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 InstituteJune 25, 2014
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_JWJune 30, 2014
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 InstituteJune 30, 2014
Thank you very much for the kind words Joana – we’re happy you found it useful!
RyanJuly 8, 2014
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 SullivanJuly 29, 2014
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 InstituteJuly 30, 2014
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).
Rory CarlyleAugust 18, 2014
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 DurowAugust 25, 2014
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.
AJSeptember 3, 2014
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?
colmcqSeptember 10, 2014
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 http://ux.stackexchange.com/questions/64198/help-improving-vast-search-interface
for anyone interested
InfiniteSOctober 17, 2015
Great detailed explanation and examples….
Tushar GoswamiFebruary 26, 2016
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’ ?
raviFebruary 28, 2017
Nice artical thanks for sharing very use ful
LokendraDecember 4, 2017
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: lokendra@xfactory.in
GeorgeMarch 13, 2018
Thanks a Lot for the info!
Had me reconstructing my whole text search system, for the best!
AndyOctober 15, 2018
Me too George!
CounfreediseMay 17, 2018
Long but very useful article. Thanks for the post.
tomSeptember 28, 2018
thanks for sharing, absolutely great work and advice!
adieMarch 4, 2020
I’m developing a marketplace and very interested if anyone here knows of a way of implementing any of the above or WordPress integrations’ or plugins.
thanks for any help or advice
Zoe BeckerApril 23, 2020
This article still help, with today’s AI, we can serve most of the user queries, but without the fundamental insight like this, we won’t be able to handle most of the cases.
Thank you again