Web Server Modules

Introduction

Kameleoon traditionally allows the operation of A/B tests at the front-end level (JavaScript) or back-end level (web application languages such as Java, .NET, PHP...). However, many customers use extensive caching strategies for performance reasons, and very often, HTTP requests never even hit the back-end application servers, as a front-facing web server replies directly with a cached version of the requested page. In these configurations, unfortunately back-end SDKs cannot be used, since the logic of the allocation of a visitor to an experiment happens in the back-end application code, where most of the requests won't end up anyway. In other words, code implementing the repartition of traffic to the various variations of an experiment will never be reached / ran.

To provide a solution for 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 (for instance nginx or Apache httpd) to determine which variation will be used by each visitor. The server can then reply with a cached version of the correct variation, so this approach allows standard caching strategies to work as usual.

In short, with these new modules, we introduce web testing at the web server level. This is a new intermediary level, somehow between the front-end and the back-end.

General concepts

A Kameleoon web server module is a low-level component (written in C for achieving maximal performance) that will perform variation allocation whenever an HTTP request triggers an A/B experiment. It will then (internally) redirect the request to a potentially different URL corresponding to the chosen variation.

For instance, 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 3 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 of the cached version has expired).

Of course, the visitor only sees the canonical URL https://www.shop.com/plasma-tvs.html on its end. The A/B/C test is completely transparent for end users, as it should be.

Note that all the setup, choice and configuration of the experiments (their target URLs and their redirection URLs, for example the addition of the ?version=B parameter) can be done inside the Kameleoon platform as usual. Our module automatically periodically refreshes its own configuration from the configuration present on our back-office server and database. This makes it very convenient to plan and deploy A/B tests, as all the usual features of Kameleoon can all be used (starting, pausing and stopping tests; changing deviation; modifying configuration, etc).

Operating web-server A/B experiments via Kameleoon

Create a new A/B experiment as usual in the Kameleoon back-office, making sure the type of the experiment is "Server-side". You can choose either a pure server-side experiment, or an hybrid one.
In Kameleoon, create all the variations you wish to implement for the experiment. For each of the variation, choose the URL redirection option and enter the desired new URL.

3. Choose the targeting of the experiment by adding one or more URL targeting conditions. Any matched URL on your web server will trigger the Kameleoon module for this request, and potentially activate an internal redirect. Note that the module will place a (first-party) cookie named kameleoonVisitorCode on the matched requests.

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 an URL may match several distinct experiments.

Supported Platforms

Apache HTTPd server module

Our Apache httpd module supports version 2.4 of the software. It has been tested on a CentOS distribution with a x86_64 CPU architecture.

Note that a Python script should also be installed in parallel (and launched periodically via a CRON job; we recommend running it every 30 or 60 minutes). This script is responsible for refreshing / updating the generated Apache configuration file that is needed by the Kameleoon module (and making the server process reload the configuration file).

Nginx server module

Our nginx module supports version 1.18 of the software. It has been tested on a CentOS distribution with a x86_64 CPU architecture.

Note that a Python script should also be installed in parallel (and launched periodically via a CRON job; we recommend running it every 30 or 60 minutes). This script is responsible for refreshing / updating the generated nginx configuration file that is needed by the Kameleoon module (and making the server process reload the configuration file). To use the script, you will need Automation API credentials (for OAuth 2.0 Authentication). See this article for more details.

You can download the Docker package here.

Content Delivery Networks

Content Delivery Networks (CDNs) pose another challenge as they are also often used for caching, but each CDN has its own interface and API. Our development team is currently working on this topic. In particular, we're exploring a way to leverage Cloudflare's edge workers architecture to enable an integration with Kameleoon. You may contact us if you're interested in this subject.