- Rule conditions
- Rule actions
- Query pipeline stages for rules
- Rules on response signals
- Rules and experiments
Business rules are manually-created formulas for rewriting queries. This is the most versatile strategy for creating custom query rewrites. It supports a variety of conditions and actions to address a wide range of use cases. When you need a very specific query rewrite, this is the best strategy.
Business rules are applied in the Apply Rules stage of the query pipeline.
|When a query triggers a business rule, then the business rule overrides any query rewriting strategies that conflict with it.|
A rule can have one or more conditions which define the criteria that trigger the rule’s actions. The + Add Condition button allows you to add a condition type to a rule, and you can add multiple conditions to the same rule. When multiple conditions are defined, they are joined by Boolean OR, that is, one or more conditions must be met in order to trigger the rule.
Since the Query condition can be configured with multiple criteria, you only need one condition of that type per rule.
To configure a rule that always fires with every query, select no conditions.
Multiple conditions of different types are joined by Boolean OR, that is, the rule is triggered when one or more conditions of different types are met.
By default, multiple field value conditions are joined by Boolean OR. To use AND so that all field value conditions must be met, go to the Apply Rules query pipeline stage and de-select Partially Matched Filter Queries Will Trigger the Rule.
Condition types are described below:
The rule is applied only during the specified date and time range, which can be open-ended.
The rule is applied when the query terms match using one of the following methods:
The query term exactly matches one or more specified query terms. Keyword matching is case-insensitive. Multiple keywords can be specified with a comma delimiter.Tip
This is the fastest type of query matching.
The query term is matched using text tokenization. For example, "customer" matches "customer service" and "customer help".
Enter one or more query terms to match using the selected method. When you enter multiple terms, any match against one of them will trigger the action (logical OR).
This condition type identifies a predefined field name and value that may be present in the Solr filter query parameter (
fq), such as an "on_sale" field whose value is "true". In that example, your rule could block results whose "on_sale" field value is "false".
Field Value conditions require whole-field exact matches and are generally called programmatically, by a link to a category or a click on a facet.
A rule can have one or more actions that are triggered when the rule’s conditions are met by the incoming query.
Built-in rule actions
Boost particular items to the top of the results.
For example, boost gift items on sale to the top of search results during the first weeks of December.
Display a user-defined banner message when the rule fires.
For example, a search for "office dvd" could return a results page that includes a special banner that advertises "The Office DVD boxed set: Now 50% off".
When the condition is met, the rule down-ranks all the documents with the specified field values for the given field name. Use this action when you want to minimize certain results without blocking them.
Suppress one or more items from the list of results.
This rule type corresponds to the Additional Query Parameters stage and permits the complex modeling of a rule.
Change the results so only a specified set of content is shown.
For example, a search for "kids movies" could return only the titles whose
MPAA_ratingfield matches "G" or "PG".
Send users to a different URL instead of the search results.
For example, a search for "black friday" could redirect users to a special sale page instead of a list of products that match "black" and "friday".
This action boosts documents with specific attributes by adding the
boostparameter to the incoming Solr request and executing a boost query.
When the condition is met, the boost query is executed and the docs returned from the boost query are boosted in the results. For example, this action can be used to boost items where
color="red"when the incoming query contains "red".
My Custom Rule
Select an alternate query pipeline that implements special processing for this rule. See below for more details.
Query Elevation Component for Rule Actions
Fusion AI currently supports the use of the Query Elevation Component (QEC) with boost lists and filter lists. You must configure Solr in order to enable the QEC option.
Create an XML file named
elevate.xmlin the same directory as the
solrconfig.xmlfile. Use the following as the contents of the file:
<?xml version="1.0" encoding="UTF-8" ?> <elevate> </elevate>Note
Although it will not be accessed for the elevation process, Fusion requires this independent
elevate.xmlfile for the use of built-in rule actions with QEC.
Add the following in the elevator searchComponent:
Add elevate as a 'last component' part of the select handler in the
solrconfig.xmlfile. If a
last-componentsarray is not already defined, create it at the end of the select handler’s configuration. If one is already defined, add
<arr name="last-components"> <str>spellcheck</str> <str>elevator</str> </arr>
When you create a new business rule, check the USE QUERY ELEVATION COMPONENT checkbox to use elevation.
The Query Elevation Component only elevates documents within the query rewriting rules engine by the document
Query pipeline stages for rules
These stages are part of the default query pipeline:
This stage looks up rules that have been deployed to the
_query_rewritecollection and matches them against the query. Matching rules that perform query rewriting are applied at this stage, while matching rules that perform response rewriting are applied by the Modify Response with Rules stage later in the pipeline.
Most rules operate on the request, but some rule types, such as banner rules or redirect rules, do their work when the response comes back. The Modify Response with Rules stage applies those rules to the response. For example, a banner rule can add a banner URL to the response before returning it to the client.
Generally, if you are using rules then you need both of these stages enabled in your query pipeline. The Apply Rules stage must come before the Solr Query stage, while the Modify Response with Rules stage must come after the Solr Query stage. Disabling or removing the Apply Rules stage will disable rules entirely, while disabling or removing the Modify Response with Rules stage will disable only the rules that perform response rewriting, if any.
Rules on response signals
Rules and experiments
The easiest way to integrate rules and experiments is to create one query pipeline with rules enabled and one without, with all other settings constant between the two pipelines. The pipeline without rules enabled must be configured manually.
To create an experimental rule, use tags on the rule and set the tag in one of the variant pipelines.