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 constraints of the client-server model on the web, using URL conditions is the only way to configure experiment targeting at the web server level. Similarly, always use URL redirects in Kameleoon to configure variations at the web server level. The negative performance and SEO impacts associated with front-end (browser) redirection are not an issue with web server redirects. Instead, internal web server redirects are perfectly safe and considered a good practice because they are processed internally on the web server (they're fast) and are transparent to search engine crawlers.
Operating web server A/B experiments
In the Kameleoon app, create a new A/B experiment, with the Code editor.
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.
Traffic exclusion does not work with web server A/B experiments. Analytics for the original version of the experiment will include data from visitors in the excluded bucket, instead of excluding those visitors from the experiment entirely.
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, when the option is turned on in Nginx config file (kameleoon_headers on;). The first header is named kameleoon-experiment and its content is in the format experimentID=variationID, where experimentID represents the triggered experiment ID, and variationID represents the ID of the variation assigned. The second header is named kameleoon-redirection and its content is in the format variationID=redirectionURL, where variationID represents the ID of the variation assigned and redirectionURL represents parameter used for the redirection.
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 latest 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.