We have a heavily customised SharePoint publishing (WCM) site that uses no web parts in order to meet with XHTML and (AA) accessibilty guidelines. The trouble is that the search functionality is not generating any usage statistics (Usage reports within Search Administration in the SSP). We know this is down to our customisations because we have a couple of the OOTB team sites in the farm which are generating search statistics. We are not sure where/how we need to fix this. It seems we may need to wire up a call to the search.asmx web service but I'm not sure. Perhaps we need to call something from within the SharePoint API as part of our call to the search service? I'm not sure.

Has anyone out there built a heavily customised SharePoint site (no web parts) and are logging search statistics, can you comment on how you did it? Or can anyoone provide insight into how the staistics are generated?

If it helps we are running a medium sized farm with 2 WFEs, 1 Index server and 1 SQL Server box. All Windows 2003 R2 SP2, 32-Bit. MOSS 2007 SP1 (plus December CU) Enterprise Edition.

Thanks, James.

P.S. this question was previously asked on Stack Overflow (https://stackoverflow.com/questions/1432182/how-do-sharepoint-search-statistics-get-generated) but some commenters recommended it should be moved here.


This might not be the answer you want to hear but our workaround was to place the search control webparts (just searchboxex needed I think) in one of the hidden content place holders (in our case ContentPlaceHolderId = PlaceHolderSearchArea)

  • Thanks, that might be worth investigating. The trouble is we don't even have a webpartmanager on the page. Do you have a public search results page I could look at where I could see this in action? Sep 30 '09 at 10:37
  • It's not live yet sorry, but you don't need to have a web part manager. 1. On a dev site create a basic web part page. Add the SearchBoxEx and CoreSearchResults web parts. 2. Open up SharePoint Designer and detach the page so you can see the code. 3. Copy only the actual web part code into the hidden content holder. It doesn;t need to be wrapped in a zone. See trinkit.co.nz/blog/archive/2009/08/18/… for similar example
    – Mark
    Oct 1 '09 at 1:08
  • Sorry in case it's not clear for step 3 I meant copy the web part code from your dummy web part page into the hidden content holder of your actual Search Results page (and of course make sure you have any necessary Tagprefixes registered)
    – Mark
    Oct 1 '09 at 1:10
  • OK - I'll give this a go over the next few days. Thanks for your help. Oct 1 '09 at 15:58

From what I've gathered so far queries are logged by calling the RecordClick method of the search web service. The Microsoft.Office.Server.Search.WebControls.SearchResultsBaseWebPart webpart, which is used to render search results, makes the magic happen.

When the page rendered by SearchResultsBaseWebPart is loaded a function is registered for the onlick event of all HTML link elements whos ID matches a RegExp filter. The page's unload event is also registered to send a soap request containing a serialized Microsoft.Office.Server.Search.Query.QueryInfo object to the search web service RecordClick method. The properties of the QueryInfo object is then stored in the Share service provider database, in the MSSQLogUnprocessed and MSSQLogNonClickedUnprocessed tables.

This is the only query logging functionality I have found so far. If you know of or find any other leads, please share them.

I gathered this information by looking at the different classes in Reflector. I hope it helps.

  • Thank you for this. I've been led down the same path myself and I did come to the same conclusions. I did begin to try to replicate the javascript that get injected by SharePoint but the code was using an internal object that I do not have access to. Its possible to recreate this functionality but I do not have the time at the moment. I understand why the onclick event has to happen omn the client-side but I don't understand why the onunload event is not a server side API call made during the search query. So search stats only work if you use the OOTB web parts - not very extensible! Sep 24 '09 at 10:07
  • Agreed, not the easiest thing to customize, but it should be possible to write your own implementation. Check out how they do it in SearchResultsBaseWebPart.GetWireSRBLinksCall(). I guess the tricky part is getting the correct QueryInfo data back to RecordClick. Sep 24 '09 at 11:53
  • download.microsoft.com/download/8/5/8/… Here's a document describing the QueryInfo class. Sep 24 '09 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.