SharePoint Query Rules, Part 9
custom search, full trust Web part, Search
This is episode nine in the series “SharePoint Search Queries Explained - The Series”. See the intro post for links to all episodes.
This is one of my favorite areas of search, but also one of the harder ones to get right. The overall concept is as follows:
For a specific group of users you change the search experience based on that group.
In the sample image above I show a promoted result for new employees who happen to like StarWars. It’s a very simple concept, but a really powerful one, and it’s up to you to decide what your query rule should do with your result – promoted results, change sort order, change what is displayed etc..
In SharePoint 2013/Online the way to provide context aware experiences is to create a query rule that is triggered based on User Segments.
Technically a user segment is a term in a term set, and it can be anything. It could be a term for the organization unit you work in, the kind of web browser you are using, your primary language, that you are newly employed, that you like to dress up as Luke Skywalker while searching on your intranet between 1 and 3 am in the morning. Anything! It’s up to you to define the contexts you want to use to change the search results and then tie the terms to query rules.
The hard part is this: how do you evaluate or create this context so that it is used when a user searches in SharePoint?
Mantra alert!!! Turning business rules into query rules!
Below I created a term set named Search Contexts, and added two terms
For my query rule I have added a new user segment named New guy with SW likes, which consists of these two terms. So, both of the terms have to be present in a search query for the rule to trigger.
If you look at the reference links at the end of this episode you see that the samples tell you to create a new full trust web part, which will contain the business logic to evaluate your context, look up the term for it, and put the terms GUID in a variable named UserSegmentTerms. The query engine will then match the GUIDs from this variable against your query rules and trigger accordingly.
For my above sample, I could look at the employees start date to determine if he/she’s a new guy or not. As for the interest in StarWars, this could come from a user profile property of interests, or perhaps by examining his/her Facebook profile. When you have assembled the context, throw up a promoted results about the cool StarWars-themed party for all the new hires on Friday.
This made the next search trigger my promoted result.
To recap, I based business rules I assembled into a user context to show promoted results for users who are new employees and who like StarWars. How you implement to define what a new guy is and if a person likes StarWars or not, that’s entirely up to you, and the hardest part of the equation for sure.
If you managed to master the art of user contexts combined with query rules, there is no doubt you can achieve greatness for your users. If you’re lucky you might even get some fame :-)
] = [
Photo credit for rotating banner image: http://freehdwallpaperdownloads.com/lego/star-wars-lego-characters-hd-wallpaper.html/
Topic: Search Experiences