Best strategies for sorting items in product lists
What is a best strategy for sorting products on the category pages?
The simplest way is setting up the order manually. In retail outlets it is called merchandising. For e-commerce this method works well for the small catalogs, up to 50-100 items.
In contrast, the alternative comprehensive way is using big data analysis. You can collect all behavior data, browser information, device information, screen resolution to create a dynamic customer profile. You can find the similar profiles in your history to identify customer expectations and push some products higher based on this information. This approach is at the other end of the complexity scale. If you are not Amazon, Booking.com or Ebay, this approach can be too expensive and not so efficient as you may expect.
Hybris default product sorting options
By default, hybris Accelerator is equipped with the following sorting methods:
- Relevance (default)
- Top Rated
- Name (ascending)
- Name (descending)
- Price (lowest first)
- Price (highest first)
By default, sorting by Relevance means sorting by inStockFlag and Score, where Score is a Solr relevancy index and inStockFlag is a availability flag (to push unavailable products towards the end of the list).
However, for the category pages “relevance” doesn’t make sense because the query is very specific (“select all product from the category X and its subcategories”). As a result, the sorting is undefined (except inStockFlag that splits the results into two parts, available and not available).
Using hybris Backoffice CommerceSearch some products can be marked as boosted and they will be displayed at the very top of the product list.
Manual sorting of products
Let’s start with the simplest approach, a manual sorting. If you have less than 50 products in the catalog, this way is the most recommended.
However, for the larger catalogs, neither customer not merchandiser is able to keep all products in their minds.
Hybris out-of-the-box doesn’t provide an efficient mechanism of the manual sorting. A good candidate for hybris Marketplace!
Sorting by best selling products
The next step is putting the bestsellers towards the top. There have been, however, some deficiencies. Sorting by sold quantities (number of sales) moves the least profitable products higher on the list as well as cheap offers.
Hybris doesn’t provide this feature out of the box. To implement it you need to update solr product index with the sold quantities and add a custom sorting method that uses this attribute. A good candidate for hybris Marketplace!
Using product ratings and reviews
User ratings could be used as a secondary sorting method. However, this approach has serious drawbacks as well. In the default hybris, product rating value is created/updated once the customer writes a product review. The average rating means different things for one user review and for one hundred. Users don’t like writing reviews, so the majority of your products will not be rated properly.
The solution is obvious: use the number of reviews as a weighting factor in the formula. The correlation coefficient is not linear: for different ranges the different weighting factors should be used. Over time, however, the product ratings followed Gaussian distribution. The majority of the products are in the 2..4 range (scale of 1 to 5) with a maximum in 3.5-4. All bestsellers were rated as 4.5 in average, the most of the remaining products were averagely rated as 4. Over time, these groups became closer to each other and sorting by rating didn’t seem useful anymore.
Another issue was about the rating form. To avoid cheating counters, you need to implement the specific anti-cheating logic and/or authentication. The latter is too complicated for the customers and eventually leads to reducing the number of reviews. Anti-cheating tools like captchas or IP check won’t help because for the small amount of reviews every single review counts and pushes the product towards the top. If you sell products from different suppliers/manufacturers, the cheating will be not long in coming.
The alternative solution is using Facebook LIKE button. Anti-cheating and authentication is handled by Facebook, the number of likes is available for processing in e-shop and using as a sorting criteria.
The main problem with this method is that old SKUs will always get higher than the newer ones, which in turn will take more time to move upwards.
Hybris OOTB provides this sorting method in the default configuration. Hybris calculates the average rating at the indexing phase and saves it into Solr Index. This value is used for sorting when the “Sort by rating” is selected.
Sorting by price
This approach is very clear for the customer. As a rule, customers know their budget and they are able to choose between the products of the same price category. When you sort by price low-high, you can see the progression in price as you scan the list of products.
Customers use this sorting to understand the price range of the available products and make a decision based on this numbers. Very often they turn to the average-priced products.
This aspect of human nature is exploited to increase sales. Some stores specially add expensive products to shift the average. There, in the absence of any price information, consumers are more likely buy expensive products.
Suk, Lee, and Lichtenstein (2012) tested that claim in a bar. Over an 8-week span (and 1,195 beers), the researchers alternated the sequence of beer prices. They maximized revenue when they sorted prices from high to low.
Thanks to a simple change in sequencing, the bar owners now make an extra $0.24 (on average) for every beer sold.
But why does that happen? The researchers proposed two reasons.
Anchoring / Reference Prices. When consumers evaluate a list of products, they use the initial prices to generate their reference price.
Reason 2: Loss Aversion. As humans, we focus on losses. Whenever we choose an option, we lose benefits from the options that we didn’t choose. And that hurts. Depending on your pricing sequence (i.e., low to high vs. high to low), customers perceive different losses when they scan down the list of products.
When you sort products by ascending price (i.e., low to high), customers view each new product as a loss in price. With each new option, they’re gradually losing the ability to pay a lower price. Thus, they feel motivated to minimize that loss by choosing a lower priced product.
But here’s the flipside. When you sort products by descending price (i.e., high to low), customers view each new product as a loss in quality. Thus, they feel motivated to retain a higher quality (and more expensive) product.
Sorting by price has its flaws.
The first problem is that bestsellers are usually not on top of the list. The cheapest products are generally not being interested
The second issue is crowding out of “normal products” by cheap accessories and consumables.
The third issue is about navigation: it works well if all items are on the same page. The pagination makes navigation difficult. From a customer’s point of view, for a result set of 100,000 items, sorting by price actually filters the result set, selecting at most 300 items with the lowest prices and effectively removing the remaining 99,700 higher-priced items from consideration
This approach looks like a good candidate for a secondary sorting method.
When price sorting is selected, you can think about rethinking the price facet design and moving it to the fore:
A good candidate for hybris Marketplace!
Hybris OOTB provides sorting by price in the default configuration.
Sort by turnover/margin
To overcome the issue with accessories and consumables in the first positions, you can use a turnover/maring as a popularity index. You can use time window of 30 days or as per business requirement. You can recalculate turnover/margin periodically for all products using the value of sales for the last N days/weeks. It also shows good results for the seasonal products as well. The shorter this period of time is, the new/trending SKUs will be higher. Longer periods move the established SKUs towards the top. However, this approach has its flaws too. For example, product sold more during valentine season may influence product sorting unduly in the month of April.
This approach seems the best and can be used as a default one for the product listings.
Hybris OOTB doesn’t provide this functionality.
This sorting criteria is close to the ratings, but with the simpler rate mechanism (just visit the page). The drawbacks are the same. No protection against cheating. I don’t recommend to consider this option at all.
Hybris OOTB doesn’t provide this functionality.
Unfortunately, this sorting method is completely overlooked by the e-commerce community. By “category-specific sort types” I mean any sorting options that are only available in one or a few select categories (because they wouldn’t make sense as site-wide sorting options – they only make sense for the products within those particular categories).
Examples include being able to sort suitcases by volume, fishing rods by length, pens by point size, hard drives by storage capacity and spindle speed, road bikes by weight, etc. It’s this category specificity that makes them different from common site-wide sort types such as ‘Best Selling’, ‘Relevance’, ‘User Ratings’, and ‘Price’, which are typically available for all products and categories throughout a site.
If users could sort lipstick by color (the progression in color shades) , that would be an enormously popular feature. Users sort as a way of grouping, or to help them find a particular item if they know where it will be in a list (e.g. sort by name) and there doesn’t need to be a natural progression to be useful.
Hybris OOTB doesn’t provide this functionality. To implement that in hybris we need to display different sorting methods for different categories based on the configuration and facet information. If the results have no products with weight attribute, there is no need to display this sorting method in the list to not confuse the customer.
A good candidate for hybris Marketplace!
© Rauf Aliev, November 2016