I recently bought some cake decorating supplies. Yes, I could have dyed fondant icing black, but it’s surprisingly difficult and messy to achieve at home, so I went looking to buy this in. I found a sugar-craft site that delivers nation-wide, clicked on the search bar, started typing “blac” then paused.
I realised that I was waiting for it to suggest an auto-completion or even better guess what I wanted and show me products. I’ve been somewhat spoiled by the improvements in site search, but I persevered, found my icing and checked out. But would all customers have bothered?
Why bother as Google exists?
SEO for google search in particular is great at getting customers to your site, and deep links with structure can mean that they get to the right page immediately. But what about all those that get to your site on the homepage or another landing page from search or another channel? They still need to find what they want.
The conversion rate for those who use site search tends to be higher – around twice that of non-search users. On the flip side, 68% of customers report that a bad search experience will result in them leaving a site.
A good experience is both accurate and timely.
Accuracy for the body of requests can be tailoring, assuming the tools are available for redirections and search merchandising. For retailers with a long tail of search terms that are too large for tailoring, they need something automatic. This is where algorithmic quality and handling of inaccuracies matter, as over 30% of customers who hit the dreaded “no results” message will give up without trying another term. So fuzzy matches, indexing of all relevant material, and automatic conversion analysis can all aid in presenting useful results as often as possible.
Slow sites encourage customers to go elsewhere. Google has long championed site speed as an important metric, baking it into their Core Web Vitals. A slow search is frustrating, even if accurate. The search box is where interaction is the most immediate. Outside of the checkout it may be the only time a customer types something into your website. As I touched upon in the intro, this speed is not just results page response time. A fast response now also coverts the display of products and suggestions as you type.
The original and slowest
So for Magento, what are the options? It comes with a built-in search. This originally was based on mysql queries and so was fairly slow. There was a move to using ElasticSearch in Magneto 2.4, which improved the index retrieval part of search. They even introduced a simple auto-completion drop-down. However, as these requests still hit the Magento monolith there’s an overhead that gives a high floor for search result speed.
Leaving the speed issues to one side, the Magento search was fairly basic. The ability to include synonyms, spelling corrections, redirects for landing pages, merchandising etc. could be added with 3rd party extensions. These are all features one would expect to see in state of the art SaaS offerings. But we’ve found the speed and quality of results to still be wanting. That is even when using Elasticsearch in the backend and GraphQL to streamline calls. Often one is looking at hundreds of milliseconds responses, even getting up to whole seconds.
One advantage these extensions have is a close integration with Magento, so they tend to be easy to set up. Their search results page can support layered (filter) navigation, they can handle all Magento product types – because they are designed for Magento directly. This is something that can be lost with more platform-agnostic SaaS search.
Adobe Live Search to the rescue?
Enter the fray: Adobe Live Search. It’s a SaaS ecommerce search solution specifically for Adobe Commerce. It also makes use of some of the recommendation power of Adobe Sensei. On first glance, this should hit the sweet spot of bringing SaaS external computation and functionality to something specifically designed for Magento.
First the good of Adobe Live Search:
- Easy setup
- Supports layered navigation, colour patches
- Improved drop-down suggestions with images and prices
- Supports synonyms and redirects based on existing Magento controls
- If you pay for Adobe Commerce it’s no extra cost
- It’s fast – bypassing Magento allows it to drop below 100ms responses
There are a few limitations that it’s worth being aware of:
- There is no ability to customise the templates for drop-down or results page
- It’s not available for Magento Open Source at all
- It does not work with the Blank theme. Why that is a pain for developers is outside the scope of this article
The issue of not being able to customise output templates does not mean that output cannot be made to look as you wish, just that you’ll have to implement this yourselves using their GraphQL. This is mainly going to affect the lower end of enterprise who can afford Adobe Commerce but who are looking to save by just tweaking what’s off the shelf. This is in contrast to SaaS offerings like Klevu and Aglolia which allow complete re-writes but also support templating and other customisation options as a half-way house.
Speaking of which…
Klevu and Algolia
There are plenty of offerings in this space, but let’s pick out a couple of the big ones – Klevu and Algolia. Let’s start with what these offerings have in common:
Both have natural language search (semantic search) at least at certain levels. Both can offer excellent speed, though it’s hard to confirm as there are variations when testing sites using both, suggesting that these services can still be implemented badly for a given site! As mentioned previously, both have progressive approaches to customisation, allowing customisations to a default set of templates; or frontend APIs and framework support that can be used to build your own interface.
What about AI?
As you’d expect from 2023, both also offer an array of “AI” options.
AI is rather a broad term so let’s consider what intelligent functionality is really being offered:
Semantic search The ability to understand natural language questions is suddenly pretty ubiquitous due the relative ease of integrating a large language model into a search architecture. If this is something you think your customers would appreciate then you need to consider at what service level and price point each service offers this capability.
Result optimisation The “long tail” I mentioned earlier can be better serviced by automation than days of leg-work. This is where search as a service like these offer transparent optimisation that improves with experience, offering customers more accurate results as time goes on. It can sometimes be bootstrapped by providing historical order data – we know Klevu offer this.
Personalisation This is more Machine Learning (ML) than AI, but search services unlikely to be offering recommendations and personalisation at an even greater rate in the future and the inverse is likely as well. So before diving into picking your approach for search on Magento I would consider what your strategy wants to be around personalisation as you may find that existing services you have may be increasing their range or you can concentrate on a single provider to join up search and personalisation.
How they differ
We have found Klevu’s customer service to be excellent, and this is borne out in reviews generally. This means that even if there are limitations in documentation these are more than made up for by access to real people to help with integration, issues and planning.
Klevu is not without its limitations. Its management API, although existent, primarily caters to record updating, leaving room for improvement in more comprehensive control. Additionally, while Klevu boasts about the AI elements of their offering, these advanced features are not very evident or accessible at their base offerings, potentially limiting smaller businesses from leveraging AI’s full benefits.
On the other hand, Algolia stands out for its extensive API capabilities not only on the frontend but also back end. One notable drawback is that while Algolia supports creating rules for redirects, it lacks native support for this feature, which could add complexity for businesses wanting a more out-of-the-box solution.
Algolia’s pay-as-you-go pricing model can be an attractive option for smaller to mid-market companies due to its affordability, but there have been concerns about the transparency of its pricing, especially as usage scales. Reading online reviews, customer service experiences have been mixed, with some users reporting challenges in resolving issues without upgrading to more costly enterprise plans; though I’d always take such reports with a pinch of salt.
The need for fast accurate e-commerce site search means that Magento’s built in search is no longer fit for purpose. So what should we be using?
It depends on your situation and feature needs, but all other things being equal we can give some recommendations:
If I were using Adobe Commerce and had either limited product list customisation requirements, or the deeper pockets of a corporation to make its own interface I would definitely consider Adobe Live Search – it’s fast, well integrated and already included in the cost of Adobe Commerce.
For Magento Open Search or the mid-market Commerce customers for whom the Adobe Live Search limitations rule it out, I’d start looking at Algolia. They offer the speed and features of Search as a Service but with a price point that can be very attractive for lower traffic sites. If you need to control everything via an API, this is also a strong choice.
As your traffic or customisation needs increase I would then look at Klevu whose speed, features, support and customisability make them markets leader for several good reasons.
There may be no single best answer, but in 2023 there are some excellent choices available.
If you need some help with your Magento site search, C3 have over a decade of Magento expertise.