Analytics & Reports

Navigation Recommendations (iNav)

As part of every search response, the engine will return a set of Dynamic Navigation, which shows your users what refinements are available for the given set of records shown.

This is most commonly used to drive the navigation menu for Search, but can be used for other purposes as well - for example, if you want to create a carousel or another set of refinement options.

iNav is the functionality of the Recommendations API that lets you re-order the navigations, or their refinements, by popularity. You can specify filters like duration (popular in the last week or month), region (to make the order geospecific), and other custom filters.


In this visualization we see two kinds of Navigation orders side by side. On the left, is the order that was decided by the Merchandiser. On the right, is the proposed order from the Recommendations API.


Our front end can decide which information to use from the Recommendation API. For example, on the front end we can choose to always show Price second, even if it was the most popular refinement used.

Sample query

We will use the refinements/_getPopular call of the Recommendation API to fetch popular refinements.

You can try other Recommendation Endpoints here.

The response will contain both the refinements (e.g. brand) and the values (e.g. Nike).

Sample call
Send requests directly from the browser (CORS must be enabled)
2 variables not set

Integration Paths

For each integration you’ll need to decide 3 things:

  1. Will we use the navigation order information? (E.g. "Price goes ahead of Color")
  2. Will we use the refinement values order information? (E.g. "grey goes ahead of blue")
  3. Will we want to give merchandiser some control via Command Center? (e.g. “never show Price first”)

The first two decisions will drive which sections of the Recommendation API response you will be using.

The last decision is important as it lets you integrate Merchandiser requirements via the Navigation metadata. The original Search API response that returned the Dynamic Navigations available also returns metadata, which can be leveraged to “pin” certain values, navigations, and integrate other business logic.

Logic For Development

You will have 2 responses:

  1. Search API response that contains the available navigation for given results. This needs to be integrated so that you show navigations that are actively available for the current results. This will also contain metadata if you are planning to integrate business logic into your navigation.
  2. The Recommendations API response that will give you the suggested ranking of the values, by their JSON address.

You will need to:

  • For each value in the available navigation…
  • Check against the business logic
  • Check against the Recommendations response …
  • And render it into the appropriate section of your navigation

This logic applies equally to Navigations and their Refinements, as both Search and Recommendation return both values within one nested array.

Sample Business Logic to Integrate

This is a list of best-practices business requirements to discuss with your business and technical teams for implementing dynamic navigation:

Requirement Action
Never show some navigations Exclude at query time with excludeNavigations
Sometimes not show some navigations? Ask the business to tag the navs to hide with a key-value setting within Command Center, such as key: display - value:false. Look for this value to be absent or true before rendering.
Pin some navs to the top? Ask the business to tag the navs to pin with a key-value setting within Command Center, such as key: location - value:1. Look for this value to drive the rank of the navigation for rendering.
Pin some values to the top? Ask the business to tag the values to pin with a key-value setting within Command Center, where the key will the value to pin. For example to pin Blue to the top of colors, ask them to add the metadata of key: Blue - value: 1. Look for this value to drive the order of refinements for rendering.
Other requirement that requires merchandiser decision Design around the same pattern of key-values