Tests côté serveur

Certaines modifications ne peuvent pas se faire en éditant une page rendue. Classer un résultat de recherche différemment, changer ce que renvoie un endpoint de prix, ou remplacer un modèle de recommandation : tout cela se passe avant qu’aucun HTML n’existe. Un test côté serveur couvre ces cas : votre propre code affiche chaque variante, et Pertento porte le test, décide qui reçoit quelle variante et se charge de la mesure.

Qui choisit la variante est un réglage. Avec l’affectation par le navigateur, la balise Pertento la choisit selon le poids, exactement comme pour un test visuel, et le code de votre page l’affiche : pas de clé serveur, aucune modification du backend, et le ciblage par URL, par appareil et par cookie fonctionne comme d’habitude. Avec l’affectation par le serveur, votre backend interroge le SDK serveur avant le rendu, si bien que le premier rendu est déjà la bonne variante et que rien ne change après le chargement de la page.

L’affectation par le serveur apporte ce dont un backend a besoin. Chaque test a une clé de flag et chaque variante une clé sur laquelle votre code s’aiguille, avec un payload JSON facultatif pour les valeurs qu’utilise cette variante. Des règles d’attributs portant sur vos propres données, comme la formule ou le pays, décident qui entre dans le test, et un test peut répartir selon votre propre identifiant client, pour qu’un client connecté voie la même variante sur tous ses appareils. Pertento ne stocke jamais cet identifiant.

Les résultats arrivent sur les mêmes écrans de statistiques que tous les autres tests. La page compte le visiteur sous l’identifiant pour lequel votre serveur a décidé, et les conversions viennent du navigateur ou uniquement de votre backend, jamais des deux. Déployer un gagnant fonctionne comme ailleurs : chaque décision désigne alors la variante gagnante, si bien que votre code la sert à tout le monde sans nouvelle mise en production.