qb_dnt and qb_dnt_ext

In this article

It’s possible to partly or totally block user data storage and retrieval. There are cookie directives to manage how the Coveo Experience Hub and Coveo Experimentation Hub (CEH) work with user data.

  • qb_dnt manages data tracking and personalization in Experience Hub campaigns and CEH experiences

    Value Behavior

    0 or no qb_dnt

    Allows for data collection and personalization.

    1

    Blocks the Experience Hub and CEH from collecting visitor data.

    • Personalization is still delivered, but based on data stored locally in the user’s browser. That data is available via the qb_permanent and qb_session cookies.

      Data example
      {
          "sample": "39452",
          "viewTs": 1687897647751,
          "visitorId": "aeb36c3f-ddeb-54c5-a469-abdz5c7e07a9",
          "pageViewNumber": 1,
          "cookiePersists": true,
          "timezoneOffset": 240,
          "conversionNumber": 0,
          "conversionCycleNumber": 1,
          "lifetimeValue": 0,
          "firstViewTs": 1686171444000,
          "firstConversionTs": 0,
          "sessionNumber": 3,
          "entranceNumber": 3,
          "ipAddress": "85.26.276.13",
          "city": "whitby",
          "cityCode": "4682",
          "country": "canada",
          "countryCode": "CA",
          "latitude": 43.87,
          "longitude": -78.95,
          "area": "oshawa",
          "areaCode": "124532",
          "region": "ontario",
          "regionCode": "63",
          "entranceTs": 1687897647751,
          "viewNumber": 15,
          "entranceViewNumber": 1,
          "eventNumber": 6,
          "sessionViewNumber": 1,
          "sessionTs": 1687897647751
      }
    • The events are still generated, but they’re not sent from the browser to Coveo or any third-party servers (such as Google UA or GA4). To work properly, some campaigns would retrieve data from generated events.

      Example

      An Experience Hub Recommendations campaign would need to retrieve the product data from the ecProduct events.

    2

    Blocks all personalization.

    Important

    qb_dnt=2 means that CMH and CEH don’t set any cookies and smartserve.js isn’t loaded.

  • qb_dnt_ext can be used when a visitor consents to Experience Hub and CEH data tracking and personalization, but doesn’t consent to data tracking with external integrations such as Google UA or GA4.

    Value Behavior

    no qb_dnt_ext cookie

    Allows for sending events to third parties.

    ga

    Blocks the Experience Hub and CEH from sending events to Google UA and/or GA4.

Usage best practices

Consider the following options that may help you decide the most appropriate solution:

Option 1: smartserve.js loaded through a tag manager

Following this approach, we don’t load the Smartserve tag when the visitor lands on site. We prompt the visitor to review cookie consent and they may choose to:

  • Accept all cookies. We load the smartserve.js script through the tag manager.

  • Not accept first-party personalization cookies. We set qb_dnt=1 and load the smartserve.js script through the tag manager.

  • Not interact with the cookie prompt. We don’t set any cookies and you need to set up the tag manager so that it won’t load smartserve.js.

Dropping the qb_dnt cookie with a value of 1, for example:

document.cookie = 'qb_dnt=1; path=/'

blocks event, meta, and context data being sent to Coveo via Jolt.

The first-party personalization cookies used by smartserve.js to serve campaigns are set, campaigns will still fire, and data can still be sent to services such as Stash.

There are two main drawbacks to this approach:

  1. Visitors that decide not to interact with the cookie consent prompt and continue navigating will never be exposed to your personalizations

  2. Visitors will experience a degree of flickering until smartserve.js is loaded on the page, more so when a personalization makes significant changes to the look and feel of page, simply because of the increased amount of time required to process those changes.

Option 2: smartserve.js is hard-coded and qb_dnt=1 is set in the prescript

Following this approach, we set qb_dnt=1 in the prescript. Campaigns are loaded immediately when the visitor lands on the site and they may choose to:

  • Accept all cookies—we set qb_dnt=0. We don’t reload the page and we track events on the next page load

  • Not accept first-party personalization cookies—we do nothing since qb_dnt=1

  • Not interact with the cookie prompt—we don’t set any cookies, but smartserve.js is loaded and campaigns are shown.

The main drawback to this approach is that it’s not possible to track events on the landing page. If the user accepts personalization cookies and qb_dnt is set to 0`, then event tracking will only start on the next page load.

For visitors that specifically refuse cookie consent or withdraw consent at a later date, there’s the option of blocking any data being sent to Coveo:

document.cookie = 'qb_dnt=2; path=/'
Warning

This approach will block smartserve.js from delivering campaigns, segmenting visitors, and collecting data. Following this method means that none of your campaigns will fire for any visitors. This is the safest approach to follow if a visitor refuses to give or withdraws cookie consent.