Best practices for E-commerce Search Testing
Every e-commerce website nowadays essentially comes with a search functionality integrated which allows the user to directly search the products they are looking for.
Sounds simple enough but to put things into perspective below data provides useful insights
According to a Forrester research report,
-
8 seconds is the average time visitors spend before deciding whether or not to remain on a site.
-
43 percent of visitors immediately go to the search box and searchers are 2-3x more likely to convert than non-searchers.
-
50 percent of users prefer to use a site’s internal search engine, as opposed to navigating the site.
Since e-commerce websites are all about providing good user experience search needs to be effective and accurate, we will be trying to list down some best practices to be followed while testing search on an E-commerce website or App.
1. Data Accuracy: When a user inputs a search term (say a product name) there is a good chance that he is already aware of what he wants. Providing incorrect results for the same can make the user go away from the website permanently. Below are some areas to be verified for accuracy:
- The results should be relevant to the query. For e.g.
A user is searching for “Samsung smartphone”, search module should be able to identify the indent of the user and show the results from smartphone category for Samsung and not in camera category.
- Handling of the special characters: Some products might be listed with specifications which may include special characters. The user may search with or without these special characters, hence it must be handled. For eg:
Product Name is “Samsung Galaxy J2 Prime SM-G532 Smartphone – Black [8GB/ 1.5GB]”
User can enter it as it is or exclude the special characters altogether or use space instead of “-“. So, searching for all these scenarios should provide the above-mentioned product.
- Synonyms – A user might use a synonym of a word for search which might not match with exact product name but the intent of the user is same so these should be handled. For e.g.:
User might enter “Samsung j2 dual sim” or “Samsung j2 double sim” the user should be provided with same results
- Search result page provides details such as price, discount, stock information and number of sellers. These should match with product details page else it will be a pretty bad user experience.
- Products where search term words are present in close proximity should be shown first. For e.g.:
User enters “Samsung j7 smartphone”, it matches with “Flip cover for Samsung j7,j7 prime smartphone” and “Samsung j7 smartphone 4GB/64GB” both matches are correct but in second product the search term words are nearer and hence should be shown before. This is easily handled by slop in SOLR.
- When a user enters a search term which is a brand name and not a specific product he can be redirected to a brand page which lists all products of that brand, listing the most popular products first and provide facets to navigate between all the categories of the products where that brand product exists.
2. Facets and Filters: Search results might span to thousands of products, so there should be a mechanism to filter out even further. This is done via facets and filters.
For e.g. user might want to filter out results on basis on RAM, ROM, Screen Resolution, Price, Colour for a handphone category on the e-commerce site etc.
Below points need to be considered while testing facets and filters.
- Facets counts should match with the number of products visible when that facet is selected.
- Once a facet is selected, other facet values need to change accordingly
- Facets might be category specific. Such as RAM is useful for smartphone category but not in Fashion category, hence it should not be shown there
- Facet calls have considerable performance impacts and hence should not be made unnecessarily such as while paginating
- Disabling/Not showing the facets with no products is a good user experience.
- Filters with text box should be properly validated with positive and negative scenarios.
- Faceted Navigation should be provided in case search results span multiple categories.
- Different sorting options such as “Low Price”, “High Price”, ”New Product” etc. allows user to look into the search results as required, hence these should be tested for consistency across multiple pages.
3. Auto correction: As a human nature, there is a tendency to type in incorrect spelling, search module should be able to auto correct that provide results based on corrected search term. For eg:
User might enter “Samsnug j7 prmie” instead of “Samsung j7 prime”, this should be auto corrected and results should be shown for “Samsung j7 prime”
4. Autocomplete: Embedding the autocomplete capabilities into search serves multiple purpose. It avoids spelling errors, promotion of products and can also provide one click navigation to product details page helping in fast and easy shopping experience. Below are the things to verified for autocomplete.
- Suggestions provided should be relevant to the search query being input.
- There should not be any suggestions which results in zero results.
- Suggestions should be provided without much latency, else it beats the purpose of autocomplete
- There should be a cap on number of suggestions provided.
- Suggestions should be based on popularity of the products on the website/market and should not be random
5. Performance improvements: Any module can be functionally efficient but if it does not provide good performance it is not production ready. Same goes for search as well. Below points can be considered in this regard.
- Truncation of long search queries: User can copy and paste an entire paragraph or a page in search text box with or without malicious intent. Most Search modules use SOLR or Elastic search as a backend which breaks the query into tokens and matches them with the indexes. While dealing with long queries these tools may might face hardware issues or provide slow responses, hence the user query terms must be restricted to a fixed number of words and max number of characters.
- Using Stop words: Both SOLR and Elastic search provide inbuilt functionality of stop words, which are nothing but removing commonly used words such as “a”,” this”,” the” etc. which might be important to the user but are not necessary while searching and reduces effort required to calculate the relevancy of a term in the indexed documents. This helps in increasing the performance of search.
- Response Time: Response time plays an important role as users don’t like to wait long for the responses. Tweaking the delays help a mile in these regards. For e.g.
User might enter the search term slowly, and for each character entered we might be calling suggestion API, instead of this we can add a delay for 50ms and try to provide suggestions when 3 characters have been typed.
Also caching of search responses might for some time (such as 2 min) might decrease the load on SOLR.
6. Handling no results: There might be times where the user enters a search term which does not match exactly with any product. Below strategies can be used in such cases:
- Reduce the minimum match criteria in SOLR dynamically and retry searching.
For e.g.:
User enters a search term as “Samsung j7 prime gold” which does not match any product when mm=100, dynamically reduce it to mm=70 and search which might match it to “Samsung j7 prime silver” and hence we provide some results for the query instead of no results.
- Popular or promoted products in case there is no match
- Personalization – showing recommendations on basis of view and order history of the customer
7. Comparison of search results on Web and App: Search results on different platforms, browsers should be consistent and all facets/sorting options should be available everywhere with similar counts on results.
Some of the challenges faced with search testing:
- Test data available for in-house testing is only a subset of production data. Products in production might be in millions but test data might be in thousands so there is always a scope of missing out some corner case.
- Performance remains a key aspect due to change in load between test environment and production environment. Performance testing, Stress testing and load testing should be carried in a setup which is replica of production.
- SDK Changes: Even though the functionality remains same, following micro services architecture some business logic might be implemented as client SDK to other services, where same functions might not be used by Web App and Mobile App, hence testing the SDK changes is required at all fronts.
By Kumar Abhinav
Engati – www.engati.com – A Coviam technologies platform
Coviam Technologies
www.coviam.com