Please see this post on the new Office blog for information on how to filter and personalize the site for the specific content that you want to see.

Thank you and we look forward to reading and responding to your comments on Office blogs!

-- The SharePoint IT Pro Blog team

The solution requires a site-to-site VPN connection to Windows Azure. SQL Server log shipping and Distributed File System Replication (DFSR) are used to move SharePoint databases from the on-premises environment to Azure. Our Azure environment looks similar to this reference architecture.

The file share serves double duty running both DFSR and serving as the 3^rd node of a Node Majority for SQL Server AlwaysOn.

One lesson we learned is to design the entire architecture BEFORE creating VMs in Azure. Hopefully we have done most of the ‘learn by doing’ for you in this category. For us, changing the configuration of availability sets and cloud services involved throwing away one set of VMs and starting over. There’s no need for you to experience this pain. In partnership with the Azure Center of Excellence and a few of our best SharePoint field experts, we settled on some best practices for architecture that are described in Windows Azure Architectures for SharePoint 2013. These best practices can be applied to any SharePoint solution in Azure.

As we wrap up this project we are capturing some of the operational issues and best practices that we learned. One of them is to monitor and manage time sync issues between the on-premises and Azure environment. We ran into at least one issue that was solved by adhering to best practices in this category. We hope to publish more operational guidance soon.

Finally, I’ll reiterate a best practice I learned from Mark Russinovich, Technical Fellow in the Cloud and Enterprise Division at Microsoft. Create the largest VM in your Windows Azure environment that you plan to use first. This ensures your solution lands on a “stamp” that allows the largest size you need. This size issue may not be a problem at some point in the future of Azure. However, my team confirmed that this was necessary for our environment.

For more information see: SharePoint Disaster Recovery in Windows Azure.

To learn more about setting up the site-to-site VPN connection, see Deploy Office 365 Directory Synchronization in Windows Azure.

For more information on DR planning, see Brian Lewis' blog series: Disaster Recovery Planning for IT Pros.

• About the usage analytics reports
• View the Most Popular Items report for a catalog
• Change the Recent time period for a usage event
• Narrow the Most Popular Items report to a specific attribute or category
• View the Popularity Trends report for an item
• About the TailTrimming parameter

About the usage analytics reports
The usage analytics reports show statistics of how visitors have interacted with the content on your website, for example which item has been viewed the most. The reports are broken down per usage event. This means that by default you’ll be able to see:

• The number of views for an item.
• The number of recommendations displayed per item.
• The number of recommendations clicked per item.

SharePoint Server 2013 creates two usage analytics reports:

• Most Popular Items – shows usage event statistics for all items in a library or list.
• Popularity Trends – shows usage event statistics for an item, a site or a site collection.

The reports are automatically updated once every 24 hour when the usage analytics job is run.

View the Most Popular Items report for a catalog
In a cross-site publishing scenario where you are displaying catalog content on a Publishing site, you view the Most Popular Items report on your authoring site. Do the following:

1.  On your Authoring site, go to your catalog.
2.  Click the LIST tab –> Most Popular Items.

3.  On the Most Popular Items page, use the menu to select which usage event you want to view statistics for.

Note: You can view statistics for the Recommendations Displays usage event in the Popularity Trends report.

Change the Recent time period for a usage event
On the Most Popular Items page, there are two time periods: Recent and Ever.

The Ever time period shows statistics from the first day a usage event was recorded. The Recent time period is by default set to the last 14 days. To view the default settings of a usage event, do the following:

1.  On the server where SharePoint Server 2013 is installed, open the SharePoint 2013 Management Shell.

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

$SSP = Get-SPEnterpriseSearchServiceApplicationProxy
$tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
$event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }
$event

<EventTypeId> is the numeric EventTypeId of the usage event that you want to view. In the example below, I want to view the Views event, so I entered 1.

The Recent time period is defined by the RecentPopularityTimeframe property. You can change the Recent time period to be anything between one and 14 days. To change the time period, do the following:

1.  In the SharePoint 2013 Management Shell, at the Windows PowerShell command prompt, type these commands:

$SSP = Get-SPEnterpriseSearchServiceApplicationProxy
$tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
$event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }
$event.RecentPopularityTimeFrame = <TimeFrame>
$tenantConfig.Update($SSP)

<EventTypeId> is the numeric EventTypeId of the usage event that you want to change, and <TimeFrame> is the new time period you want to set for the usage event.

In the example below, I wanted to change the Views Recent time to a week, so I entered 1 and 7.

2.  To verify the change, at the Windows PowerShell command prompt, type the following command:

$event

Notice that the value for the RecentPopularityTimeframe parameter has changed to 7.

Narrow the Most Popular Items report to a specific attribute or category
Viewing usage reports per usage event is useful when you want to find out how visitors are interacting with your site. But many times you want to narrow the report to a specific attribute or category, for example all items that are on sale or all Laptops. To do this, you can use Keyword Query Language (KQL). If you don’t know KQL, don’t worry. You can easily narrow your Most Popular Items report without having much knowledge of KQL.

 In our Contoso catalog, we have a site column called RetOnSale. For each item, the value of RetOnSale specifies if the item is on sale or not.

To narrow the Most Popular Items report to only show items that are on sale, we’ll use the managed property that represents the RetOnSale site column. In our Contoso scenario, this is RetOnSale (in another blog post I explain how you can find a managed property name).

In the Search Schema, we can see that the RetOnSale managed property is Queryable. This means that we can use it to narrow the Most Popular Items report.

To see Views usage event statistics for items that are on sale, on the Most Popular Items page, select Most Views, and enter RetOnSale=True.

And just like that, only items that are on sale are shown.

You can also narrow usage event statistics to a specific category, for example all Laptops. In our Contoso scenario, the Item Category site column is used to specify the category for each item.

The managed property name of the Item Category column is owstaxIdProductCatalogItemCategory. The owstaxIdProductCatalogItemCategory managed property is queryable, which means that we can use it to narrow the Most Popular Items report.

To see which laptops are viewed most by visitors, on the Most Popular Items page, select Most Views, and enter owstaxIdProductCatalogItemCategory:Laptops

By narrowing the Views usage event statistics to a specific category, we can verify that the Popular Items Web Part is working correctly on our publishing site. For example, on the Laptops page, notice that the three items that are displayed in the Popular Items Web Part are the same that are shown to have the most Views in the Most Popular Items report that we just narrowed to Laptops.

View the Popularity Trends report for an item
There are two ways you can access the Popularity Trends report for an item:

a.  On your catalog, select the item for which want to view the Popularity Trends report. In the ribbon, click ITEMS --> Popularity Trends.

b.  On the Most Popular Items page, click Popularity Trends.

Both of these options will open a Microsoft Excel sheet where you can view the daily and monthly statistics for the item. Each usage event is shown in a separate tab.

About the TailTrimming parameter
While we’re on the subject of usage analytics reports, one usage event parameter that is worth mentioning is TailTrimming. This parameter specifies when the numbers that are shown in the usage analytics reports should be updated.

IMPORTANT: This parameter does not affect how recommendations are calculated.

For example, for the Views usage event the TailTrimming parameter is by default set to 3.

This means that the usage analytics reports will be updated for an item when the item has been viewed a minimum three times within the last 24 hours. For example, if the item Fabrikam Laptop16 M6000 has been viewed twice within the last 24 hours, these two views won’t show up in the usage analytics reports. If within the next 24 hours the Fabrikam Laptop16 M6000 item is viewed 4 times, the usage analytics report will be updated with 4 views.

The reason the TailTrimming parameter is set to 3 is to avoid having to update items that almost none of your website visitors are interacting with. By not updating these items, you reduce the load on your system. On the other hand, when the TailTrimming parameter is set to 3, the usage analytics reports can be somewhat inaccurate. In the example with the Fabrikam Laptop16 M6000, the two views in the first 24 hours will not show up in the usage analytic reports. Total number of views of Fabrikam Laptop16 M6000 over the last 48 hours will show 4, but in reality, it was viewed 6 times.

If you want the usage analytics reports to be updated regardless of minimum amount of views within the last 24 hours, do the following:

1.  In the SharePoint 2013 Management Shell, at the Windows PowerShell command prompt, type these commands:

$SSP = Get-SPEnterpriseSearchServiceApplicationProxy
$tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
$event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }
$event.TailTrimming = <TailTrimming>
$tenantConfig.Update($SSP)

Where <EventTypeId> is the numeric EventTypeId of the usage event that you want to change, and <TailTrimming> is the minimum amount of times the usage event has to occur within 24 hours for the usage analytics reports to be updated.

In the example below I wanted the usage analytics reports for the Views usage event to be updated if a Views usage event occurs within 24 hours, so I entered 1 and 0.

2.  To verify the change, at the Windows PowerShell command prompt, type the following command:

$event

Notice that the value of the TailTrimming parameter has changed to 0.

So with that, this series has come to an end. Hopefully you now have a better understanding of how recommendations and popular items work, and can start adding them to your website.

• Enable usage cookies to generate unique user IDs
• Enable the recording of a usage event for anonymous users
  
  

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

Enable usage cookies to generate unique user IDs
In an earlier blog post I described how I arranged a “click party” to generate usage events. All users that participated in the “click party” were logged in. When users are logged in, each user has a unique user ID. In the event store file I was therefore able to verify that different user IDs were recorded for the usage events.

So how can usage events be recorded with a unique user ID when users are not logged in, that is, when they’re anonymous visitors? The answer is usage cookies. By default, usage cookies are not enabled for a SharePoint web application, but you can enable them. These usage cookies generate a unique GUID that is used as a user ID when usage event data is processed. The GUID is available for the lifetime of the cookie. The lifetime of the cookie is 14 days.

IMPORTANT: Local legal restrictions might apply when you enable usage cookies on websites that have anonymous users.

To enable usage cookies, do the following:

1.  In Central Administration, click Manage web applications.

2. Select the web application that contains your publishing site, and click General Settings.

3.  In the Web Application General Settings dialog box, in the Usage Cookie section, for Usage Cookie Status, click On.

4.  Click OK to save your changes.

To verify that the Views usage events were correctly recorded on my Contoso website, I asked two colleagues to click around on my Contoso Electronics website. They were both anonymous users. I then started search analytics, and pushed the usage events to the Event store (I showed you how to do this in an earlier blog. In the usage event file, I verified that two different user IDs had been recorded.

Enable the recording of a usage event for anonymous users
When you enable usage cookies, only the Views usage event can be recorded for anonymous users. So, before you can record other usage events, for example Recommendation Displays, for anonymous users, you have to change a parameter value on the usage event.

The Options parameter specifies if the usage event can be recorded for anonymous users. For example, for the Views usage event, the Options parameter is set to AllowAnonymousWrite by default.  This means that the Views usage event can be recorded for anonymous users.

For the Recommendation Displays usage event, the Options parameter is set to None by default.  This means that the Recommendation Displays usage event can’t be recorded for anonymous users.

To enable the recording of a usage event for anonymous users, do the following:

1.  On the server where SharePoint Server 2013 is installed, open the SharePoint 2013 Management Shell.
2.  At the Windows PowerShell command prompt, type the following commands:

# View the EventTypeId’s for all usage events:
$SSP = Get-SPEnterpriseSearchServiceApplicationProxy
$SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

# Get a usage event:
$tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
$event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }

<EventTypeID> is the number of the usage event that you want to enable for anonymous users, for example 2, which is the Recommendation Displays usage event.

# Enable the recording of a usage event for anonymous users:
$event.Options = [Microsoft.Office.Server.Search.Analytics.EventOptions]::AllowAnonymousWrite
$tenantConfig.Update($SSP)

# Verify that the recording of a usage event for anonymous users has been enabled:
$event

After I enabled Recommendations Displays and Recommendations Clicked for anonymous users, I wanted to verify that these usage events were recorded. So, I again asked two colleagues to click around on my Contoso website. They were both anonymous users. I then started search analytics, and pushed the usage events to the Event store (I showed you how to do this in an earlier blog).

Remember, in the Event store, each usage event type will be recorded in a separate file. Each file name starts with the EventTypeID, so a file name that starts with 1 contains the Views usage events. A file name that starts with 2 contains the Recommendations Displays usage events etc.

In the Event store, I verified that three usage event types were logged. Nice!

So now you know how to configure and display recommendations and popular items on your website. If you want more details about the number of views for a specific item or category, you can do this by looking in the usage analytics reports on your catalog.  I’ll show you how you can do that in the next blog.

Next blog post in this series
View and configure usage analytics reports

• Add a Recommended Items Web Part to a page
• About the recommendedfor managed property
• Configure the Recommended Items Web Part
• About the display template that is used by the Recommended Items Web Part
• Add a Popular Items Web Part to a page
• Configure the Popular Items Web Part

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

Add a Recommended Items Web Part to a page
Navigate to the page where you want to add the Recommended Items Web Part (RIWP). In our Contoso scenario, we want to add the RIWP to our catalog item page. Do the following:

1.  Select the Settings menu --> Edit page.
2.  In the Web Part Zone where you want to add the Web Part, select Add a Web Part.
3.  In the Categories list, select Search-Driven Content.
4.  In the Parts list, select Recommended Items, and then Add.

In our Contoso scenario, we‘ll show the RIWP below the CSWP.

About the recommendedfor managed property
In a previous blog post, I told you about the UsageAnalyticsId managed property that is used by Usage analytics to specify how recommendations between individual items should be calculated. The result of this calculation is sent to the recommendedfor managed property. The RIWP uses the recommendedfor managed property to query for recommendations. You don’t need to know about this managed property when you configure the RIWP. But, to understand how the query in the RIWP works, it’s important that you keep the recommendedfor managed property in mind.

Configure the Recommended Items Web Part
When you configure the RIWP, you should configure it on an item details page where recommendations have been generated.  Remember, in a previous blog post I told you how I generated recommendations by inviting some co-workers to a “click party.” At this “click party” I told my co-workers to click specific items so that recommendations would be generated. So, in our Contoso scenario, I added the RIWP to an item details page where I knew recommendations had been generated through the clicking of my co-workers.

Here’s what you should do to configure the RIWP:

1.  Select the Settings menu --> Edit page.
2.  In the RIWP, select the Web Part Menu --> Edit Web Part.

3.  In the Web Part tool pane, select Change query. This will open a dialog box.
4.  In the Build Your Querydialog box, select the following:

• In the Get recommended items for section, select A token from the URL and then select from which URL value you want to get recommendations. In our Contoso scenario, we want to get recommendations from {URL.Token.2} (number).
• In the Restrict by app section, select Specify a URL, and then enter the URL of your catalog.

So now you might be thinking "OK, that was easy, but what does this actually mean?" Well, understanding what this means is a bit complicated. So, let’s take a deep breath and take a closer look.

• A token from the URL means that we want to get recommendations for a value that is used in the URL.
• {URL.Token.2} is a query variable that represents the second value in the URL as counted from right to left. For example, in the URL https://www.contoso.com/computers/desktops/5637145799/5637146352, the query variable {URLToken.2} represents the value 5637145799.  Remember, when we connected our publishing site to the catalog, we specified that the value of Group Number should be used as the second to last value in the URL of our catalog item page. That means that the query variable {URL.Token.2} represents the value of Group Number.  Also, we mapped UsageAnalyticsID to Group Number so that the Usage analytics calculation would be based on Group Number. 
• Specify a URL means that we want to specify from which site we want to get recommendations, in this case our Authoring site.

But from these settings, it’s not clear which managed property is used in the query. So, to view more information about the query, select TEST. The query that is issued by the Web Part is shown in the Query text section.

If we break this down, we get the following:

• recommendedfor is the managed property that is used in the query.
• The colon : means “contains.”
• 5637145799 is the value of the query variable {URL.Token.2}, which is a Group Number value.
• path:"https://ib-perf-8/sites/catalog" is the URL to our Authoring site.
• (IsDocument:"True" OR contentclass:"STS_ListItem") narrows the search result down to only documents or list items.

If we put all this information together, we can understand that the query means the following:

From the URL of the Authoring site, search for document or list items where the value of the managed property recommendedfor contains the value that is currently used as the second value in the URL, counting from right to left.  

So, now we know what the query means. But we’re not quite done with the configuration. In the SEARCH RESULT PREVIEW section, we can see that all items in a product group are displayed, for example all SV Keyboard E10 (notice that they all have the same value for Group Number in the URL).

All items in the product group are shown because the Usage analytics calculation is done on the group level (remember, we mapped UsageAnalyticsId to ows_ProductCatalogGroupNumber). But we only want to display one item per product group.

Luckily we can do this by grouping search results. To group search results, do the following:

5.  Select REFINERS --> Show more.

6.  From the Group by menu, select Show all properties.

7.  We want to show only one item per product group, so we select ProductCatalogGroupNumberOWSTEXT (the managed property of Group Number). We only want to display one item per group, so we leave the value in Show there results as 1.

In the SEARCH RESULT PREVIEW, we can now see that only one item per product group is shown.

8.  Select OK to save the changes.
9.  In the Web Part tool pane, in the Number of items to show field, enter how many items you want to display in the Web Part.

10.  Select OK, and save the page.

Even though it doesn’t look good, good recommendations are now displayed on our catalog item page.

About the display template that is used by the Recommended Items Web Part
Just as you do with the Content Search Web Part (CSWP), you use display templates to control how content should be displayed in a RIWP. In an earlier blog post, I explained how you can upload and apply display templates to the Content Search Web Part. You can do the same for the RIWP, but the display template that is used by the RIWP contains important code that logs the two usage events Recommendation Displayed and Recommendation Clicked. 

Remember, in an earlier blog I told you that there are three default usage events in SharePoint Server 2013. The usage events Recommendation Displayed and Recommendation Clicked are used to record statistics of how visitors have interacted with the content on your website. When an item is displayed as a recommendation, a Recommendation Displayed usage event is recorded. When an item is clicked on when it is displayed as a recommendation, a Recommendation Clicked usage event is recorded. I will show you how you can view these statistics in a later blog post. 

In the previous blog we modified the CSWP display template to log the Views usage event. The logging of the Recommendation Displayed and Recommendation Clicked usage events are done in the RIWP. The default display template that is used by the RIWP is Item_RecommendationsClickLogging. This display template contains the two functions LogRecsViewToEventStore and LogRecsClickToEventStore. These two functions log the Recommendation Displayed and Recommendation Clicked usage events.

When you change your RIWP display template, you should copy the Item_RecommendationsClickLogging file, make changes to the copied version, and apply it to your RIWP. That way you don’t have to worry about adding code in the same way that we did for the CSWP.

After applying the changed display template to the RIWP, the recommended items are displayed nicely.

Add a Popular Items Web Part to a page
You can display the most popular, that is, the most viewed, items within your catalog by adding a Popular Items Web Part (PIWP) to your category page. It’s important to understand that when you add a PIWP to your catalog page, the PIWP will automatically show the most viewed items within each category. For example, if a visitor is viewing the Cameras category, the PIWP will show the most viewed items within the Cameras category. If a visitor is viewing the Camcorders category, the PIWP will show the most viewed items within the Camcorders category.

To add a PIWP, navigate to the page where you want to add the PIWP. In our Contoso scenario, we’ll add a PIWP to our category page. Do the following:

1.  Select the Settings menu --> Edit page.
2.  In the Web Part Zone where you want to add the Web Part, select Add a Web Part.
3.  In the Categories list, select Search-Driven Content.
4.  In the Parts list, select Popular Items, and then Add.

In our Contoso scenario, we‘ll show the PIWP above the CSWP.

Configure the Popular Items Web Part

1.  Select the Settings menu --> Edit page.
2.  In the PIWP, select the Web Part Menu --> Edit Web Part.

3.  In the Web Part tool pane, select Change query. This will open a dialog box.
4.  In the Restrict by app section, select Specify a URL and enter the URL of your Authoring site.
5.  In the Restrict by tag section, select Restrict by current and child navigation terms.

No results are displayed in the SEARCH RESULT PREVIEW section. What’s going on?

To find out more about the query that the PIWP issues, select TEST. On the TEST tab we can see the Query text.

The query text means the following:

• path:"https://ib-perf-8/sites/catalog" is the URL to our Authoring site.
• owstaxIdMetadataAllTagsInfo is the managed property that is used in the query.
• The colon : means “contains.”
• #91eb9f0d-3e5a-41a8-8487-78dfe234ca7c is the GUID of the current category. In this example the current category is Cameras.
• (IsDocument:"True" OR contentclass:"STS_ListItem") narrows the search result down to only documents or list items.

If we put this information together, we can understand that the query means the following:

From the URL of the Authoring site, search for document or list items where the value of the managed property owstaxIdMetadataAllTagsInfo contains the GUID of the current navigation category or any of the children of the current navigation.

An important piece of information that we can see in the query text is that the PIWP uses the owstaxIdMetadataAllTagsInfo managed property in its query. You can’t change the query in the PIWP to use another managed property. That means that for the query in the PIWP to work correctly, the owstaxIdMetadataAllTagsInfo managed property needs to include the value of the managed property that we use to drive managed navigation.  In our Contoso scenario, the managed property that drives managed navigation is owstaxIdProductCatalogItemCategory. So, what we need to do is to map the crawled property of owstaxIdProductCatalogItemCategory to the owstaxIdMetadataAllTagsInfo managed property. 

I showed you how to map a crawled property to a managed property in an earlier blog.

IMPORTANT: You have to do the mapping on the Authoring site.

In our Contoso scenario, the correctly mapped owstaxIdMetadataAllTagsInfo property looks like this:

After you have changed the mapping of the property, you have to start a full crawl.

But there is one very important thing that you can’t see in the query text, and that is how the search results are sorted. The PIWP sorts search results in a descending order on the ViewsRecent managed property. By default, the ViewsRecent managed property contains the number of views for an item within the last 14 days (I’ll show you how you can change this to, for example, the last 7 days in another blog article). This means that the query issued by the PIWP will do the following:

From the URL of the Authoring site, search for document or list items where the value of the managed property owstaxIdMetadataAllTagsInfo contains the GUID of the current navigation category, or any of the children of the current navigation. Sort the search results in descending order of views for the last 14 days.

When the full crawl has finished, you’ll see search result in the Web Part.

6.  Select OK to save the changes, and save the page.

To display the popular items nicely, you can apply a display template in the same way that you did with the CSWP.

To check that the PIWP is working correctly, go to the Cameras section. On this page, the most viewed items within the Cameras category are displayed.

When we go to the Camcorders category, the most viewed items within the Camcorders category are displayed.

Our PIWP is working the way it should. Nice!

So now you know how to configure the RIWP and the PIWP. You might have noticed that throughout the examples I showed, I was always logged in to my account.

In the next blog post, I’ll explain how all of this works if the website only has anonymous users, that is, users who’re are not logged in.

Next blog post in this series
Use recommendations and popular items on websites with anonymous users.

• Change the mapping of the UsageAnalyticsID managed property
• Modify a Content Search Web Part display template so that usage events are logged correctly
• Why you should simulate the generation of Views usage events
• Run Windows PowerShell scripts to start search analytics and push usage events to the Event store
• View usage events in the Event store
• Prepare usage events files before starting Usage analytics with Windows PowerShell
• Start the Usage analytics job with Windows PowerShell

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.

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

3.  From the Property Name field, select 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.

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.

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

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.

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',

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.

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:

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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

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.

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.

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

Here’s how Usage analytics works:  

1. Visitors do something on your website, for example, they view an item. This generates a usage event.
2. The usage event is recorded in the Event store.
3. The usage events are sent to the Analytics Processing Component where they are analyzed. The result is sent to the Search index.
4. When visitors navigate to a page that contains a Recommendations or Popular Items Web Part, a query is automatically issued and sent to the search index.
5. The query results are returned from the search index and displayed in the Recommendations and Popular Items Web Part on your website.

View the usage event definitions
There are three default usage events in SharePoint Server 2013:

• Views – a usage event is registered when a visitor views an item on your site.
• Recommendation Displayed – a usage event is registered when an item is displayed as a recommendation on your site.
• Recommendation Clicked – a usage event is registered when a visitor clicks an item that is displayed as a recommendation on your site.

To view the usage event definitions, do the following:

1.  On the server where SharePoint Server 2013 is installed, open the SharePoint 2013 Management Shell.

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

$SSP = Get-SPEnterpriseSearchServiceApplicationProxy
$SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

The default usage event definitions are displayed. I’ll explain some of the usage event settings in later blog posts, but for now, just notice that each event has an EventTypeId and an EventName.  

The default usage events have the following EventTypeID values:

About Usage analytics in a cross-site publishing scenario
One important step in how Usage analytics works is step 2: The usage event is recorded in the Event store. In the Event store, each usage event must be recorded using the URL of the item. I’ll repeat this, because this is really important:

In the Event store, each usage event must be recorded using the URL of the item.

This is especially important in a cross-site publishing scenario. With cross-site publishing, content is stored in an Authoring site collection and displayed in a Publishing site collection.  Managed navigation is used together with category pages and catalog item pages to display content. This means that when visitors view an item on the Publishing site, the usage event takes place on the catalog item page, for example https://www.contoso/sites/Pages/ContosoItemPage.aspx. Because the same catalog item page is used to display many items, the usage event can’t be recorded using the URL of the catalog item page. For Usage analytics to work in a cross-site publishing scenario, the usage event must be recorded using the URL of the item in the Authoring site collection, for example: https://www.contoso/sites/catalog/Lists/Products/DispForm.aspx?ID=12.

Depending on how you’ve set up your website, SharePoint Server 2013 can automatically record the usage event on the URL of the item in the Authoring site. Here’s the question you have to ask yourself: Which Web Part are you using to display items on your catalog item page? If your answer is “Catalog Item Reuse Web Parts”, then you have nothing to worry about. The Catalog Item Reuse Web Part will automatically ensure that usage events are recorded correctly in the Event store. However, if you’re using a Content Search Web Part to display items on your catalog item page, you’ll have to do some extra configuration steps. But not to worry: I’ll explain all these steps in the next blog articles.

But before we move on, there’s one more thing that you need to know about: The UsageAnalyticsID managed property.

About the UsageAnalyticsID managed property
The items on our Contoso website are available in different colors. For example, the item Southridge Video Laptop15.4W M1548 is available in four different colors. On the Authoring site, color versions are grouped under a common Group Number.

On the Publishing site, we use the value of both Group Number and Item Number in the friendly URL (FURL). Visitors can easily see that the product exists in other colors, and they can quickly view details about the product in another color without having to go back to the category page.

The default Usage analytics calculation will consider the color of the items when calculating recommendations. For example, recommendations for a white Southridge Video Laptop15.4W M1548 could turn out to be a white Litware Laptop Keyboard X105, a blue Litware Laptop Keyboard X105, a white Litware Wireless Laser Mouse M55 and a blue Litware Wireless Laser Mouse M55.

The two recommended keyboards are the same product, and so are the two mice. These are not good recommendations. To get recommendations that will ignore the product color, we have to change the mapping of the UsageAnalyticsID managed property.

By default, UsageAnalyticsID is mapped to the crawled property ows_ProductCatalogItemNumber. If you used the Product Catalog site template when you created your Authoring site collection, this crawled property represents the site column Item Number in your Products list.

If you didn’t use the Product Catalog site template when you created your Authoring site collection, or, if you don’t want to use the site column Item Number in the Usage analytics calculation, you’ll have to change the mapping of the UsageAnalyticsID managed property. However, when you change the mapping, you’ll have to make sure that the property you map to UsageAnalyticsID is used in the friendly URL (FURL) of your catalog item page (most likely, you specified this FURL when you connected your publishing site to your catalog). This is because the Recommended Items Web Part uses a value from the FURL to show the correct recommendations (I will show you how to configure the Recommended Items Web Part in a later blog post).

Remember, the color versions of our products are grouped under a common Group Number, and we use the value of Group Number in the FURL of our catalog item page.  So, by mapping UsageAnalyticsID to the crawled property of Group Number, the Usage analytics calculation will be done on a group level. This means that we can display one product per product group as recommendations.

There is of course more to it than this, so if you’re confused, I hope you’ll hang in there. In the next blog posts, I’ll walk you through all the steps that you have to do to display recommendations and popular items on your website.

Next blog post in this series:
Modify the Content Search Web Part display template and use Windows PowerShell to start Usage analytics

To help explain, I’ll use examples from a fictitious company called Contoso. Here’s what the website will look like once we’re done.

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

Blog posts in this series:

• An introduction to recommendations and popular items
• Modify the Content Search Web Part display template and use Windows PowerShell to start Usage analytics
• Add and configure the Recommended Items and Popular Items Web Part
• Use recommendations and popular items on websites with anonymous users
• View and configure usage analytics reports

Why this series is like Season 2 in a TV series
The Contoso website that I’ll use as an example throughout this series is a cross-site publishing website. If the story of how the Contoso site was set up were a TV series, the blog series How to set up a product-centric website in SharePoint Server 2013 would be Season 1. This series would therefore be Season 2.

Throughout this series, I’ll refer to many concepts and features that I explained in the previous blog series (Season 1). You should read the first series before continuing with this one. As with a TV series, knowing the story from the beginning makes things not just easier to understand, but also more interesting.

Are you going to the SharePoint Conference this year?

We are once again offering a limited number of dedicated solution-design sessions for individual customers.

These Design Time sessions are intended to help IT professionals and developers envision and plan a solution based on the SharePoint 2013 products or Office 365.

Sessions will last 60 minutes. If you are selected, you will meet with one or more product experts (Microsoft product team members, consultants, or MVPs) and one or more SharePoint documentation team members to discuss your solution goals, get advice on current challenges, and envision how to enhance your solution using SharePoint 2013 products and Office 365. Design sessions are offered for the categories listed in the table below.

If you are selected for a focus area, you will meet with product experts who specialize in your focus area and your session will focus on your design and implementation choices.

To be eligible to participate, you must meet the following criteria:

• Your organization must be planning or maintaining a solution that fits a focus area.

• You must bring either a draft of your intended solution or a representation of your existing SharePoint solution. For example, your draft can include the proposed physical topology, logical farm architecture, hierarchy of sites, plan for database sizing and settings, search settings, plan for security and isolation, etc.

To nominate your company or organization for a design session, send email to spcdesign@microsoft.com by January 20 30 (extended!), 2014, and include the following information:

• Name of your company or organization
• Contact information: name and title or role in your organization
• One or two focus area(s) you are interested in and any specific questions you have about that area now
• Brief description of your solution goals and the challenges you’d like to discuss in the Design Time session

Due to a limited number of available sessions for each focus area, not every nomination will be accepted. We will review nominations and select those that best fit the focus area and that look like they will lead to a meaningful discussion for both the organization and Microsoft.

Information that you share with the product experts and documentation team either in e-mail or during a design session will be treated confidentially. If you are selected, a member of the SharePoint conference team will contact you with the day and time of your session by February 14, 2014.

We look forward to seeing you in March!

- The SharePoint Content Team

SharePoint automatically creates a query suggestion when users have clicked a search result for a query at least six times. For example, if users have entered the query word “coffee” and then clicked on a search result six times, then “coffee” automatically becomes a query suggestion.

You can also create query spelling suggestions manually. In this blog post I’ll use a simple example to show how you can do that. In this blog post I’ll explain:

• How to create a query suggestions file
• How to import a query suggestions file to SharePoint Online 
• How to import a query suggestions file to SharePoint Server 2013
• How to verify that your query suggestions are working
   

How to create a query suggestions file

1. Open a text editor, for example Notepad.
2. Enter the query spelling suggestions that you want to add. Add one word or phrase per line.

3. Save the file as a .txt file and encoding UTF-8.

Now that you have your query suggestions file, the next step is to import it to SharePoint.

How to import a query suggestions file to SharePoint Online

1. From the O365 Admin menu, select SharePoint.

2. On the SharePoint admin center, select search.

3. On the search administration page, select Query Suggestion Settings.

4. In the Language for suggestions phrases section, select the language of your query suggestions. In the Always suggest phrases section, select Import from text file.

5. In the Text file with phrases section, select Choose File, and import your query suggestions file.

6. Select OK, and then Save Settings.

IMPORTANT: When you import query suggestions, existing query suggestions will be overwritten. If you haven’t previously imported any query suggestions, you have nothing to worry about. Automatically created query suggestions will not be overwritten when you import new ones. However, if you want to import additional query suggestions, you should export the existing query suggestions file, update it, and then re-import it.

How to import a query suggestions file to SharePoint Server 2013

1. Go to Central Administration --> Manage service applications --> Search Service Application --> Query Suggestions.
2. On the Query Suggestion Settings page, in the Always suggest phases section, select Import from text file.

3. On the Import phrases for query suggestions page, select Browse, and import your query suggestions file.

4. Select OK, and then Save Settings.

IMPORTANT: When you import query suggestions, existing query suggestions will be overwritten. If you haven’t previously imported any query suggestions, you have nothing to worry about. Automatically created query suggestions will not be overwritten when you import new ones. However, if you want to import additional query suggestions, you should export the existing query suggestions file, update it, and then re-import it.

How to verify that your query suggestions are working

IMPORTANT: After you have uploaded your query suggestions file, it might take a few hours before your query suggestions are displayed.

To verify that your query suggestions are working correctly, in a search box, type two letters of a phrase from your query suggestions file. The query suggestions appear under the search box.

Additional resources

• Manage query suggestions in SharePoint Server 2013
• How to customize query suggestions for SharePoint search

QuerySuggestions_coffee.txt