A / B Testing & Server-side : quels cas d’usage ?
L’activation de la donnée est au cœur des problématiques d’optimisation et d’amélioration du parcours client chez les grands acteurs du digital. Seule une approche méthodologique appuyée par la donnée permet d’améliorer l’expérience client de façon consistante, et ce via l’identification des points de friction des parcours et la définition d’hypothèses à tester.
L’A/B testing est un des cas d’usage d’activation de la donnée. C’est une méthodologie d’expérimentation itérative qui consiste à confronter une version A (version de contrôle) et une version B afin d’en déterminer la version qui performe ou convertit le mieux.
L’A/B testing peut être déployé via deux approches techniques : côté serveur et côté client. Deux approches qui répondent chacune à des besoins et des cas d’usages bien distincts.
Nous mettrons en exergue dans cet article les différences entre les deux afin d’identifier quelle technique conviendrait le mieux pour votre stratégie d’optimisation continue.
Client-side et Server-side ?
-
L’A/B testing client side & server side
Sur le Web, il existe 2 types d’ordinateurs connectés:
- Les serveurs qui fournissent des applications et des sites internets
- Les clients qui consultent via des navigateurs et des services les contenus fournis par les serveurs
Le testing client-side, consiste à créer une expérimentation sur la machine cliente, donc sur le navigateur de l’utilisateur. Techniquement, l’expérience est d’abord calculée en javascript sur le navigateur de l’utilisateur avant de s’afficher sur le site. On peut retrouver les tests client side sur web & web mobile.
Le testing server-side implique de migrer la logistique de l’expérimentation vers un serveur web. Les scripts s’exécutent sur serveur et au lieu de demander au navigateur d’interpréter le test, il sera alors demandé au serveur web de livrer au client une variation déjà interprétée. Techniquement, le développeur du site détermine en amont la variation à mettre en avant et affiche la page correspondante sur le navigateur du visiteur.
-
Une solution performante, omnicanale, avec plus de possibilités
En ce qui concerne le server-side, le premier argument en sa faveur est la performance. Côté serveur, la présence du test n’a aucun impact sur la performance des interfaces, alors qu’avec un test client-side, un utilisateur peut percevoir des latences, voire un effet de scintillement, c’est-à-dire voir brièvement la page originale avant la variation le temps que le navigateur applique les modifications demandées.
Délivrer des expériences à partir du serveur veut aussi dire que les freins côté clients n’existent plus. L’idéation des tests prend une autre tournure car on peut commencer à imaginer des tests très fortement impactants.
Les tests côté serveur ne sont pas écrits en Javascript. Vous pourrez donc non seulement les tester sur navigateurs, mais aussi sur apps et tous les devices sur lesquels vous ne pouviez agir avant ; smart TV, kiosques électroniques, écrans tactiles en magasin, bornes interactives… Les possibilités de tests sont donc multipliées.
L’approche server-side est omnicanale car ces tests peuvent être effectués en même temps sur ces différents appareils.
Le testing en server-side permet de ne pas se limiter à des changements sur les pages de votre site internet, mais à l’évolution produit et des fonctionnalités back-end : Libre à vous de tester des formulaires en ajoutant ou en enlevant des champs, modifier votre parcours d’inscription, ajouter de nouvelles actions, changer tout votre checkout, tester des algorithmes de suggestion de votre moteur de recherche…
Les équipes de développeurs, product & IT pourront alors gagner en efficacité sur les différentes itérations à réaliser.
Avantages et inconvénients des méthodes
| Client-side
|
Server-side | |||||
| Avantages
|
Limites | Avantages | Limites | |||
| Facilité d’implémentation : des outils proposent des widgets préconçus (pop-in, bandeau, tooltip…) | Limité aux changements sur la page en front (modifications visuelles, wording etc.) | Profondeur des expérimentations (ciblages plus fins en exploitant directement des bases de données)
|
Faire attention au ranking des pages | |||
| Permet d’obtenir vélocité plus élevée | Dégrade la performance | Test sur des devices sans javascript
|
Dépendance à la DSI | |||
| Pas forcément besoin de compétences en développement web | Peut ne pas être compatible avec des technologies front : Adblockers, pas de JS, consentement si solution pas exemptée etc..
|
Tests sur des composants back : recherche, champs de formulaires, inscription, fidélité etc. | Méthodologie plus longue avec une chaîne de décision de l’entreprise plus importante | |||
| Données accessibles | Limité aux browsers et Apps | Performance accrue
|
Courbe d’apprentissage raide | |||
| Pas d’effet de scintillement | Performance technique inchangée
|
|||||
| Omnicanalitée poussée au maximum
|
Impact SEO dans la mise en place de tests | |||||
| Pas d’appel de ressources tierces sur le site : pas de possibilité d’être adblocké
|
||||||
| Apps mobiles : Convient mieux pour des tests sur du contenu dynamique
|
||||||
| Optimisé pour des objectifs à long terme (measurement, CLV..)
|
||||||
Est-il possible de migrer 100% des A/B tests en server-side ?
Une méthode de test plus complexe
Tout va dépendre de la méthodologie de test appliquée dans l’organisation, mais il paraît déconseillé de migrer 100% des A/B tests en server-side pour rester dans une stratégie d’amélioration continue agile.
Si vous êtes dans un contexte dynamique et que vous souhaitez avoir une vélocité élevée, le server-side n’est sans doute pas recommandé à cause des moyens requis pour la mise en œuvre.
Soit les tests prendront trop de temps à être déployés pour répondre à vos besoins, soit le surcoût engendré par l’équipe nécessaire à déployer rapidement en server-side rendra la démarche d’A/B test déficitaire.
Le temps de déploiement varie en fonction des résultats des A/B tests : si à l’issue d’un test une variation est gagnante, alors en server-side elle sera mise en production beaucoup plus rapidement, puisqu’elle sera déjà codée sur votre site. Au contraire, si le résultat du test n’est pas positif, l’équipe de développeurs mettront beaucoup plus de temps à retirer ces variations du code par rapport à un test client-side.
Adapter sa méthodologie en fonction des tests
Un excellent compromis serait d’identifier quels tests créer en server-side après la phase d’idéation. Ces différentes méthodes de testing auront besoin de roadmap d’expérimentation distinctes, avec des objectifs qui leur sont propres. De cette façon, les tests réalisables en autonomie, peu impactant ou nécessitant une réactivité exemplaire seront déployés en client-side, tandis que les tests à fort impact et qui nécessitent des moyens techniques conséquents seront à déployer en server-side.
L’état actuel des outils de développement ne permet pas d’aborder sereinement un passage à 100% du testing en server-side. La tendance au low-code et no-code facilitera peut-être l’émergence de profils “couteaux suisses” qui seront en mesure de créer des tests server-side en autonomie, et il n’y aura alors que le déploiement à gérer conjointement avec la DSI de l’organisation.
Un autre facteur plus structurel : la montée en puissance des budgets d’expérimentation. Si demain les organisations décident que chaque nouveau déploiement fait l’objet d’un test, alors le server-side sera décisif.
_
Pour résumer : si vous souhaitez bénéficier d’une vélocité de test élevée avec une implémentation facilitée, la méthode côté client est à privilégier. En revanche, si vous êtes sur un environnement plus complexe et/ou souhaitez mettre en place des tests beaucoup plus structurants, l’A/B testing côté serveur vous conviendra davantage.
Photo de Campaign Creators sur Unsplash
