LogoLogo
Support
Product Discovery Developer Guide
Product Discovery Developer Guide
  • Product Discovery Developer Guide
  • πŸ›’Item catalog management
    • What is the Items API?
    • How to work with Items
      • Item Schema
        • Attributes
        • Nested Item Schemas
        • Using the Item Schema API
        • DefaultLocale API
        • Onboarding on/migrating to Fredhopper
        • List of Reserved Attributes
      • Category Tree
        • Using the Category Tree API
        • Onboarding on XO
      • Item Catalog
        • Using the Catalog API
      • Items
        • Using the streaming Items API
        • Using the batch Items API
    • Step by Step guide
      • Step by step guide for Fredhopper customers
    • Feedback
      • Using the Feedback API
    • Authorization to APIs
    • Troubleshooting API errors
  • 🎯XO Recommendations
    • Introduction
    • Using the Recommendations API
    • Setting up the Chrome extension
    • Micro-segmentation
    • XO Legacy APIs
  • πŸ”ŽXO Search
    • Introduction
    • Getting started
    • API Reference
      • Search API
      • Autocomplete API (Beta)
      • Product Suggest API
    • API Parameters
      • Search
      • Pagination
      • Faceting
      • Sorting
      • Grouping
      • Filtering
      • Disable features
      • Response mask
      • Context
    • Configuration limitation
  • πŸ§ͺA/B testing
    • Fredhopper A/B testing
      • Integration steps for a non-caching solution
      • Integration steps for a caching solution
        • Java SDK Integration
          • Setup
          • Retrieve running A/B tests - Java SDK
          • Filter and request variant - Java SDK
          • Extending the SDK
        • Manual A/B tests integration
          • Retrieve running A/B tests
          • Filter out irrelevant A/B tests
          • Assign variants to user
          • Request variant for page
        • Limitations and Best Practices
  • πŸ“šResources
    • Glossary
    • Best Practices
      • Tracker Best Practices
      • Items API Best Practices
      • Fredhopper Data Configuration Best Practices
      • Fredhopper Query Response Best Practices
      • Fredhopper Merchandising Studio Best Practices
    • Privacy Notice
  • Archived Pages
    • FHR Tracking plan
    • XO Tracking plan
    • The Tracking API and JS Library
      • What to Track
        • Generic Actions
          • View
          • Click
          • Add to Cart
          • Remove from Cart
          • Purchase
        • Custom Actions
      • Initializing the JavaScript Library
      • REST API Technical Documentation
Powered by GitBook

Copyright @ 2024 Crownpeak Technology, Inc. All rights reserved.

On this page
  • Synonyms
  • Facets
  • Item Campaigns
  • Move Modifications
  • Rankings
  • Ranking Cocktails
  • Triggers
  1. Resources
  2. Best Practices

Fredhopper Merchandising Studio Best Practices

These are some best practices to follow when configuring the merchandising studio to optimise performance.

For each merchandising studio parameter listed, there is a recommend optimal setting or limit, and if applicable an acceptable upper limit. Ignoring a recommendation won't individually cause an issue, but when combined with other recommendations being exceeded, it may lead to performance issues.

Synonyms

The number and complexity of synonyms will affect performance.

The complexity of a synonyms rule can be defined as the number of keywords in the synonym definition (e.g. "clearance, discount > sale, outlet, promo" has complexity 5).

More complex synonyms rules lead to more complex search queries because many alternative phrases will be generated, by creating all possible combinations of tokens.

Another metric to consider is the number and complexity of synonyms applied per query.

Recommendations

Keep your synonym rules simple, avoid redundancy and duplication.

Limit the number of synonym rules in your queries.

Facets

The number of facets you configure will directly impact the performance of merchandising and search results.

Facet performance will be impacted by:

  • The number of rendered facets

  • The number of values per rendered facet

Avoid triggering too many facets per query, anything higher than 10 should be optimized.

Facets that display a large number of values are slower than facets that display, for example, only the top 10 values (and use a more link).

Calculating a facet is particularly expensive if the number of results is very high (e.g. > 5000).

Some strategies to reduce the number of triggered facets are:

  • Generate facets at lower category levels or higher navigation steps, where there are much less items than at top level categories.

  • Generate some facets if the number of results is below some threshold, like 5000 items.

Both the above strategies can be implemented by adding the respective triggers to the facets, i.e. Navigation Steps trigger and Number of results trigger.

Recommendations

Limit the number of facets returned in a query.

Optimal limit: Up to 5 facets per query. Acceptable limit: Up to 10 facets per query.

Reduce the number of triggered facets on navigation and search queries.

Limit the number of facets per page when the user hasn't selected any, once they have selected some you can return more relevant facets.

Limit your use of facets based on ranking cocktails when you have a large number of results.

When using facets with a high number of options, limit them to 10 values with a more link.

Item Campaigns

Recommendation

Work with your team to make sure campaigns have been implemented to return at most 2 campaigns per query.

Move Modifications

Move modifications can become expensive and have multiple factors can impact their performance:

  • Number of applied modification rules

  • Individual items moved

  • Number of blocked items

  • Number of modification groups from dynamic location

  • Sorting based on a ranking cocktail

The more of these factors applied to a move modification, the more it will impact performance.

Recommendations

In some cases a move modification can be replaced by clever use of ranking. Check if your front-end integration can be modifed, and if a new attribute added to reflect this property and sort by this attribute.

Where possible reduce the number of triggered move modifications that use ranking cocktails for sorting, use regular attributes for sorting.

Rankings

Rankings can use multiple attributes to sort items, but the more you add will affect performance. More than five attributes is not recommended.

Ranking can become slow if there are many unique values in a data set. It is best to rank on attributes with many common/shared values (for example clothing size or color), and rank a second attribute as well. Sorting on an attribute with a unique value for every item is possible, but will be slow on large data sets.

Recommendation

Optimal limit: Reduce the number of sort attributes to 3.

Acceptable limit: Up to 5 sort attributes.

Ranking Cocktails

Rankings based on ranking cocktails are more expensive than those based on regular attributes.

If a ranking cocktail uses normalization, FAS has to calculate the ranking cocktail value of each item found by the query to find the minimum and maximum, which can be potentially tens of thousands of items.

Recommendation

Where possible limit usage of ranking cocktails in top level or large categories:

Optimal limit: Up to 1000 results.

Acceptable limit: Up to 5000 results

Triggers

When a query is processed, all active triggers that belong to that query’s universe/locale are evaluated.

The more triggers, and the greater the complexity of those triggers, the longer the query will take to process.

These factors will impact performance of the individual triggers:

  • Keyword triggers using contains are more complex than those using exact match. This will be exacerbated if there are multiple keywords and those keywords are expanded by synonyms.

  • Value Distribution triggers require calculations on the navigation index, therefore the size of that index will impact it's performance.

Recommendation

Optimal limit: Up to 1000 triggers per locale.

Acceptable limit: Up to 5000 triggers per locale.

PreviousFredhopper Query Response Best PracticesNextPrivacy Notice

Last updated 7 months ago

When implementing campaigns please consider the number of items returned per campaign. Combined with , this may impact performance.

πŸ“š
multiple campaigns being triggered in a query