/
Data Privacy Guidelines for Tracking

Data Privacy Guidelines for Tracking

Owned by Sylvain Paillard
Last updated: Mar 15, 2022
6 min read

This article describes the key aspects of tracking with the Winning Interactions platform and what is important to consider in your environment in terms of Data Protection Regulations like GDPR.

This article doesn’t address the data exported from your databases to the Boxalino Winning Interactions platform. You can find our guidelines for them here: Data Privacy Guidelines for Data Integration

What data do you track with our platform?

In a typical integration, your e-shop sends data to our platform in 3 different ways:

  1. Data Exports (not addressed here, see Data Privacy Guidelines for Data Integration )

  2. API Requests from your servers (and sometimes directly from your clients' browser or app)

  3. JavaScript tracking requests from your clients' browser or app (or directly from your servers)

We advise to consider the API requests to our servers as technically required for the functioning of your web-site. Indeed, without them, key functionalities like the search, product listing pages and product sliders would not appear to the clients anymore, making your e-shop partially (and sometimes fully) unusable.

The JavaScript tracking requests can be considered in a similar way as the Google Analytics tracking, with the difference that this tracking can enable some key functions of the e-shop (like the personalization of recommendations as well as other account management functionalities in case you use Boxalino Real-Time profiling for them).

What is important to consider?

There are two aspects which are most important to review and assess in your environment:

  1. Session identifier and Visitor identifier provided in the API requests and in the JavaScript Tracking requests and how they are stored (e.g.: cookies)

  2. Activation of the JavaScript Tracking requests (e.g.: after an opt-in validation by the visitor)

The Session and Visitor identifiers must be unique identifiers and must have the same values in both the API requests and the JavaScript Tracking requests

The Session and Visitor identifiers are called sessionId and profileId in the API requests as documented here: Narrative API - Technical Reference | Base parameters

The Session and Visitor identifiers are based on the sessionCookie and the profileCookie (by default ‘cems’ and ‘cemv’ cookies)

Managing Session & Visitor cookies

By default, the Boxalino JS Tracker will generate a session cookie (named by default ‘cems’ expiring with the session) and a visitor cookie (named by default ‘cemv’ which is a persistent cookie with a default duration of 12 months) with unique values in case they do not already exist.

The value of the identifiers of both session and visitor cookies doesn’t matter but must be unique and must be the same in both the API and Tracking requests of the visitor. Generating a UUID is a good practice to avoid collisions.

Make sure to set your session and visitor cookie before making any request to the Boxalino API (or at least make sure the values you have sent as sessionId and profileId to the Boxalino API are the same values which are then set in your session and visitor cookies as will be accessed by the Boxalino JavaScript tracker)

What cookies should be used?

If possible, we recommend to switch to other cookies which you anyway need for the functioning of your e-shop and which have the same characteristics (one session cookie and one persistent cookie).

In order to use your own cookies instead of the default ‘cems’ and ‘cemv’ cookies, use of the tracker’s options.

Make sure that you also use the values from the same cookies in your server (and in your client API calls) in the base parameters sessionId and profileId documented here Narrative API - Technical Reference | Base parameters

How and when should the cookies be set?

If your e-shop needs a session and a persistent cookie with a unique value to function, then we recommend to use them in your API requests and your Tracking requests.

In such case, you can set the profileCookie and sessionCookie options in the Tracking Options and use the same ones in your API integrations.

If no other cookies for one or both of these cases can be used, then you can either consider using the default ‘cems’ and ‘cemv’ cookies with the default parameters, but this implies that you have defined the cems and the cemv cookie to be essential for the functioning of your web-site.

You can also consider using the Tracker option writeCookies and setting it to false in case you do not want our tracker to create the cookies if they do not have a pre-existing value (either with the default names or with the name provided in the profileCookie and sessionCookie parameters)

If you do not set the option writeCookies or set it to true, then you can also set another value for maxage in case you do not want to keep the default milliseconds value of 31536000000 which represents the number of milli-seconds in a year with 365 days.

If you do not set the option writeCookies or set it to true, then even if you use your own persistent cookie (and not the default ‘cemv’ cookie) the cookie will be reset to match the default (or defined) ‘maxage’.

What to do if you do not have either (or both) a session and persistent cookie to be used instead of the default ‘cems’ and ‘cemv’ cookie but you do not want to define the ‘cems’ and ‘cemv’ cookie as essential for the functioning of your web-site?

In this case, you must set the option writeCookies to false and manage the setting of the session and profile cookies on your side (possibly set them only after a validation from the user has been provided).

In such a case, you should provide a session unique identifying string in both the sessionId and the profileId of the API request until the consent of the user has ben provided, after which you can set another value for the subsequent API requests as profileId (the session identifier should stay the same though).

Activation of the JavaScript Tracking requests

How to control the start of the JavaScript tracking?

You can implement the Strict integration to control when the events are sent (while still collecting them, but not persisting them until the user opts in; collected events are discarded once the user navigates to another page without opting in). Note that simply setting requireOptIn to true (and then setting optIn to true once the user opts in) is sufficient the prevent the tracker from sending events immediately.

The tracker does not persist its own optIn state. When using the option requireOptIn, you will have to store the tracker’s optIn state yourself (typically via a cookie) and set it every time you embed the tracker.


If you implement the Boxalino JavaScript tracker using the Simple integration and do not control when you are starting to send events to the tracker, they will be sent right away.

Additional possibilities

In addition to the base guideline documented here, several other possibilities / aspects can be considered, such as:

Domain / Sub-Domain of Cookies

Depending on your set-up it might be advisable to set the cookies on the general domain (.your-web-site.com) or on a specific sub-domain (something.your-web-site.com). By default, the cookie will be set on the general domain.

Proxy API / Tracking URL

It is also possible for you to proxy either (or both) the Boxalino API and the Boxalino Tracking URL in order to avoid any direct call from your client’s browser / app to the Boxalino (typically .bx-cloud.com) URL.

Annex #1: Shopware 6

If you have implemented Boxalino with a Shopware 6 environment, please consider the following key aspects:

 

  • Make sure to use the rtux-shopware plugin version 3.5.0 or later (GitHub - boxalino/rtux-shopware: Boxalino Real Time User Experience (RTUX) Framework for Shopware6 systems )

  • By default, the standard Shopware 6 session cookie ‘session-’ is used as a replacement of the ‘cems’ cookie. If you do not want to use it, you need to make a change in your integration.

  • By default, the persistent cookie ‘cemv’ is used, which implies that you define the cemv cookie to be essential for the functioning of your web-site. In case you do not want it to be considered as such, you need to change it in your integration.

  • By default the requireOptIn is set to true and the optIn option is set with the Komfortfunctionen under “Für Sie ausgewählte Rabatte, Angebote, Informationen, Gutscheine etc.”. In case you do not want it to be considered as such, you need to change it in your integration.

 

Related content