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).

Scenario 1 | Coveo
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).

Scenario 2 | Coveo
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.

Scenario 3 | Coveo
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.