Skip to main content
Depending on the country you are operating your website in, you may need to manage consent before collecting any data about your visitors. You can read more about it in the documentation.

Cross-device history reconciliation

Kameleoon’s cross-device history reconciliation feature merges a user’s history and actions across different devices. When a user visits a website multiple times via different devices, Kameleoon identifies them as a returning visitor and accurately reports the number of visits. This feature is straightforward to enable as long as you can identify users, usually through a customer login. By using cross-device history reconciliation, you gain three significant benefits:
  • A coherent targeting system that takes into account all visits and actions across devices.
  • Ensuring that a visitor sees the same variation for a given A/B experiment, regardless of the device they’re using.
  • A precise and accurate reporting system that correctly counts unique visitors.
To learn more about this feature, you can refer to this documentation.

ITP management

If a significant portion of your website’s traffic comes from mobile devices, implement a cookie synchronization method to prevent issues with Intelligent Tracking Prevention (ITP) on Safari. For more technical details about ITP management, refer to the documentation. There are several options available for synchronizing the visitorCode identifier (via the kameleoonVisitorCode cookie) between the front-end and back-end to avoid ITP issues on Safari. These options include:
  • Modifying your front-facing web server or Content Delivery Network (CDN) configuration to generate and add the kameleoonVisitorCode cookie. Kameleoon can provide instructions for Akamai.
  • Implementing a specific code snippet on your backend server (Java, NodeJS, or another language).

Nginx code snippet

For integration with Nginx, use the following code snippet:

Backend code snippets

You can host one of the back-end code snippets either on a single URL belonging to your main top-level domain or on every page. If you opt for a single endpoint, Kameleoon makes one call per session to the specified endpoint to ensure that your server sets the kameleoonVisitorCode cookie. This call is asynchronous and occurs after the page has finished loading. Contact your Customer Success Manager to activate this option. Kameleoon will need your chosen URL.
The synchronization endpoint you create should not return any data. A 204 No Content response code is sufficient. This endpoint is solely used to set a server-side cookie and should accept a GET request sent to the sync URL you define, using the following code:
If you embed the back-end code snippet on every page, no additional actions are needed. The cookie will be automatically created when normal page requests are made to your servers.
You can provide your own visitor code, typically a unique identifier from your database, instead of relying on automatic generation. Ensure the visitorCode you provide is unique for each visitor to guarantee accurate data for your experiments.
If you’re using both Kameleoon Web and Feature Experiments with one of the server-side SDKs, you can directly use the getVisitorCode() method. This helper method automatically retrieves the Kameleoon visitor code for the current visitor and creates the cookie on the back end.

Java

NodeJS

PHP

Copy and paste this code, and replace MY_DOMAIN by your base top-level domain (ie, mydomain.com).

C#

Go

Python

Ruby

Using a custom domain

If you want to use your own domain instead of Kameleoon’s default domain, or if ad blockers are preventing some users from being included in experiments, Kameleoon offers a premium option to set up a custom domain and bypass detection. Learn more about how to enable a custom domain.

Using your own CDN or hosting server (self-hosting)

The Kameleoon application file engine.js (previously named kameleoon.js) can be hosted either on the Kameleoon CDN or on your own CDN or servers. Hosting it on your own servers can offer a slight performance improvement by avoiding an additional DNS query and SSL handshake that the Kameleoon CDN requires. Additionally, self-hosting may be preferred for security reasons, as you can ensure compliance with your internal security policies and take responsibility for the security of your hosting servers. If you want to self-host the Kameleoon application file, see the self hosting documentation.