Migrate boosting

16 min

--- title: Migrate boosting slug: migrate-boosting excerpt: >- Migrate boosting configurations from Optimizely Search & Navigation to Optimizely Graph, including filter boosting, decay functions, and weighted scoring. deprecated: false hidden: false metadata: title: Migrate Boosting from Optimizely Search & Navigation to Optimizely Graph description: >- Learn how to migrate boosting configurations from Optimizely Search & Navigation to Optimizely Graph. Covers filter-based boosting, time decay, hit popularity boost, unified weights, and property boosting with code examples for both platforms. keywords:

Optimizely Find boosting migration

Optimizely Graph boosting

migrate boosting to Graph

Search and Navigation boosting

BoostMatching migration

auto-boosting decay

time decay Graph

hit popularity boost

unified weights migration

property boosting Graph

GraphQL boost parameter

filter boosting Graph

decay function Graph

factor operator Graph

search relevance scoring

Optimizely CMS search migration robots: index

Boosting changes the relevance score of search results so that certain content appears higher or lower. Boost based on business rules, content freshness, popularity, or field importance. Both Search & Navigation and Optimizely Graph support boosting, but they work differently.

Key differences

Search & Navigation provides five boosting features. The following table shows whether each has a Graph equivalent.

Search & Navigation feature	Graph equivalent	Status
BoostMatching (filter-based)	boost parameter on filter operators	Supported (different syntax)
Auto-boosting: decay	decay function on DateTime/Date fields	Partial (different curve model, fewer parameters)
Auto-boosting: hit (popularity) boost	No equivalent	Not supported (workaround available)
Unified weights and property boosting	boost on individual field predicates	Supported (no Admin UI)
Boosting with attributes	No equivalent	Not supported
No equivalent	BOOST_ONLY ranking mode	Graph only (scores using only boost values, ignoring text relevance)

Migration workflow

BoostMatching (filter-based boosting)

The BoostMatching method in Search & Navigation boosts results that match specific filter criteria. The following table shows how the BoostMatching settings compare between Search & Navigation and Graph.

Search & Navigation	Graph	Notes
Filter expression (x => x.InStock.Match(true))	where predicate with operator (InStock: { eq: true })
Boost factor (Double, for example 2)	boost parameter (Int, for example boost: 2)	Graph accepts Int only. Scale fractional values (for example, 1.5 and 3.0 become 15 and 30).
Multiple .BoostMatching() calls	_or clause with boost per operator
Combined filters (&)	Both conditions in the same object with boost on one operator
Negative boost (factor < 1.0)	Not supported	Workaround: give other conditions a higher boost, or use _not to exclude.

The following is a BoostMatching example in Search & Navigation:

var results = client.Search<Car>()
    .For("Volvo")
    .BoostMatching(x => x.InStock.Match(true), 2)
    .BoostMatching(x => x.SalesMargin.GreaterThan(0.2), 2)
    .BoostMatching(x => x.NewModelComingSoon.Match(true)
                      & x.InStock.Match(true), 5)
    .GetResult();

The following is the same BoostMatching example in Graph:

{
  Car(
    locale: en,
    where: {
      _fulltext: { contains: "Volvo" },
      _or: [
        { InStock: { eq: true, boost: 2 } },
        { SalesMargin: { gt: 0.2, boost: 2 } },
        {
          NewModelComingSoon: { eq: true, boost: 5 },
          InStock: { eq: true }
        }
      ]
    }
  ) {
    items {
      Name
      InStock
      SalesMargin
      _score
    }
  }
}

Apply the boost parameter to individual filter operators (for example, eq, gt, like, contains), not to logical blocks such as _and or _or.

Auto-boosting: time decay

Search & Navigation uses Weibull decay, and Graph uses Gaussian decay. These are different mathematical models, so the same parameter values produce different results. After migrating, test your queries and adjust scale and rate in Graph until the ranking meets your expectations.

In Search & Navigation, decay uses the document's last modified date (IChangeTrackable.Changed). This is hardcoded. In Graph, apply decay to any DateTime or Date field (for example, Changed, StartPublish, Created, or custom fields). To match Search & Navigation behavior, use the Changed field in Graph.

In Search & Navigation, UsingAutoBoost includes hit boost whenever statistics are enabled, so hit boost affects your decay results. In Graph, decay is independent, so your migrated decay scores may differ even with the same parameters.

Search & Navigation provides two configuration methods:

UsingAutoBoost() – Applies to all documents in the query.

ForInstancesOf<T>().SetDecayParameters() – Applies per content type.

Graph has no convention system. Each content type needs its own decay configuration directly in the query.

The following table shows how the Auto-boosting settings compare between Search & Navigation and Graph.

Search & Navigation	Graph	Notes
decayScale/scale (TimeSpan)	scale (Int, days only)	Must be >= 0. Convert hours and minutes to days.
decayOrigin/origin (DateTime)	origin (Date scalar)	Formats: YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ. Default: now().
decayMinimum/minimum (Double, 0.0-1.0)	rate (Float)	Valid range: [0..1). Defaults differ: Search & Navigation 0.2, Graph 0.5.
decayOffset/offset (TimeSpan)	No equivalent	Graph decay starts immediately from the origin.
decayShape/shape (Double)	No equivalent	Graph uses Gaussian decay with a fixed curve shape.

Method 1: UsingAutoBoost() (applies to all documents)

Search & Navigation:

var results = client.Search<BlogPost>()
    .For("Banana")
    .UsingAutoBoost(
        decayScale: TimeSpan.FromDays(14),
        decayOrigin: DateTime.UtcNow,
        decayMinimum: 0.2,
    ).GetResultAsync();

Graph:

{
  BlogPost(
    where: {
      _fulltext: { contains: "Banana" },
      Changed: {
        decay: {
          scale: 14,
          rate: 0.2
        }
      }
    }
  ) {
    items {
      Name
      Changed
      _score
    }
  }
}

Method 2: ForInstancesOf<T>().SetDecayParameters() (per content type):

Search & Navigation:

client.Conventions
    .ForInstancesOf<BlogPost>()
    .SetDecayParameters(new DateDecayParameters(
        scale: TimeSpan.FromDays(60),
        minimum: 0.3,
        origin: new DateTime(2024, 1, 1)
    ));

Graph:

{
  BlogPost(
    where: {
      Changed: { decay: { origin: "2024-01-01", scale: 60, rate: 0.3 } }
    }
  ) {
    items { Name Changed _score }
  }
}

If you use per-type conventions in Search & Navigation (for example, BlogPost decays over 60 days and NewsPage decays over 7 days), use separate Graph queries for each content type and merge the results in your application. You cannot compare _score values from different queries, so you may need to adjust scores before sorting.

Auto-boosting: Hit (popularity) boost

Hit boost in Search & Navigation is automatic. It tracks user clicks on search results and boosts frequently clicked documents in future searches.

Graph does not provide this feature. Graph search tracking only logs data and does not use click data in scoring.

As a workaround, collect click data from your own tracking system, store click counts in a numeric field on your content model (for example, NumClicks), and use the factor operator to boost by that field.

{
  BlogPost(
    where: {
      _fulltext: { contains: "Banana" },
      NumClicks: {
        gt: 1,
        factor: {
          value: 10.0,
          modifier: SQRT
        }
      }
    }
  ) {
    items {
      Name
      NumClicks
      _score
    }
  }
}

For more details about the factor operator and modifiers, see Graph Boosting documentation.

Unified weights and property boosting

In Search & Navigation, property boosting works with UnifiedSearch to search across all content types. Configure weights using the UsingUnifiedWeights() API or the Admin UI at Search & Navigation > Configure > Boosting.

In Graph, query with Content to search across all content types. Graph has no Admin UI and no weight system. Use the boost parameter in each query.

The following table shows how the properties compare between Search & Navigation and Graph.

Search & Navigation property	Graph equivalent on Content	Notes
SearchTitle	boost on Name	Name: { contains: "...", boost: 4 }
SearchText	No direct mapping	Query specific content types instead
SearchSummary	No direct mapping	Query specific content types instead
SearchAttachment	No direct mapping	Query specific content types instead

The following is a unified weights example in Search & Navigation:

var weights = new UnifiedWeightsValues()
{
    SearchTitle = 4.0,
    SearchText = 3.0,
    SearchSummary = 2.0,
    SearchAttachment = 1.0
};

var result = client.UnifiedSearch(Language.English)
    .For("Beethoven")
    .UsingUnifiedWeights(weights)
    .GetResult();

The following is a unified weights example using Content in Graph. Only Name maps to the Search & Navigation SearchTitle property.

{
  Content(
    locale: en,
    where: {
      Name: { contains: "Beethoven", boost: 4 }
    }
  ) {
    items {
      Name
      _score
    }
  }
}

The following is a unified weights example on specific content type in Graph, where you can boost all fields.

{
  ArticlePage(
    locale: en,
    where: {
      _or: [
        { Name: { contains: "Beethoven", boost: 4 } },
        { MainBody: { contains: "Beethoven", boost: 3 } },
        { Summary: { contains: "Beethoven", boost: 2 } },
        { AttachmentText: { contains: "Beethoven", boost: 1 } }
      ]
    }
  ) {
    items {
      Name
      _score
    }
  }
}

Field names (for example, MainBody, Summary, AttachmentText) depend on your content model. Check your Graph schema for the correct field names.

Boost with attributes

Boosting with attributes in Search & Navigation is specific to Product Recommendations. It boosts search results based on product attributes and personalization signals.

Graph does not have this feature. If you use this feature, handle the personalization logic in your application layer.