Consent management

Documentation Index

Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt

Use this file to discover all available pages before exploring further.

Refer to the User Guide for instructions on setting up the consent management policy when using Kameleoon on your web app.

​

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: With this policy, consent is not explicitly required for this website and module. Kameleoon assumes it is granted automatically and starts immediately in full-featured mode.
• Consent required: With this policy, 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 the SDKs if you run feature flags. For more information on this topic, refer to the user guide.

​

Reading the current consent state for a visitor​

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.

​

Modes of operation for Kameleoon Web Experimentation engine​

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. The following section describes all possible modes for the 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.experimentLegalConsent or Kameleoon.API.Visitor.personalizationLegalConsent is null, and you selected the option “Completely block Kameleoon” when consent is unknown.
• Kameleoon.API.Visitor.experimentLegalConsent or Kameleoon.API.Visitor.personalizationLegalConsent is 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.experimentLegalConsent or Kameleoon.API.Visitor.personalizationLegalConsent is null, and you selected the option “Partially block Kameleoon” when consent is unknown.
• Kameleoon.API.Visitor.experimentLegalConsent or Kameleoon.API.Visitor.personalizationLegalConsent is false, you selected the option “Partially block Kameleoon” for the opt-out behavior.

​

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. The two main problems are described here. 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. The delayed mode can mitigate this problem, 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.