Un simple changement de wording ou de design peut influencer l’experience utilisateur et dégrader ou améliorer l’engagement. L’A/B Testing est un procédé important de l’évaluation des performances d’une page web. Cet article vous guidera pour mettre en place un AB Test sur votre application NextJs sans impacter ni l’experience de vos utilisateurs ni les performances de votre site !
Pourquoi faire de l’AB Testing?
Un A/B Test est une méthode utilisée en marketing pour tester l’impact d’un changement mineur sur les performances d’un site selon un objectif définit. Il s’agit de modifier le design d’un élément, une mise en page, un texte pour créer des variation d’une même page. Le but étant de choisir l’une ou l’autre des variations en fonctions de celle qui va, par exemple, inciter plus les utilisateurs à s’abonner à une newsletter.
Les utilisateurs sont alors répartis dans plusieurs groupes qui verront chacun leur version du site. En comparant les performances des versions, souvent mesurées par des indicateurs tels que le taux de clics, le taux de conversion ou le temps passé sur la page, les marketers et les concepteurs peuvent prendre des décisions plus éclairées pour optimiser leur contenu et améliorer l'expérience utilisateur.
Variant A de la homepage d'un siteVariant B de la homepage d'un siteLes solutions techniques existantes
NextJS propose deux paradigmes pour la génération des pages.
NextJS peut générer des pages statiques (SSG - static site generation) à la construction du site. Cela signifie que les pages sont pré-rendues en HTML et servies aux utilisateurs sans nécessiter de rendu côté serveur ou côté browser pour chaque requête. Les temps de chargement sont ainsi très rapides.
En ajoutant un CDN (content delivery network, groupe de serveurs répartis géographiquement qui met en cache du contenu afin d’accélérer son chargement aux utilisateurs), les pages statiques sont alors cachées et disponibles très rapidement à travers le monde.
Static Site GenerationLa génération côté serveur (SSR Server Side Rendering) est un pré-rendu est fait côté serveur pour éviter de faire toute l’exécution du javascript dans le browser. Cela permet de rendre disponible rapidement un contenu dynamique ou qui change en temps réel.
On pourrait aussi imaginer un rendu des pages côté client (CSR). Le navigateur télécharge la page HTML et le JavaScript nécessaire à la génération de la page. Le JavaScript est ensuite utilisé pour mettre à jour le DOM et rendre la page. Lorsque l'application est chargée pour la première fois, l'utilisateur peut remarquer un léger délai avant de voir la page complète, car la page n'est pas entièrement rendue tant que tout le JavaScript n'a pas été téléchargé, analysé et exécuté.
Pour implémenter l’A/B Testing, on semble alors avoir deux possibilités qui s’offre à nous.
- Faire de l’A/B Testing Client Side
Certaines solutions d’A/B Test utilisent une approche côté client. Dans cette méthode, tout se passe au niveau de Javascript et donc du browser. Un identifiant unique est généré pour chaque utilisateur à qui sont ensuite attribués un variant (A, B ou défaut). La logique se trouve alors au niveau de la page ou du composant.
Une fois que le script côté client a reçu le variant de l’utilisateur, il va modifier le DOM avant de le renvoyer à l’utilisateur. Il peut alors y avoir un délai visible par l’utilisateur dans le browser, ou encore des apparitions/disparitions d’éléments (glitch) sur la page. Les conséquences peuvent aussi être visibles au niveau des core web vitals qui peuvent impacter le SEO.
C’est la solution la plus simple pour l’implémentation de l’AB test dans le code existant. Ce n’est, en revanche, pas la meilleure approche en terme d’expérience utilisateur et de performance.
- Ou faire de l’A/B Testing ServerSide
L'AB testing côté serveur fonctionne en déterminant quelle variation d'une page ou d'un composant afficher avant que la requête ne soit envoyée au client.
Lorsqu'une requête est reçue, le serveur utilise la valeur attribuée à l'utilisateur pour lui assigner une variation et rend ensuite la page correspondante. Toutes les décisions sont prises avant que la page ne soit rendue, ce qui élimine les biais liés aux capacités du client et garantit une expérience utilisateur cohérente.
Cependant, implémenter l'A/B testing côté serveur peut être plus complexe, nécessitant des modifications du code backend. Chaque requête nécessite une décision de variation côté serveur, ce qui peut introduire une latence supplémentaire et ainsi affecter les temps de réponse.
Server Side and Client Side Rendering page display flowLes deux solutions ne remplissaient pas nos critères, ils modifient l’expérience utilisateur ou impactent nos performances.
De plus, nos pages étant statiques, nous ne pouvions pas faire d’A/B Testing côté serveur
Comment concilier pages statiques NextJS et A/B Testing avec NextJS Middleware
Qu’est ce que le middleware?
Le middleware dans NextJS est une fonction qui s'exécute avant qu'une requête ne parvienne à une route spécifique ou à une page de l’application. Il agit comme un intermédiaire qui peut modifier la requête, rediriger l'utilisateur, ou répondre directement à la requête avant qu'elle n'atteigne le code de la page ou de l'API et ainsi court-circuiter le server. C’est particulièrement utile pour les tâches telles que l'authentification, la validation de requêtes, la gestion des cookies, ou même pour l'A/B testing. En s’exécutant “on the edge”, le middleware est rapide mais possède un environnement d’exécution limité.
Middleware functions run at the edgeA la racine du projet, on ajoute un fichier middleware.js:
Il est alors possible de modifier la requête entrante avant qu’elle n’atteigne la page ou l’API mais aussi de n’appliquer le middleware que sur certaines routes spécifiques.
Implementation
Utiliser le middleware pour l’A/B Testing constitue un avantage majeur pour garder le caractère statique des pages. Les versions des pages de tous les variants sont rendues et cachées dans le CDN. Le middleware s’insère juste après la requête.
NextJS Middleware est disponible depuis la version v12.0.0 de NextJS.
Supposons que notre homepage est sujette à l’A/B Test. Les variants de la homepage sont créées sous le dossier pages/homepage :
- pages/homepage/variant-a.tsx
- pages/homepage/variant-b.tsx
Ces trois pages sont générées au build de l’application et prêtes à être servie.
Serving two versions of the same page with NextJS MiddlewarePage display flow using NextJS Middleware Dans l’ordre, le middleware:
- Génère un id unique pour l’utilisateur
- Associe un variant à l’utilisateur en faisant appel à une API (ex: LaunchDarkly)
- Redirige l’utilisateur vers la bonne version de la homepage sans changer l’url
- les autres versions sont alors cachées sous /404
Afin d’éviter un call API à chaque requête de l’utilisateur et pour qu’il voit la même version chaque visite, on crée un cookie qui prend la valeur du variant de l’utilisateur et qui ne change pas tant qu’il n’est pas supprimé.
- on check si ce cookie existe avant de faire le call API
Resultats
Une fois que ces étapes sont réalisées, l’A/B Test est lancé. Il n’y a plus qu’à attendre que les résultats parlent.
Il suffit de filtrer les utilisateurs par valeurs de cookie ‘abTesting2024’ dans votre outil de visualisation des données.
Combien de temps faut il attendre avant de pouvoir conclure sur l’experience?
Pour connaître la durée de votre A/B Testing, il existe des calculateurs en ligne tels que https://speero.com/ab-test-calculator. Il vous demandera votre trafic organique, le taux de conversion et le nombre de variants de l’AB Test.
Le calcul prend aussi en compte:
- le niveau de confiance, c’est la probabilité de ne pas commettre d'erreur de type I (faux positif) s'il n'y a pas de différence de taux de conversion entre les variations comparées. C’est le niveau de confiance avec lequel on est certain de ne pas se tromper dans la décision qu’un variant est plus performant qu’un autre. La valeur minimale recommandée est de 95 %.
- la puissance statistique, c’est la probabilité de rejeter l'hypothèse nulle (par exemple l'hypothèse selon laquelle les groupes sont identiques au regard d'une variable) sachant que l'hypothèse nulle est incorrecte (en réalité les groupes sont différents). C’est donc la probabilité de ne pas voir un écart entre les variants alors qu’il y en a un.
Le calcul est ensuite fait pour déterminer les nombre de semaines qu’il vous faut pour atteindre un MDE (Minimal detectible effect) recevable.
Le Minimal Detectible Effect correspond à l’écart minimum détectable, c’est la précision que l’on veut avoir sur l’écart de taux de conversion entre deux variants.
Imaginons être dehors par une journée où la température varie légèrement, et on essaie de sentir la différence de température sans utiliser de thermomètre. Supposons que nous pouvons ressentir des changements de température, mais seulement au-delà d'une certaine différence, disons 2°C. Cela signifie que si la température change de 20°C à 21°C, on ne le sentira pas, mais si elle passe de 20°C à 22°C, on commencera à sentir une différence.
Il s’agit alors de choisir une valeur d’écart acceptable avant de conclure sur l’un ou l’autre des variants.
Une puissance statistique élevée permet alors de détecter des effets plus petits, réduisant ainsi le MDE.
Prenons un exemple:
Notre site a 10000 visiteurs par semaines, un taux de conversions de 10% et on souhaite tester 2 variants avec un niveau de confiance à 95 et une puissance statistique à 80% (recommandé).
Il faudra alors 6 semaines à cette expérience pour détecter un écart de 6% entre les taux de conversions des variants.
Conclusion
L'A/B testing via NextJS Middleware est une solution puissante pour ceux qui souhaitant expérimenter et affiner leurs applications web de manière fluide et efficace. Cette méthode permet de maintenir le caractère statique des pages tout en offrant une flexibilité et une précision optimales pour la distribution des variants.À l'avenir, l'intégration de l'intelligence artificielle et de l'apprentissage automatique pourrait encore améliorer ces tests en permettant des ajustements en temps réel et des analyses prédictives, ouvrant ainsi la voie à des optimisations encore plus personnalisées et dynamiques.
