SharePoint’s Popularity Trends & Popularity and Search Reports

Web Analytics in SharePoint 2010 is now known as Popularity Trends, and in SharePoint 2013, it’s known as Popularity and Search Reports. The rename comes at a time whenMicrosoft moved the analytics functionality to be a part of the search component.

This is a troubleshooting guide that will give you an overview of all the different components for the analytics, hopefully aiding in identifying where the break down is inside of the process. I will focus mainly on the Popular Trend’s Usage Reports.

Prerequisite:

Ensure that there is traffic to the site, not just from administrative users. In some cases, SharePoint will not log administrative accounts page requests. If this is the case, browse the site with a non-administrative or non-service account and make sure to traverse the sites content pages and libraries and lists.

Make sure Alternate Access Mapping is configured correctly.

(SharePoint 2013 Server) Ensure that Reporting is turned on.  This can be found under Site Settings -> Manage site Features. Look for Reporting, not Reporting Service. If it is notActive, turn it on. If you do not see it, don’t worry – it should be fine as I’ve seen sites function without this feature.

Configure usage and health data collection:

Ensure that Enable usage data collection is enabled.

Check under the Events to Log: that Analytics Usage, Feature Use, and Page Requestsare also selected.

Ensure that Enable health data collection is enabled.

Ensure that under Log Collection Schedule the two jobs Microsoft SharePoint Foundation Usage Data Import and Microsoft SharePoint Foundation Usage Data Processing are both there.

Check their jobs schedule: Microsoft SharePoint Foundation Usage Data Import should run every five minutes and Microsoft SharePoint Foundation Usage Data Processing runs daily.

Check if those two jobs are failing: While still on the same screen where we checked the schedule, go to Job History on the left. If you look at the view and it says Service change it to Failed Jobs. Go through the failed jobs and look to see if you see the two jobs listed above.

Search:

After we checked and made sure the jobs are healthy and running, let’s make sure Search is functioning properly. Since the search function now does the Analytics, it is vital that the site collection is crawled and search results are coming up fine on the site.

To check Search: Go to System Settings, under Servers, click Manage Services on Server. On the Service on Server, find SharePoint Server Search and click it. On the next screen, under Search Service Applications select the Search Service Application. Now you should be on the Search Service Application: Search Administration menu.
On this screen look under the Search Application Topology for your Analytics Reporting Database.

On the left side of the page, look for Content Sources under Crawling. Select it to go to the Search Service Application: Mange Content Sources page.

Select the Local SharePoint Site and make sure that the URL of the site in question is in the Start Address box. Make sure if the site is httpS that it is httpS in the box as well.

After we made sure search is set up correctly, make sure that the site is returning results when you run a do a search on the site.

Lastly, we need to make sure that the search service account is a member of WSS_WPG group.

So, after checking all of those components, we will need to dig deeper to find out what is going on with the Analytics.

Usage File Creation

(typically found C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS\RequestUsage)

In the logging folder, we need to find a folder called RequestUsage. In this folder, if healthy and working correctly, we will see a *.tmp file and periodically a *.usage file being generated. If there is no file being created in here then the site is not listening for page requests.

If there is no file in here being generated make sure the site has some traffic to it, so browse the site, and check the folder periodically.

The Microsoft SharePoint Foundation Usage Data Import timer job looks in this folder and takes *.usage file and imports the data to the Event Store.

The Event Store

(typically found at C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\)

The Event Store can be a chore to find, because the folder before it consists of a name with a GUID in it. If you look at your server’s shares, you’ll see it in there. In some cases, you can navigate directly from there to folder, but in other cases you cannot and will have to find it manually. Usually, I run a search for this folder by searching the computer for Analytics or EventStore. In the picture below you can see the “Analytics_(GUID)” share.

Once you find the event store, we want to make sure that it is creating folders with data in them. The folders are names based on their date. Inside the folders, you should find some .log files.

Not everything that gets passed from the RequestUsage folder gets put into the Event Store data files. Some of the information does get filtered out.

SQL

Next we must check that SQL is logging analytics data. To do this open up SQL and create a new query your logging database. We want to see if this is getting updated every five minutes by the data import timer job, so re-run the query below every five minutes to check for an increase in the row count.

Select userlogin,* from dbo.RequestUsage (nolock) where RequestType=’GET’ order by RowCreatedTime desc

Select count (*) from RequestUsage (nolock)

Conclusion

We broke down the analytics reporting function into Configuration of the Health and Data Collection, Search, Usage Request, Event Store, and SQL. Reviewing each competent can determine a point of failure in the process and focus on fixing the broken component. There is still much more to the reporting process that I haven’t gone into such as the Search Queries, but that is for a different day…