Kameleoon — User Manual | Questions Archive - Kameleoon — User Manual
Beginner Experiment ...
Personalization

In the back-office

On your Kameleoon back-office, in the left menu, click on “Installations” and then on “Sites”. You will find your site ID on your website card.

In the Chrome extension

You can also find your sitecode on the Dashboard of our Chrome extension.

A click on the + icon allows you to add inserts to customize your dashboard and thus access the information you are interested in at a glance. Add the “Sitecode” insert.

Beginner Experiment

You can edit anything on an online experiment. However, we do not recommend it!

Indeed, any change, from the variation edition to the trafic allocation or the segment targeted, will disrupt the interpretation of your results. In this case, your results might not be reliable.

If you want to edit an online experiment, here is how we recommend you to proceed:

  1. Stop the experiment (if you want to)
  2. Duplicate the experiment
  3. Edit it as you wish
  4. Launch this new experiment

The duration of an A/B experiment depends on the kind of experiment running and on the traffic.

Let’s imagine an experiment with such a positive modification that the first visitors of the variation make a conversion. You will see very quickly how efficient the experiment is. But this kind of result is very rare.

Most of the time, the conversion rate does not change a lot right after the launching, but if you keep your experiment running long enough, the variation will be seen by hundreds of thousands or even millions of visitors, and the results will be relevant. We recommend to use the z-score, a mathematical tool calculating the statistical significance of your result. As you use it, you will learn to detect how many chances a variation has to perform better than another.

Note: If you are using Google Analytics or Kameleoon internal reporting tool, Kameleoon will calculate automatically the significance of your experiment according to the goals you previously set up in your back-office. For further information, you can read our article about Statistical significance.

Estimate the duration of an A/B experiment with Kameleoon

You can estimate the duration of your A/B experiment from Kameleoon editor. To do this, click on the “Finalize” button, located on the top right of the Kameleoon editor.

Then, click on the clock icon to estimate the duration of the experiment.

To have an estimation of the duration, you need to fill in the following information:

  • Average number of daily visitors: traffic in number of daily visitors on the tested page(s).
  • Current conversion rate (Original): conversion rate measured on your website for the goal used as a reference.
  • Desired reliability: required confidence to consider the experiment as significant. For example, a significance level at 95% means your variation has 95% chances to beat the original.
  • Desired improvement rate: the improvement expected between the conversion rate of the reference page and the conversion rate of the variation.

The estimator automatically takes into account the traffic allocation and the number of variations.

Once you filled in these information, click on “Calculate” and the estimate duration of your A/B experiment will display. You can then close the pop-in to go back to the edition of your experiment.

The key factor for A/B testing is the amount of data available. In our case, it comes from the traffic on your website.
Therefore, keep these numbers in mind:

  • Below 10,000 monthly visitors, it is difficult to do A/B testing, apart from a few special cases
    (for instance on landing pages).
  • From 10,000 to 200,000 monthly visitors, A/B testing is possible, but experiments will often take time to give results.
  • From 200,000 to 1 million monthly visitors, your traffic is comfortable enough for A/B testing. You might still have some difficulties with some less frequented pages (at the end of the conversion funnel for instance).
  • Above 1 million monthly visitors, traffic is rarely an issue.

Beginner Experiment ...
Personalization

Kameleoon and its interface are available in English, French or German.

The language set up in your browser will be used by default in Kameleoon. If your browser language is not one of the three languages available, the editor will launch in English.

In the editor

To change the language, click on the burger menu on the top left of the screen > “General Setup” > “Language”.

Then select the language and confirm your choice.

In your personal space

To change the language in your personal space, click on your avatar on the top right of the header.

A drop-down menu opens: click on “Language” to open the pop-in.

Choose your language and confirm your choice.

Beginner Experiment ...
Personalization

Click on the parent selector icon, then use the drop-down list to select the element of your choice.

When you select an element, click on the <…> button on the left of the hierarchy panel. A list appears, it contains:

  • The selected element, highlighted in green;
  • The children elements, above the selected element on the list;
  • The parent elements, below the selected element on the list.

A/B experiment

An A/B experiment allows you to make variations of one or several pages.
For instance, an A/B experiment can measure the performance of a product page A versus a product page B.

The disadvantage of this kind of experiment is that you need to change only one element per page (for example, the title of the download button) to know if this modification has an impact on the conversion rate.

Please note that you can change a multitude of elements with an A/B experiment but it would be impossible to know the impact of these changes individually.

Multivariate test (MVT)

The MVT allows you to change several elements of a page in order to analyze which combination converts the most.

For instance, you want to try on one A/B experiment your original version + 2 versions of the color + 2 versions of your button title and analyze which of the title-color combination suits the most.

If you choose an MVT, you will have 2 x 3 = 6 variations (including the original one) tested. Here is the main interest of an A/B testing solution such as Kameleoon, able to handle an unlimited number of variations and to statistically calculate which version is the more efficient.

For example, a simple MVT allows you to test the performance of these 6 buttons by creating 2 sections in the Kameleoon editor (one to change the title and one to change the color):

Note : The number of versions of a same page can quickly become important in the case of an MVT. You need to make sure to have enough unique visitors for the result to be statistically significant. For further information, you can read our article about Statistical significance.

To create your first MVT with Kameleoon, please read our article Creating a Multivariate test (MVT).

If you do not want the editor to be accessed from your website with the shortcut Shift + F2, you can disable it from your personal space.

Disable the shortcut

To do so, log in to your personal space.

Then, click “Administrate” in the left menu, go to the “Sites” page.

Click on “Configuration” for the website of your choice.

In the “Experiment” tab, click on the switch to disable launching the editor via Shift + F2.

Then, click on the “Validate” button on the bottom of the page to save your changes.

Launch Kameleoon without the shortcut

Once you have disabled the shortcut, you will have to add the following code to your URL in order to launch Kameleoon editor:

#kameleoon=true

For example, your URL will become:

https://www.website.com/#kameleoon=true

Beginner Experiment ...
Personalization

Adblock can create problems in the Kameleoon graphic editor, which is why we recommend you to disable it before. To do so, just follow these simple steps!

Disable Adblock

Go to the site on which you would like to launch the experiment.

Click on the AdBlock icon. The icon is located in the upper-right corner of your browser, to the right of your address bar. Clicking on the icon opens the Adblock settings.

Warning: on Safari, the icon will appear on the left of your browser’s address bar.

Click “Don’t run on pages on this domain”.

Click “Exclude” on the window that appears.

Disable Adblock Plus

Go to the website on which you would like to launch the experiment.

Click on the AdBlock Plus icon. The icon is located in the upper-right corner of your browser, to the right of your address bar. Clicking on the icon opens the Adblock settings.

Warning: on Safari, the icon will appear on the left of your browser’s address bar.

Click on “Enabled on this site” to disable Adblock Plus on the website you are visiting. The button will change to “Disabled on this site”.

Beginner Experiment ...
Personalization

Web browsers supported by the script

Kameleoon script does not support some of the old browsers. If one of your visitors is using one of these browsers, your A/B experiment will not display and the visitor will see the original page. It will not have any impact on your user’s experience nor your A/B experiment.

Here are the browsers supported for Kameleoon script:

  • Chrome
  • Firefox
  • Microsoft Edge
  • Opera
  • Safari

We ensure compatibility with the last 3 versions of each browser.

Web browsers supported by the graphic editor

Here are the browsers supported for the edition and the creation of your A/B experiments:

  • Chrome
  • Firefox
  • Microsoft Edge
  • Opera
  • Safari

We ensure compatibility with the last 3 versions of each browser.

Compatibility with responsive design websites

You can create this kind of experiment with Kameleoon thanks to the advanced edition functionalities. For an A/B experiment on a website with a responsive design, the main obligations are mostly due to resizing and moving blocks.

Indeed, the pages displays according to the screen resolution or the device used, so you need to be very careful when you move elements for your experiments. Also, you cannot use heat maps, because there is no frame on the page.

To deal with this obstacles, Kameleoon offers some advanced functionalities to move elements.

Experiment Intermediate ...
Personalization Technical

When your webpage is loading, it can sometimes occur that the original page displays for a split second instead of the variation. This twinkling is called flicker effect or flickering.

Why this flickering?

This flickering happens because of the time needed for the JavaScript engine to process the page.

It is one of the very few disadvantages of having a 100% JavaScript engine on which are based A/B testing solutions. Indeed, the elements will be changed according to the order indicated in the JavaScript code created by the A/B testing tool.

Consequently, if Kameleoon script loads after the webpage, the variations will also load last, creating this flickering.

How to avoid it?

Kameleoon’s engine is maximized to limit the flicker effect. Therefore, you are unlikely to encounter this inconvenience during your A/B experiments.

Besides, we highly recommend to integrate Kameleoon JavaScript code as high as you can on the HTML page, ideally right after the <head> element to make sure Kameleoon loads first.

Experiment Intermediate ...
Personalization Technical

Kameleoon is a 100% JavaScript solution and does not use jQuery. There will not be any conflict if you are using jQuery on your website.

However, Kameleoon uses the Sizzle library which is the CSS selector engine of jQuery. You can use it when you create your experiments.

When you create your segment, if you need to use several conditions to define it, the connection between them can be “And” or “Or”.

Definitions

‘AND’ corresponds to a simple addition: condition A and condition B must be reached to activate the personalization.

‘OR’ means that only one of the conditions must be reached: condition A or condition B must be reached to activate the personalization.

The “Narrow this condition” option, corresponds to the mathematical parentheses.

The “Add new condition” option puts the new condition on the same level.

Colors

The colored lines on the right help you better understand the logical links between your different conditions. Several cases :

  • the segment contains two conditions A and B, linked by an “AND”: they share the same orange line ;

  • the segment contains two conditions A and B, linked by an “OR”: they are distinguished by two different lines (orange and pink);

  • the segment contains two conditions A and B linked by an “AND” + the condition B is narrowed by a condition C linked by an “AND”: they share the same orange line ;

  • the segment contains two conditions A and B linked by an “AND” + condition B is narrowed by a condition C linked by an “OR”: they share the same orange line.

The color of the lines therefore represents the set of conditions (A and B) and does not take into account the fact that some conditions may be narrowed (C).

Examples

Condition A and condition B = both conditions must be reached

Condition A and condition B and condition C = all three conditions must be reached

Condition A or condition B = at least one of the conditions must be reached

Condition A or condition B or condition C = at least one of the conditions must be reached

Condition A and condition B or condition C = Condition A and one of the two other conditions must be reached

(Condition A and condition B) or condition C = the two condition A and B or only the condition C must be reached.

Beginner Experiment ...
Personalization

When creating a segment, and if you have already selected one condition, you can either narrow this condition or add a new condition.

Definition

Add a new condition

« Drag and drop to add a new condition » allows you to add a condition independently of the first one: condition A and/or condition B. You can add as many condition as you want to: condition A and/or condition B and/or condition C etc. The order of the conditions does not matter.

Narrow this condition

« Drag and drop to narrow this condition » allows you to clarify an existing condition. It is similar to mathematical parenthesis: (condition A and/or condition B) and/or (condition C and/or condition D). Once again, you can add as many conditions as you want to.

Examples

Example 1

In this example, the visitors targeted are the one coming from a SEO and located in France or all visitors coming from an emailing. Here, the condition “IP geolocation” only applies to visitors coming from a SEO.

(condition A and condition B) or (condition C)

The colored lines on the right help you to better understand the logical links between your different conditions. In this case:

  • the first two conditions must be cumulated (AND): the same orange line links them together;
  • the third condition differs from the other two (OR): its line is pink.

Example 2

In this example, the visitors targeted are the new ones who have seen more than 2 pages or returning visitors who have seen more than 4 pages.

(condition A and condition B) OR (condition C and condition D)

The colored lines on the right help you to better understand the logical links between your different conditions. In this case, two blocks of conditions can be distinguished from each other (OR): the first is orange, the second is pink.

Example 3

In this example, the visitors targeted are the visitors on the page https://www.mozilla.org/fr/about who have seen more than 3 pages or browsing the website for more than 6 minutes.

Even if only one page is targeted, the conditions “Number of page views” and “Elapsed time” will take the whole website into account.

condition A and (condition B or condition C)

The colored line on the right helps you to better understand the logical links between your different conditions. In this case, all the conditions are part of the same set: the visitor is included in the segment from the moment he meets the first condition and at least one of the two following ones.

Example 4

In this example, the visitors targeted are either the visitors of a specific page who converted a goal or visitors with a certain number of tabs open or visitors whose last visit was less than 7 days ago or visitors on mobile.

((condition A and condition B) or condition C) or condition D or condition E

Example 5

In this example, the visitors targeted are either the visitors of a specific page, who also arrived either on page XX of the website or on page YY of the website, or visitors coming from a specific acquisition channel.

(condition A and (condition B or condition C)) or condition D

Example 6

In this example, the visitors targeted are the visitors of a specific page who also arrived either on page XX of the website or on page YY of the website, and who also come from a specific acquisition channel or are about to exit the website.

(condition A and (condition B or condition C) and (condition D or condition E))

Experiment Intermediate ...
Personalization Technical

Kameleoon offers visitor targeting according to geolocation data.

On average, the accuracy of this geolocation is as follows:
  • country, 99.8% accurate ;
  • region, 80% accurate;
  • town, 68% accurate within a 50 kilometer radius.
Please note that:
  • the accuracy will mainly vary depending on the country and the type of device used by visitors on your website;
  • IP geolocation will always be more accurate for broadband IP addresses than on cellular networks (mobile devices);
  • fewer countries are available for IPv6 IPs so the IP geolocation won’t provide accurate results when that’s the case.

Intermediate Personalization

You can activate a personalization if the sum of the weights of the targeting conditions exceeds a certain threshold. The personalization will only start if the main conditions, or most of the conditions are met.

First, you need to define the weight of your conditions when you create your segment. Then, you need to define the weight needed to activate the personalization.

Define the weight of your conditions

You can define the weight of your conditions when you create your segment. If you want to define the weight of an existing segment, you must edit it.

Defining a weight allows you to rank the conditions of your segment. If a condition is more important than another, its weight should be higher.

When you select a condition, the weight appears on the right of the block:

By default, the weight of each condition is 1 (the minimum weight). Click on it to edit this number.

Define the cumulative weight needed

When you create your personalization, go to the “Micro-targeting” in the “Display settings” part to define the cumulative weight of the targeting conditions. You can use this option even if  you have not set up the weight of your conditions: by default, the weight of all conditions is 1.

By default, the option checked is “All of your segment’s targeting conditions are met”.

To define a cumulative weight, click on “The cumulative weight of active targeting conditions reached a limit”.

A new field opens, allowing you to choose the minimum weight to reach.

Example

As an example, let’s take a segment set up with:

  • Condition 1 – weight 1
  • Condition B – weight 4
  • Condition C – weight 2
  • Condition D – weight 2

If you define ‘7’ as cumulative weight to reach, the sum of the weight of the conditions should be at least 7 for the visitor to display the personalization.

In our example, the conditions A+B+C (7), B+C+D (8) or A+B+D (7) would be enough to activate the personalization.

Advanced Experiment ...
Personalization Technical

Here is the list and description of the data collected by Kameleoon. These data differ according to the type of campaign and the configuration of your website.

Local storage

Kameleoon saves the collected data in the Local storage.

Visitor data is always encoded.

You can find the updated list of variables in our developer documentation

Common data (A/B + Personalization)

  • kameleoonData: Contains a lot of data about the visitor and his visits (mostly browsing related data). This data is encoded on the Local Storage via a simple encoding scheme. You can see the full list of data present on this key here. Lifespan of 380 days. Find out more about the collected data
  • kameleoonLegalConsent: Legal consent (usually RGPD or similar regulation) obtained for the use of Kameleoon. The value can be for instance {“AB_TESTING”: true, “PERSONALIZATION”: false} or {“PERSONALIZATION”: true}. Lifespan of 380 days.
  • kameleoonOpenTabs: Contains ids of opened tabs on the same website. Lifespan of 380 days.
  • kameleoonSimulation: Data needed for simulation purposes. Lifespan of 1 hour.
  • kameleoonSimulationShortURL: Short URL of the simulation. Lifespan of 1 hour.
  • kameleoonSimulationVisitorData: Contains all the (virtual) data about the visitor and his visits for simulation. Lifespan of 1 hour.

Experiments data

  • kameleoonVariation-${variationId}: Saves variation for preview or simulation. Stored for the duration of the session.
  • kameleoonExperiment-${experimentId}: Saves the experiment variation allocation, the ID of the variation (either “Reference” or the variation ID or “none” if a traffic exclusion has been configured) and the date on which the variation was assigned. Stored for 30 days.

Personalizations data

  • kameleoonPersonalization-${personalizationId}: Saves the personalization variation allocation. Lifespan of 30 days.
  • kameleoonGlobalPersonalizationExposition: Represents 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”, he will be if he triggers the required targeting conditions). By default, 10% of the global traffic is excluded from any personalization. This value is configurable on Kameleoon’s back-office. Lifespan of 380 days.

Session storage

All these data are kept only for the duration of the session.

Common data (A/B + Personalization)

  • kameleoonDisabledForVisit: Disables the loading of Kameleoon for the current visit. This depends on whether or not you have activated this option in your website settings in the Kameleoon back-office. By default it will never be used.
  • kameleoonAnalyticsTrackingTimes: Used to optimize (reduce) the number of 3rd party analytics tracking calls made by Kameleoon when using a web analytics integration.
  • kameleoonFullApplicationCode: Contains Kameleoon entire 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).

Cookie

  • kameleoonVisitorCode: Contains the visitor code (unique identifier randomly assigned to a visitor). This cookie is automatically replicated by Kameleoon in Local storage (inside the key kameleoonData), so if it is deleted Kameleoon will recreate it automatically from the data contained in kameleoonData. Stored during 380 days.
  • One additional cookie may be set by the default Kameleoon CDN (Content Delivery Network) when delivering the application file, if you don’t self host this file. Note that Kameleoon does not use this cookie at all. Deleting it has no impact on Kameleoon operations.
    __cfduid: This cookie is set by the default Kameleoon CDN. Stored during 30 days.

Encoded data

Visitor data is always encoded.

In the case of KameleoonData (contains all the data about the visitor and his visits; stored for 380 days), the following data is encoded:

  • 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 (present if a weather targeting condition has been 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 has been 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);
  • internal search history (if activated);
  • products seen (if activated).

Most of this data is also sent to our servers for reporting purposes (to filter / break down the data afterwards). However, for previous visits, only the number of the visit is sent to our servers.

How long does Kameleoon keep the data stored on its server?

The data stored on our servers is kept for 2 years.

How does Kameleoon handle visitor consent?

GDPR compliance

Kameleoon is GDPR compliant and has legal consent policies already in place. We do not stock any user data unless legal consent is obtained. Our solution does not use cookies, it works using local storage only after consent is obtained. The only data collected is anonymized browsing data which doesn’t allow a visitor to be identified.

However, you are able to inject existing personal data from your technology ecosystem (such as CRM or DMP solutions) into Kameleoon, to improve analysis and results. In this case, you have total control over the information you use and should only select authorized data. Kameleoon processes this personal data in a totally GDPR-compliant way and follows your written instructions and data processing procedures.

Opt-out management

With Kameleoon, you can set up an opt-out mechanism if you wish to do so. Find out more about Opt-out management

Apple ITP

Kameleoon automatically and transparently handles all Apple ITP versions. This means that ITP will not impact on the results of your campaigns. Find out more about how Kameleoon handles Apple ITP

Advanced Experiment ...
Personalization Technical

Kameleoon’s policy on cookie management has changed. All information can be found in this article.

Advanced Experiment ...
Personalization Technical

Kameleoon’s policy on cookie management has changed. All information can be found in this article

Advanced Experiment ...
Personalization Script Technical

When first landing on your website, a visitor’s browser needs to download the code that runs on your website, including the Kameleoon script. The page loading time is impacted by the length of this code, but also by the number of external resources to download (images, css, scripts…). Caching allows to reduce this loading time during the next visits: the code of the website and all static ressources are downloaded and put in the browser cache in order to improve performance.

Caching therefore has a very important advantage and improves the user experience. But there’s a downside: if Kameleoon’s script changes (for example, if you have launched a new experiment), old visitors who have already started their visit on your website (and already downloaded the previous version of our script) won’t see the new experiment yet.

To get around this problem, we added a flag in our script, Cache Expiration (TTL: Time-to-live), that asks a browser to take a new version of our script every 1,5 hour: our script embeds its own expiry date.

Note: Sometimes, even though we have a TTL in place, a browser can decide to not take into account that information (this is very often the case on mobile browsers as they want to optimise the performance). It depends on each browser policy.

Experiment Intermediate ...
Personalization Technical

If you are using Commanders Act Tag Management System, you can create custom data based on Commanders Act datalayer variables. Please read these guidelines.

If you are using Commanders Act Customer Data Platform, you can plug Kameleoon to it to use all your existing segments. Please follow this article to get started.

Experiment Intermediate ...
Personalization Script Technical

Installation of the extension

First, add the extension to Chrome. It can be downloaded here on the Chrome Web Store.

Open the web console (F12 on PC or command+option+I on Mac).

Click on the Kameleoon tab from the web console, then on the “Activate” button

Then let yourself be guided by the extension to activate it! Your login page to your Kameleoon back-office opens automatically. Enter your login details.

The “My websites” page opens.

That will activate the extension and give you the authorisations to use the extension on all websites configured in your Kameleoon account.

The first time you activate the extension, you will then be redirected to your website so that you can use the extension straight away.

Note: If you add a new website to your Kameleoon account, you will see the following message:

Simply click on the button to update your authorizations. A message will then confirm the update.

Note: If you add a new website to your Kameleoon account, you can also update your authorizations by clicking on the link “Update list of sitecodes” at the bottom of the extension dashboard.

Several tabs are available in the extension :

  • Campaigns
  • Assets
  • Dev tools
  • Options

You also get access to a dashboard page by clicking on the Kameleoon logo, from which you can add custom widgets.

Dashboard

The section that appears by default when the extension is opened is a dashboard.

With one click on the + icon you can build and customize this dashboard to have in front of you the information that is essential to you.

Each widget can be enlarged, reduced, closed…

You can increase the number of lines by clicking on the three-point menu at the top left.

The inserts at your disposal are as follows:

  • Consent: indicates whether consent has been given for Experiments/Personalisations (“true” may mean either that you have given your consent or that your consent is not required; “false” means either that you have refused your consent or that pending your consent the experiments have been blocked);
  • Custom data: lists the active custom data on the page, their ID and value;
  • Experiments: lists all experiments running on the page and indicates their ID, evaluates targeting (true/false), also indicates the ID of the registered variation and displayed variation;
  • Personalizations: same for all personalizations running on the page;
  • Site Code: you can find it at a glance!
  • Visitor Code: indicates the visitor code that has been assigned to you, which allows you to monitor (among other things) the accounting of visits.

You will find at the bottom of this dashboard a link to update the sitecodes when a new website is added to your Kameleoon account.

Campaigns

Experiments

You will find in this tab all your experiments running on the page.

You can add or remove columns by clicking on “Add columns” to customize the table.

  • Id: ID of the experiment. On click you can display the details.
  • Name: Name of the experiment.
  • Triggered: True if the experiment was triggered on the page, else false.
  • Triggered In Visit: True if the experiment was triggered in the current visit, else false. This means that your visit fulfilled the experiment’s segment conditions at some point.
  • Active: True if the experiment is currently active on the page, else false.
  • Activated In Visit: True if the experiment was activated in the current visit, else false. Note that a triggered experiment does not necessarily imply that the experiment was activated, since several additional factors can affect this activation (for instance, the visitor may be part of the traffic excluded from this experiment, or capping options may have been set).
  • Displayed Variation: ID of the variation displayed to you (“No variation” when not targeted; “0” when targeted but assigned to the reference).
  • Associated Variation: ID of the variation on which you have been assigned with the visitor code (“0” when not targeted). You can force a variation by selecting it in the dropdown. The eye icon on the right allows you to preview it.
  • Date Modified: Date of the last change made to the experiment.
  • Assignment Time: When you were assigned to the variation. If this is the original and you have not been targeted, the value is “Nos assigned yet”.
  • Online since: The date the experiment was put online.

Variations

When you click on the ID of an experiment, a menu opens. The first tab gathers all the variations of the experiment, indicating their name, ID and JS/CSS (if code has been injected on the variation).

Configuration

The entire configuration of the experiment is displayed in the extension.

You will then directly find the information that is normally in the console.

Targeting

In this section, the targeting conditions are shown in a much more intelligible way than in the console, with logical links between the conditions.

Some conditions give access to additional details when you click on them. For example, for a JS condition, the JS to be executed will be displayed.

Personalizations

You will find in this tab all your personalizations running on the page.

Add or remove columns by clicking on “Add columns” to customize the table.

  • Id: ID of the personalization. On click you can display the details.
  • Name: Name of the personalization.
  • Triggered: Whether or not you are targeted.
  • Triggered In Visit: True if the personalization was triggered in the current visit, else false. This means that your visit fulfilled the personalization’s segment conditions at some point.
  • Active: True if the personalization is currently active on the page, else false.
  • Associated Variation: ID of the variation on which you have been assigned with the visitor code (“0” when not targeted). You can force a variation by selecting it in the dropdown. The eye icon on the right allows you to preview it.
  • Activated In Visit: True if the personalization was activated in the current visit, else false. Note that a triggered personalization does not necessarily imply that the associated action was displayed, since several additional factors can affect the execution of the action. For instance, capping options may prevent the execution, or the visitor may be part of a control group for this personalization (in which case Kameleoon also does not display the personalization’s action).
  • Not Exposed Reason: If personalization was triggered but not displayed / activated, this field represents the reason for the non exposition. Possible values are:
    • GLOBAL_EXCLUSION (the visitor is part of the population globally excluded from all personalizations);
    • PERSONALIZATION_EXCLUSION (the visitor is part of the population excluded from the current personalization, ie he falls into the control group for this personalization);
    • PRIORITY (another personalization has higher priority);
    • SCHEDULE (personalization is currently off according to its schedule);
    • PERSONALIZATION_CAPPING (the personalization has reached its global capping in terms of visitors);
    • VISITOR_CAPPING (the visitor has reached a capping preventing the display of the personalization);
    • SCENARIO (the personalization won’t be displayed because some of the scenario conditions are not fulfilled);
    • SIMULATION (in the simulation mode, the non exposition was forced. This reason cannot happen in production). This property is available if the personalization was triggered on the current page and the active property is false, else it will be null.
  • Date Modified: Date of the last change made to the personalization.

Variations

When you click on the ID of a personalization, a menu opens. The first tab indicates the name and ID of the variation, and JS/CSS if code has been injected on the variation.

Configuration

The entire configuration of the personalization is displayed in the extension.

You will then directly find the information that is normally in the console.

Targeting

In this section, the targeting conditions are shown in a much more intelligible way than in the console, with logical links between the conditions.

Some conditions give access to additional details when you click on them. For example, for a JS condition, the JS to be executed will be displayed.

Assets

Segments

In this tab, you will find all the the active segments on the page, which makes it possible to check that you have set the correct parameters and that the targeting works properly.

The segment is “Triggered” if your visit fulfilled the conditions at some point.

If you click on the segment ID on the left, you can access the details of the conditions.

Custom Data

In this tab, you will find all the configuration parameters of a custom data, which makes it possible to check that you have set the correct parameters.

Add or remove columns by clicking on “Add columns” to customize the table.

  • Id: ID of the custom data.
  • Name: Name of the custom data. 
  • Value: If one or several value(s) have been associated to the custom data.
  • Format: String/Boolean/Number
  • Type: Unique/List
  • Scope: Page/Visitor/Visit
  • Local: Indicates if the custom data uses the local of the visitor’s browser.
  • Mapping Identifier: Indicates if the custom data uses an unique identifier on your side, such as an account id or email.
  • Learnable: Indicates if the “learnable” function has been activated or not on the custom data

Goals

In this tab, you will find the configuration of each goal associated with your running experiences so you can check that they are achieved when they need to.

Add or remove columns by clicking on “Add columns” to customize the table.

  • Id: The ID of the goal.
  • Name: The name of the goal.
  • Type:
    • Click
    • Scroll
    • URL
    • Engagement
    • Time spent
    • Page views
  • Converted: Whether the goal has been converted during the current visit or not.
  • Conversions: The total number of times you have converted this goal.
  • Revenue: The total revenue associated with this goal (if applicable).

Global custom script

You will find here the global script (equivalent to script tracking in the back office).

Dev tools

Performance analysis

This tab allows to analyze the composition of the script and to understand which parts of the script can possibly slow down the website.

  • Script size: Script size according to CDN.
  • Script size (uncompressed): Overall size.
  • Last updated: Date of the last update of the script.

The “Engine” part (in grey) must normally occupy more than 35% of the total weight. If it is not the case, the Performance score below will be POOR instead of OPTIMAL.

Some additional indicators are provided as guidelines you should follow:

  • Script size < 120 KB;
  • No experiments (experiments running for more than 3 months);
  • Less than 50 segments;
  • Less than 50 goals;
  • Global custom script < 30 KB.

Request analysis

With this tab, you can easily debug all requests.

Add or remove columns by clicking on “Add columns” to customize the table.

Visits analysis

With this tab, you can find information on all the visits you have made.

  • The number of visits;
  • The timestamp of the beginning of each visit;
  • The number of pages viewed during each visit;
  • The duration of each visit.

Add or remove columns by clicking on “Add columns” to customize the table.

Code synchronization

You can also synchronize Microsoft Visual Studio (VS Code) with the Chrome extension. It will allow you to automatically send any update to Chrome via a websocket between VS Code and our Chrome extension, to test your JS and CSS code. Chrome then injects the new code in the Kameleoon engine and reloads the page.

To use this feature you can follow this link: Documentation

Tag injection

Inject the Kameleoon tag on a website in no time!

Select your environment (development/ preview/test/production), select the tag and the site code to inject, click, it’s done! You can close the console afterwards, it will be as if it is natively on the page.

Options

Two additional options are available.

Block Kameleoon script

Useful for developers that need to work on their website without any Kameleoon experiment or personalization running on the page.

Block Kameleoon tracking request

Useful for not having an impact on the results with your own visits and conversions.

Troubleshooting: The extension does not load all data or is not working

In exceptional cases, our Chrome extension may need to be reinstalled. Please follow these steps:

  • Log out of Kameleoon (click on your name in the upper right corner and log out);
  • Close all windows and reopen Chrome;
  • Go here and remove the Kameleoon extension;
  • Download the extension again;
  • Click on “Install” then go to your site;
  • Open the Chrome console and go to the Kameleoon extension;
  • Click on “Activate” and you will be redirected to Kameleoon
  • Log in to Kameleoon and go to your “My Sites” page. The installation will be completed;
  • Close the tab of your site and access your site again.

The extension will load properly and you will see the information displayed.

Experiment Intermediate ...
Personalization Troubleshooting

You launched your experiment a few hours ago but still do not visualize any statistics on your reporting tool (Kameleoon, Universal Anaytics…)? You can follow this guide to make sure your experiment is set up properly.

Kameleoon

With Kameleoon reporting tool, results are sent in real time by default. However, Kameleoon will show you these results only if there is enough visits and conversions (above around 100 visits and 60 conversions).

Universal Analytics

Check your reporting tool configuration

Universal Analytics is the latest version of Google Analytics. However, both solutions are technically different and you must activate the right tool when you set up your reporting tool in Kameleoon.

To know if you are using Google Analytics or Universal Analytics, you can open a web console in your browser (with F12 on a PC or CMD+ALT+I on a Mac). Then, click on the “Network” tab and look for the “utm” information in the filter zone to know if Google Analytics is used or “collect” if it is Universal Analytics.

Then, check if the right reporting tool was chosen on your experiment.

Warning: For Universal Analytics, you must have previously declared a custom dimension, or there will be no Experiment data available. For further information, you can read our article Setting up Universal Analytics (ex Google Analytics).

Check if the “utm” call (Google Analytics) or “collect” call (Universal Analytics) contains the Experiment data

If Kameleoon loads before Google Analytics, the A/B experiment data are sent with the standard page view call. If Kameleoon loads after, the data are sent with a type “Event” call.

With Google Analytics, the information you must look for is “utm”. It contains the name of the experiment and the name of the variation displayed. In the example below, one experiment is running on this website: Modification Header Wording and the variation displayed is Variante 1.

With Universal Analytics, the Experiment data are in the custom dimension you chose when you launched your experiment. In the example below, the custom dimension is “CD21”, the name of the experiment is Test 1 : Bloquage prospect and the displayed variation is Blocage LP.

If you cannot find any data, your configuration might not be correct.

Check the name of Google Analytics tracker

Sometimes, the name of Google Analytics tracker might have been customized by your CIO. In this case, you must indicate to Kameleoon which name will be used to send the Experiment data. To do this, open a web console in your browser and type in: window._gat._getTrackers()[0]._getName(). In the example below, the name of Google Analytics tracker is secondTracker.

Note: Sometimes, several trackers are available on your website if several Google Analytics are active on your website. To know if it is the case, type in the command window._gat._getTrackers().length. If the command returns more than one result, it means that several Google Analytics are used. In this case, please contact your CIO or Kameleoon to help you with your configuration.

If the tracker code is not the one by default (usually, the command window._gat._getTrackers()[0]._getName() returns an empty chain of characters), you have to set up the right tracker name to send the Experiment data in Google Analytics. To do this, go to the reporting tools parameters in your Kameleoon account.

For Universal Analytics, it can be necessary to specify the ID of Universal Analytics view, if, for example, several Universal Analytics are used on the same website. You can find this ID on the “Admin” page.

AT Internet

AT Internet works similarly to Google Analytics. When Kameleoon loads before AT Internet, A/B experiment data are sent with the standard page view call. If Kameleoon loads after, the data are sent with an MVT call, using the function called xt_mvt. In most cases, this function must be located in the xtcore.js folder (AT Internet file). To know if this function is available on your website, open a web console in your browser and type in the command xt_mvt. If an error occur, this function is not available. Your AT Internet file has to be updated by your CIO as the function xt_mvt is automatically available with the xtcore.js file in the latest versions.

Adobe Analytics (Ex Omniture Site Catalyst)

Omniture works similarly to Google Analytics. When Kameleoon loads before Omniture, the A/B experiment data are sent with the standard page view call. If Kameleoon loads after, the data are sent with an “Event” type call. If you are using the plugin doPlugins on your website, please read this article from our developers documentation, which indicates the JavaScript code lines that you must add to the variable in order to push your experiment results in Adobe Analytics.

During the configuration of your split URL experiment you have distributed your traffic between your variations, but you notice significant data discrepancies between Kameleoon results and a third party analytics tracking solution, especially regarding the number of visits on variation B.

It can be explained by several reasons:

  • The Kameleoon tag is not installed on variation B of your experiment. This problem is common and the Kameleoon snippet has to be also installed on the new page (URL B) of your website so that Kameleoon can track your visits and conversions.

Note: In this case, you may notice some visits on variation B even though Kameleoon is not installed on page B. This is because Kameleoon will try to send the tracking call before doing the redirection to page B. So all visits counted on variant B are actually tracking calls from page A.

  • The bounce rate metric could also be one of the reason. Indeed, with a split experiment and when a visitor has been bucketed to variation B, Kameleoon will either send the tracking data from the original page before redirecting the visitor to page B, or do it only when the visitor has landed on page B. This depends on how quick the redirection is being done. So if your bounce rate is high, you could see significant discrepancies between Kameleoon and your third party analytics results. Kameleoon won’t be able to trigger the third-party analytics tracking (as usually the tag won’t have loaded yet on the page), whereas it won’t be the case for Kameleoon (as usually our script will load first on your website). This usually explains why you have more traffic on variation B in Kameleoon that in the third-party analytics tool.
  • If your consent policy is set to “Required”, you will need to follow these guidelines in order to have accurate metrics for your experiment.

One good test to identify if there is an issue or not is to compare the number of visits you have in your third party analytics tool for variation B with the number of visits you have for page URL B, independently of your experiment. You should get approximately the same numbers, assuming visitors cannot access page URL B without going through the experiment first (which is usually the case).

Advanced Experiment ...
Personalization Technical Troubleshooting

You may encounter this issue if you have installed our snippet with the option “Cross-Domain tracking” which needs the hosting of a static resource (an iFrame) on your main domain.

This iFrame will be loaded whenever, during the visitor’s journey, the page URL does not match the main domain of your website.

The iFrame HTML file is static and contains only immuable code used to save and restore visitor data in the Local Storage.

To know more you can read this documentation.

How to fix this issue?

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

For more details please follow Mozilla developers documentation.

To enable cross-domain tracking, the Kameleoon iFrame must load on all your domains, so you must not set an X-Frame-Options response header.

Please also note that you can secure the iFrame by providing a restricted list of domains (e.g., your own domains and subdomains) that are able to call the iFrame. This list must be provided inside the static iFrame file that will be hosted on your side.

It is possible to create an experiment where the implementation of variations is done in the back-end and targeting in the front-end. This allows the data to be collected via third-party analytics tools, such as Google Analytics for example.

To do this, you need to create a “Hybrid” type experiment. In the “Tracking and goals” step, you can select other tracking tools.

Learn more about Hybrid Testing in the User Manual

Learn more about how to link a server-side experiment with front-end targeting in our Developer Documentation

Advanced Experiment ...
Personalization Technical

Why activate cross-device history reconciliation?

The Kameleoon platform offers the ability to merge history and actions made from visits on different devices, if the user responsible for those visits is the same. Basically, what it means for a personalization platform is that a person visiting your website twice via a desktop computer at work, then a third time via his smartphone at home, will be correctly identified as a returning visitor. The platform will correctly report his number of visits on the smartphone as 3, not 1 as would be the case without history reconciliation. This is a very powerful feature that is extremely simple to implement on Kameleoon, as long as you have a way to identify users on your side (most of the time, this will be via a standard customer login).

Using cross device history reconciliation has three significant advantages:

  • the ability to have a coherent targeting system, taking into account all visits and all actions across all devices;
  • the ability to ensure that a single visitor always sees the same variation for a given A/B experiment, no matter his current device;
  • the ability to have a precise and exact reporting system, where unique visitors are correctly counted.

More about this feature

How to activate cross-device history reconciliation?

Prerequisites

To benefit from Kameleoon’s cross device history reconciliation, you need:

  • to have suscribed to the Personalization module;
  • to have this option activated in your account.

Create a new custom data

In your Kameleoon back office, go in the “Assets” menu in the sidebar, click on “Advanced tools”.

In the “Custom data” tab, click on “+ New”.

Follow the usual steps to create a new custom data. At the bottom of the pop-in, activate the tooltip “Use this custom data as a unique identifier for cross-device history reconciliation”.

This will allow Kameleoon to treat this custom data as a unique identifier on your side, which will be used to map several Kameleoon visits to a unique user.

Experiment Intermediate ...
Personalization Technical

You might wonder if Kameleoon will have an impact on your SEO. Actually, it depends on how you set up your experiment.

Even though it is not clearly stated, most of the bots will not see experiments running but some can (such as Google bots).
Why? Because more and more websites are now highly dynamic so they had to adapt in order to read single page app websites for instance. To be fully compliant with SEO, we recommend to follow these simple guidelines :
  • Having an equal percentage of traffic allocated to each variation. Bots will know that you are A/B testing and won’t impact your SEO. If you want to exclude traffic, it is best to use our dedicated feature for that rather than doing a 90/10 distribution for instance.
  • Do not run your experiment for too long (more than 2 months) as bots could considerer you show a different page to different audiences.
  • For split URLs A/B experiments, you have to use the canonical tag (for further information about this tag, please refer to Google support and the article on how to use canonical URLs). Never do a “no index” one as it will impact your SEO, as bots will also be redirected to variation B. By seeing a “no index” tag they will considerer you don’t want them to see this content.
In a nutshell, bots will always index the page they see most often, so as a rule of thumb split traffic equally.

Advanced Experiment ...
Personalization Technical

Kameleoon was conceived in order to support a ramp-up of A/B experiments on websites with millions of visits each month.

Files needed by Kameleoon to run (file kameleoon.js containing Kameleoon engine and data on A/B experiments created from the editor) are hosted on a CDN optimized to serve quickly static content.

Experiments data are given directly to outside systems (Google Analytics, KISSmetrics, AT Internet, etc.), without passing through your servers, allowing an efficiant ramp-up.

The request to our servers (CDN not included) happens only when the editor is used or if you want to use our reporting tool.

Once the A/B experiment is launched, Kameleoon generates the kameleoon.js script, specific to your website and containing Kameleoon engine and Experiments data. This script is hosted and cached in Kameleoon CDN.

Beginner Experiment ...
Personalization

Kameleoon is available in three languages: French, English and German. By default, the language will be defined according to your browser’s language, but of course you can change it at any time.

For further information about the procedure, you can read the article How to change the language?

You can run an A/B experiment on the mobile version of your website.

To do this, you can use a Chrome extension (like this one for example) to load the mobile view.

Then make the desired changes and launch your experiment as you normally do.

Experiment Intermediate ...
Personalization Technical

Kameleoon works with a single JavaScript call, which weighs around 30KB and is served by a CDN (Content Delivery Network).

Please note that the size of the script will increase depending on your usage of the platform. Our script contains several main components and your custom settings (experiments, personalizations, KPIs, custom data…). You can get access to the size of each component by using the Performance analysis tool of our Chrome Extension.

Our script is downloaded only once per visit on first page load. Then the script is automatically cached by the browser for 90 minutes.

Experiment Intermediate ...
Personalization

It is highly unlikely that you encounter a conflict between the Kameleoon script and the other scripts on your website.

Indeed, Kameleoon is a 100% JavaScript solution and does not use jQuery, so there will be no conflict if you use jQuery on your website.

In addition, Kameleoon operates independently of the server-side development language and does not use global JavaScript variables, minimizing the risk of incompatibilities.

Advanced Experiment ...
Personalization Script Technical Troubleshooting

If you just launched an experiment but do not visualize the changes, you can follow this guide to make sure your experiment is set up properly.

Note: There is a delay between the launch of an experiment on Kameleoon and its visibility on your site. It can take up to ten minutes for the experiment to be actually online.

Check if Kameleoon script is updated on your computer

When you launch an experiment, Kameleoon updates its script, to make sure it contains the new data. The script loaded on your cache might not be updated. To make sure it is, open a web console on your browser (with F12 on a PC or CMD+ALT+I on a Mac) and type in this command:

Kameleoon.API.experiments.getAll()

It will list every experiment running on your website.

In the example below, 4 experiments are launched on the website. You can click on the small arrow on the left of every Object to see the detail and check if the experiment you just launched is here (thanks to the name information with the name of your experiment).

If your experiment is not on this list, you can empty your cache to force your browser to load the last version of the script.

Find out more in our documentation for developers

Make sure you are not on the reference

You can force the display of a variation on your computer.

Check the targeting criteria of your experiment

If you defined a target for your experiment, you might not be targeted. To check if you fulfill all criteria, open a web console on your browser (with F12 on a PC or CMD+ALT+I on a Mac) and type in this command:

Kameleoon.API.experiments.getActive()

It will list every experiment running on your website page. If your experiment is not in the list, it means there is a problem with targeting.

Find out more in our documentation for developers

Note: It is always recommended to launch a simulation to check if everything is correct. Please read the article about the Targeting tab of the simulation panel for further information.

Experiment Intermediate ...
Personalization Technical

You may see different results between Kameleoon and Google Universal Analytics. How can you identify the cause of these discrepancies? There are several possible reasons depending on the situation.

If you are comparing the same segment on Google Universal Analytics and Kameleoon

Discrepancies in the number of visits

  • (Frequently) The custom dimension is used in several experiments at the same time or is already used by your website for another purpose.
  • Google Universal Analytics is not installed on all the pages on which Kameleoon is installed (e.g. Kameleoon is also installed on the staging environment whereas Google Universal Analytics will only track data from the production one).
  • Cross-domain is not enabled on both Google Universal Analytics and Kameleoon.
  • The loading time of the Google Universal Analytics snippet is longer (e.g. your website has a high bounce rate), the data isn’t sent to Google Universal Analytics while it will be the case for Kameleoon.
  • Some IP addresses are excluded on one tool and not on the other (don’t hesitate to contact your Kameleoon Customer Success Manager about these excluded IP addresses).

Discrepancies in the number of conversions

  • All the above reasons.
  • Conversion tracking has not been configured in the exact same way on the two tools.
  • The compared data are not equivalent (e.g. total conversions / converted visits).

If your experiment has been launched on your entire website

Discrepancies in the number of visits

  • All the above reasons.
  • (Frequently) The timeout option is enabled: the script hasn’t loaded after one second, Kameleoon has been disabled, but on the GA side the data has been recorded.
  • Kameleoon did not target all browsers (incompatibility with some older browsers).

Advanced Feature flag ...
Technical

This guide is designed to help you create and activate Feature flags in your mobile application (Android or iOS) or your website. For each use case, we provide SDKs in the main languages (PHP, Java, Swift, NodeJS..). You can have the complete list of our SDKs and follow the installation guidelines provided for each SDK.

Create a new site / property

Before creating any feature flag, you need to create a new site/property in your Kameleoon account. A site can be an environment (production, staging), a website or your mobile application (Android or iOS). 

Each site has its own sitecode, which uniquely identifies a site in your Kameleoon account. If you want to run feature flags across several of your applications and websites without having to duplicate them on each site, we recommend you set up only one site and use the same sitecode in all our SDKs.

The sitecode is really important and it will be required in our SDK when you initialize the KameleoonClient object.

NodeJS SDK example

Create your first feature Flag

On the side menu of the back-office, click on “Feature flag” to access the dedicated dashboard. Then click on the “New feature” button.

Name your feature flag, provide a unique key (which you will use in our SDKs methods) and choose the site / property on which you would like to activate this feature flag.

To activate your first feature flag, you only need to:

  • define the exposition rate: this is the percentage of your users for which you want to activate or roll out your feature flag;
  • choose at least a goal/KPI you want to measure in our reporting tool for this feature flag.

Optionally, you can:

  • enter a description;
  • add tags, which you can use to filter the dashboard list;
  • rollout your feature flag to specific groups of users who share common attributes. For this, you will need to define custom data and then build segments by combining custom data with OR/AND operators;
  • define feature variables (Number, Boolean, String or JSON) to remotely update the content of your feature flags in production. There is no limitation in the number of feature variables you can create.

Rollout a feature flag to specific group of users

If you want to rollout a feature flag to a group of users, you will need to:

  • create custom data;
  • set the value of the custom data by using our SDK method addData();
  • create a segment by combining several of your custom data.

Create a custom data

On the side menu of the back-office, click on “Configure” > “Advanced tools” and then hit the “New” button.

Choose the “Custom data” type and select your site/property.

Name your custom data, choose the “Kameleoon Activation API” acquisition method, the type of your custom data (“String”, “Boolean” or “Number”) and the scope “Visit”. Those are the settings compatible with our feature flag product.

Set the value of the custom data by using our SDK

To associate various custom data with the current user, you need to use the addData() method of our SDK (please read the technical documentation of our SDK). This method has to be called before you activate your feature flag with the method activateFeature().

Note that the addData() method doesn’t return any value and doesn’t interact with the Kameleoon back-end servers by itself. Instead, all declared data is saved for further sending via the flush() method. This reduces the number of server calls made, as data is usually grouped into a single server call triggered by the execution of flush().

See an example of code below:

kameleoonClient.addData(

    visitorCode,

    new Data.CustomData(10, "Brand name 1")

);



kameleoonClient.flush(visitorCode);

Note that you will need to use the unique id of the custom data (in the code above, the ID is 10). This index can be found once the custom data is created, by hovering over the custom data line.

Create a segment by using your custom data

To create a segment, simply hit the CTA “Create a new segment” from the feature flag configuration page. The segment builder will open and you will be able to use your custom data and set the value(s) you want to target. You can combine several of them with AND/OR.

Defining feature variables

Feature variables let you variabilize parts of your feature flag code so that you can dynamically assign values depending on your use case, without having to hard code them in your source code. So, instead of updating your application or website by deploying new code, you can directly update the feature flag remotely by updating the feature flag configuration.

A feature variable can be a number, a boolean, a string or a JSON code. To retrieve a feature variable content, you need to call the obtainFeatureVariable() method of our SDK right after calling the activateFeature() method.

Once you are happy with your configuration, you can click on the CTA “Launch” to activate the feature. Then you will need to use our SDK methods to retrieve the feature flag configuration and activate it from your application or website.

Implementation guidelines

Once your feature flag has been launched / activated, you will need to follow the developer documentation available for each SDK. In a nutshell, you will need to :

  • Install the SDK in your app or website. For web SDKs, you will need to provide credentials (client_id and client_secret) via a configuration file available in the SDK, which can also be used to customize the SDK behavior. You can ask your credentials to your Account Manager.
  • Initialize the KameleoonClient. Remember: you will need your sitecode here.
  • Activate the feature flag by calling the activateFeature() method of our SDK. This method usually takes a visitorCode and the featureKey (the one you have chosen when you have created your feature flag). The activateFeature() method returns a boolean value: true if the user should have this feature or false if not. Kameleoon will randomly expose your visitor to your feature flag (except if you have rolled out it to 100% of your users). If you have set up a segment for your feature flag, Kameleoon will only activate the feature if the user meets the conditions defined in your segment. For mobile SDKs, the initialization of the Kameleoon Client is not immediate, as it needs to perform a server call to retrieve the current configuration for all active feature flags. The runWhenReady() method of the KameleoonClient class allows to pass a callback function that will be executed as soon as the SDK is ready for use. It also allows the use of a timeout. Two methods must be implemented: onReady() and onTimeout(). The onReady() method will be called once the Kameleoon client is ready, and should contain the code that activates your feature flag. The onTimeout() method will be called if the specified timeout happens before the client is initialized.
  • (Optional) Retrieve the feature variables associated with your feature flag by calling the obtainFeatureVariable() method of our SDK. This method takes two input parameters: your feature Key and your variable Key. It will return the data as a java.lang.Object instance. Usually it should be casted to the expected type (the one defined on the web interface).
  • (Required if you use a segment in your feature flag) You can associate data with the current user. For this, you need to use the addData() method of our SDK. Data associated with the current user via this method is not sent immediately to our servers. It is stored and accumulated until it is sent automatically by the activateFeature() or trackConversion() methods, or manually by the flush() method. This allows you to control exactly when the data is flushed to our servers.
  • Track metrics to measure the success of your feature flag. You need to use the trackConversion() method. This method requires a visitorCode and a goal ID to track conversion on this particular goal. In addition, this method also accepts revenue as a third optional argument to track revenue. Only custom goals can be tracked in feature flags reports. The ID you need to use in the trackConversion() method is available in the custom goal creation popin.

Experiment Intermediate

A/B testing is based on statistical methods. You don’t need to know all the maths behind, but a little brush up in statistics won’t hurt and certainly improve the chances of your success.

There are 2 main statistical methods behind A/B testing solutions. There aren’t one better than the other, they just have different use. Here is how we handle it with Kameleoon’s statistical engine.

Frequentist approach

Allows a simple read on result reliability thanks to a confidence level: with a level of 95% or more, you have a 95% chance of obtaining the same result should you reproduce the experiment in the same conditions. But this method has a downside: it has a “fixed horizon”, meaning the confidence level has no value up until the end of the experiment.

Bayesian approach

Provides a result probability as soon as the experiment starts. No need to wait until the end of the experiment to spot a trend and interpret the data. But this method also has prerequisites: you need to know how to read the confidence interval given to the estimations during the experiment. With every additional conversion, the trust in the probability of a reliable winning variant improves.

Experiment Intermediate ...
Personalization Technical

It may happen that data reported by Kameleoon does not correspond exactly to the data reported in third-party solution. Several elements can explain this situation:

  • The two solutions are not installed on exactly the same pages;
  • The cross-domain is activated and used on one solution but not on the other (which therefore counts new visits in excess);
  • The two solutions do not have the same definition of a visitor;
  • Some IP addresses are excluded in the configuration of a solution;
  • The two solutions were not activated in the experiment at the same time;
  • The two solutions do not practice the same management of legal consent.

Experiment Intermediate ...
Personalization Script Technical

Why disable the script?

  • If you attach great importance to the performance of your website and wish to limit the loading time as much as possible.
  • And if you don’t use Kameleoon continuously because you only need to test your hypotheses once in a while.

Kameleoon allows you to temporarily deactivate its script when you don’t use it.

How to disable the script?

A button to disable Kameleoon’s script can be found on the configuration page of your website. When you click on it, all the content of the script is erased: the script is now 0Kb.

In your Kameleoon back office, in the left side menu, click on “Aministrate” > “Sites”.

In the lower part of the card dedicated to your website, you will find two indicators:

  • the status of Kameleoon (active/inactive) ;
  • the script installation (installed/not installed/not detected).

To deactivate the script, the status must change from “Kameleoon enabled” to “Kameleoon disabled”. When hovering over the card, action buttons appear. Click “Disable” to deactivate the script.

A warning pop-in asks you to confirm your choice: by continuing, your experiments and personalizations will no longer be visible on your website.

Once the deactivation is confirmed, the status becomes “Kameleoon disabled”.

How to enable the script again?

You can reactivate the script whenever you want. Just click on the button again. Your experiences will then resume on your website.