Consent management
Depending on the country where you operate your website, you may need to obtain visitor consent before collecting any data. This article describes how Kameleoon manages consent and outlines the available options on the Kameleoon platform.
You can refer to our user guide for instructions on how to implement a consent management policy using Kameleoon.
Kameleoon provides native built-in integrations with Consent management platforms.
Consent policies
For a given visitor, legal consent to use Kameleoon is considered either granted, denied or unknown (a special state used when consent is not defined, as the visitor has not granted nor denied it yet). To begin, you should choose how Kameleoon treats legal consent:
- Consent not required: This policy means that consent is not explicitly required for this website and module. It is assumed to be granted automatically, so Kameleoon starts immediately in full-featured mode.
- Consent required: This policy means that consent must be explicitly obtained from the visitor. Until it is given, the legal consent will be considered to be "unknown" and Kameleoon will not operate normally.
To inform Kameleoon when legal consent has been obtained, you must either use the Kameleoon Activation API method, which requires custom JS code to be implemented or one of our SDKs if you run feature flags. For more information on this topic, please refer to our user guide.
To cover all possible use cases, Kameleoon's Web Experimentation behavior can be further customized in the case when consent is considered unknown, or in the case when consent is denied. To know more about the options we provide, please read our article on behavior when consent is unknown.
Reading the current consent state for a visitor
This section only applies for web experiments and personalizations.
To obtain (read) the current legal consent state for a visitor, use the Kameleoon.API.Visitor object:
Kameleoon.API.Visitor.experimentLegalConsent: returns true, false, or null if the state is unknown (consent is required but has not yet been granted nor denied).Kameleoon.API.Visitor.personalizationLegalConsent: returns true, false, or null if the state is unknown (consent is required but has not yet been granted nor denied).
While the Kameleoon.API.Core.enableLegalConsent() and Kameleoon.API.Core.disableLegalConsent() methods allow you to change (write) the legal consent status for this visitor, obtaining (reading) the current state is done via Kameleoon.API.Visitor.
If you have chosen a Consent not required policy, the legal consent can never be in an unknown state. The Kameleoon.API.Visitor.experimentLegalConsent or Kameleoon.API.Visitor.personalizationLegalConsent will always return true by default and will be set to false only if the Kameleoon.API.Core.disableLegalConsent() method is called.
Modes of operation for Kameleoon Web Experimentation engine
This section only applies for web experiments and personalizations.
Kameleoon's engine works differently depending on its mode of operation. To determine the operational mode, Kameleoon considers the current value of the consent in Kameleoon.API.Visitor.experimentLegalConsent and Kameleoon.API.Visitor.personalizationLegalConsent. If the value is is null (unknown state) or false, Kameleoon takes into account the corresponding configuration value in the project settings for the Behavior when consent is unknown or Behavior in case of opt-out.
Below is a description of all modes possible for our engine:
Active mode
This is the normal mode of operation. Kameleoon sends data to tracking servers and writes data to the device as needed. The visitor is supposed to have granted consent to the use of Kameleoon.
This mode is operational when Kameleoon.API.Visitor.experimentLegalConsent or Kameleoon.API.Visitor.personalizationLegalConsent is true
Disabled mode
In this mode, Kameleoon does nothing at all - data is neither sent out to remote servers nor written to the local device. Experiments and personalizations are never displayed. For all purposes, it's as if Kameleoon did not exist for this particular visitor.
This mode is operational when:
Kameleoon.API.Visitor.experimentLegalConsentorKameleoon.API.Visitor.personalizationLegalConsentis null, and you selected the option "Completely block Kameleoon" when consent is unknown.Kameleoon.API.Visitor.experimentLegalConsentorKameleoon.API.Visitor.personalizationLegalConsentis false, and the customer selected "Completely block Kameleoon" for the opt-out behavior.
Delayed mode
In this mode, Kameleoon does not send any data to tracking servers nor write any data to the device. However, it will still display experiments (or personalizations) normally, if the visitor triggers the associated segment.
In addition, every data that should be written or sent to a remote server is kept in memory. If later Kameleoon switches to the active mode (usually because the consent is granted at some point), all the data gathered so far (in the context of this page) is written and sent at once. Thus the "delayed" name: if the full consent is obtained at some point, the end result will be that Kameleoon behaved almost like in active mode.
This mode is operational when Kameleoon.API.Visitor.experimentLegalConsent / Kameleoon.API.Visitor.personalizationLegalConsent is null, and you selected the option "Do not block Kameleoon" when consent is unknown.
Restricted mode
In this mode, Kameleoon does not send any data to tracking servers nor write any data to the device. However, it will still display experiments (or personalizations) that have been flagged with the "Technical" tag in Kameleoon. All other experiments / personalizations are not displayed.
This is a very useful mode that allows most Kameleoon operations to be disabled if a visitor does not want to grant consent, but that still permits critical experiments and personalizations to run for this visitor. Very often, Kameleoon is used as a quick workaround for deploying bugfixes and small improvements to production. In this particular context, data privacy regulations such as GDPR explicitely do not apply, and Kameleoon can be used without consent for such use cases.
The restricted mode is equivalent to the delayed mode, but more restrictive. Since it can be chosen as a result of a final legal consent choice (a denial), it is expected that data will probably never be written nor sent in this case (whereas the delayed mode is normally only a "transitional" mode).
This mode is operational when:
Kameleoon.API.Visitor.experimentLegalConsentorKameleoon.API.Visitor.personalizationLegalConsentis null, and you selected the option "Partially block Kameleoon" when consent is unknown.Kameleoon.API.Visitor.experimentLegalConsentorKameleoon.API.Visitor.personalizationLegalConsentis false, you selected the option "Partially block Kameleoon" for the opt-out behavior.
It is very possible that Kameleoon will have different operational modes for AB experiments and personalizations. In that case, everything works as expected. For instance, experiments are displayed and tracking data, but nothing happens for personalizations.
Advanced considerations
Choosing to implement an explicit consent policy in the context of AB testing usually leads to complex issues, and there is no ideal solution. We describe here the two main problems.
The first thing to take into account is that if you choose a strict behavior (disabled mode) while consent is unknown, experiments / personalizations will be triggered "late" in the context of the first page view of a totally new visitor. With this setup, they can indeed be displayed only after the legal consent has been obtained, which is typically after a few seconds. This can unfortunately lead to some serious UX issues, depending on the underlying experiments and personalizations, and should be taken into account.
This problem can be mitigated with the delayed mode, as display is immediate and only writing is delayed. However, there is a second issue arising when a visitor "stays" with an unknown legal consent status over several pages. Since Kameleoon does not write any data to the device, not even the Kameleoon visitorCode identifier, it keeps being randomly (re)generated on each page while final consent is not determined. This implies that for experiments, variation allocation will happen at each new page view, and no consistency is guaranteed in those allocations. It is thus important to take steps to prevent this situation from happening. Several options are possible (blocking consent banner, denying consent automatically after X seconds...), but a visitor should never stay in the unknown legal consent status forever. Either consent is granted, or it is denied.
For the same technical reason (permanent variation reallocation), if the restricted mode is chosen for opt-out behavior, it is expected than only personalizations or experiments with a 100% traffic deviation to a variation will be flagged with the "Technical" tag. Doing otherwise can seriously deteriorate the navigational experience of users that refused, as they could be subject to several different variations in the same session.