For reporting on knowledge searches - how do I only report on actual searches of the knowledge base

chrisperry · ‎04-07-2016

When I go look at the logs for knowledge searches, it is showing all knowledge searches - including automatic knowledge searches that are initiated when a user is typing the short description into an incident ticket. How can I distinguish between knowledge searches actually made by a user vs. knowledge searches that were automatically sent when a user was entering the short description of an incident ticket? Thanks, Chris perry

If this answer is helpful please mark correct and helpful!

Regards,
Chris Perry

LaurentChicoine · ‎06-20-2016

Hi Christopher,

I had the same issue as you as the contextual search was making the search logs completely useless with partial search and searches with the incident name used by our support teams.

Also, something interesting to be noted is that the new service portal in helsinki does not log the search made in the KB. Which means we will have to customize the widget to add the search log.

I chose to remove the contextual search (blacklist), a whitelist approach could also had been used. I only took the beginning of the URI being used for search so it might block some other macro searchs but personnaly what I was most interested into was search in $knowledge.do which is not using this URI.

Business rule: Remove KB contextual search logs

Table: Knowledge Searches [ts_query_kb]

Advanced: true

When: Before

Insert: true

Script (put inside the before function or the executeRule function):

var blockedURIs = ['xmlhttp.do?cxs_macro_names'];

try{

       var URI = gs.action.getGlideURI().toString();

       for (var i = 0; i < blockedURIs.length; i++){

               if(URI.startsWith(blockedURIs[i])){

                       current.setAbortAction('true');

               }

       }

}

catch(e){

       //catch error in situation where the GlideURI is not defined such as inside the service portal

}

I chose to simply abort action which does not insert the search in the search log but you could choose to populate a custom field to flag this search as a contextual search.

WARNING: This script relies on a function/object that is not officialy documented by ServiceNow ("gs.action.getGlideURI()"). ServiceNow could chose to remove or modify this function/object without any warning and that could break this script that is proposed.

View solution in original post

Mike Patel · ‎04-07-2016

If you want report on search log you can do something like below;

Search Table: Text Searches

Filter: Table is kb_knowledge

chrisperry · ‎04-07-2016

Hi Mukeshkumar,

Thanks for responding. I tried your solution, and this is still giving me all searches of the knowledge base - including knowledge searches that were automatically created when a user entered text into the short description of an incident (we have a Related Search Results section that is automatically populated with knowledge articles based on what the words are in the short description of the incident ticket).

So what I am looking for is a way to distinguish between searches that users actually made in knowledge bases, vs. searches that were automatically created when a user entered words into the short description of an incident ticket.

Thanks,

Chris Perry

If this answer is helpful please mark correct and helpful!

Regards,
Chris Perry

kriss · ‎06-20-2016

We have the same issue and also see "junk" in the search log for system-generated tickets Would love to know how to split out the results so I could get a "real" report for determining if there is something we need to do with Short Descriptions or Meta.

Michael QCKM · ‎07-19-2018

AMEN. We too are having the same issue anywhere the type ahead and/or Contexual Search is used.