2

We are using Lucene search for one of our projects. The site is growing fast and needs search improvement. One key thing is to mix recency and relevancy.

Currently, the search happens on user-entered key terms in some of the designated fields (like page title, content etc) and results with highest score are returned.

Right now the user is not finding these results very useful as they are seeing articles from old dates on the top. Although the content is relevant it's not recent.

We need to boost search results to included the published/updated date. We've a computed column (publishedupdateddate) for it, how can it be used to boost up the search results using query time boosting?

If not query time, do we have any other way to include the dates while calculating the score for an item...

please advise

sehe
  • 374,641
  • 47
  • 450
  • 633
Vijaya Akkenapally
  • 163
  • 5

2 Answers2

1

You can create a form of date scoring just using the standard sitecore search api. By adding several OR conditions each on different date bands i.e.

AND (Title = searchTerm OR author = searchTerm) AND ( publishDate > dateTime.Now.AddDays(-7) OR publishDate > dateTime.Now.AddDays(-30) OR publishDate > dateTime.Now.AddDays(-90) OR publishDate > dateTime.Now.AddDays(-180) OR publishDate > dateTime.Now.AddDays(-365) )

In the example above articles 3 days old will score 5x relevancy from matching all 5 date conditions. An article from 9 months ago will only score once from the < -365 condition. An article over 365 days would be excluded altogether because the outer AND condition mandates that at least one of these date conditions MUST match, flipping that to an OR would mean that we just add relevancy when things do match, rather than be a hard filter when they don't.

Paul George
  • 1,788
  • 16
  • 33
0

Computed fields are in general created to let us to add additional data to the index. They can improve time of queries only when you will simplify with them the queries. If you want to give results faster then you should try to use SOLR or some cache - but it hard to pick the right path when we do not know how big set of data you have there and how complex yours queries are.

Łukasz Skowroński
  • 183
  • 2
  • 9