Skip to main content

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.


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 can create a cookie associated with the domain * and access this cookie from, Local Storage is partitioned by exact subdomain and protocol. If you write data in local storage on the subdomain, you cannot access it later from a page at

As an example, let's imagine that most of your e-commerce website is hosted on, but the conversion funnel is on 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.


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.


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

Data stored for all visitors of your website


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

kameleoonVisitorCodeContains the unique Kameleoon visitorCode identifier365 days
kameleoonDataContains 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 allocation30 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.
kameleoonGlobalPersonalizationExpositionRepresents 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 settings365 days
kameleoonLegalConsentLegal consent obtained for the use of Kameleoon. The value can be for instance {"AB_TESTING": true, "PERSONALIZATION": false} or {"PERSONALIZATION": true}365 days
kameleoonOpenTabsContains ids of opened tabs on the same website.365 days
KameleoonProducts_device_idContains a unique device ID for the visitor (only if you have the Product Recommendation add-on)365 days

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

kameleoonDisabledForVisitDisables 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
kameleoonAnalyticsTrackingTimesUsed 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.

_detectRootDomainTemporary test cookie (value=testRootDomain) that Kameleoon uses to detect the main domain of the site.Deleted immediately after use.
kameleoonVisitorCodeContains the unique Kameleoon visitorCode identifier365 days

If you use the Kameleoon Product Recommendation add-on, three additional cookies will be stored.

KameleoonProducts_session_codeContains a unique sesssion identifier.Session duration
KameleoonProducts_session_last_actContains the last activity timestamp.1 hour
KameleoonProducts_device_idContains a unique device ID for the visitor. It is also replicated in Local Storage.365 days

Temporary data stored only for Kameleoon internal use

Data stored in the Local Storage

kameleoonSimulationData needed for simulation purposes.1 hour
kameleoonSimulationShortURLShort URL of the simulation.1 hour
kameleoonSimulationVisitorDataContains all the (virtual) data about the visitor and his visits for simulation.1 hour

Data stored in the Session Storage

kameleoonFullApplicationCodeContains 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