Disclaimer: This website requires Please enable JavaScript in your browser settings for the best experience.

HomeDev GuideAPI Reference
Dev GuideAPI ReferenceLegal TermsDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Architecture and languages

Describes built-in functionality and the underlying technology, and supported languages in Optimizely Search & Navigation.

Optimizely Search & Navigation is a powerful, scalable query platform that can index and query large amounts of structured or unstructured data of any type, create custom search functionality, and build advanced navigation for non-hierarchical content.

Optimizely Search & Navigation includes the following functionality:

📘

Note

To ensure maximum availability and scaling flexibility, Optimizely Search & Navigation uses dynamic IP ranges. If you for example require whitelisting of IP addresses in the firewall, make sure that your firewall supports domain-based whitelisting.

Architecture

Optimizely Search & Navigation consists of a back-end software service and a front-end facing client used to build the site search functionality. Various integration options for integrating Search & Navigation with Optimizely Content Management System (CMS), Optimizely Customized Commerce, and other platforms are available. Optimizely Search & Navigation is the default search solution when running CMS using the Optimizely Digital Experience Platform cloud service.

Numerous back-end systems, based on modern infrastructure components, are used behind the scenes for provisioning, indexing, querying, and monitoring the service.

Provisioning of service account and index

Indexing content

Querying content

REST API

Optimizely Search & Navigation uses the Elasticsearch search engine. The Optimizely Search & Navigation API enforces several conventions and restrictions to be aware of, such as adding mappings (automatically handled by the conventions) and adding and removing indexes.

Integration

Optimizely Search & Navigation is the foundation for search functionality in CMS and Optimizely Customized Commerce. A .NET-based client API integrates it and interacts with the REST API through JavaScript using JSON. However, Optimizely Search & Navigation is not limited to being used from .NET.

🚧

Important

Optimizely Search & Navigation does not support direct use of the JSON API, as there is no way to secure the connection without exposing the access key. In general, do not implement client-side requests directly to Optimizely Search & Navigation.

Language support and analysis

You can index any content language, but Optimizely Search & Navigation uses a language analyzer to get the best search results for a specific set of content languages. When purchasing Optimizely Search & Navigation, you will order an index and specify analyzer support for a defined group of languages.

Search queries in any of these supported languages will run through the language analyzer, and the search results delivered are richer and more nuanced than for unsupported content languages. While Optimizely Search & Navigation indexes the content in unsupported languages, it does no analysis. See Elasticsearch Analysis and Analyzers.

The language analyzer breaks down text based on a language's characteristics. For example, the English analyzer might use stemming analysis to identify fish as the root word for fishing, fished, fishes, fisher, and fisherman. By understanding how to construct a language's words, Search & Navigation can recognize several versions of a word as the same term, providing better search results. Likewise, Optimizely Search & Navigation optimization only works with supported languages.

Optimizely Search & Navigation's analysis and optimization features supports the following indexing languages.

Indexing languages with analytics support

  • Arabic
  • Armenian
  • Basque
  • Brazilian
  • Bulgarian
  • Catalan
  • Chinese
  • CJK (Chinese, Japanese, and Korean)
  • Czech
  • Danish
  • Dutch
  • English
  • Finnish
  • French
  • Galician
  • German
  • Greek
  • Hindi
  • Hungarian
  • Indonesian
  • Irish
  • Italian
  • Latvian
  • Norwegian
  • Persian
  • Polish
  • Portuguese
  • Romanian
  • Russian
  • Spanish
  • Swedish
  • Thai
  • Turkish

See also Language-specific queries.

📘

Notes

Since language codes in FIND are limited we use fallback language for search analyzer and bestbets settings. In case you select and search for language Norwegian (Nynorsk)(nn-NO)which known as Norwegian but in FIND we only know Norwegian(no) code so that search request could return results with unexpected analyzer. To correct it, from FIND 16.4.0 we allow developers to add the language mapping by key LanguageMaps inside Find section which will define the fallback from [language code] to [other language code]. We define nn and nb fallback to no as below example:

    "Find": {
      "DefaultIndex": "your_idex",
      "ServiceUrl": "service_url",
      "LanguageMaps": {
        "nn": "no",
        "nb": "no"
      }
    }

Compound splitting

​​​Many European languages contain compound words, such as the English term "steel thermos." In Swedish, that phrase is "ståltermos," one word. Compound words adversely affect relevancy for normal free-text search engines, especially for ecommerce, and can result in lower conversion rates.

Optimizely Search & Navigation uniquely includes a feature called compound splitting, which analyzes each word and discovers compound words. To continue the previous example, a visitor can search for the Swedish word "termos" and get a relevant match for "ståltermos". Most search solutions (including Elasticsearch) do not include such functionality. And solutions that usually employ a less sophisticated approach that does not give the same high relevancy and associated conversion rates.

Compound splitting is available for Swedish and Norwegian.

Turn decompounding on and off

[New in Optimizely.Search & Navigation 12.3.0]

The default query setting is to not decompound the query string. To enable decompounding, use this syntax:

.For("query", x => x.Analyzer = Language.Swedish.Analyzer)

If a user submits a search term fotbollsmatch, the query only matches fotbollsmatch/er/en/… and not (as it did previously) ‘fotboll/ar/en/..’ and match/er/en/….

On the other hand, if a user submits the search term fotboll, the search matches fotboll/ar/en…, fotbollsmatch/er/en/…, and fotbollsplan/er/en.

See also: Elasticsearch guide