Applying Site Search Best Practices using Sitecore Part 4

This is the last part of my long adventure to cover all the best practices listed in the Best Practices for Site Search eBook. The previous parts can be foundhere.

Search Analytics and Reporting

In previous posts, I covered the global search box, the search result pages and the search driven content listing pages. It is now time to close this series with a more general topic affecting all the previously mentioned components: Analytics and tracking.

13. Track visitor activity

Coveo for Sitecore components will track all events on the page and send the data to the Coveo Usage Analytics.

You can also send these events to the Sitecore reporting database by setting the Enable Sitecore Analytics property on the Coveo Search View Rendering to true.

An event is only sent from a published page. You can track it by looking at the network traffic using a browser console or a web debugging proxy.

Here is an example of a payload sent to the Coveo Cloud Usage Analytics API:

{ "actionCause":"documentOpen", "actionType":"document", "anonymous ":true, "device ": "Chrome ", "mobile ":false, "language ": "en ", "responseTime ":0, "originLevel1 ": "CoveoSearch ", "originLevel2 ": "_524BC2CF-1942-42EA-A236-6AE80E3B7596 ", "originLevel3 ": "/sitecore/content/Home/CoveoSearch ", "customData ":{ "documentURL ": "/en/Team/Mike-Casey ", "documentTitle ": "Mike Casey ", "JSUIVersion ": "1.1276.20;1.1276.20 "}, "userAgent ": "Mozilla/5.0 (windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 ", "searchQueryUid ": "938f1d27-6b40-4fef-add2-e31035ee7e43 ", "queryPipeline ": "Launch Sitecore ", "documentUri ": "sitecore://database/web/ItemId/A410F42C-903A-4D73-AF5C-F13313EA1BF2/Language/en/Version/1 ", "documentUriHash ": "WOHY1H6vY78EOH ", "documentUrl ": "/en/Team/Mike-Casey ", "documentTitle ": "Mike Casey ", "collectionName ": "default ", "sourceName ": "Coveo_web_index", "documentPosition ":1, "viewMethod ": "documentOpen " }

The payload above shows a click event on the “Mike Casey” document from the “CoveoSearch” interface. As you can see, there is a lot more to it, and you can expand it if needed. I will be covering this subject in a bit.

From the Coveo Cloud Usage Analytics perspective, the actionCause is categorized in one of the three Event Causes: Search, Click, and Custom. In the example above, documentOpen is a Click event. The rest of the metadata will be used to document the event.

From a user perspective, the metadata can be extracted in the Coveo Cloud platform. The metadata will be called API Name and can be combined with an Event Cause to create aDimension.

In other words, a Dimension is metadata (extracted through an API Name) in the context of one or more Event causes. This might be a bit confusing so far, but you can refer to thistable for more details.

Let’s say I want to identify my queries without results. I will be using dimensions,metrics, andfilters. My dimension will be Query , which is defined in the Dimensions menu as a Search event using a queryExpression Api Name. The metrics will be Query Count and Visit Count , which is the number of times the query was executed and the number of unique visits related to this query. Finally, the filter Has Results is false is added on the card to show only queries without results.

With these basic principles in mind, it will be easier to understand the remaining best practices regarding Analytics.

14. Slice-and-dice by attribute

The example in the last section used dimensions, metrics, and filters. By combining the three together, you have a rich toolbox which can be used to visualize everything happening with search on your site.

Before we see how to extend this with custom events and metadata, the first thing you should do is to separate your search components in different reports.

In the analytics event payload, you can see the origin key:

"originLevel1 ": "CoveoSearch "

Coveo for Sitecore uses the name of the page hosting the Coveo Search View component when setting the origin key. In my case, CoveoSearch is the name of my search result page item. So to have different origins for each of your search driven pages, you simply need to name them differently in Sitecore.

Now that you understand how to set the originLevel1 , you can use it in multiple ways. As I mentioned earlier, you could combine the originLevel1 dimension with the Query Count metric to create a simple table or pie chart showing the number of queries per origin.

You can also use the origin as a filter on your table, which would allow you to combine several dimensions under the same filter. This filter can be added at the card level, like my previous example with the content gap table, or you can set it at the report level to have multiple cards and tabs affected by the filter.

The originLevel2 is the ID of the current tab. If you do not have a tab component on your page, then the value will be default .

The standalone global search box, which was the subject of the first part of this series of post, will not log any data in the originLevel1 , since it simply redirects the query without sending an analytics payload. Instead, it will be logged in the originLevel3 sent by the search component it redirects to. In short, the originLevel3 is the referrer.

Although the origin is a very useful dimension, it is only one amongst many offered out of the box. You could use the same logic with the Device Category dimension to show only mobile users, or the City and Country dimensions for geographical mapping. You can also create your own dimension, which I will explain in the next section.

15. Track every search experience

By now you should have an idea on how to use the data sent to the Coveo Cloud Usage Analytics platform. With this information in hand, you might want to start sending more complex data , such as the item(s) in a visitor’s cart or if the visitor is a specific type or account like a partner or a premium user.

Metadata can be added directly on theproperties of the Coveo Search View rendering. However, this set of metadata will be static. Since the items in a cart can always change, you will need your set of metadata to be dynamic.

My favorite approach is to send the metadata programmatically by adding the key value directly to the analyticsCustomMetadata option of the component. In the first part of this series , I explained how to retrieve and extend the options of a Coveo component. You can use the same logic for custom analytics metadata, so if you want to send the item(s) in the cart of your site visitor, you could do something like this:

var cartItems = // Code to retrieve the items in the cart of the user. CoveoForSitecore.componentsOptions.analyticsCustomMetadata["cartIte