Consent management policy

Written by Julie Trenque

Updated on 03/01/2024

3 min


Was this content useful?

Processing personal data is generally prohibited, unless it is expressly allowed by law, or the data subject has consented to the processing: this is legal consent.

Kameleoon provides flexible options to define the level of consent management required by your website, in compliance with the latest privacy legislation updates (GDPR, CCPA).

How to choose your consent management policy

For web experiments / feature experiments / hybrid experiments

The level of consent required depends on the applicable legislation. You should have either the CONSENT NOT REQUIRED or CONSENT REQUIRED option enabled.

Note: Kameleoon complies with applicable regulations (as outlined in the GDPR guidelines available at Kameleoon’s use of cookies falls under the category of “Strictly Necessary Cookies” for feature flags associated with targeted or progressive delivery rules. This means that visitor consent is not required for these types of rules.

Targeted or progressive delivery rules primarily serve purposes related to release management and technical functionality. As a result, they are exempt from GDPR and similar privacy regulations. This exemption ensures that the data collected for these feature flags is limited to technical information, including exposure events such as rule and variation names and goal conversion events.

It’s important to note that when using Kameleoon SDKs, a first-party cookie is stored, which contains a randomly assigned ID. This ID is used to uniquely identify a visitor’s browser or device. Consent is not required for this cookie, as it is classified as an essential cookie. This essential cookie enables visitors to access website features that are hidden behind feature flags.

Additionally, it’s important to note that for feature experiments, Kameleoon will display a variation of an experiment, but no tracking of data will occur for these experiments until consent is given. This ensures complete privacy and non-intrusive user experiences.

For web personalizations

You should always enable the CONSENT REQUIRED option.

However, these choices depend on your use of Kameleoon. Your Customer Success Manager is there to help you choose the policy that best suits your website.

How to define your consent management policy

The consent management policy settings are accessible in the Admin > Projects menu of the Kameleoon App.

You can set up the fields relating to consent management in each of the two blocks (Experiment and Personalization). You can define the settings separately for each of the Experiment (web or feature experiments) and Personalization options.

Use the three dropdown options to define the following:

  • The consent management policy.
  • The behavior of Kameleoon when consent is unknown (only required for web experiments and personalizations).
  • The behavior of Kameleoon on opt-out (only required for web experiments and personalizations).

Consent policy

Whether consent is required or not

Consent not required

Select this option if you are not subject to the GDPR or similar privacy regulations. If you select this option, all experiments will be run and data will be collected without consent.

Consent required

Select this option if you are subject to GDPR or similar privacy regulations.

If you choose this option, it is mandatory to obtain visitor consent before initiating any data collection. Kameleoon provides JavaScript methods, namely ‘enableLegalConsent()‘ and ‘disableLegalConsent()‘, as well as the SDK ‘setLegalConsent()‘ method. These methods should be utilized after obtaining legal consent from the visitor to activate or deactivate Kameleoon on both the front-end and server-side.

Note: Kameleoon delays tracking requests for data associated with experiment rules until explicit consent is obtained from the visitor, provided that the consent is given during the current session. This approach ensures that no data tracking occurs for experiments until the visitor has given their consent. For feature flags, delayed data will be sent to Kameleoon with the next following request when calling one of these methods: ‘isFeatureFlagActive()’, ‘getFeatureVariationKey()’, ‘getFeatureVariable()’, or ‘trackConversion()’. You can also trigger immediate data transmission by calling the ‘flush()’ method.

The PHP SDK does not support delayed requests due to technical constraints: the PHP SDK does not persist between requests. Each request creates a new SDK instance that destroys itself as soon as it receives a response, preventing Kameleoon to keep in memory requests that have been stored before consent is provided.

Important technical considerations

  1. When using Kameleoon in Hybrid mode, ensure that both the JavaScript Activation API and SDK methods are called upon collecting consent to make sure Kameleoon can collect the user events that come from both Kameleoon Application File and the SDK.
  2. As Kameleoon is restricted from storing the visitorCode key in a cookie, it is crucial to ensure that the visitorCode key generated by the SDK for all first requests is shared with the Kameleoon engine running client-side. This is necessary to ensure proper tracking for new visitors for whom consent has not yet been obtained. We recommend incorporating the following code into the source code of the page when the user is bucketed with a variant of the experiment. This code snippet facilitates the passing of the visitorCode key to the Kameleoon engine, enabling accurate tracking for new visitors once consent is provided client-side. If this step is not implemented, the Kameleoon engine will generate a new visitorCode, potentially resulting in a new variant being provided upon the second page load.
    level: "IMMEDIATE",
    command: () => Kameleoon.API.Visitor.setVisitorCode("<USER_ID>") // Replace <USER_ID> with the visitorCode generated by the Kameleoon SDK.

Behavior when consent is unknown

This section only applies for web experiments and personalizations.

Kameleoon’s behavior when consent has not yet been granted

For web experiments and personalizations, you can choose between 3 options.

Completely block Kameleoon

Kameleoon will not run at all, and no data will be collected or sent to an analytics platform until consent has been given.

Partially block Kameleoon

Kameleoon will only trigger web experiments with a Technical tag, no data will be collected or sent to an analytics platform until consent has been given.

How to tag a campaign as Technical?

If the second option is selected, the Technical tag must be added to each web experiment you would like to run. There are several possibilities for this:

When creating an experiment or a personalization, associate the Technical tag with it.

In the case of an already created experiment, on the Experiments dashboard, on its line click on the three-point menu, then on Manage tags. In the field that opens on the right, enter “Technical”.

If you use the Graphic editor, click on the burger menu at the top left > Test currently being edited > Tags and descriptions. Enter “Technical”.

If you use the Code editor, go to the Experiment tab > Tags and descriptions. Enter “Technical”.

If the Personalization has already been created, go to its card in the Personalization  dashboard and click on the pencil icon to edit it. On the personalization configuration form, click on Create a tag and enter “Technical”.

Do not block Kameleoon (don’t write / send anything)

Experiments will be run but no data will be collected without consent.

Behavior on opt-out

This section only applies for web experiments and personalizations.

Kameleoon’s behavior when the visitor refuses consent

For web experiments and personalizations, you can choose between 2 options.

Partially block Kameleoon

The visitor sees only one variation of the campaigns tagged as Technical ; no data is collected.

Completely block Kameleoon

In this case, no campaign is run and no data is collected by Kameleoon.

  • In this article :