The average user should feel that searching on the site is easy. He is us to the intelligent search capabilities of Google and Yandex, and expects the same from any other search bar by default. You type, for example, “teliskp” or “porocytomol” and get a list of optical devices and pharmaceuticals with an indication of the catalog sections in which they are locat.
How does a website search engine understand what the user actually meant? Magic or science? Let’s try to figure out what threatens a business from insufficient attention to internal search, how it helps shorten the user’s path and improve conversion.
The Impact of Search Bar on Conversion
The search bar on your website is part of your sales funnel.
Zero results for a request = loss of a client. If the user did not find what he was looking for, you will not sell it to him.
How does Bitrix’s built-in search work?
The standard search module in “1C-Bitrix: Site Management” solves its tasks well when you just ne to find something without a complex context and conditions. Using the exact semantics of the request, it searches the entire text, headings, fields and tags in various sections of the site (catalog, news, knowlge base, blog, about the company, etc.). Such a full-text search is quite suitable if the site has a small assortment, does not require filtering, recent mobile phone number data does not ne to include promotional items in the results and does not ne to perform any complex conversion actions.
There are other nuances that can negatively affect the conversion of a site with a default search. For example, a request with a spelling error or an incorrect number in the product code will have a zero response, as will the conversion from search to the transition to the product card.
To offset the shortcomings of full-text search, it is supplement with facet filtering, but this is a few more extra steps on the way to a purchase. Meanwhile, visitors who search directly on the site are more convertible than the rest of the audience. analytics within the salesforce platform hey already know what they want to buy.
How to boost Bitrix search
Since version 14.0.0. in 1C-Bitrix products, support for the Sphinx full-text search system is available. It allows you to search faster and better, ruces the load on the server, and is also fully integrat with the components of the Search module. Unfortunately, the current version 3.x.x is still support by the Bitrix core.
Pros of Sphinx:
- high scalability, indexing and search spe;
- the presence of three built-in (ru, en, cs) gambler data and 12 plug-in morphological plugins for lemmatization (bringing a word to dictionary form) and stemming (finding the word stem for a given source word);
- full-text, facet, geo search and indexing;
- support for stop words, in case you ne to remove some words from search results;
- distribut search across multiple nodes (running Sphinx instances) in a cluster;
- ready-made integrations for various platforms and frameworks;
- moderate use of server memory.
Cons:
- limit API and no default fuzzy search;
- the ne to manually configure the index structure, which complicates scaling;
- performance degradation as data volumes increase;
- no visualization possible;
- small community.
Fast indexing makes Sphinx ideal for projects with low requirements for search functionality. But what if the project has grown, you want to scale, or you ne flexible management of search results?
Migrating search to Elasticsearch
Usually it is discuss when the current search engine of the site is not satisfactory for some reason. In conjunction with other developer products (the so-call Elastic Stack, ELK), this tool provides even more opportunities in managing search and data presentation.
- Log storage and analysis, data visualization. Today, this is almost a must-have for any Internet project, but only the ELK ecosystem can present data in a form convenient for analysis. It can process gigabytes of data from balancers
Elasticsearch for Search
Elasticsearch uses indices to organize and store data. An index is a logical storage where documents of the same type are organiz.
In order for data to get into ES indexes, it cannot be simply pull from the site database “as is”. This “raw” data nes to be index. To create an index, the system’s own API is us, which nes to be call from somewhere. This can be done by event handlers in Bitrix or an agent that will periodically update the data, or a queue server. It is very convenient to work with Kibana from the ELK stack.
Below is an example of an index with manual field mapping. The index can be creat using the REST API or a ready-made library for working with it. The best result is obtain with a combination of dynamic and explicit mapping; you can create your own tricky field mapping rules.
