Web Server Modules
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.
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.
- 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.
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.
Apache HTTPd server module (Beta)
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).
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.