Skip to main content

Data collection (client-side)

This article serves as a reference guide for listing all data collected on the client side (in the user's browser) by the Kameleoon Application File (kameleoon.js) for Web Experimentation, where data is used for activation (e.g., audience targeting).

If you are interested in learning which data is stored on our backend servers—mainly for analytics and reporting—you can read this article.

note

This article applies only to Kameleoon Web Experimentation.
For Feature Experimentation, please refer to:

Introduction

Like any web analytics solution, Kameleoon collects a range of data, such as URLs visited, browser version, and time spent on your website. However, as an Experimentation and Personalization platform, Kameleoon also requires real-time, permanent access to this data to trigger experiments and personalization campaigns with minimal latency and no impact on user experience.

Since the JavaScript runtime environment is reset on each page change, it is impossible to store this data in memory alone. Instead, Kameleoon writes and reads large amounts of data across different web pages (URLs).

One solution would be to fetch data from a backend server at the beginning of each page load. However, this approach is:

  • Performance-intensive: Each page load would be delayed due to the extra server call.
  • Scalability-limited: Frequent server requests would degrade performance.

A more efficient approach is local storage, which allows Kameleoon to store data directly in the browser.

Local Storage as a data storage mechanism

Kameleoon does not use cookies to store data because:

  • Cookies are not designed for storing large amounts of data.
  • They are sent with every HTTP request (including static resources such as images), negatively impacting performance and bandwidth.

Instead, Kameleoon uses Local Storage, a standard web technology supported by most browsers. It functions similarly to cookies but allows much larger storage capacity (typically a few MBs, depending on the browser).

Unlike cookies:

  • Local Storage can only be written via JavaScript—servers cannot store anything in this space.
  • Data in Local Storage can only be accessed via JavaScript.
  • Local Storage data is never sent to remote HTTP servers, making it inherently more secure.

However, Local Storage has a key limitation: it is restricted to a single exact subdomain.

Local Storage limitations for unified session data

Unlike cookies—where a script on http://www.example.com can create a cookie accessible from buy.example.com—Local Storage is partitioned by subdomain and protocol.

For example, if most of your e-commerce website is hosted on https://www.randomshop.com, but your conversion funnel is on https://transaction.randomshop.com, Local Storage cannot share data between these two domains. This could lead to inconsistent experiment variations across the customer journey, impacting both the user experience and experiment validity.

To solve this, Kameleoon provides a mechanism to unify session data across subdomains. Learn more in our Unify Session Data Across Subdomains article.

List of collected data

This section is divided into two parts:

  1. Data collected and stored for all visitors (excluding those who opted out).
  2. Data collected for internal use when Kameleoon users operate the platform to build experiments.

For data privacy concerns, you only need to consider the first list, as the second applies only to a few internal employees.

note

Unlike cookies, Local Storage does not have a built-in expiration mechanism.
To address this, Kameleoon’s JavaScript engine emulates lifespan expiration by storing data with two keys:

  • "value": The actual information stored.
  • "expirationDate": A timestamp defining when the data should no longer be used.

Example:

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

Data stored for all visitors

note

All data is always stored in a first-party way (i.e., associated with your domain).
Kameleoon never stores third-party data on Kameleoon-owned domains.

Data stored in the Local Storage

KeyDescriptionLifespan
kameleoonVisitorCodeUnique Kameleoon visitorCode identifier.365 days
kameleoonDataVisitor and session data (e.g., browsing history, session info). This data is stored in Local Storage using a simple encoding scheme. The full list of data contained in this key is provided below.365 days
kameleoonExperiment-${experimentId}Experiment variation allocation and assigned variation ID (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 (renews on revisit)
kameleoonPersonalization-${personalizationId}Contains the personalization variation allocation.30 days (renews on revisit)
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", they will be if they trigger 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
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
kameleoonRequestEventsSaves failed requests that cannot be sent when the page is immediately reloaded (this behavior 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 (if a weather targeting condition is 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 is 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 the Product Targeting add-on is enabled).

Data stored in the Session Storage

KeyDescriptionLifespan
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 third-party analytics tracking calls made by Kameleoon when using a web analytics integration.Session duration

Data stored in cookies

Kameleoon uses only one cookie to store a randomly generated visitor identifier. Additionally, the Kameleoon CDN may set an optional cookie when delivering the application file (if you don’t self-host).

KeyDescriptionLifespan
_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 identifier.365 days
kameleoonReferrerTemporary cookie 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.

KeyDescriptionLifespan
KameleoonProducts_session_codeContains a unique session identifier.Session duration
KameleoonProducts_session_last_actContains the last activity timestamp.1 hour

Temporary data stored only for Kameleoon internal use

Data stored in Cookies

KeyDescriptionLifespan
kameleoonSimulationParametersThis 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

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

Data stored in the Session Storage

KeyDescriptionLifespan
kameleoonFullApplicationCodeContains the entire Kameleoon 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
kameleoonRedirectionURLStores 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.