Debugging content recommendations in SharePoint 2013
Content recommendations in SharePoint 2013 are a powerful mechanism that can help you expand the reach of your content and increase the conversion from your website. The process of gathering and calculating recommendations is quite complex and consists of quite a few moving parts. If, for some reason, you’re not getting any recommendations there are a few things that you can check to verify that things work as expected.
Debugging content recommendations in SharePoint 2013
Below is a process that you can follow whenever you notice that recommendations don’t work as they should. Although the steps presented in this article aren’t by any means exhaustive, they could help you get things to work or at least get closer to finding out why things don’t work as expected.
Requests logged in ULS?
The first thing that you should check, is whether requests to your pages are logged in the ULS. Whenever you visit a publishing page in the browser, you should see ULS display some information about this request. If your requests are not logged they also cannot be processed what explains why you don’t see any recommendations.
A common cause for requests not being logged in the ULS is the fact that the Application Pool account, that serves the website, is not a member of the Performance Monitor Users group. The Application Pool account should also be a member of the WSS_WPG group. If you had to add the Application Pool account to the Performance Monitor Users group you should reboot the server to ensure that the changes are reflected in your environment.
Requests logged in the RequestUsage log?
The next step is to check whether your requests are logged to the RequestUsage log. This log is located in the RequestUsage folder of the 15\LOGS folder. Whenever you visit a publishing page you should see an entry being added to the files in this folder. Events are flushed to the file with a slight delay so it might take a moment or two for the files to reflect the latest changes.
Typically if you don’t see the RequestUsage log being filled with your requests it means that you don’t have usage data collection enabled in your Farm. You can enable it from Central Administration by navigating to Monitoring and from the Reporting group clicking the Configure usage and health data collection link.
Requests logged in Search Analytics Event Store?
After you verified that the RequestUsage log is filled with requests, the next step is to verify that the Search Analytics Event Store gets filled with the requests from the RequestUsage log. The Search Analytics Event Store is located by default in C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Analytics_00000000-0000-0000-0000-000000000000\EventStore, where the GUID corresponds to the ApplicationName property of the Search Service Application in your Farm.
In the Event Store you should see a folder for each day. In each folder you should see events imported from the RequestUsage log and which have also been filtered and rewritten (this is why you for example see the physical URLs in the RequestUsage log but you see Friendly URLs in the Event Store).
Typically if you don’t see anything in the Event Store it means that the Microsoft SharePoint Foundation Usage Data Import Timer Job is either disabled or hasn’t run properly. This job should run every 5 minutes by default and you should verify that it doesn’t report any errors.
Another thing that you should check is whether the Usage Analytics job doesn’t report any errors. By default it should run each day at midnight which means that it takes at least a day to reflect the latest visits in recommendations. You can check the status of the Usage Analysis using the following PowerShell snippet:
$job = Get-SPTimerJob -Type Microsoft.Office.Server.Search.Analytics.UsageAnalyticsJobDefinition
$job.GetAnalysisInfo()Logged URLs match URLs in the query
If everything so far seems to be okay it could just be that although usage events are being recorded and processed correctly there is a mismatch between the URL for which the usage analytics events are recorded and for which you are trying to request recommendations. Generally this should not be a problem but in certain scenarios, such as when working with pages with Friendly URLs located in subwebs or with content catalogs, some additional work is required to have recommendations configured correctly. If you’re using cross-site publishing and have problems with recommendations I suggest you read the great series on recommendations by Bella Engen to ensure that you have configured everything correctly.
Recommendations visible?
If you’re still not seeing recommendations at this point it could just be that not enough usage data has been logged yet. As Bella mentioned in her series, for an item to appear in recommendations it needs to be viewed by at least three different users. If you’re using recommendations on a public-facing website with anonymous users, it is important that you have the Usage Cookie enabled to distinguish between the different users.
Another possibility remains of course that there is something else wrong in your environment in which case carefully examining the ULS log might give you an idea of what is wrong.