Searching with your own search index¶
Our service works on top of an existing search infrastructure. We currently support Apache Solr (with the Query Elevation Component enabled) and Elasticsearch. In case you are already using either of these two, we can connect to your own Apache Solr/Elasticsearch. This means that your data remains entirely yours, and that you don't need to change your web app to parse the search result format. To access your search infrastructure (Apache Solr or Elasticsearch), our REST app needs to be able to connect to your search engine. During the setup of the system we propose a way that suits your settings and requirements. In case there is no existing search infrastructure available, please refer to our Cloud Indexing documentation.
We assume that a web app is present on the client side. This app communicates with our REST app and serves your website. Other than this, there are no prerequisites for using 904Labs A.I. for Search service.
904Labs A.I. for Seach works with multiple consecutive calls from your web app to our REST app. Our REST app, in turn, makes several calls to the existing search engine (Apache Solr or Elasticsearch). In a common setup, the workflow consists of eleven steps.
|A visitor searches on your website and sends a text query to your web app.|
|Your web app sends the visitor's text query to our suggest endpoint. See POST /suggest for the request details.|
|Our REST app communicates with your Apache Solr/Elasticsearch to find appropriate suggestions.|
|Our REST app returns suggestions for the query to to your web app. See POST /suggest for the response details.|
|Your web app shows the suggestions to the visitor. When the visitor selects a suggested query or hits enter to submit her query, the workflow continues. If a category or specific product is selected, the visitor is directed to the appropriate page (see GET /browse for optimizing category pages).|
|Your web app sends the original or suggested text query to our search endpoint. See POST /search for the request details.|
|Our REST app communicates with your Apache Solr/Elasticsearch to construct a ranked list of items for the given query.|
|Our REST app returns a modified sls query to your web app. See POST /search for the response details.|
|Your web app fires the sls query to Elasticsearch or to an Apache Solr core endpoint that has the Query Elevation Component enabled (e.g., /elevate). It receives a ranked list of items in the same format as in the current situation.|
|Your web app formats the ranked list and shows the results to the visitor. When the visitor interacts with the results (e.g., clicks, adds-to-basket), the web app records these feedback signals.|
|Your web app sends the feedback signals to our feedback endpoint. See POST /feedback for the request details.|
904Labs provides three API endpoints to facilitate the workflow described above:
POST /suggest for providing suggestions for queries (typeahead), categories, and products.
POST /search for ranking items based on the original or suggested query.
POST /feedback for sending visitors' feedback signals (e.g., clicks, add-to-basket).
- Steps 2 to 5 are optional. Your web app could also directly send the visitor's text query to the /search endpoint and receive a modified sls query.
- There is no need for caching of results. 904Labs A.I. for Search is using sophisticated caching strategies for serving requests as fast as possible. We take away processing load from your search infrastructure and move it to our own servers. This also speeds up response times by minimizing network traffic between your and our servers. Since caching is already in place, we strongly recommend not to use any caching on 904Labs' results at your end. First, it is very difficult to synchronize independent caches. Second, it leads to loosing important feedback from which 904Labs A.I. for Search learns.
For more information or questions, please send an email to email@example.com