Passer au contenu principal
Kameleoon a traditionnellement permis l’execution d’A/B tests au (en utilisant un moteur JavaScript) ou au (en utilisant un SDK cote serveur). Cependant, comme les strategies de mise en cache etendues sont courantes pour des raisons de performance, les requetes HTTP peuvent ne jamais atteindre les serveurs d’application back-end. Au lieu de cela, un serveur web frontal repond directement avec une version mise en cache de la page demandee. Dans ces configurations, les SDK cote serveur ne peuvent pas etre utilises, car la logique d’attribution d’un visiteur a une expérience se produit dans le code de l’application back-end, ce qui signifie que de nombreuses requetes ne peuvent pas etre traitees car une version mise en cache de la page est renvoyee a la place. En d’autres termes, le code implementant la repartition du trafic vers les variations d’une expérience ne serait pas execute. Pour resoudre ce probleme, des modules d’A/B testing Kameleoon sont disponibles pour les principaux serveurs web. Cela permet au serveur web de determiner la variation utilisee par chaque visiteur. Le serveur peut repondre avec une version mise en cache de la variation correcte, afin que l’application puisse beneficier des strategies de mise en cache standard. Le test web au niveau du serveur web est un niveau intermediaire entre le front-end et le back-end.

​
Concepts generaux​

Un module de serveur web Kameleoon est un composant bas niveau (ecrit en C pour des performances optimales) qui effectue l’attribution de variations chaque fois qu’une requete HTTP declenche une expérience A/B. Il redirige ensuite (en interne) la requete vers une URL potentiellement differente correspondant a la variation choisie. Par exemple, si un visiteur arrive sur la page https://www.shop.com/plasma-tvs.html et qu’une expérience est en cours sur cette page de categorie, avec trois variations, le serveur web redirige la requete HTTP en interne vers https://www.shop.com/plasma-tvs.html (version originale), https://www.shop.com/plasma-tvs.html?version=B (premiere variation) ou https://www.shop.com/plasma-tvs.html?version=C (deuxieme variation). Il renvoie ensuite une version mise en cache de ces pages (ou transmet l’appel au serveur d’application pour en generer une nouvelle si la valeur TTL a expire). L’A/B/C test est totalement transparent pour les utilisateurs finaux. Le visiteur ne voit que l’URL canonique https://www.shop.com/plasma-tvs.html dans le navigateur. La configuration de l’expérience (y compris la definition des URL cibles et de redirection ; par exemple, en ajoutant le parametre ?version=B) est realisee dans la plateforme Kameleoon. Le module de serveur web actualise periodiquement sa configuration depuis les serveurs et la base de donnees Kameleoon. Pour une planification et un deploiement pratiques des A/B tests, toutes les fonctionnalites Kameleoon habituelles sont disponibles, y compris demarrer, mettre en pause et arreter les tests ; modifier la deviation ; et modifier la configuration.
En raison des contraintes techniques du modele client-serveur sur le web, l’utilisation de conditions URL est la seule maniere de configurer le ciblage d’une expérience au niveau du serveur web. De meme, utilisez toujours des redirections URL dans Kameleoon pour configurer les variations au niveau du serveur web. Les impacts negatifs sur les performances et le SEO associes a la redirection front-end (navigateur) ne sont pas un probleme avec les redirections de serveur web. Au contraire, les redirections internes du serveur web sont parfaitement sures et considerees comme une bonne pratique car elles sont traitees en interne sur le serveur web (elles sont rapides) et sont transparentes pour les robots des moteurs de recherche.

​
Exploitation des expériences A/B au niveau du serveur web​

  1. Dans l’application Kameleoon, creez une nouvelle expérience A/B, avec l’editeur de code.
  2. Dans Kameleoon, creez les variations que vous souhaitez implementer pour l’expérience. Pour chaque variation, choisissez l’option de redirection URL et entrez la nouvelle URL souhaitee.
  3. Choisissez le ciblage de l’expérience en ajoutant une ou plusieurs conditions de ciblage URL. Toute URL correspondante sur le serveur web declenchera le module de serveur web pour la requete et activera une redirection interne. Le module stocke un cookie (de premiere partie) nomme kameleoonVisitorCode pour les requetes correspondantes.
Seules les options de redirection URL sont prises en compte pour les expériences au niveau du serveur web. Toute autre modification sur les variations, comme les changements de code JavaScript ou CSS via l’editeur graphique, sont ignores.
Vous pouvez ensuite choisir la deviation et lancer l’expérience comme d’habitude. Mettre en pause ou arreter l’expérience fonctionne egalement comme prevu.
L’exclusion de trafic ne fonctionne pas avec les expériences A/B au niveau du serveur web. L’analytique pour la version originale de l’expérience inclura les donnees des visiteurs du bucket exclu, au lieu d’exclure entierement ces visiteurs de l’expérience.
Pour faciliter les traitements potentiels cote serveur (suivi, implementation des variations), le serveur web ajoute un en-tete HTTP a toute requete correspondant a une expérience Kameleoon, lorsque l’option est activee dans le fichier de configuration Nginx (kameleoon_headers on;). Le premier en-tete est nomme kameleoon-experiment et son contenu est au format experimentID=variationID, ou experimentID represente l’ID de l’expérience declenchee et variationID represente l’ID de la variation attribuee. Le second en-tete est nomme kameleoon-redirection et son contenu est au format variationID=redirectionURL, ou variationID represente l’ID de la variation attribuee et redirectionURL represente le parametre utilise pour la redirection.

​
Plateformes prises en charge​

​
Module de serveur Nginx​

Le module prend en charge les versions 1.18.0, 1.20.2 et 1.21.4 de Nginx ; le package Docker est disponible ici. La derniere version du module prend en charge la version 1.27.1 de Nginx ; le package Docker est disponible ici.
Le module est teste sous une architecture x86_64.
Un script Python doit egalement etre installe en parallele (et lance periodiquement via une tache CRON ; des intervalles de 30 ou 60 minutes sont recommandes). Des identifiants Automation API (pour l’authentification OAuth 2.0) sont requis pour utiliser le script. Voir l’article identifiants API pour plus de details.

​
Module de serveur Apache HTTPd (deprecie)​

Le module Apache httpd prend en charge la version 2.4 et a ete teste sur une distribution CentOS avec une architecture CPU x86_64.
Un script Python doit egalement etre installe en parallele (et lance periodiquement via une tache CRON ; des intervalles de 30 ou 60 minutes sont recommandes). Ce script actualise ou met a jour le fichier de configuration Nginx genere requis par le module Kameleoon. Le script recharge egalement le fichier de configuration.