Testing server-side : 3 applications concrètes pour optimiser vos taux de conversion

Testing server-side : 3 applications concrètes pour optimiser vos taux de conversion

Après plusieurs mois en bêta, nous avons récemment annoncé la sortie de notre solution de testing server-side.

Cette fonctionnalité, de plus en plus demandée par nos clients, permet de réaliser des tests A/B en pilotant les changements directement depuis le code côté serveur ou depuis une application iOS ou Android, et répond ainsi à des besoins beaucoup plus avancés que le testing réalisé client-side.

Pour rappel, la promesse du testing client-side est de pouvoir réaliser des tests front-end très rapidement : modifications de textes, placement de vos boutons d’action, interversion de blocs, etc.

Même s’il est aussi possible de réaliser des changements plus complexes : nombre d’étapes dans votre tunnel de conversion, refonte de pages, etc, le testing client-side rencontre parfois des limites et il n’est pas possible de tout tester (test d’algorithmes de tri, ajout de nouvelles fonctionnalités, tunnel en 1 étape versus 5 étapes, etc.).

Dans un environnement dit client-side, la modification de vos pages a lieu directement sur le navigateur du visiteur. Autrement dit, le code source de la page d’origine (référence) est transféré du serveur jusqu’au navigateur du visiteur et un script pilote tous les changements à la volée sur le navigateur (Chrome, Firefox, Safari, Opera, etc.) pour afficher une version de la page modifiée (variante).

Un environnement dit server-side fonctionne différemment :

  1. un utilisateur se rend sur votre site,
  2. une requête est envoyée au serveur qui se charge de traiter la donnée (une page HTML par exemple) et d’envoyer le résultat au client (c’est-à-dire le navigateur du visiteur). C’est à ce niveau que le testing server-side opère : le split version d’origine / variante est réalisé à ce moment-là et la page qui est retournée au visiteur contiendra (ou non) les changements liés au test.

Attention, il ne faut pas opposer testing server-side et le testing client-side. Ce sont deux méthodes de testing qui répondent à des enjeux complètement différents. Les solutions de testing qui permettent d’opérer les deux sont dites Full Stack.

Pour en apprendre davantage sur la structure de Kameleoon Full Stack, je vous conseille de parcourir notre article dédié.

Dans cet article, je vous montre, via des exemples concrets, ce en quoi consiste le testing server-side et comment vous pourriez l’exploiter dès maintenant pour optimiser votre site.

À qui s’adresse le testing server-side ?

Le testing server-side s’adresse aux équipes IT, produits et de développement. 

Avec le testing server-side, l’A/B testing n’est plus uniquement l’affaire des marketeurs. Et c’est tant mieux puisque l’on est maintenant capable d’optimiser tous les aspects d’un site web ou d’un produit.

tableau_testing_server_side

Quels sont les bénéfices du testing server-side ?

Le testing server-side est une pratique d’optimisation itérative différente qui ne vient pas concurrencer, mais compléter le testing historiquement réalisé client-side.

1. Un gain d’agilité pour les développeurs, équipes Produit & IT

Grâce au testing server-side, les développeurs, équipes Produit & IT gagnent en agilité et peuvent maintenant, elles aussi, soumettre chacune des évolutions des fonctionnalités back-end de leur produit à un test A/B.

Frederic_optimisation_experience_utilisateur_commencer« Le gain en agilité des équipes IT n’affecte pas l’indépendance des équipes marketing qui peuvent continuer de mener des tests client-side. Le testing server-side apporte simplement plus de possibilités de testing et étend l’usage de la pratique en interne. »

Frédéric De Todaro, Head of Consulting, Kameleoon.

Prenons deux situations où le testing server-side s’impose. 

Test des algorithmes de suggestions d’un moteur de recherche

Si vous êtes e-commerçant, votre chiffre d’affaires dépend en partie de la facilité avec laquelle vos visiteurs parviennent (ou non) à trouver les produits qu’ils cherchent sur votre site.

Autrement dit, une part significative de votre chiffre d’affaires dépend de votre moteur de recherche.

Un cas d’école d’utilisation du testing server-side.

Pour optimiser l’expérience de recherche de vos clients et visiteurs, vous voulez tester l’impact que pourraient avoir de nouveaux algorithmes de recherches sur la valeur de chaque visite (c’est-à-dire le chiffre d’affaires moyen réalisé par visiteur).

Lorsque vous utilisez un moteur de recherche, les suggestions réalisées en temps réel sont 100 % corrélées avec votre recherche.

exemple_fnac_testing_server_side

Sur fnac.com, par exemple, les suggestions faites sont mises à jour en temps réel et dépendent des mots-clés que j’utilise.

Pour ne pas imposer un lourd téléchargement côté client (sur le navigateur du visiteur donc), les résultats (ou suggestions) des algorithmes de recherche sont opérés et stockés sur le serveur de votre site.

Pour tester la pertinence des suggestions affichées et/ou l’ordre des suggestions affichées par l’algorithme au visiteur, vous devez alors passer par une solution de testing server-side.

 

Test des algorithmes de filtre produit sur un site e-commerce

Si un visiteur recherche un type de produit, sans avoir une idée bien précise de ce qu’il souhaite, les fonctionnalités de tri de votre catalogue peuvent l’aider à mieux se projeter.

Prenons un nouvel exemple de test sur algorithme, chez Darty.

Voici (ci-dessous) les types de résultats proposés par l’algorithme de tri de Darty.com.

darty_testing_server_side

Comme les algorithmes qui génèrent des suggestions en temps réel à partir des mots-clés du visiteur, les algorithmes de tri du catalogue produit se situent sur votre serveur.

À titre d’exemple, si les équipes de Darty souhaitaient tester la pertinence de l’ajout d’une catégorisation « Meilleures ventes » à leur algorithme de tri, elles devraient impérativement utiliser le server-side.

Pourquoi serait-ce compliqué de réaliser ces deux exemples de tests client-side ?

En réalisant ces tests client-side, vous devriez soit :

  1. vous contenter de modifications cosmétiques (ordre des catégories, taille des caractères, etc.),
  2. gérer ces tests en redirection d’URL via l’ajout d’un paramètre en fin d’URL permettant d’activer les variantes de votre algorithme.

 

Rien ne vous empêche de réaliser des optimisations cosmétiques de votre moteur de recherche (1), mais les gains de conversion seront moindres.

En optant pour l’option (2), vous risquez d’imposer des temps de chargement très (trop) importants à vos visiteurs.

2. Des expériences cross-canal optimisées

Les parcours de navigation de vos visiteurs sont très complexes. Le Baromètre Digitas de l’expérience marchande rapporte par ailleurs que nous utilisons en moyenne 5 terminaux différents pour aller sur le web.

Nous savons très bien le challenge et le casse-tête que cela représente pour vous.

Avec une solution de testing client-side (dépendante de JavaScript donc), vous ne pouvez pas, dans le cadre d’un test A/B sur votre site, proposer une variante similaire sur desktop et application mobile à un visiteur, même connecté.

Avec une solution de testing server-side, vous pouvez A/B tester l’expérience d’un visiteur quel que soit le terminal ou le mode de contact (navigateur ou application) et alors rendre son expérience plus pertinente.

Pourquoi cela pose problème client-side ?

Reprenons le cas du test d’un algorithme qui effectue des suggestions.

Le testing client-side ne permettant pas de réaliser de test en simultané sur desktop et application, l’expérience pourrait être chaotique pour un visiteur qui ferait face à une nouvelle configuration de l’algorithme dès lors qu’il se connecte depuis un nouveau terminal

Exemple : un visiteur se rend sur votre site et utilise votre moteur de recherche pour trouver un type de paire de chaussure en particulier, sans idée très précise du modèle qui peut l’intéresser, dans un premier temps. Il est exposé à un test A/B réalisé client-side et est exposé à une variante de l’algorithme de recherche via une redirection URL.

Il trouve, grâce aux suggestions de recherche, un modèle qui l’intéresse tout particulièrement : Les Nike Air Zoom.

recherche_nike_testing_server_side_desktop

Lorsqu’il se rend, quelques heures plus tard sur l’application de l’enseigne pour acheter les chaussures, les suggestions sont différentes. 

recherche_nike_testing_server_side

Dommage, il ne se souvient plus du nom de la paire de chaussure en question.

Il quitte l’application.

« Si un visiteur se rend sur un site via son ordinateur au travail et voit une variante A de votre homepage, puis une variante B lorsqu’il se connecte sur son ordinateur, puis une variante C lorsqu’il se connecte depuis sa tablette sur application … son expérience peut devenir chaotique (et les résultats de vos tests biaisés). Le testing server-side permet d’éviter complètement ce problème en envoyant une variante identique au visiteur connecté, quel que soit le terminal utilisé. »

Anaïs Rousseau, Business Consultant Manager, Kameleoon.

Attention ! S’agissant d’une expérience multicanale, il n’y a pas de miracle : le visiteur doit être connecté si vous voulez le reconnaître d’un terminal à l’autre.

 

3. Faites du testing sans affecter les performances de votre site

Moins de data à télécharger pour vos visiteurs = chargement plus rapide des pages

Les variations n’étant pas chargées client-side, le testing server-side rend vos expériences totalement invisibles pour vos visiteurs (c’est-à-dire qu’il n’ont aucun moyen de savoir qu’ils sont soumis à un test A/B) et réduit dans le même temps le chargement des pages soumises à un test A/B.

Parce que seule la variante sélectionnée server-side est envoyée au visiteur, on élimine tout risque d’effet flicker (c’est lorsqu’un visiteur voit l’original puis la variante d’un test suite à un micro-chargement) étant donné que le chargement des variantes s’effectue server-side et qu’elles sont ensuite envoyées sur le terminal du visiteur.

« Dans un souci de proposer une expérience plus qualitative, vous pouvez aussi utiliser une solution de testing server-side pour évaluer la pertinence d’une lourde refonte d’une page. Plutôt que de charger la version originale et sa variante, les navigateurs de vos visiteurs n’auront qu’une variante à charger : celle envoyée par le serveur. »

Anaïs Rousseau, Business Consultant Manager, Kameleoon.

Des variantes de test générées une seule fois

Lorsque vous lancez un test server-side, une unique requête a lieu entre Kameleoon et votre serveur, pour le premier visiteur exposé au test.

  1. Un premier visiteur ciblé par votre test arrive sur votre site
  2. Votre serveur envoi une requête à Kameleoon pour télécharger la configuration des paramètres de tests.
  3. Le SDK Kameleoon attribue une variante au visiteur et le serveur génère le code de la variante.
  4. Le visiteur reçoit la variante.

Pour les autres visiteurs, l’étape 2 disparaît et l’expérience est invisible et indolore. Autrement dit, le chargement des variantes n’affecte que la première personne à être ciblée par un test, le temps pour le serveur de télécharger la configuration des paramètres de tests (les tests en ligne, le pourcentage de répartition de trafic par variante, etc.) via Kameleoon.

Prêt·e à optimiser l’ensemble du parcours client ?

Vous souhaitez en apprendre plus sur le server-side et étudier en détail comment vous pourriez l’exploiter ? Demandez une démonstration de Kameleoon Full Stack et nous nous ferons un plaisir de vous venir en aide.

demande de démo kameleoon

Clément René

Content marketer chez Kameleoon, Clément analyse tous les retours de nos clients et consultants et partage les meilleures pratiques d'optimisation de l'expérience utilisateur.

Laisser une réponse
Quelle est la capitale de la France ?