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 App

To change the language in your Kameleoon App, 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 App.

Disable the shortcut

To do so, log in to your Kameleoon App.

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

Common Intermediate ...
Technical

If a visitor to your site has an ad blocking service or browser extension enabled, it is possible that Kameleoon is listed under the block list for this ad blocker. Extensions like AdBlock Plus, Ublock or Ghostery have been known to block Kameleoon assets, which prevents Kameleoon from executing on the page.

Some ad-blockers have kameleoon.com and kameleoon.eu on their blacklists. This can affect Kameleoon’s ability to record conversions on metrics and cause discrepancies in expected behavior for visitors with ad-block services enabled. Please note that if you use an adblocker, there is a high chance you won’t be able to access app.kameleoon.com to create campaigns as some of our own ressources will also be blocked.

There is currently no way around this problem: if your visitors have activated an ad blocker, they will have to manually remove Kameleoon from the blacklist.

However, it is possible to display a message on your site encouraging your visitors to disable ad-blocking. This method has proven to be a good alternative.

If you believe you have a large portion of your visitors using ad blockers, Kameleoon can offer “on premise” tracking request URLs, which is a good option to avoid being blocked by ad blockers. Please reach out to your Customer Success Manager for assistance.

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 a list and description of the data collected by Kameleoon. This data differs depending on the type of experiment and the configuration of your website.

Local storage

Kameleoon saves the collected data on 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: This contains a lot of data about the visitor and their visits (mostly browsing-related data). This data is encoded on 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 GDPR or similar regulations) obtained for the use of Kameleoon. For instance, the value can be {“AB_TESTING”: true, “PERSONALIZATION”: false} or {“PERSONALIZATION”: true}. Lifespan of 380 days.
  • kameleoonOpenTabs: This contains the 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: This contains all the (virtual) data about the visitor and their visits for simulation. Lifespan of 1 hour.

Experiments data

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

Personalizations data

  • kameleoonPersonalization-${personalizationId}: This saves the personalization variation assigned. Lifespan of 30 days.
  • kameleoonGlobalPersonalizationExposition: This represents the visitor’s global exposure 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”, they will be exposed if they trigger the required targeting conditions). By default, 10% of the global traffic is excluded from any personalization. This value can be configured in Kameleoon’s back-office. Lifespan of 380 days.

Session storage

All this data is kept only for the duration of the session.

Common data (Experiment + Personalization)

  • kameleoonDisabledForVisit: This disables loading by Kameleoon for the current visit. It will depend on whether or not you’ve activated this option in your website settings in the Kameleoon back-office. By default, it will never be used.
  • kameleoonAnalyticsTrackingTimes: This is used to optimize (reduce) the number of third-party analytics tracking calls made by Kameleoon when using a web analytics integration.
  • kameleoonFullApplicationCode: This contains the entire Kameleoon 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: This contains the visitor code (a unique identifier randomly assigned to a visitor). This cookie is automatically replicated by Kameleoon on local storage (inside the kameleoonData key), so, if it is deleted, Kameleoon will recreate it automatically from the data contained in kameleoonData. Stored for 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 doesn’t 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 (which contains all the data about the visitor and their 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 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 complies with the General Data Protection Regulation (GDPR) and has already implemented a legal consent policy. No user data is stored without legal consent and our solution doesn’t use cookies. It works by using local storage, only after obtaining consent. The only data collected is anonymous browsing data that makes it impossible for anyone to identify a visitor.

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 total compliance with the GDPR 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 the results of your experiments. Find out more about how Kameleoon handles Apple ITP

Experiment Intermediate ...
Personalization Technical

Kameleoon has a native consent management and therefore only collects data from visitors who have given their consent. Learn more about Kameleoon’s consent management policy

The measurement of unique visitors is based on cookies and Local Storage. A cookie is a file placed on a browser that contains an anonymous unique identifier, called the Kameleoon visitorcode, randomly assigned to a visitor. This ID is used to uniquely identify a browser. This cookie is also automatically replicated by Kameleoon in Local storage, so if it is deleted, Kameleoon recreates it automatically from the data contained in Local Storage. Our visitorcode is stored during 380 days on the user’s browser.

Kameleoon bills your account based on the number of monthly unique visitors who visit your site. A monthly unique visitor is an individual user who accesses your site within 30-day window.

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

Internet bots are software applications that run repetitive, automated tasks over the Internet. This behavior may impact the results of your experiments and personalizations as bots don’t behave like real visitors and inflate the volume of traffic (visits) to your site and may impact your conversion metrics (KPIs/goals). So, removing this traffic from your campaign results makes your data more accurate.

Kameleoon has developed internal algorithms to detect bots traffic on your website and filter it out of your campaign results. When building a visit from visitor events, the visit can be rejected from our statistics if detected as an outlier (bot, troll, tracker bug, etc.) if at least one of the following conditions is met during a visit:

  • Duration of the visit > 120 minutes
  • Duration of the visit < 100 milliseconds
  • Number of events (conversions, clicks, targeting, product, page view, etc.) > 10K

If you use Kameleoon Full Stack and code your experiments server-side, we recommend you read this article.

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 App 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 campaigns 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 App).

 

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.

How does the Kameleoon iframe work?

The Kameleoon iframe is used to ensure continuity and consistency of data (exposures, conversions, custom data, etc…) when moving from one subdomain to another, this is accomplished by delegating the iframe the task of reading and writing the information in localStorage (in the domain where the iframe is deployed).

As the local storage is specific to a single domain, the iframe allows us to read from all your subdomains the kameleoon data we store in the local storage of your main domain to keep track of a same visitor without impacting the performance of your website, by making extra server calls.

More detailed documentation on this subject

In order to secure our iframe, we have implemented the following 3 measures:

  • Restriction of access to identified domains : only the domains specified in the allowedDomains variable (in the iframe code) are authorised to request the iframe. the Kameleoon iframe can only load and execute code on the allowed list of domains you explicitly set in the iframe file, so there is no way the iframe could load and execute outside your own domains.
  • Restricting access to identified sitecodes : only a Kameleoon engine with the specified sitecode (in the iframe code) is allowed to request the iframe.
  • Prefixed Local Storage : the iframe (and Kameleoon at large) is only allowed to read/write entries prefixed with “kameleoon”.  No other data can be read/written.

The data collected by Kameleoon is of a non-personal nature in accordance with current regulations. Please read the exhaustive list of this data

Kameleoon offers consent management that can be adapted to all needs & ecosystems via a dedicated API and adjustable behaviour in case of unknown consent. More documentation on this subject

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 App, 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

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

Kameleoon offers many out-of-the-box analytics integrations which you can use to measure the impact of your campaigns (A/B tests or Personalizations). However, you may see different results (visits, visitors or conversions) between our reporting system and your Analytics platform (Google Analytics, Adobe Omniture, AT Internet, Matomo..). Small variations are usually “normal” though, even if your integration is correctly set up. This is because different analytics platforms often define metrics differently or are configured differently. Some analytics platforms will not manage ITP issues with the Safari browser as we do, bots filtering rules will not be exactly the same, etc. However, you should start looking for a problem as soon as you have a data discrepancy of more than 7-10% between Kameleoon and your analytics platform.

If you’re seeing large discrepancies in your data, this article will guide you to make sure you’re following some best practices to identify the root cause of it. 

This documentation also assumes you are using our native analytics integrations. So please always compare figures for visitors who have been tagged with Kameleoon experiment and variation information, with a custom dimension, custom variable, eVar, etc, depending on the analytics platform you use. Indeed, when a native integration is being used in one of your experiments, Kameleoon will flag your visits when visitors are targeted by the experiment. So your analytics platforms’ data should be filtered to only show data that contains experiment and variation information. Otherwise it will make the comparison unreliable.

Visits / Visitors discrepancies

How are visits and visitors counted

First, you should know that Kameleoon measures unique visitors based on cookies and Local Storage. A cookie is a file placed on a browser that contains an anonymous unique identifier, called the Kameleoon visitor code. It is stored on the user’s browser for 380 days. 

Each time the same visitor lands on your website, a new visit is created by Kameleoon and ends as soon as no new activity event (page view, scroll, clicks, etc.) has been received by Kameleoon over the last 30 minutes. In other words, a new visit will be created by Kameleoon after 30 minutes of inactivity.

So, first advice: please make sure both the number of visitors and visits are counted the same way in your analytics platform. For instance, in Google Analytics, there are two methods by which a visit ends: 

  • Time-based expiration: after 30 minutes of inactivity or at midnight.
  • Campaign change: if a same visitor arrives via one campaign, leaves after 2 minutes, and then comes back via a different campaign 2 minutes later, Google Analytics will count 2 visits whereas in Kameleoon, it will still be the same visit.

Bots filtering

Kameleoon offers bot filtering out-of-the-box which may also differ from your analytics platform. A Kameleoon visit can be automatically rejected from our statistics if detected as an outlier (bot, troll, tracker bug, etc.) if at least one of the following conditions is met during a visit:

  • Duration of the visit > 120 minutes
  • Duration of the visit < 100 milliseconds
  • Number of events (conversions, clicks, targeting, product, page view, etc.) > 10K

Browser compatibility

Kameleoon does not run on Internet Explorer so any visits from Internet Explorer users will be automatically excluded from your experiment reports. Please also note that Kameleoon only maintains full compatibility with the last 3 versions of any browser, so some visits might not appear in our reports as well.

IP exclusion

In most analytics platforms, you can add IP filtering rules, which will allow you to exclude certain IP ranges from showing up in your campaign results. You should have exactly the same filters in Kameleoon. Please contact your Customer Success Manager to set up them in your Kameleoon account so that we are measuring the same thing.

Ad / Content blockers

Many visitors are using ad blockers such as Adblock, Ghostery, uBlock..to block trackers and advertisers. Some ad blockers can also block client-side trackers such as analytics events, including unfortunately Kameleoon client-side events as well. So if you have a significant portion of your visitors that have ad blockers extensions enabled in their browser, there is a high chance that the number of visits will vary between Kameleoon and your Analytics platform. Indeed, if your analytics platform is not ad blocked whereas your Kameleoon is, the number of visits will be different. Some analytics platforms offer “on premise” tracking request URLs that allow them to avoid being blocked by ad blockers. Please note that Kameleoon can also offer the same capabilities. Please reach out to your Customer Success Manager for assistance.

If you believe you have a large portion of your visitors using ad blockers and that you have more visits and visitors in your analytics platform than we have in Kameleoon, we recommend sending an event to your analytics platform when Kameleoon has loaded so that you can have a clear idea of the percentage of visitors using ad blockers that block Kameleoon. To do so, you can use our Activation API events to send an event to your analytics platform when Kameleoon has loaded. Here is an example of code you can use. Please make sure it runs before the Kameleoon installation snippet. 

window.addEventListener('Kameleoon::Loaded', function (event) {

    // Here you should implement the logic to send the data to your analytics platform.

    // It can be something similar to:

    myAnalyticsPlatform.sendEvent("Kameleoon has loaded");

});

//Place here the Kameleoon installation snippet

Loading timing / implementation differences

One of our best practices is to have our snippet implemented in the <head> section of your source code to prevent any flickering from appearing in your experiments. It also means that Kameleoon will usually be one of the first tags to run, so we will send activity events as soon as possible. However, best practices for analytics platforms are completely different. In fact, most of the Analytics platforms will usually be loaded in the <body> section, or after the page has fully loaded. This means that Kameleoon will be sending events before most analytics platforms and will be counting more visits and visitors. Indeed, visitors may bounce, lose internet connection or click back. These visitors will not be counted by your analytics platform, whereas it will be the case in Kameleoon.

Analytics platforms may be installed on more or less pages than Kameleoon

This is a common root cause, especially if you want to run an A/A experiment that is targeting “the entire site” like it is displayed in the screenshot below. 

When that’s the case, Kameleoon will simply execute the code of your experiment on all pages where the Kameleoon’ snippet has been installed. In other words, technically, it is like having no targeting at all. So a difference in counts could be due to this reason. For instance, if the exact same Kameleoon snippet has also been installed on your staging environment, your experiment will also run there whereas in your analytics platform there is a high chance you won’t get the visits from this environment. A good way to identify if this is the cause of the discrepancy, is to break down your data by “Visited page URL”. It will show you all main URLs where the experiment has run so that you can identify URLs where Kameleoon should not have loaded (other environments, webviews on mobile apps, etc.).

Best practices for these types of discrepancies are to:

  • Always run an A/A test on a small part of your website to make sure you fully master the scope of your experiment. 
  • If you need to make targeting adjustments to an A/A test, never do it on the same experiment. Stop that one and run another A/A test to verify that the issue was corrected by having fresh data on this experiment. Why? Because when visitors land on your site, they will download the Kameleoon snippet which will be automatically put in the browser cache, so that they don’t need to download our script again on the next pages, for performance reasons. The downside is that if you make new updates to a running experiment, not all your visitors will see your latest updates because some returning visitors may be running the older cached copy of our snippet. So there is a good chance that your experiment will contain data from returning visitors who still have an older cached version of our snippet. 

Events (click, transaction..) discrepancies

First, please note that if you have discrepancies in the number of visits or visitors, there is a good chance you will also have the same discrepancies in the number of conversions for a given event (click tracking, scroll tracking, transaction or total revenue). So you should first be looking at why you have visits or visitors discrepancies. 

However, if you have similar visitor or visit counts but different conversion counts, below are some guidelines to read to ensure that your events conversions can be compared to Kameleoon results. 

Event tracking configuration

The first thing is to check how the event is configured and tracked with your developers and our support team. For instance in Kameleoon a click tracking goal will listen both for mouse down events (for a desktop computer) and for touchdown events (in mobile phones and tablets), which is very different from an onclick event only. 

Also, if you have been using the graphic editor to configure your click tracking, please make sure the CSS selector attached to it is the right one. When there is no ID on the selected element, Kameleoon selects the element according to its (unique) hierarchical position on the page, by creating a hierarchical path from one of the parent blocks containing an HTML ID. Thus, a data issue may come from a default CSS selector which is not measuring the right event conversions. Please read this documentation to know more about it.

If you have been using our Activation API to track custom conversions, please make sure that the API function is called after Kameleoon has loaded on your page. We strongly recommend you use Kameleoon Command Queue, which allows for delayed command execution. The principle is simple: instead of directly calling the Activation API via the Kameleoon.API JavaScript object, you pass commands and functions to another JavaScript object, kameleoonQueue. If the Kameleoon engine is already loaded, the commands / functions will be instantly executed, otherwise they will be queued and executed once the engine is ready. This makes sure that all conversion events will be received by Kameleoon.

In a nutshell, always make sure your events track the same things the same way, otherwise the data won’t match at all between Kameleoon and your analytics platform. 

Event conversions count

In Kameleoon, for the same event, you can look at converted visits OR all conversions. The default view on our reporting page is “converted visits”, which means that even if a visitor clicks 3 times on an element, we will only display 1 converted visits. So if you want to compare the total number of conversions, you will need to switch to the “All conversions” view in our reports.

Event conversions attribution

In Kameleoon, visitor’s conversions only count toward an experiment as soon as the visit has been targeted by the experiment. So it means that:

  • Conversions happening in subsequent, non targeted visits are not taken into account in our report.
  • If a conversion event fires before the targeting decision occurs, it won’t be counted in our report.

In most analytics platforms, there is a good chance that conversions will continue to be counted even if visitors no longer meet the targeting conditions, so Kameleoon results page may show lower total conversions than in your analytics platform for a same event.

Conclusion

The vast majority of data (visit, visitor, event) discrepancies observed with our customers  came down to root causes covered in this documentation. In case the guidelines above don’t point you to anything conclusive, our support team is here to help, so please feel free to reach out. When submitting support requests, please provide as much detail as possible including screenshots of your analytics platform results, code samples of your event tracking configuration, explanations on how your analytics platform has been implemented (classic or on premise).

Experiment Intermediate ...
Personalization Technical

You may see different results (visits or conversions) between Kameleoon and Google Universal Analytics. Small variations are usually “normal”, even if your integration is correctly set up. This is because different platforms often define metrics differently or are configured differently (no ITP management, no cross-device management, bots filtering, etc.). You should start looking for a problem as soon as you have a data discrepancy of more than 7-10% between Kameleoon and your analytics platform. How can you identify the cause of these discrepancies? There are several possible reasons depending on the situation. This article will help you identify them:

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 App, 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 campaigns will then resume on your website.