Overview
Kameleoon provides web experimentation capabilities that let you run A/B/n or multivariate experiments on websites or web apps by using a graphic or code editor.
This guide explains the various implementation options that Kameleoon offers. Although the implementation process itself is simple, there are a few important details you need to know. Typically, you install a JavaScript tag to the HTML source code of your pages. It's important to know where to place the tags, the pros and cons of our different implementations, and when the Kameleoon application file is loaded and parsed by the browser. Getting all of these factors right is crucial to optimizing your Kameleoon setup for performance while maintaining the full functionality of the platform.
By familiarizing yourself with the implementation methods offered by Kameleoon, you can make an informed decision about which method will best suit your website and requirements. To create a basic implementation of the Kameleoon solution on your website, follow the Simple implementation guide.
After selecting the implementation method that suits your website, you should configure it for your Kameleoon project. By doing so, the Kameleoon platform can automatically generate the appropriate installation tag for you. To configure your Kameleoon project, follow the steps outlined in this guide.
Join us in our Slack Community to ask questions about our product features and get access to the latest updates.
List of installation tags & features
In the table below, you'll find an overview of our implementation options, including the features and performance characteristics of each options. Each row represents a different implementation option and indicates how the browser will load the Kameleoon JavaScript application file. The columns highlight different factors to consider, such as performance and flickering, as well as additional features like unified session data and compatibility with tag managers.
Later sections in this guide provide more information on these implementation options, including detailed explanations of their characteristics and features, as well as code snippets to help you get started.
| Implementation method | Flicker | May block page loading | Prioritized script loading | Affected by ITP | Use with Tag manager |
|---|---|---|---|---|---|
| Asynchronous loading, with anti-flicker | No | No | Yes | No | No |
| Asynchronous loading | Yes | No | Yes (if not installed via a Tag manager) | No | Yes |
| Synchronous loading | No | Yes | Yes | No | No |
In addition, it's important to note that all implementation methods can support unified session-data across subdomains if required.
Description of characteristics & features
This section defines and explains the characteristics and features presented in the previous table.
Flicker
The Flicker column indicates if this type of installation can induce a problem commonly occuring with JavaScript based A/B testing solutions, called the flicker effect. For more information about the flicker effect, please refer to our dedicated documentation.
May block page loading
The characteristic in the table that refers to "May block page loading" indicates whether the loading of your website will be impacted if Kameleoon's Content Delivery Network (CDN) servers (or your own CDN or server hosting the Kameleoon application file) are down or unresponsive. Only the JavaScript file (synchronous loading) implementation method presents this potential risk. With all other methods, your website will remain fully functional even if all our hosting servers are unavailable (although such an eventuality should never occur in practice).
Prioritized script loading
When an HTML page includes various static resources such as JavaScript files, CSS styles, Iframes, images, etc, they must be downloaded by the browser before they can be utilized according to their type. CSS or images will simply be displayed, while JS files and Iframes will execute code, among other things.
To download these resources, browsers typically place them in a network queue and then download them in a specific order of priority. Although this order of priority is not clearly documented and varies by browser, there are two critical factors to consider. First, a browser can only download a resource after it has been "discovered." Second, major browsers assign a higher priority to scripts included in the page statically than to those loaded dynamically through JavaScript code.
Eg, if you want a JS file to be loaded with higher priority, it's better to use this:
<script type="text/javascript" src="resources/scripts/example.js" async></script>
rather than this:
```html
<script type="text/javascript" >
var scriptNode = document.createElement("script");
scriptNode.type = "text/javascript";
scriptNode.src = "resources/scripts/example.js";
document.head.appendChild(scriptNode);
</script>
While we cannot be certain, our empirical knowledge suggests that this is because resources discovered by the HTML parser are given higher priority slots than resources added through dynamic modification of the DOM, which is typically done via JavaScript code.
Prioritized script loading is a technique where the Kameleoon application file is placed at the top of the browser's network queue. This ensures that it will load faster compared to a non-prioritized setup. While this option is recommended for Kameleoon, it does have the downside of delaying other resources. However, since A/B testing is a critical feature that needs to load as soon as possible (unlike tracking or analytics technologies that can load later since they do not affect the host pages), we consider this trade-off reasonable. Therefore, all current Kameleoon implementation methods provide prioritized script loading, except when installing Kameleoon via a tag manager system.
How ITP affects web experimentation
Intelligent Tracking Prevention (ITP) is a technology developed by Apple for Safari browsers, both on desktop and mobile devices, with a similar technology implemented by Mozilla in their Firefox browser. This technology aims to prevent unwanted third-party tracking, primarily by blocking advertising trackers from tracking users across multiple websites and serving targeted ads.
While Kameleoon offers a solution to these ITP restrictions, it now requires an additional configuration step since version 2.3, with the significant March 2020 update. You can find more information on this topic in our dedicated article.
Use with tag manager
The "Use with tag manager" option refers to whether the implementation method you have chosen allows the use of a tag manager or not. Kameleoon is compatible with all major Tag Management Systems (TMS). Nevertheless, we highly recommend that you install Kameleoon directly into the source code of your pages, if possible, rather than using a TMS. This is because it can help address the flicker effect, which is explained further in our core concepts section.
Tracking unified session data across subdomains
Kameleoon supports unifying session data across subdomains, which allows you to link sessions across multiple subdomains as a single session. This means that if a visitor starts a session on one of your owned websites, such as portal.myecommercesite.com, and continues the session on another owned website, such as transaction-engine.myecommercesite.com, it will be treated as one continuous visit.
This feature ensures accurate data collection across multiple subdomains that you own. Without unified session data, a visitor starting on one subdomain is treated as a new visitor once they move to another related domain. This causes all the data collected on the previous domain (such as the number of page views, time spent on site, etc.) to be reset on the new domain. Targeting based on these criteria may also yield unexpected results if unified session data across domains is not enabled.
For example, let's say you have a personalization that triggers on the fourth page viewed. A visitor visits your first website and sees three pages. Then, they load the fourth page on a different domain website. With unified session data tracking, the personalization will trigger as expected. However, without it, the page view on the new domain will be treated as the first page view of a new visit, and the personalization will not trigger.