Skip to main content
Data protection law generally prohibits processing personal data unless the law expressly allows it or the data subject has given legal consent to the processing. Kameleoon provides flexible options to define the level of consent management required by your website, in compliance with current privacy legislation (GDPR, CCPA).

​
For A/B tests and feature experiments

These settings are in the For A/B tests and feature experiments section of the Consent tab. The level of consent required depends on the applicable legislation. Select either Consent not required or Consent required in Consent policy.
Kameleoon complies with applicable regulations, as outlined in the GDPR guidelines available at https://gdpr.eu/cookies, and recommends the following approach:
  • Targeted and progressive delivery rules primarily serve release-management and technical purposes. Kameleoon recommends exempting these rules from consent management and classifying Kameleoon as a “Strictly necessary cookie,” so Kameleoon triggers these types of rules even when the visitor hasn’t given consent. Kameleoon limits the data collected for these feature flags to technical information, including exposure events such as rule and variation names and goal conversion events. When you use Kameleoon SDKs, the SDK may store a first-party cookie containing a randomly assigned ID. This ID uniquely identifies a visitor’s browser or device. If you prefer not to use this ID, the SDK lets you set your own ID instead. However, you are responsible for keeping this ID consistent, because Kameleoon uses it to display the same variation of a feature flag throughout the visitor’s session on your web app.
  • For feature experiments, Kameleoon displays a variation of an experiment, but doesn’t track data until the visitor gives consent, which ensures complete privacy and a non-intrusive user experience. However, if the visitor hasn’t given consent, the visitor may see different variations of a given feature flag across multiple pages.
These guidelines serve as recommendations, but consult your Data Protection Officer (DPO) for the final decision regarding GDPR compliance, since your DPO is accountable for ensuring regulatory adherence.

​
For personalizations

These settings are in the For personalizations section of the Consent tab. Your choice depends on your use of Kameleoon. Your Customer Success Manager can help you choose the policy that suits your website.

​
For product recommendation

The For product recommendation section of the Consent tab has its own Consent policy field. Select either Consent required or Consent not required. You can change it without contacting Kameleoon. For more information, see Consent management in the product recommendations documentation. The consent management policy settings are on the Consent tab of each project. To open it, click Admin > Projects, click Edit on your project’s row, then click the Consent tab. The tab has three sections: For A/B tests and feature experiments, For personalizations, and For product recommendation. Click Edit to change the settings, and click Save changes when you finish. You can define the settings separately for each section.
The Consent tab with the three consent policy sections
Each section has a Consent policy dropdown, where you set whether you require visitor consent. When you select Consent required for For A/B tests and feature experiments or For personalizations, two more dropdowns appear:
  • Behavior when consent is unknown: What Kameleoon does before the visitor gives consent.
  • Behavior on opt-out: What Kameleoon does when the visitor refuses consent.
The For product recommendation section has only the Consent policy dropdown.
The For A/B tests and feature experiments section with Consent required selected, showing the Behavior when consent is unknown and Behavior on opt-out dropdowns
Whether you require consent
The Consent policy dropdown with the Consent required and Consent not required options
Select this option if you aren’t subject to the GDPR or similar privacy regulations. If you select this option, all experiments run and Kameleoon collects data without consent. Select this option if you are subject to GDPR or similar privacy regulations. If you choose this option, you must obtain visitor consent before Kameleoon collects any data. Kameleoon provides JavaScript methods, including enableLegalConsent() and disableLegalConsent(), as well as the setLegalConsent() method. Use these methods after the visitor gives legal consent, to activate or deactivate Kameleoon on both the frontend and the backend.
Kameleoon delays tracking requests for data associated with experiment rules until the visitor gives explicit consent, provided the visitor gives consent during the current session. This approach ensures that no data tracking occurs for experiments until the visitor gives consent. For feature flags, Kameleoon sends delayed data on the next request when you call one of these methods: isFeatureFlagActive(), getFeatureVariationKey(), getFeatureVariable(), or trackConversion(). You can also trigger immediate data transmission by calling the flush() method.The PHP SDK doesn’t support delayed requests due to technical constraints, because the PHP SDK doesn’t persist between requests. Each request creates a new SDK instance that destroys itself immediately after it receives a response, so the PHP SDK can’t keep in memory any requests stored before the visitor gives consent.

​
Important technical considerations

  • When using Kameleoon in Hybrid mode, call both the JavaScript Activation API and SDK methods after collecting consent, so Kameleoon collects user events from both the Kameleoon application file and the SDK.
  • Kameleoon can’t store the visitorCode key in a cookie, so you must share the visitorCode key the SDK generates for all first requests with the Kameleoon engine running client-side. Sharing this key with the client-side Kameleoon engine ensures proper tracking for new visitors who haven’t yet given consent. Incorporate the following code into the page’s source code when the experiment buckets the visitor into a variant. This code snippet passes the visitorCode key to the Kameleoon engine, enabling accurate tracking for new visitors once the visitor gives consent client-side. If you skip this step, the Kameleoon engine generates a new visitorCode, which may result in a different variant on the second page load.
Consent information stays in sync between the Kameleoon engine and the JS SDK. This synchronization means that once you set consent in either the engine or the SDK, Kameleoon automatically applies it to both. This feature eliminates the need for manual consent handling and ensures that SDKs operate in compliance with user preferences.

​
IAB TCF

The Consent policy dropdown in each section also lists IAB TCF 2.3 consent, but only after you enable the IAB TCF integration on the project. Select this option when your consent management platform follows the IAB Transparency and Consent Framework, so that Kameleoon reads the visitor’s consent from the framework. In For A/B tests and feature experiments and For personalizations, the Behavior when consent is unknown and Behavior on opt-out fields still apply. To enable the integration, see IAB Transparency and Consent Framework.
The For A/B tests and feature experiments section with IAB TCF 2.3 consent selected in Consent policy
This section applies to A/B tests, feature experiments, and personalizations. Kameleoon’s behavior before the visitor gives consent
The Behavior when consent is unknown dropdown with the Do not block Kameleoon, Completely block Kameleoon, and Partially block Kameleoon options
You can choose from three options.

​
Completely block Kameleoon

Kameleoon doesn’t run at all, and Kameleoon doesn’t collect or send any data to an analytics platform until the visitor gives consent.

​
Partially block Kameleoon

Kameleoon triggers only experiments with a Technical tag, and Kameleoon doesn’t collect or send any data to an analytics platform until the visitor gives consent. How to tag a campaign as Technical? If you select Partially block Kameleoon, you must add the Technical tag to each experiment you want to run. You can add the tag in either of the following ways:
  • To tag a new campaign, associate the Technical tag with the experiment or personalization when you create it.
Associate the Technical tag with an experiment or personalization
  • To tag an existing campaign, go to the Experiments dashboard, and click the three-dots menu on the campaign’s card > Manage tags. In the field that opens on the right, enter Technical.

​
Do not block Kameleoon

Experiments run, but Kameleoon doesn’t collect data without consent.

​
Behavior on opt-out

This section applies to A/B tests, feature experiments, and personalizations. Kameleoon’s behavior when the visitor refuses consent
The Behavior on opt-out dropdown with the Partially block Kameleoon and Completely block Kameleoon options
You can choose between two options.

​
Partially block Kameleoon

The visitor views only one variation of the campaigns tagged as Technical, and Kameleoon collects no data.

​
Completely block Kameleoon

Kameleoon runs no campaign and collects no data in this case.