Verndale Receives 2022 Sitecore Partner Awards
Aug 03, 2022 • 1 Minute Read • Jim King, VP, Partenariats et alliances
See All Our Insights
The Tech to Optimize Website Product Search
Aug 18, 2022 • 5 Minute Read • Bill Cronin, Directeur technique
The road visitors take to arrive at your website is unique for different types of visitors. New visitors often arrive through a search engine like Google. This hopefully gets them to the exact page they're looking for. However, that's not always the case. Some new visitors from Google will come from paid searches, which also doesn’t always land the buyer exactly where they need to be. And what about your most important shoppers – repeat visitors? Building a repeat customer base with high lifetime value (LTV) is a great way to keep your most profitable sales rolling in. So, how do you get the right shopper to the right content at the right time?
The on-site search and browsing feature's design is like that for this exact purpose.
In digital commerce, specifically B2B ecommerce, on-site search is critical to helping customers find products. When a seller offers hundreds of thousands or even millions of products, “browsing” is not the best way for buyers to find what they want. There could be hundreds of products that appear nearly identical, so much so that they may even use the same image. Plus, the buyers may not even know what they’re buying – they could be procurement staff purchasing by part number to complete a bill of materials.
Search tools to the rescue! Analytics often tie this out. Site owners can agonize over the ideal product hierarchy – only to learn through analytics that most users aren’t using the “browse” function. Later, we’ll discuss the browsing experience in search tools and how it's better for shoppers who choose to shop this way.
Platforms with Search Options
Depending on your platform, there are several onsite search options available. Most of these options are based on either Solr or Elasticsearch – with some brand-specific “special sauce” built in to provide differentiation and competitive advantage. Whatever your platform and choice, the search platforms all work against the same basic Lucene parsing, indexing, and retrieval engine.
Optimizely B2B uses Elasticsearch. Recently, they've opened the options up to allow the implementation of a search interface. Hawksearch is the first to be offered, and I imagine there are more coming in the future.
Optimizely DXP features “Search & Navigation” and is a tool based on Elasticsearch, with some optimizations like integrated AI to better “learn” what results are best.
Sitecore has a few options. Until recently, you had to either roll your own with Solr, or invest in Coveo. A home-brewed Solr-based solution can be effective for simple searches but usually lacks integrated features like user-managed synonyms, reporting on “poor” search results, and custom indexing types. These features could all be built of course, but most organizations choose not to as Solr was chosen for the low implementation and ongoing hosting costs.
Coveo is an outstanding product, and there are a few options for the implementation method. Coveo for Sitecore integrates indexing into the Sitecore publish process. The Coveo Stream API allows data to be pushed into the index outside the Sitecore publish process. Coveo can also use the Sitemap XML as a source to drive a site crawl. Finally, Sitecore acquired Reflektion in late 2021 and serves as their search offering as part of the composable DXP model.
Other than a homegrown Solr solution for Sitecore, all the options discussed above offer basically the same set of tools: user modifiable synonym lists, “fuzziness” tuning, and field-level modification of indexing types. That last bit is particularly interesting for data elements like product numbers, both internal ERP SKU numbers and manufacturer part numbers.
A Brief Tip for SKUs & Manufacturer Part Numbers:
SKUs and manufacturer part numbers should have special indexers that look at the part numbers both with and without special characters, as well as Ngram indexing. Ngram indexing will index segments of the part numbers to return relevant results for partial matches. For example, if your product numbers are formatted like ABC12345 and your customers normally search for only the numeric segments, 12345 will be indexed and a search for it will return a match for the product.
All this technology for search is great for customers using the onsite search feature, but what else do these tools bring to the table?
In most instances, the engine that drives search also drives product browse. This engine is where some additional magic happens. Information such as sales by customer, browsing history by the user, and “wisdom of the crowd” AI modeling can inject additional information into the index to make certain products bubble to the top of the list when browsing – even tailored to individual users. Tailoring additional results is usually limited to the default sort order, or relevance when browsing. As a user, personally, I’m not too fond of it when I choose to sort by Product Name and marketers have promoted products in such a way that they're not in alphabetical order. However, in relevance sort order, this type of additional information can be a fantastic way to get the right product in front of the right person at the right time. Additionally, facets can be added for data elements such as previously purchased or in stock, allowing your customers' search to be further refined so they see the products they're looking for.
Special Cases Relevant to B2B Commerce
In B2B commerce, pricing and in particular sorting or filtering results by pricing can pose unique challenges. Often, pricing is fetched for products in real-time from an ERP system. This is because there are either too many product/customer/price combinations to effectively integrate or the pricing changes so often that it’s not feasible to integrate it effectively. Since all the data that we need to sort or filter must be present at indexing time, this makes it very difficult to make a performant system.
Finally, product restrictions are another challenge, especially with composable DXP environments. Product restrictions occur when some products are only available for sale or viewing to specific customers, such as with a distributor who carries multiple brands with exclusive territories. A customer may be eligible to purchase products from brand A in state 1, but not brand B.
How the restrictions are handled now and in the future will determine the level of attention paid to the architecture. The commerce system isn't the “system of record” for product data, but it is for product restrictions. Therefore, the search and browse features need to be driven by that system. Alternatively, product data would need to be provided to and kept up to date by the system that "owns" the search.
Search and browse are two facilities that may seem very different on the surface, but underneath are typically tightly coupled. Understanding the tools these systems can leverage and getting them the data to maximize their potential is the key to getting the right content in front of the right user at the right time.
Want to learn more about search and browse systems for your platform and how to maximize their potential? Contact us to discuss your website product search strategy.