Web server modules
Kameleoon has traditionally allowed the operation of A/B tests at the front-end level (using a JavaScript engine) or at the back-end level (using a server-side SDK). However, because many customers now use extensive caching strategies for performance reasons, HTTP requests may never reach the back-end application servers. Instead, a front-facing web server replies directly with a cached version of the requested page. In these configurations, server-side SDKs cannot be used, since the logic of allocating a a visitor to an experiment happens in the back-end application code, which means many requests can't be processed because a cached version of the page is returned instead. In other words, the code implementing the repartition of traffic to the variations of an experiment would not be run.
To solve this challenge, we implemented Kameleoon A/B testing modules for the major web servers used in the market today. This allows the web server itself to determine which variation will be used by each visitor. The server can then reply with a cached version of the correct variation, so your application can benefit from standard caching strategies as well.
With these new modules, we introduce web testing at the web server level. This is a new intermediary level, between the front-end and the back-end.
General concepts
A Kameleoon web server module is a low-level component (written in C for optimal performance) that performs variation allocation whenever an HTTP request triggers an A/B experiment. It then (internally) redirects the request to a potentially different URL corresponding to the chosen variation.
For example, let's say a visitor hits the page https://www.shop.com/plasma-tvs.html and there is a running experiment on that category page, with three variations. Internally, the web server will redirect the HTTP request to either https://www.shop.com/plasma-tvs.html (original version), https://www.shop.com/plasma-tvs.html?version=B (first variation) or https://www.shop.com/plasma-tvs.html?version=C (second variation). It will then usually return a cached version of these pages (or pass the call to the application server to generate a new one, if the TTL value of the cached version has expired).
The A/B/C test is completely transparent to end users. The visitor only sees the canonical URL https://www.shop.com/plasma-tvs.html in the browser.
You can complete the entire setup and configuration of the experiment (including setting the target and redirection URLs; for example, by adding the ?version=B parameter) inside the Kameleoon platform as usual. The web server module periodically refreshes its own configuration from the configuration present on the Kameleoon servers and database. To make it very convenient to plan and deploy your A/B tests, you have access to all the usual features of Kameleoon, including starting, pausing, and stopping tests; changing deviation; modifying configuration, and so on.
Due to the technical nature of the client-server model on the Web, experiment targeting at the web server level can only be done with URL conditions. Similarly, the implementation of the different variations should always be configured using a URL redirect in Kameleoon. Note that in this case, all the negative aspects (performance and SEO impacts) of URL redirection disappear when it is performed at the front end. It's perfectly safe and good practice to use an internal, transparent redirect at the web server level.
Operating web server A/B experiments
In the Kameleoon app, create a new A/B experiment, making sure the type of the experiment is Server-side or Hybrid.
In Kameleoon, create the variations you want to implement for the experiment. For each variation, choose the URL redirection option and enter the desired new URL.
Choose the targeting of the experiment by adding one or more URL targeting conditions. Any matched URL on your web server will trigger the web server module for this request, and potentially activate an internal redirect. Note that the module will store a (first-party) cookie named kameleoonVisitorCode for the matched requests.
Only URL redirection options are taken into account for web-server experiments. Any other modifications on the variations, such as JavaScript or CSS code changes via the graphical editor, are ignored.
You can then choose the deviation and launch the experiment as usual. Pausing or stopping the experiment also works as expected.
To help with potential treatments on the server-side (tracking, implementation of variations), the web server adds an HTTP header to any request that matches a Kameleoon experiment. The header is named kameleoon-experiment and its content is a comma-separated list of experimentID=variationID values. For instance, kameleoon-experiment: 32=268, 64=375. Note that we provide a list because a URL may match several distinct experiments.
Supported platforms
Nginx server module
Our nginx module supports version 1.18.0, 1.20.2 and 1.21.4 of Nginx. It has been tested on a CentOS distribution with an x86_64 CPU architecture.
You also need to install a Python script in parallel (and launch it periodically via a CRON job; we recommend running it every 30 or 60 minutes). To use the script, you need Automation API credentials (for OAuth 2.0 Authentication). See the API credentials article for details.
You can download the Docker package here.
Apache HTTPd server module (deprecated)
Our Apache httpd module supports version 2.4 of the software. It has been tested on a CentOS distribution with an x86_64 CPU architecture.
You also need to install a Python script in parallel (and launch it periodically via a CRON job; we recommend running it every 30 or 60 minutes). This script is responsible for refreshing or updating the generated nginx configuration file that the Kameleoon module needs. The script also makes the server process reload the configuration file.