Design an architecture for multiple search experiences
Design an architecture for multiple search experiences
The Coveo Platform can serve many purposes, from the classic search page to listing pages, support portal, and Case Deflection panels, among other things, each of which offers a different experience to your users.
When designing multiple search experiences that use the Coveo Platform, you need to think about how best to separate these experiences. This article presents the leading practices to follow when doing that, as well as some example scenarios that follow these practices.
Leading practices
Apply the following leading practices to design a functional and flexible search experience architecture:
-
Each search experience should have its own search hub
This is for usage analytics and queries per month (QPM) reporting, as well as for Coveo Machine Learning (Coveo ML) purposes. Using different search hubs ensures that your ML models provide the right suggestions for the right search experiences.
Furthermore, a search experience without a search hub is inaccessible from a reporting and a Coveo ML perspective, but still counts towards your maximum allowed queries.
-
The global search box should have the same search hub as the search page it redirects queries to
This is to ensure that your global search box and global search page suggests the same queries.
-
Search experiences with similar purposes and rules should use the same query pipeline
This is to ease the addition or deletion of rules inside query pipelines, and to prevent unnecessary duplication.
-
Search experiences with different purposes should have different query pipelines
This is to easily divide your experiences, so rules can be added or deleted in one experience without affecting the other.
-
When various audiences are using the same search experience, use a single query pipeline, but send custom user context information along with each search request and usage analytics event
This is so Coveo ML can learn trends among your different audiences without creating a new, separate model for each.
Examples
The following examples contextualize these leading practices.
Scenario 1: Website with multiple search pages
You have a public website that leverages the Coveo Platform in many places.
Aside from your global search page accessible from the search box in your header, you have the following search experiences:
-
A dedicated search page listing your different products and solutions
-
A documentation-focused search page
-
A blog post listing page
For these experiences, you create the following search hubs:
-
global-search
used for your global search box and global search page -
product-listing
used for your product and solution listing page -
doc-search
used for your documentation search page -
blog-listing
used for your blog post listing page
Since these experiences are related and share the same terminology and rules, you decide to put them all in the same query pipeline.
This way, each search hub has its own Query Suggestion (QS) and Automatic Relevance Tuning (ART) boosts. All of your search experiences share the same query pipeline rules (see Query pipeline features).
Note
Dark-lined box: Query pipeline Blue-lined box: Search hub Green-lined box: Search experience |
Scenario 2: Coveo for multiple use cases
You’re leveraging the Coveo Platform on your ecommerce website (shop.example.com
), support portal (support.example.com
), and on your intranet (employees.example.com
).
Your sites have the following search experiences:
-
Commerce:
-
Global search page
-
-
Support:
-
Case deflection
-
Documentation search
-
-
Intranet:
-
Global search page
-
HR resources
-
People search
-
For these experiences, you create the following search hubs:
-
commerce-search
for your global commerce search page -
support-deflect
for your support case deflection experience -
support-doc
for your documentation search on your support portal -
intra-global
for the global search page of your intranet -
intra-hr
for your HR resources search page of your intranet -
intra-people
for the people search of your intranet
Since your experiences are separated on three different websites, with people that use different terminology and have widely different needs, you decide to use three query pipelines - one for each site.
This way, each distinct search hub has its own Coveo ML QS and ART boosts. Your three sites also have separate query pipeline rules, though all of your search experiences within a given site share the same rules (see Query pipeline features).
Note
Dark-lined box: Query pipeline Blue-lined box: Search hub Green-lined box: Search experience |
Scenario 3: Coveo for multiple audiences
You have a product used by audiences with very different sets of skills and challenges to overcome. You have identified the following main expertise profiles:
-
Audio Designers
-
Programmers
-
Visual Artists
-
Writers
All of your different audiences are looking to solve their own challenges using your product.
You use the Coveo Platform on your help portal, where you have a search page that surfaces all of your product documentation for these different profiles.
You decide to have only one search hub for your help portal, and only one query pipeline. However, when sending your queries and usage analytics events to the Coveo Platform, you ensure that the current user profile is sent as custom context information.
In this scenario, Coveo ML doesn’t filter its recommendations based on the audience. Instead, it uses context for added personalization, meaning that some recommendations will be specific to a certain audience, while others will be shared among different audiences.
Note
Dark-lined box: Query pipeline Blue-lined box: Search hub Green-lined box: Search experience Orange-lined box: Audience |
What’s next?
The Tune relevance section explains how you can improve the relevance of your search interface.