Wednesday, May 28, 2014

S15E05: Query Rules – The Basics

Want the book? Go get it!

This is the fifth episode in the series “SharePoint Search Queries Explained - The Series”. See the intro post for links to all episodes.

I want to start out by saying that Query Rules Rule!! And in a big way!

If you are coming from SharePoint 2010 and used keywords for synonyms and best bets in search, then Query Rules is the brand new revved up engine which took it’s place. Think an old Toyota with a 1.4l engine, being replaced by a Tesla Model S (or The Expendables without steroids).

So what is a query rule exactly? When a search query is being executed, one or more query rules can based on specified conditions intercept the query and take actions on it.
The available actions are:
  1. Add promoted results (Best Bets in 2010)
  2. Add one or more result blocks, which are additional groups of results or side results to the original result
  3. Re-write the query
  4. Change the sorting or ranking of the results
image

Promoted Results

A promoted result is an authored result which is added to the top of the search results. For example if a user searches for search blog, you can at the top of the results show a link or banner pointing to this blog.

For the promoted result you add a title, the URL and a description. You may also check to show it as a banner, and it will then load the URL content in an iframe instead.

image

The result of the above promoted result will be displayed above the regular results.

image

The use cases are many and it’s possible to override the way it displays with either a custom display template or CSS overrides.

Result Blocks

Out of the box SharePoint comes with a whole list of pre-defined query rules which will add result blocks based on trigger words. One of them will trigger on the term blog anywhere in the query, and list items based on the blog web template in SharePoint.

image
Executing the same search search blog as in the previous sample, below the prompted result you now get a block showing blog content hits from SharePoint. And below the block, you get regular results.

Something to note about result blocks is that they don’t have to appear at the top. This particular one will actually move down in the results if no one ever clicks on the items inside the block region. And eventually it will move out of page 1 etc.  This means that the users decide if the block is important or not, not the person creating the rule (unless it’s chosen to always appear at the top).

image

Re-write the query

In the above example with the blog result block, there is actually a query rewrite going on. {subjectTerms} WebTemplate=blog. It uses the original query and adds a property query to limit results from WebTemplate equals blog. That’s all there is to it, and you have the full list of query variables at your disposal as well. If you’ve been reading the previous posts in this series, it should start to come together, and you are getting close to being able to turn business rules into query rules -  which coincidentally happens to be my #1 favorite search slogan.

It is also possible to use query rules for synonym expansion where you trigger on a term, and then add one or more terms. For example if someone searches for Puzzlepart you may want to rewrite the query as:

puzzlepart OR pzl OR puzlepart OR puzzelpart
to include any acronyms or spelling mistakes.

Change sorting or ranking

In addition to re-writing the search queries, a query rule can also change the sorting or ranking of the results. Say you want your blog posts to appear with the newest first, then sort on LastModifiedTime in descending order.

image
As with result sources, query rules can be created at the Search Service Application (tenant) level, site collection level and site level. Where you create them depends on how much you want to re-use their logic. By default there are a lot of rules coming out the box, attached to the out of the box result sources. I recommend heading over to a query rule settings page near you to take a look at the existing rules and familiarize yourself with them.

It is also possible to set a start and end date for a rule, which means you can have the promoted result about the upcoming summer party only appear up until the party is over.

Local SharePoint Results have the most rules included by far, and you might find that the rules trigger on your custom search sites without you wanting them to. The quickest solution to this is to create your own result source, equal to that one of Local SharePoint Results, and use that source as your basis. Then you can add one and one rule as you see the need.

Query Rules Rule!

Hopefully after reading this you should have a brief overview of what query rules are, and what they can do for you. In the next episodes I will cover more in-depth how to use the different options of query rules.
References

9 comments:

  1. Hi Mikael! I have an question about promoted results. We see that users more and more are using natural language queries like: "Which customers can have product A?". We have promoted results on all our product names, so the query "product A" would trigger a promoted result, but a natural language query containing a product name won't. Do you have any tips on how to make that work without investing in NLP tools?

    ReplyDelete
    Replies
    1. "Query Contains Action Term" should do the trick. Also take a look at a better approach for promoted results: http://blogs.msdn.com/b/ericdixon/archive/2015/10/23/sharepoint-2013-search-even-better-best-bets-with-exact-matching.aspx which builds upon a solution I wrote about over at http://blogs.msdn.com/b/mvpawardprogram/archive/2014/07/21/better-best-bets-with-lists-in-sharepoint-2013.aspx

      Delete
    2. If I understand you correct I should use the product name as action term? If yes: This seems to only work if the action term is first or last in the query.

      I'm trying to make a search solution for natural language queries using SP2013 ootb and as part of that I'm considering using your Better Best Bets solution. I'll look in to Eric Dixons solution but as I don't want exact matches I think I'll stick to yours.

      Delete
    3. You are right of course. If on-prem you can use regular expression matching which solves it. But the list solution I linked to is much more maintainable and scalable.

      Delete
    4. And use : instead of = and you get contains in Erics as well :)

      Delete
    5. Great. I'll look in to it. Thanks for your advice.

      Delete
    6. So now I've gotten it to work with your solution and natural language queries containing one or more keywords triggers the best bets. Only thing missing is keyword synonyms. I've put in some synonyms in the enterprise keywords but it seems that the're not indexed together with the main term. Is that possible or do I have to use Erics solution? I prefer your solution as the maintenance can be made from on list instead of two.

      Delete
    7. You need to either go with Erics solution or use multiple keywords. Search only index the main label of a term.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete