Data collection (client-side)

This article serves as a reference guide for listing all collected data on the client side (in the browser of the user), where data are used for activation (targeting segments of audience, etc).

If you are interested in knowing which data is being stored to our backend servers, mostly for analytical and reporting purposes, you can read this article.

Introduction

Kameleoon collects a lot of data (URLs visited, version of the browser, time spent on your website..), as does any web analytics solution. The main difference is that as a an Experimentation and Personalization platform, we also need to have permanent, real-time access to those data, to trigger experiments and personalizations campaigns with no latency or without impacting the user experience.

So basically, we need to write and read large quantities of data on every different web page (URL). Since the JavaScript runtime environment is reset on each page change, it is impossible to just keep these data in memory.

Of course, one solution would be to always make a call at the beginning of each page load to a backend server to refetch those data. This is extremely costly in terms of performance: every page load would be delayed by this additional server call, and personalizations or experiments could only be triggered once the call is over. In addition, it scales very badly. So it is natural to try to write such data locally on the browser.

Local Storage as a data storage mechanism

Kameleoon does not use cookies to store data, as they are not designed to hold the large quantities of data Kameleoon needs. Also, they are sent to every server call made on their associated domain (including static resources such as images), so even a few KBs in a cookie is bad for performance and bandwidth.

Local Storage, a standard Web technology supported by virtually all browsers, has some common characteristics with cookies. It's basically a data store in the browser, so it can handle data in the same way that cookies do, but it can store much more data than cookies (the exact amount is browser dependent, but is usually around a few MBs).

Contrary to cookies:

• Local Storage content can be written only through JavaScript access, servers cannot store anything in this space
• Local Storage data can only be retrieved via JavaScript as well
• Local Storage content is never sent out to remote HTTP servers, which makes it inherently more secure / private.

However, there is one main drawback with Local Storage: it is limited to a single exact subdomain.

Local Storage limitations for unified session data

Unlike cookies, where a JavaScript code running on http://www.example.com can create a cookie associated with the domain *.example.com and access this cookie from buy.example.com, Local Storage is partitioned by exact subdomain and protocol. If you write data in local storage on the subdomain https://www.example.com, you cannot access it later from a page athttps://buy.example.com.

As an example, let's imagine that most of your e-commerce website is hosted on https://www.randomshop.com, but the conversion funnel is on https://transaction.randomshop.com. If you run an experiment modifying the navigation menu, with two variations, one user could very well be exposed to the first variation on the main site, but to the second one on the funnel. This is of course impacts the whole user experience, while also voiding the results of the experiment.

To address this, Kameleoon allows you to unify session data across subdomains for customers running their websites on multiple domains. You can read more about it in the Unify session data across subdomains article.

List of collected data

We break this section in two subsections:

1. the first one lists the data collected and stored by Kameleoon on all your visitors (except those that opted out of Kameleoon).
2. the second lists all the data collected and used only for internal use by Kameleoon, when your team operates the Kameleoon platform to build experiments.

For data privacy issues, you can take into consideration only the first list, as the second one concerns a few employees only.

note

It's worth noting that unlike cookies, LocalStorage does not have a built-in expiration mechanism. Thus our JavaScript engine implements an "emulation" of lifespan for local storage keys. Every key stored by Kameleoon in the Local Storage has a JSON content with two keys, "value" and "expirationDate". "value" contains the actual information to be persisted, while "expirationDate" corresponds to a (virtual) expiration date when this Local Storage key would not been read at all.

Example:

kameleoonLegalConsent: \{"value": \{"AB_TESTING": true, "PERSONALIZATION": true},"expirationDate":1545297630228}

Data stored for all visitors of your website

note

All data is always saved in a first-party way (ie, the data is associated with your own domain). Kameleoon never stores third-party data (associated with Kameleoon's domains) for your visitors.

Data stored in the Local Storage

Key	Description	Lifespan
kameleoonVisitorCode	Contains the unique Kameleoon visitorCode identifier	365 days
kameleoonData	Contains data about the visitor and his visits (mostly browsing related data). This data is encoded on the LS via a simple encoding scheme. You can see the full list of data present on this key below.	365 days
kameleoonExperiment-${experimentId}	Contains the experiment variation allocation, the ID of the variation (either “Reference” or the variation ID or “none” if a traffic exclusion has been configured) and the date on which the variation was assigned.	30 days. But if the visitor comes back after 30 days, the exact same information will be saved again (as the variation allocation mechanism is based on the visitorCode identifier.
kameleoonPersonalization-${personalizationId}	Contains the personalization variation allocation	30 days. But if the visitor comes back after 30 days, the exact same information will be saved again (as the variation allocation mechanism is based on the visitorCode identifier.
kameleoonGlobalPersonalizationExposition	Represents the visitor's global exposition status for all personalizations. If the value is "false", this visitor won't be exposed to any personalization (and if it is set to "true", he will be if he triggers the required targeting conditions). By default, no global traffic is excluded from any personalization. This value is configurable in the project configuration settings	365 days
kameleoonLegalConsent	Legal consent obtained for the use of Kameleoon. The value can be for instance {"AB_TESTING": true, "PERSONALIZATION": false} or {"PERSONALIZATION": true}	365 days
kameleoonOpenTabs	Contains ids of opened tabs on the same website.	365 days
KameleoonProducts_device_id	Contains a unique device ID for the visitor (only if you have the Product Recommendation add-on)	365 days
kameleoonRequestEvents	Saves failed requests that cannot be sent when the page is immediately reloaded (this behaviour is specific to Safari)	deleted once the page reloads

The kameleoonData key contains (in encoded form) the following data for each visit made by a visitor (on this device only, or ALL visits if you use cross-device history reconciliation).

• custom data;
• device type (mobile, tablet or desktop);
• operating system;
• name and version of the browser;
• screen size;
• window size;
• time zone of the browser;
• language of the browser;
• original referrer (acquisition channel);
• number of pages viewed;
• title and URL of pages visited;
• time spent on the website;
• time of the beginning and end of the visit;
• number of opened tabs;
• adblocker activated;
• list of conversions (clicks, transactions, etc);
• list of personalizations and A/B experiments seen by the visitor;
• current weather conditions (if the corresponding targeting condition is activated): temperature, wind, rain...;
• time of sunset (present if a weather targeting condition has been activated, as it is required for some weather targeting criteria);
• weather forecast (if the corresponding targeting condition is activated): temperature, wind, rain...;
• geolocation (if the corresponding targeting condition is activated or if a weather targeting condition has been activated, as it requires geolocation data);
• IP (if the corresponding targeting condition is activated);
• external segmentation data (obtained from a third party DMP or CRM);
• products seen (if this add-on is enabled).

Data stored in the Session Storage

Key	Description	Lifespan
kameleoonDisabledForVisit	Disables Kameleoon for the current visit. This is needed if you selected the Disable Kameleoon for the entire visit option in case of timeout.	Session duration
kameleoonAnalyticsTrackingTimes	Used to optimize (reduce) the number of 3rd party analytics tracking calls made by Kameleoon when using a web analytics integration.	Session duration

Data stored in cookies

Kameleoon only uses one cookie to store the unique identifier randomly generated for each visitor. The same identifier is also saved in the LocalStorage.

In addition, one additional cookie may be set by the default Kameleoon CDN (Content Delivery Network) when delivering the application file for Web Experimentation, if you don't self host this file. Note that Kameleoon does not use this cookie at all. Deleting it has no impact on Kameleoon operations.

Key	Description	Lifespan
_detectRootDomain	Temporary test cookie (value=testRootDomain) that Kameleoon uses to detect the main domain of the site.	Deleted immediately after use.
kameleoonVisitorCode	Contains the unique Kameleoon visitorCode identifier	365 days
kameleoonReferrer	Temporary cookie is used for redirect URL experiments. It stores the document.referrer value before the redirection occurs	Deleted immediately after use.

If you use the Kameleoon Product Recommendation add-on, two additional cookies will be stored. You can also request your Customer Success Manager to enable a cookieless option to store these data points in Local Storage.

Key	Description	Lifespan
KameleoonProducts_session_code	Contains a unique sesssion identifier.	Session duration
KameleoonProducts_session_last_act	Contains the last activity timestamp.	1 hour

Temporary data stored only for Kameleoon internal use

Data stored in Cookies

Key	Description	Lifespan
kameleoonSimulationParameters	This cookie is utilized by Kameleoon Simulation Mode to enable simulation across subdomains. Without it, if you have subdomains, the simulation will not function properly. Therefore, this cookie is essential in such cases. All simulation query parameters must be included like in URL as JSON.stringify for example, KEY - kameleoonSimulationParameters, VALUE - {"kameleoon-experiment-id":"266118","kameleoon-simulation":"true","kameleoon-language":"en"}	1 hour, but deleted immediately if the simulation is closed

Data stored in the Local Storage

Key	Description	Lifespan
kameleoonSimulation	Data needed for simulation purposes.	1 hour
kameleoonSimulationShortURL	Short URL of the simulation.	1 hour
kameleoonSimulationVisitorData	Contains all the (virtual) data about the visitor and his visits for simulation.	1 hour

Data stored in the Session Storage

Key	Description	Lifespan
kameleoonFullApplicationCode	Contains Kameleoon entire codebase, which is needed for simulation purposes (as the production version of the application file is optimized for size and does not contain all the code).	1 hour
kameleoonVariation-${variationId}	Variation code and data for preview or simulation purposes.	1 hour
kameleoonRedirectionURL	Stores the absolute URL of the page when a redirect experiment is triggered. This helps prevent infinite redirection loops.	The data is removed when navigating to a different page