This is a blog post in the series “How to display Recommendations and Popular items on a SharePoint Server 2013 site.” In the previous post, I introduced you to the Usage analytics feature. In this blog post:

Note: The examples in this blog series are based on an on-premises installation.

Change the mapping of the UsageAnalyticsID managed property
In our Contoso scenario, we want to recommend one product per product group, that is, we want Usage analytics to ignore the product color. This means that our recommendations must be calculated on Group Number. We can do this, because Group Number is part of the friendly URL (FURL) on our item details page.

In the previous blog post, I told you that the managed property that’s used to specify how recommendations between individual catalog items should be calculated is UsageAnalyticsID. So, in order for Usage analytics to do its calculation on Group Number, we have to change the mapping of the UsageAnalyticsID property. Here’s how you do that:

IMPORTANT: You have to change the property mapping on the Authoring site.

1.  On your authoring site, go to Site settings --> Search Schema.

Search Schema

2.  On the Managed Properties page, in the Managed property field, type UsageAnalyticsID, and then select the arrow button.

Type UsageAnalyticsID

3.  From the Property Name field, select Edit/Map Property.

Edit/Map Property

4.  On the Edit Managed Property page, select Add a Mapping. Notice that by default, this property is mapped to the crawled property ows_ProductCatalogItemNumber.

Add a Mapping

5.  In the Crawled property selection dialog box, use the Search for crawled property name field to search for the crawled property that you want to map to this managed property.

In our Contoso scenario, we want to map the site column called Group Number. Crawled properties don’t contain spaces, so leave out the space, enter GroupNumber and select Find.


Find GroupNumber

Two crawled properties are found. Select the crawled property with the ows_ prefix, and select OK.

Map crawled property

If you are confused because two crawled properties that look about the same are found, then you’re not alone. This is quite tricky. In another blog post, I talk about the naming convention for crawled and managed properties.

If you are interested in a cliff note version of that blog post, here it is: When mapping a crawled property to the UsageAnalyticsID managed property, you should select the crawled property with the ows_ prefix!

6.  On the Edit Managed Property page, select the ows_ProductCatalogItemNumber crawled property, and then Remove Mapping.

Remove crawled property mapping

7.  Select OK to save the new mapping.

IMPORTANT: Map only one crawled property to the UsageAnalyticsID managed property. If you map more than one crawled property, the Usage analytics calculation won’t work correctly.

After you have changed the mapping of the UsageAnalyticsID managed property, you have to do a full crawl of your catalog. I describe how you can do this in this blog post.

Modify a Content Search Web Part display template so that usage events are logged correctly
On our Contoso site, we use a Content Search Web Part (CSWP) to display items on the catalog item page. By default, the CSWP does not log usage events. To enable our CSWP to log usage events we have to modify the display template that the CSWP is using. Here’s what you need to do:

1.  In your mapped network drive, open the display template that you have applied to your CSWP.
2.  In the ManagedPropertyMapping element, add the following two properties:


'Original Path'{Original Path}:'OriginalPath',
'SiteID'{SiteID}:'SiteID',

Add tow managed properties

3.  Add the following Java-Script just above the HTML part of your display template:

//Log Views usage event on URL of catalog item
    window.LogViewsToEventStore = function(url, site)
    {    
        SP.SOD.executeFunc("sp.js", "SP.ClientContext", function()
        {
            var spClientContext = SP.ClientContext.get_current();
            if(!$isNull(spClientContext))
            {
                    var spWeb = spClientContext.get_web();
                    var spUser = spWeb.get_currentUser();
                    var spScope = "{00000000-0000-0000-0000-000000000000}";
                    
                    SP.Analytics.AnalyticsUsageEntry.logAnalyticsEvent2(spClientContext, 1, url, spScope, site, spUser);spClientContext.executeQueryAsync(null, null);                  
            }
        });
    };
    
    var originalPath = $getItemValue(ctx, "Original Path");
    var originalSite = $getItemValue(ctx, "SiteID");
    LogViewsToEventStore(originalPath.value, originalSite.value);

I want to point out one value in this script. In the previous blog post, I told you about the different EventTypeIDs for the usage events. The value 1 in this script represents the EventTypeID of the Views usage event. If you want to log a different usage event, you’ll have to substitute this value with the EventTypeID of the usage event that you want to log.

Add Java Script to display template

4.  Save the file.

Why you should simulate the generation of Views usage events
Now that our CSWP can correctly log usage events, the next step is to actually generate usage events. In our case, we modified the CSWP to log Views. If the Contoso site was LIVE, visitors would create a Views usage event every time they viewed an item on the website. However, the Contoso site is only a demo site, so it doesn’t have any visitors.

When you set up your site, you’ll most likely want to test the Usage analytics feature before you put it into production. To be able to test the Usage analytics feature, you’ll need to generate usage events. To generate recommendations based on usage events, a minimum of three different users have to click the same items

There is not one single correct way of simulating the generation of Views usage events. To generate Views usage events for the Contoso site, I invited some of my co-workers to a “click party” (they were bribed with candy). To ensure that recommendations were generated, I gave all users a list of items that they had to click. That way I ensured that at least three different users clicked the same items.

Here’s an example of the instructions that I gave my co-workers:

Click-party instructions

When Usage analytics is run, SV Keyboard E10 will generate a recommendation for WWI Desktop PC2.30 M2300 (people who viewed WWI Desktop PC2.30 M2300 also viewed SV Keyboard E10) and WWI Desktop PC2.30 M2300 will generate a recommendation for SV Keyboard E10 (people who viewed SV Keyboard E10 also viewed WWI Desktop PC2.30 M2300).

Run Windows PowerShell scripts to start search analytics and push usage events to the Event store
After you have generated Views usage events, you have two options on how to proceed. The Usage analytics timer job runs once every 24 hours. If you are a patient person you can now relax, go home, and let Usage analytics work its magic overnight.

On the other hand, if you are more of an “I want results now” type of person, you can use some Windows PowerShell scripts to speed up the process. Here’s what you need to do:

1.  Verify that you meet the following minimum permission requirements.
2.  On the server where SharePoint Server 2013 is installed, open the SharePoint 2013 Management Shell as an Administrator.

Run as administrator

3.  At the Windows PowerShell command prompt, type the following commands to start Search analytics. The output from Search analytics is used by Usage analytics to map usage events against the actual items in the search index.

$a = Get-SPTimerJob -Type Microsoft.Office.Server.Search.Analytics.AnalyticsJobDefinition
$sa = $a.GetAnalysis("Microsoft.Office.Server.Search.Analytics.SearchAnalyticsJob")
$sa.StartAnalysis()

4.  Wait for the search analytics job to finish. To check the status of the search analytics job, type the following command:

$sa.GetAnalysisInfo()

As long as the search analytics job is running, State is Running.

The search analytics job is finished when State is Stopped and Status is 100.

Search analytics stopped

5.  The usage events are added to the Event store within a 10 minute interval. To push the usage events to the Event store, type the following commands:

$tj = Get-SPTimerJob -Identity ("job-usage-log-file-import")
$tj.RunNow()



View usage events in the Event store
After you have pushed the usage events into the Event store, you should verify that the usage events are recorded correctly. To do that, on the machine where SharePoint Server 2013 is installed, go to the Event store. In most cases you can find the Event store in this file directory:

C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Analytics_<GUID>\EventStore

In the Event store, the usage events of each day are stored in a separate folder. In our scenario, we can see that a folder has been added.

Folder in event store

In this folder, you’ll see some text files. These files contain our usage events. Notice that all file names start with 1_.

Usage event log files

This number is the EventTypeID of the usage event that is logged in the file. Remember, 1 is the EventTypeID of the Views usage event. At this point the only usage event that we are logging is the Views event, so this is a good sign that we are doing things right.

Open one of the files in a text editor, for example Notepad++. This file contains quite a bit of information, but you should really only be looking for two things:

  • Verify that the usage events are logged correctly.
  • Verify that different users have generated the usage event.

In the previous blog post, I explained that for Usage analytics to work, the usage event must be recorded on the URL of the item. In the Event store file, you’ll see many URLs. Look for URLs that end in dispform.aspx?id= followed by a number. In our file, we can see that it contains many entries with such URLs.

Item URLs in log file

This is a very good sign, because it means that the usage events are being recorded correctly. To verify that the URLs actually belong to one of our catalog items, copy one of the URLs from this file, and paste it into your browser.

Verify item URL in log file

To verify that different users have generated the usage event, look in the third column of the file. In our scenario, we can see that we have at least three different user IDs.

Three user IDs in log file

Now that we have verified that the usage events are correctly logged, you could be tempted to think that we are ready to run the Usage analytics job.  But remember, by using Windows PowerShell to start Usage analytics, we are actually kick-starting timer jobs.

When the Usage analytics timer job kicks off, it’ll take the usage events from yesterday and process them. Since we want to process the files from today, we’ll use a simple trick so that the correct files can be processed by Usage analytics.

Prepare usage events files before starting Usage analytics with Windows PowerShell

1.  In your EventStore file directory, create a new folder called myevents.

myevents folder

2.  Copy the usage event files that you want Usage analytics to process into your myevents folder.

In our scenario, I copied all files from the 20131206 folder into myevents.

Usage event files copied to myevents

3.  Right-click on your myevents folder and select Properties.

myevents Properties

4.  In the Attributes section, select Read-only (Only applies to files in folder), and then OK.

Set myevents to Read-only

5.  In the Confirm Attribute Changes, select Apply changes to this folder, subfolder and files and then OK.

Apply to all folders

Now we’re ready to start the Usage analytics job.

Start the Usage analytics job with Windows PowerShell

1.  At the Windows PowerShell command prompt, type the following commands:

$tj = get-sptimerjob -type microsoft.office.server.search.analytics.usageanalyticsjobdefinition
$tj.DisableTimerJobSchedule()
$tj.StartAnalysis(“\\<hostname>\Analytics_<guid>\EventStore\myevents”)
$tj.EnableTimerJobSchedule()

Notice that one command contains two placeholders: hostname and guid. The hostname is the name of the server where SharePoint Server 2013 is installed. You can see the guid in the file path to your EventStore.

GUID

Run Usage analytics

2.  Check the status of the Usage analytics job by entering the following command:

$tj.GetAnalysisInfo()

The Usage analytics job is finished when State is Stopped and Status is 100.

Usage analytics stopped

Now that Usage analytics have processed the usage events, the next step is to display the results of the analysis on our Publishing site. To do that, we’ll add and configure two Web Parts. I’ll show you how to do that in the next blog post.

Next blog post in this series:
Add and configure the Recommended Items and Popular Items Web Part