Bloomreach has precision modes available that can limit a search recall set by identifying product types, either through categories or our semantic engine. However, for many use cases where attribute intent is clear, customers want to pre-filter search results for those attributes. For example, a customer searching for “2015 Toyota Corolla brake pads” specifically wants results fitted to their vehicle (that is, matching on all three of “2015”, “Toyota”, and “Corolla”).
The Automatic Query Filtering (AQF) feature analyzes queries for any attributes matching a designated AQF field, then pre-filters the recall set if a match is found. For example, if you designated year, make, and model as AQF fields, then AQF would pre-filter results by year=2015, make=Toyota, and model=Corolla.
This can be used for several other use cases depending on how your catalog and how your end users are searching. For example, a merchant selling apparel might want to use brand as an AQF field, so when their customers search for “gucci dress”, the results are pre-filtered by brand=gucci and any noisy results are eliminated.
Note: this feature will also clean up unwanted facet noise as can be seen in the example below for the query “3M” where the user is looking for “3M” branded products only. Without AQF, the recall set contains products from brands that are not 3M, as shown in the list of Brand facets. With AQF enabled and brand designated as an AQF field, the recall set is pre-filtered to only include 3M products.
With AQF, end users are presented with a more precise recall set and cleaner facets, which should allow them to get to the product they are looking for, faster.
Bloomreach will also return the query tags in the “metadata” section of the API response, as shown in the screenshot below. You can use this data for other front end functionality.
While most cases are automatically handled by the system, there are edge cases due to language complexities where the feature might not behave as you would like. For such edge cases, we have created manual overrides that you can access through our support team. Some common edge cases are listed below.
Product-Attribute Ambiguity: Some words can refer to either a product type or an attribute. For example, “bolt” could refer to bolt as a product (should not match for AQF) or bolt as a model (should match on model for AQF). Another example is “mud pie”, which is both a product type and a brand. In these cases, Bloomreach remains conservative and does not apply AQF because that could limit the recall unnecessarily.
Note: If you have such cases, and you’d like to give preference to recognize a word as an attribute, please contact the Support team and they should be able to help you override it.
Attribute-Attribute Ambiguity: Some words can refer to multiple attributes. For example, “brass” could be a value for color or material. In these cases, Bloomreach applies AQF to both attributes (i.e., show products that have color=brass AND material=brass).
Note: If you have such cases, and you’d like to give preference to one of the attributes, please contact the Support team and they should be able to help you configure it.
Attribute Aliases: Sometimes, users may search for brands by different names than what you have in your catalog data. For example, users may search for “chevy” while you have “chevrolet” in your data, users may search for “ysl” while you have “saint laurent” in your data. In these cases, you would want to treat the two names as the same so that you don’t get null results.
Note: If you have such a use case and require aliases for some of your attributes, our Support team can help.
There is no additional charge to enable Automatic Query Filtering.
New Customers: If you are currently integrating Bloomreach’s Search module, please speak with the Technical Services team member who has been assigned to help with your integration.
Existing Customers: For existing customers, a ticket can be filed with Support to get the feature turned on. If you have already integrated Bloomreach’s Search module, then no extra integration steps are required (note: some front end work may be needed, depending on whether you wish to handle things differently on your front end when enabling this feature). You can discuss whether Automatic Query Filtering is suitable for your use cases with your Digital Experience Manager.
If you would like to enable Automatic Query Filtering on your account, contact Bloomreach Support and provide the following information:
- Names of fields from your catalog that you would like to designate for Automatic Query Filtering
Does it make sense for everyone to have this feature on?
No. This feature is most useful if you have a high volume of queries where users tend to encounter noisy results in searches for specific attributes (e.g., brand, color, make, model, year, size etc.).
The fields you designate for AQF should also be well populated, otherwise recall might only be limited to those fields with data. For example, if you have 100 gucci products but only 50 of those products list brand=gucci, then recall for a query containing “gucci” would be limited to those 50 products (this is similar to what you’d expect if the user selected a brand filter).
Please note, any feature that impacts product recall needs careful consideration. We suggest that you turn on AQF in Staging to preview any changes before turning the feature on in production.
Can we A/B test this feature?
No, you cannot A/B test the AQF feature. If you would like to preview the results with AQF enabled, you can request to enable AQF on Staging first.
Does this feature increase latency?
You should expect a very slight increase in latency with AQF enabled.
How many fields can be used for Automatic Query Filtering?
You can designate up to 5 fields for AQF. However, we suggest that you avoid overusing this feature because curtailing the recall set too much can have negative effects.
Automotive customers will likely require 3 AQF fields: year, make, and model. Otherwise, we suggest using 1-2 AQF fields.
How does Automatic Query Filtering differ from Lookups?
Automatic Query Filtering and Lookups are similar features. However, Lookups requires the entire query to be an exact match on the designated field, while AQF allows any term in the query to match the designated field.
Let’s use an example to show how AQF handles searches differently from Lookups. Suppose brand has been designated as an AQF field or Lookup field.
|Query||Results with Lookups||Results with AQF|
|“gucci”||All products that match brand=gucci||All products that match brand=gucci|
|“black gucci dress”||No Lookup available, uses default search||All products that match “black gucci dress”, filtered to only include products with brand=gucci|
How does Automatic Query Filtering impact Recommendations & Pathways?
Recommendations are not affected by AQF.
If AQF is enabled, then Pathways results will automatically reflect the same results as Search.
How does Automatic Query Filtering impact redirects?
Redirects will function as is.
How does Automatic Query Filtering impact product suggest?
Product suggest will show the same result as the Search API if AQF has been configured.
How does Automatic Query Filtering impact synonyms?
Synonyms are applied to the query as is. Two points to note:
- Synonyms cannot match on AQF fields. For example, suppose you create a synonym chevy → chevrolet in the Dashboard. A query containing "chevy" would not be considered a match on model=chevrolet for AQF. AQF has its own alias list that can be updated by Support or Technical Services.
- Synonyms are applied as is, but the recall set will only contain products that match the requirement of the AQF. For example, suppose color is a designated AQF field, and you have the following queries and synonyms:
|“black lace dress”||black → charcoal||Products that match “charcoal lace dress” and have color=black (not color=charcoal)|
|“black party dress”||party dress → maxi dress||Products that match “black maxi dress” and have color=black|
Does Automatic Query Filtering work for non-English languages?
No, AQF only works with English.
How does Automatic Query Filtering interact with Merchandising rules?
|Merchandising rules||Feature Interaction|
|Boost, Bury, Slot, Soft Boost, Add to Recall||Products boosted/buried/slotted/added to recall may get removed/filtered out from the result set after the Automatic Query Filter is applied. This is because the Automatic Query Filter is applied on top of the existing ranking rules.
|Include, Exclude||There will be no impact. Include/Exclude rules will continue to apply with the Automatic Query Filter.|
|Broad Match||There will be no impact. Broad Match rules will continue to apply with the Automatic Query Filter.|
Does Automatic Query Filtering alter the facets and show the attribute being filtered as "selected"?
No. The filters would be based off of the final recall set returned to the customer. For example, if AQF matched on brand, the brand facet would not be selected.
Does Automatic Query Filtering impact result ranking?
No. AQF only impacts result recall, it has no impact on ranking. If you are also using Lookups, then do note that Lookups apply before AQF does.
Updated 5 days ago