- Editing rules in the Simulator
- The _rules_simulator query profile
- Enabling and disabling query rewriting strategies
The Simulator provides an interactive preview of how your staged rules affect relevancy, using your search data and a simple search interface. When you enter a query, the Simulator shows you the triggered rules, in the order in which they were triggered, along with any triggered facets.
The Simulator sends requests to the
_rules_simulator query profile, which you can configure to point to any pipeline and collection in your app.
In the Fusion UI, navigate to Relevancy > Query Rewriting.
The query rewriting dashboard appears.
Click the Simulator button.
The Simulator appears:
From here, you can:
Enter search terms to see the results, using query rewriting data from the
Edit rules that are triggered by the current query
Click Query Rewriting Dashboard to go to the dashboard, where you can enable or disable query rewriting strategies, then return to the Simulator to see how relevancy is affected
Editing rules in the Simulator
You can edit any rule in the list of triggered rules, including disabling it, by clicking the icon next to the rule.
|Only rules triggered by the current query are available to edit in the Simulator. To edit other rules, see Business Rules.|
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.
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.
_rules_simulator query profile
Each app has a
_rules_simulator query profile, configured to use the
_query_rewrite_staging collection for query rewrites instead of the
_query_rewrite collection. This profile is created automatically whenever a new app is created.
By default, this query profile points to your default query pipeline and collection. You can configure it to point to any pipeline or collection, for example when testing a new pipeline before it has been deployed.
Open the Fusion UI.
Navigate to Querying > Query Profiles.
_rules_simulatorquery profile for your app.
For example, if your app is called "Demo" then the name of the query profile is
Modify the configuration as desired.
Enabling and disabling query rewriting strategies
By default, all query rewriting strategies are enabled, and all of the data in the
_query_rewrite_staging collection is applied in the Simulator. To see how relevancy is affected by individual strategies, you can selectively enable or disable strategies in the query rewriting dashboard.
From the Simulator, click Query Rewriting Dashboard.
The query rewriting dashboard appears:
Click Enabled to disable an active strategy, or click Disabled to enable an inactive strategy.
Click Simulator to return to the Simulator and see how your changes affect search results.