Now you have complete control over the most important real estate in your search results, the top results.
How Did This Work Before?
Before this change the QueryElevationComponent elevated documents based on mappings in an XML file. The XML file contained mappings between query strings and docIds to elevate and exclude from searches.
For example the query “shoes” could be mapped to a list of docId’s that should come first in the search result.
This approach is fine as long as a direct mapping from query string to docId’s is the logic that you need. But there was no way to apply more sophisticated logic to query elevation.
What Changed?
The change introduced in SOLR-5541, and scheduled to be in Solr 4.7, is that now you can pass in the docId’s to elevate via a new http parameter.
This gives you the flexibility to promote products in much more sophisticated ways. Perhaps you have a product catalog and want to promote products based on keywords AND past buying behavior or geo-location of the user. Now you can.
Perhaps you want to run a full scale paid placement search engine, complete with real-time auction for keywords. You can do that as well.
These are of course just a few possibilities. Now that you have the flexibility to elevate documents for arbitrary reasons you can come up with your own algorithms for elevating documents.
How Does It Work?
There are two new http parameters that can be used when calling the QueryElevationComponent. These parameters are “elevateIds” and “excludeIds”, which both point to a comma delimited list of Id’s to elevate and exclude.
The id list refers to the unique Solr document Ids. For example:
http://localhost:8983/solr/elevate?q=*:*&elevatedIds=doc3,doc4&excludeIds=doc6,doc8
When you use these parameters the QueryElevationComponent will ignore the XML file of mappings and use the ids passed in instead. If you don’t pass in the elevateIds and excludeIds then the QueryElevationComponent will revert back to using the XML file.