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.

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)

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.

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.

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.

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).

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.

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:

Open

• 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.