Troubleshooting User Visits

When analyzing user visits in the Visit Browser, you may face situations where a single visit is divided into many visits, which all contain only one usage analytics event in the Event Count column (see Why Are the Visit Counts from Usage Analytics Cards and the Visit Browser Different?).

IncoherentVisitBrowser

Typically, this kind of information displayed in the Visit Browser is the result of an implementation issue. This article provides guidelines to help you identify the problem.

Access Your Browser Developer Tools

To properly follow the guidelines provided in this article, access the page where your search component is integrated, and then access the Network tab of your browser developer tools:

Google Chrome developer tools are used in this article.

Ensure the Proper HTTP Requests Are Logged

  1. Access your browser developer tools.

  2. In the search box of the page you are looking at, type a query, and then press the Enter key or click the search button.

  3. In the Name column of the network request table, look for POST or GET requests on /rest/v15/analytics/.

    httpRequest

  1. Access your browser developer tools.

  2. In the search box of the page you are looking at, type a query, and then press the Enter key or click the search button.

  3. Select the POST or GET request on /rest/v15/analytics/ (see Ensure the Proper HTTP Requests are Logged).

  4. In the Cookies tab, under the Request Cookies section, find the visitor entry.

    VisitorCookie2

If the visitor cookie is absent, your browser may block third-party cookies. In that case, you can use the visitor query parameter to supply and store the visitor ID (see Tracking Sessions and Visitors).

Ensure There Is a visitor Query Parameter in the Requests

  1. Access your browser developer tools.

  2. In the search box of the page you are looking at, type a query, and then press the Enter key or click the search button.

  3. Select the POST or GET request on /rest/v15/analytics/ (see Ensure the Proper HTTP Requests are Logged).

  4. In the Headers tab, find the Query String Parameters section.

    queryParameter

If the visitor query parameter is absent, it means that the code of the search interface does not send the visitor ID to Coveo Usage Analytics (Coveo UA).

  1. Access your browser developer tools.

  2. In the search box of the page you are looking at, type a query, and then press the Enter key or click the search button.

  3. In the Name column of the network request table, look for POST or GET requests on /rest/v15/analytics/ (see Ensure the Proper HTTP Requests are Logged).

If the visitor cookie and visitor query parameter values do not match, you may have issues with parameter precedence. In that case, you should check the value of the prioritizeVisitorParameter query parameter (see Tracking Sessions and Visitors).

Ensure the Coveo Usage Analytics Response Value for the Visitor ID Matches the Request

  1. Access your browser developer tools.

  2. In the search box of the page you are looking at, type a query, and then press the Enter key or click the search button.

  3. In the Name column of the network request table, look for POST or GET requests on /rest/v15/analytics/ (see Ensure the Proper HTTP Requests are Logged).

  4. Compare the visitor cookie and visitor query parameter values displayed in the request with the value of the visitorid field of the JSON response. This information is displayed in the Network tab of the Google Chrome developer tools, in the Response sub tab.

    cookieResponseVsRequest

If the values are different, it means that the code of the search interface does not use the right value.

Ensure the Coveo Usage Analytics Response Value for the Visit ID Does Not Match the Request

  1. Access your browser developer tools.

  2. In the search box of the page you are looking at, type a query, and then press the Enter key or click the search button.

  3. In the Name column of the network request table, look for POST or GET requests on /rest/v15/analytics/ (see Ensure the Proper HTTP Requests are Logged).

  4. Compare the visitor cookie and visitor query parameter values displayed in the request with the value of the visitid field of the JSON response. This information is displayed in the Network tab of the Google Chrome developer tools, in the Response sub tab.

    paramResponseVsRequest

If the values are the same, it means that the code of the page uses the wrong field. The visitorId field should be used.

Ensure the API Calls Were Performed Using HTTPS

Some browsers do not save usage analytics cookies when the connection is not secured.

  1. Access your browser developer tools.

  2. In the search box of the page you are looking at, type a query, and then press the Enter key or click the search button.

  3. In the Name column of the network request table, look for POST or GET requests on /rest/v15/analytics/ (see Ensure the Proper HTTP Requests are Logged).

  4. In the Headers tab, find the General section.

  5. Ensure that the Request URL value displays a secured Hypertext Transfer Protocol (https://).

    SecuredRequest

Check Whether Your Website Uses an Intermediate Server

Using intermediate servers between users and Coveo UA, such as a proxy server, can cause inconsistencies in the visit tracking process.

Tracking Issues Across Different Website Sections

If you noticed that visits are handled correctly when the user stays within a specific part of the website, but stop working when they move to another section, visits are probably wrongly tracked across the sections.

If your cookie storage medium is not resilient to changes in the domain name, you may lose track of your user visits when they move from one section to another.

You have both a.example.com and b.example.com.

If you only set a cookie on a.example.com, the cookie would not be visible on b.example.com.

To track visits across those two websites, you would need to explicitly set the cookie on the whole example.com domain.

Verify the Authentication Providers Used Across Different Website Sections

If you use different authentication providers across your website sections, your users’ usernames can change depending on the active one.

You have both a.example.com and b.example.com.

A user has to authenticate using Google on a.example.com and Office 365 on b.example.com.

This causes the user to change from one username to another, thus dividing the user visit.