Skip to main content
The Boost with Signals query pipeline stage uses aggregated signals to selectively boost items in the set of search results. Using the main query and the stage configuration parameters, this stage performs a secondary query to the COLLECTION_NAME_signals_aggr collection and returns updated boost weights for the items in the main query’s search results. Items that have received more user interaction also receive higher boost weights. See Recommendation Methods for more information. This stage supports asynchronous processing.
This stage accesses the signals_aggr collection. Before using it, verify that the following permission is set:
GET:/solr/COLLECTION_NAME_signals_aggr/select

​
Signal sources

This stage works with aggregated signals from two sources:

​
Fusion native signals

Signals captured via the Fusion Signals API and aggregated by Fusion’s SQL aggregation jobs. Collection: {APP_NAME}_signals_aggr (created by Fusion aggregation jobs) Aggregation Type values: Typically clicks, sessions, or custom aggregation types configured in Fusion

​
Platform signals

Pre-aggregated signals from Lucidworks Platform can be captured via Signals Beacon or Platform Signals API, then retrieved and indexed by Fusion. Collection: {APP_NAME}_signals_aggr (populated by Fusion) Aggregation Type values: Platform formula names such as formula1, formula2, configured in Platform signals integration Configuration differences for Platform signals:
  • Aggregation Type: Set to the Platform formula name (e.g., formula1)
  • Rollup Field: Use doc_id (without _s suffix)
  • Rollup Weight Strategy: Use weight_d
See Platform Signals Integration for setup details.

​
Configuration overview

The fields below are especially useful to understand when configuring this stage.

​
Solr query parameters

These parameters are used in the Solr Query parameters/queryParams field for retrieving signal aggregation docs from the COLLECTION_NAME_signals_aggr collection. These Solr query params will affect which aggregated signals are used for producing the boosting parameter on the main query.

​
FAQs

If there is fq in the main query, how is it matched with the correct aggregated signal? In this case, you need to use the lw.rec.fq query parameter in the main query. lw.rec.fq can be parsed by the Boost with Signals stage, and therefore the filters specified in it can be added to the Solr query that is retrieving the aggregated signals. For example, if we have filter query param fq=format:CD&fq=name:Latin, this needs to be translated into lw.rec.fq=filters_s:"format:cd $ name:latin". Values must be lowercase. The final main query should be:
Now the Boost with Signals stage will only retrieve aggregated signals that have the same filter query.
If there are multiple fq values (for example, format:cd and name:latin), they are ordered alphabetically as strings and joined with ” "(a" (a with a space on each side). In the example, "format:cd $ name:latin".
What if my aggregated signals are in a different collection? You can point the Boost with Signals stage to a different signal collection by adding a collection parameter in the Solr Query Parameters section. BwS collection

​
Query pipeline stage condition examples

Stages can be triggered conditionally when a script in the Condition field evaluates to true. Some examples are shown below. Run this stage only for mobile clients:
Run this stage when debugging is enabled:
Run this stage when the query includes a specific term:
Run this stage when multiple conditions are met:
The first condition checks that the request parameter “fusion-user-name” is present and has the value “SuperUser”. The second condition checks that the request parameter “isFusionPluginQuery” is not present.

​
Configuration

When entering configuration values in the UI, use unescaped characters, such as \t for the tab character. When entering configuration values in the API, use escaped characters, such as \\t for the tab character.