Meilleures pratiques pour exécuter des tests A/B sur des applications à page unique (SPA)

Cet article fait partie de la deuxième partie de la série Tests A/B sur les applications à page unique .

Dans la partie 1, nous avons présenté le concept d'application à page unique (SPA), montré pourquoi il gagne en popularité et examiné 10 des meilleures plates-formes de test A/B que vous pouvez utiliser sur des applications à page unique .

Mais exécuter des tests A/B sur des SPA peut être un peu délicat en raison de leur mode de fonctionnement. Dans cet article, nous vous donnerons des conseils pratiques sur la façon d'exécuter une expérience sur un SPA et quelques bonnes pratiques à suivre.

L'évolution des frameworks SPA

Les SPA ne sont pas un nouveau concept.

Un brevet de 2002 décrit une technologie similaire à la version contemporaine de SPA.

Cependant, la technique AJAX, utilisée comme standard réseau depuis 2006, a facilité sa mise en œuvre. Il s'agit d'un ensemble de stratégies permettant de créer des applications Web asynchrones à l'aide de diverses technologies côté client. Le logiciel peut envoyer et recevoir des données du serveur en arrière-plan grâce à AJAX, sans altérer l'état actuel de la page ni le mode d'affichage du contenu, et donc sans interférer avec l'expérience de l'utilisateur.

L'introduction d'AJAX, d'autre part, n'a pas été un moment décisif dans l'adoption de SPA.

La montée en popularité des SPA fait partie d'une tendance plus large qui a été alimentée par la croissance rapide du front-end et la pertinence croissante de l'UX ces dernières années.

Les SPA ont d'abord été créés à l'aide d'applets Java ou de programmes Flash, ainsi que des bibliothèques "pures" JavaScript ou jQuery.

Cependant, des frameworks frontaux comme Angular.js, React.js et Vue.js - qui sont tous des frameworks JavaScript relativement nouveaux - ont aidé leur développement.

Quelles sont les technologies derrière une architecture SPA ?

Un SPA est essentiellement un framework JavaScript prenant en charge HTML5 et CSS3.

Cependant, en utilisant ces composants, quelques bibliothèques et frameworks distincts ont émergé et ont été adoptés dans le monde du développement :

1. Angulaire

Développé par Google, Angular est le plus mature et le plus ancien des 3 frameworks avec une documentation détaillée à utiliser mais une courbe d'apprentissage abrupte.

Il est intégré à une architecture originale de Model View Controller (MVC) mais utilise principalement un MVVM (Model-View-ViewModel) qui permet à plusieurs développeurs de travailler séparément sur la même section d'application. Il peut y avoir des problèmes de migration avec la mise à jour vers de nouvelles versions, mais Angular est le plus fiable lors de la mise à l'échelle et est idéal pour les grands projets complexes.

Grâce à TypeScript, Angular est un choix fantastique pour les grandes équipes de développeurs, et certaines entreprises utilisent déjà cette technologie dans leurs autres produits.

Sur GitHub, c'est un framework établi, mature, avec un grand nombre de contributeurs.

Google et ses produits tels que Google Drive et Gmail, ainsi que Wix, font partie des utilisateurs d'Angular pour les SPA.

2. React.js

React a été développé par Facebook et rendu open source. Il était principalement utilisé pour créer des interfaces utilisateur (Facebook, WhatsApp et Instagram).

Il est très populaire en raison de sa taille de code légère et de sa capacité à s'intégrer de manière transparente à d'autres frameworks. Il dispose également d'une méthode simple pour migrer entre les versions. (Généralement une migration en un clic).

Il est fréquemment utilisé en conjonction avec Redux pour gérer l'état des composants de l'application. Uber utilise également la technologie React.js dans ses produits.

React convient parfaitement à ceux qui débutent avec les frameworks frontaux JavaScript, ainsi qu'aux start-ups et aux développeurs agiles. De plus, cette bibliothèque JavaScript offre de précieuses options d'intégration avec une variété d'autres frameworks et technologies, ce qui est vraiment utile lorsque vous travaillez sur un projet avec un grand environnement. De tous les frameworks SPA, React a le plus de contributions sur GitHub, ce qui aide les développeurs à résoudre les problèmes potentiels.

Il a la courbe d'apprentissage la plus facile des 3 cadres et est mieux utilisé pour les projets avec un court délai qui nécessitent beaucoup d'évolutivité.

3. Vue.js

Vue.js n'appartient pas à une grande entreprise comme Facebook ou Google, mais il continue de s'accélérer avec de nouveaux utilisateurs, en particulier en Asie. C'est le plus récent des frameworks SPA ci-dessus, ayant été fondé en 2014 par Evan You, un ancien employé de Google. Une grande partie de la documentation est généralement en chinois, mais il existe encore des sources de formation.

Le framework est très léger et permet de créer simplement des applications performantes.

Pour la plupart des développeurs, il n'y a pas de problèmes majeurs avec la création dans l'un de ces frameworks, la décision se résume vraiment aux principales fonctionnalités de chacun.

Vue.js est désormais utilisé par des entreprises telles que Baidu, GitLab et Alibaba pour leurs besoins.

Comment fonctionnent les applications à page unique

Les SPA ont une conception simple. Des technologies de rendu côté client et côté serveur sont utilisées.

Sur un site Web non SPA, lorsque vous entrez une URL dans votre navigateur, le navigateur envoie la demande à un serveur et reçoit une page HTML en réponse.

Sur un site SPA, le serveur ne délivre que le document HTML sur la requête initiale et les données JSON sur les requêtes suivantes. Cela indique qu'un SPA réécrira le contenu de la page actuelle plutôt que de recharger l'intégralité du site Web.

En un mot, un SPA fonctionne comme ceci :

1. Le client établit d'abord une connexion avec le serveur et obtient le contenu de la page, qui se compose principalement de code HTML, de CSS et d'un ensemble JavaScript comprenant tous les scripts nécessaires à l'exécution de la logique d'application.
2. L'action d'un utilisateur active l'exécution du ou des JavaScript(s) pertinent(s), qui envoient ensuite des requêtes AJAX au serveur. Les données sont généralement au format JSON et ne nécessitent pas une actualisation complète de la page Web.

Au lieu de la technique normale d'un navigateur qui lance une toute nouvelle page, une application à page unique interagit avec les utilisateurs en modifiant avec force les pages Web existantes avec de nouvelles données provenant du serveur Web. Le navigateur récupère le code HTML, JavaScript et CSS nécessaire, ou d'autres ressources appropriées, et les ajoute aux pages selon les besoins.

Bien que l'API d'historique HTML5 ou le hachage de localisation puissent être utilisés pour fournir la navigabilité et la perception de différentes pages logiques dans l'application Web, la page ne se recharge à aucun moment pendant la procédure et ne transfère pas le contrôle à une autre page.

Si vous souhaitez voir un exemple d'application à page unique en action, accédez à ce lien et cliquez sur la page principale, la liste des cours les plus récents et le menu supérieur. Lorsque vous faites cela, vous remarquerez que la page ne se recharge pas complètement, seules les nouvelles données sont envoyées sur le fil lorsque l'utilisateur se déplace dans l'application.

Ceci est un exemple de SPA.

A qui s'adressent les SPA les plus adaptés ?

En raison des avantages des SPA, ils sont maintenant la solution préférée dans de nombreuses circonstances.

Ils excellent dans les projets impliquant une variété de technologies Web, où les performances et une expérience utilisateur agréable sont plus importantes que le contenu.

De nombreux grands acteurs utilisent les SPA. Facebook, Gmail, Google Maps, Netflix et Paypal sont quelques-uns des exemples les plus marquants de ce type de technologie (voir ci-dessous).

Pourquoi les tests A/B sont-ils difficiles sur les SPA ?

Les trois frameworks - React.js, Angular.js et Vue.js - sont très populaires parmi les développeurs JavaScript car ils permettent le développement d'interfaces utilisateur sophistiquées qui créent de meilleures expériences utilisateur et des taux de conversion plus élevés.

Ils sont très recherchés par les développeurs car

• L'actualisation de la page n'est pas nécessaire
• Les vitesses de chargement des pages sont plus rapides
• Les interactions sont riches et fluides
• Les transferts de données sont réduits
• Les pièces réutilisables permettent un développement plus rapide
• La communauté des développeurs est bien établie

Ils sont également la ressource incontournable pour quiconque démarre un nouveau SPA.

Cependant, il y a un inconvénient majeur : en raison du fonctionnement de ces frameworks, les outils de test A/B côté client ont du mal à fonctionner correctement .

Lorsqu'une personne parcourt une page Web sur un SPA, la page, y compris l'URL, n'est pas actualisée . Le statut de la page varie avec chaque interaction de l'utilisateur (par exemple, les différents éléments visibles à l'écran).

Étant donné que les outils de test A/B n'effectuent normalement des ajustements qu'une seule fois lors du chargement initial de la page, ces interactions ultérieures ne sont pas prises en compte.

Voici deux scénarios courants :

1. Si les pages vues sont activées sur votre SPA, vous recevrez une page vue lorsque quelqu'un visite une URL, mais pas une seconde s'il navigue sur une autre page où les pages vues sont activées. Cela est dû au fait que le matériel est chargé dans la page actuelle plutôt que dans une nouvelle page.
2. Si vous essayez de limiter un événement à une URL spécifique , vous rencontrerez le même problème. L'outil de test A/B "croira" qu'il reste sur la même page sur laquelle il a été chargé pour la première fois, même si l'utilisateur pense qu'il se trouve sur une page différente. Étant donné que les éléments sont déplacés vers et hors du site, il peut être difficile de surveiller les clics ou d'autres événements.

Pour rendre les expériences, les logiciels de test A/B côté client et les plates-formes de personnalisation s'appuient sur des chargements de page complets.

Parce que ce concept est absent lors de l'utilisation de frameworks SPA comme React, Angular ou Vue, déterminer si un nouveau contenu a été ajouté à la page ou si le statut du contenu existant a changé - et, plus important encore, quand injecter du contenu personnalisé - devient plus difficile.

Les outils de test A/B doivent donc être capables de reconnaître le contexte du visiteur, par exemple s'il est arrivé sur une page de liste de produits, de détails ou de panier, et à quel moment du nouveau matériel doit être fourni.

Cela signifie que l'équipe technique doit constamment rester au courant de l'évolution des composants modulaires React SPA ou Angular SPA, ainsi que mettre à jour les expériences influençant ces composants en temps réel.

Chaque interaction de l'utilisateur dans React.js, par exemple, entraîne l'actualisation d'un ou plusieurs éléments de l'interface utilisateur, supprimant toutes les modifications apportées par la solution de test A/B.

Test côté client vs test côté serveur sur les SPA

En ce qui concerne les tests A/B sur un SPA, il existe deux options :

1. Isoler les différents « états » de l'application que vous souhaitez tester, puis les configurer de sorte que lorsque chaque « état » est affiché, une API est appelée pour effectuer les modifications appropriées. C'est ce qu'on appelle l'activation conditionnelle et elle est effectuée côté client .

Quelques exemples d'"états" incluent l'affichage d'un formulaire d'abonnement, le chargement d'une liste de résultats de recherche, etc.

2. Codage en dur des modifications, côté serveur , ou un déploiement personnalisé pour chaque nouvelle expérience.

Ces deux options sont influencées par le framework SPA utilisé. Donc, comme vous l'avez peut-être deviné, ils nécessitent beaucoup de coopération entre l'équipe technique et les spécialistes du marketing pour continuer à bien fonctionner.

Passons maintenant en revue ces deux options et voyons ce que les équipes doivent faire pour réussir.

Activation conditionnelle côté client

Si vous devez encore effectuer des tests côté client sur une application SPA, il existe une solution de contournement.

Pour s'assurer que les scripts de test ne sont exécutés que lorsque l'application atteint l'état souhaité, les développeurs Web peuvent utiliser une fonctionnalité appelée mode d'activation conditionnelle .

Si vous n'êtes pas familier avec l'activation conditionnelle, c'est un concept simple à comprendre.

L'activation conditionnelle, en substance, vous donne la possibilité de définir quand une expérience doit être activée autrement que par sa méthode standard de le faire lors d'une actualisation de page.

Cela peut être accompli en écrivant un peu de JavaScript. Il y a deux façons de le faire.

1. La fonction d'interrogation

La fonction d'interrogation est le moyen le plus simple d'utiliser l'activation conditionnelle. La fonction scanne la page toutes les 50 ms jusqu'à ce qu'un élément spécifié apparaisse - il peut s'agir d'un modal, d'un div ou même de la page entière.

L'expérience commence lorsque l'élément apparaît.

La plateforme de test A/B génère quelques lignes de JavaScript que vous pouvez modifier en fonction de l'élément que vous souhaitez que la fonction d'interrogation recherche.

L'expérience est activée une fois que la fonction est évaluée à TRUE .

2. La fonction de rappel

L'exécution de la fonction de rappel est similaire à celle de la fonction d'interrogation, mais elle ajoute une certaine flexibilité.

Cette fonction vous permet d'entrer n'importe quelle condition JavaScript de votre choix et, si elle est évaluée à TRUE , de démarrer l'expérience.

Alors que la fonction d'interrogation envoie constamment un ping à la page pour voir si un élément spécifié est présent, la fonction de rappel est plus passive et s'appuie sur un gestionnaire d'événements.

Test côté serveur

Lorsque vous effectuez des tests côté serveur, aucune modification n'est apportée au niveau du navigateur. Au lieu de cela, les paramètres de variation de l'expérience ("L'utilisateur 1 voit la variation A") sont déterminés au niveau du serveur et directement connectés à l'application JavaScript via un fournisseur de services, ce qui facilite le test de contenu dynamique plus complexe qui s'étend au-delà des limites d'un statique l'interface utilisateur du site Web.

Prenez, par exemple, les applications de médias sociaux qui sont pour la plupart des SPA. Bien que les tests côté client frontal puissent être utilisés pour les expérimenter, ils sont beaucoup plus compliqués en raison du contenu dynamique impliqué, donc le passage aux tests côté serveur rend le processus beaucoup plus facile.

Exemples de tests A/B sur les SPA

Quelles sont les instances réelles de tests A/B sur des applications d'une seule page que vous pourriez rencontrer ?

Modification d'une image sur une page de destination

Supposons que vous deviez définir une expérience sur un SPA pour montrer une image dynamique à 50 % de l'audience qui a atterri sur une page spécifique. Le framework SPA utilisé dans cet exemple est React.js, ce qui signifie que la page change et que les images sont remplacées régulièrement.

Si vous affichez l'image variante, des problèmes de scintillement peuvent survenir, ce qui signifie qu'une séquence image originale-image variante-image originale sera observée.

Ce problème peut être entièrement évité en déclenchant l'interrogation lors du chargement de la page de destination spécifique.

Tester une copie supplémentaire sous le CTA

Une autre expérience sur un site SPA construit avec Angular.js peut impliquer de montrer une ligne de texte supplémentaire sous le CTA principal à 30 % du public cible.

Dans cet exemple, la version A affichera la ligne de texte supplémentaire sous le CTA principal, contrairement à la version B. Nous allons envoyer 30 % de notre trafic vers la version A et 70 % vers la version B, puis comparer les résultats pour voir s'il existe une différence significative dans les taux de conversion.

Étant donné que le site Web est construit avec Angular.js, les éléments sont modifiés régulièrement. L'événement de rappel ici peut nous aider à afficher les modifications apportées à la variante.

Affichage d'un bon cadeau

Dans cet exemple, supposons que lorsqu'un utilisateur ajoute un produit d'une marque premium à son panier, nous souhaitons qu'un bon cadeau exclusif s'affiche. À condition que lorsque l'utilisateur supprime le produit premium du panier, le bon soit glissé hors de la page.

1. Ce qui doit se passer ici, c'est que lorsqu'un utilisateur effectue l'action requise, un événement d'activation manuelle doit être envoyé. L'expérience sera activée à la suite de cet événement.
2. Un événement d'activation doit être déclenché lorsque l'utilisateur supprime le produit premium du panier, ce qui désactive l'expérience.
3. L'expérience doit être réactivée pour montrer le produit premium si le consommateur l'ajoute à nouveau.

Affichage du slogan sous l'incitation à l'action "Acheter maintenant"

Si vous souhaitez afficher un slogan unique sous un bouton CTA "Acheter maintenant", vous pouvez activer l'expérience si vous poussez un événement d'activation sur le changement d'historique.

En effet, la page contenant le bouton CTA "Acheter maintenant" ne se chargera pas au début.

Comment Convert a contourné le problème des tests sur les SPA

Les expériences sur les SPA doivent être traitées différemment des autres expériences. Étant donné que le script Convert ne peut pas lire l'URL sur laquelle un visiteur de site Web navigue, il ne peut pas déclencher d'expériences avec des méthodes standard.

Alors, voici comment c'est fait à la place.

Commencez par installer le code de suivi Convert comme décrit dans cet article.

Ensuite, appliquez l'une des 3 méthodes ci-dessous :

1. Déclenchement de l'interrogation

Comme mentionné, l'interrogation est le processus par lequel les conditions d'expérience sont testées pour déterminer si ladite expérience doit être déclenchée.

Cela inclut la surveillance de l'URL du visiteur, des conditions d'audience ou des conditions JavaScript pour exécuter le test.

L'interrogation est généralement déclenchée par Convert lorsqu'une nouvelle page est chargée. Sur les SPA, généralement, aucune nouvelle page n'est chargée sur l'application Web.

Dans ce cas, vous auriez besoin du code suivant pour lancer l'interrogation :

 fenêtre._conv_q = _conv_q || [] ;
window._conv_q.push(["run","true"]);

Vous devez déterminer quel serait le meilleur événement sur votre SPA pour déclencher le code ci-dessus. Exemple de code à ajouter dans la section Project Settings > Global Project JavaScript.

 console.log('SPA/Convertir le code dans le projet global Javascript exécuté');
si (!window.globalExecutedTs) {
window.globalExecutedTs = true ;
var oldPushState = window.history.pushState ;
window.history.pushState = fonction (données) {
essayer {
setTimeout(fonction() {
return oldPushState.apply(this, arguments);
console.log('conversion activée depuis pushstate');
fenêtre._conv_q = _conv_q || [] ;
window._conv_q.push(["exécuter", "vrai"]);
}, 0);
} attrape (e) {
console.log(e);
}
} ;
window.onpopstate = fonction (événement) {
setTimeout(fonction() {
console.log('conversion activée depuis popstate');
fenêtre._conv_q = _conv_q || [] ;
window._conv_q.push(["exécuter", "vrai"]);
}, 0);
} ;
}

2. Utilisez les conditions JavaScript dans la zone du site

Étant donné que le script Convert ne peut pas lire les modifications d'URL dans un SPA, vous devez utiliser une condition JavaScript au lieu d'une condition de correspondance d'URL pour déclencher une expérience.

Trouvez une explication détaillée de la façon de procéder dans l'article suivant.

3. Activer manuellement une expérience

Vous pouvez déclencher des expériences manuellement après avoir déterminé qu'un certain flux s'est produit. En utilisant cette méthode, la zone du site et les conditions d'audience seront toujours testées après le déclenchement de l'interrogation avec le code. Consultez cet article pour obtenir des informations plus détaillées sur l'activation manuelle d'une expérience.

Avec les 3 méthodes ci-dessus, vous devriez pouvoir déclencher des expériences au bon moment dans une application SPA.

Convert augmente-t-il le risque de scintillement sur les SPA ?

Réponse courte, non.

Tous les frameworks SPA sont compatibles avec la technologie anti-scintillement de Convert. Convert tire parti de la technologie SmartInsert ^TM en arrière-plan pour s'assurer que les modifications d'expérience sont appliquées ou réappliquées au moment approprié sur votre SPA, même pendant les rechargements de page dynamiques.

Nous vous recommandons de lire notre livre blanc sur l'effet de scintillement pour en savoir plus à ce sujet et pourquoi vous devriez l'éviter à tout prix.

Problèmes courants lors des tests A/B sur des sites d'application à page unique

Comme vous pouvez le voir, il y a quelques points à garder à l'esprit lors de l'exécution de tests sur des sites SPA. Une fois que vous avez couvert le cadre utilisé, la méthode de test de l'outil et l'événement déclencheur, le problème principal est généralement que l'élément de test ne se recharge pas lorsqu'une nouvelle page ou vue est affichée sur le navigateur.

Cela peut être causé par plusieurs choses :

1. Tester les modifications apparaissant sur la vue de la première page mais pas sur les suivantes

Parfois, le changement que vous souhaitez afficher ne s'affiche que sur la première page que vous chargez sur votre navigateur, mais pas sur les vues suivantes. En effet, la partie du script Convert qui évalue les expériences et les active ne s'exécute pas lors de l'accès à une nouvelle vue ou "page" du site.

2. Les modifications apparaissant sur l'éditeur visuel n'apparaissent pas lors de leur prévisualisation à l'extérieur

Il peut parfois arriver que les modifications apportées avec l'éditeur visuel ne s'affichent pas en dehors de l'aperçu de l'éditeur.

La plupart des frameworks SPA n'utilisent pas l'API DOM et utilisent à la place leurs propres méthodes pour déployer les modifications sur la page. Cela entraîne la désynchronisation du DOM lorsqu'il est mis à jour par le SPA. Ceci est courant dans React et Angular, ce qui empêche les sélecteurs CSS trouvés dans le code Jquery de fonctionner.

3. Les modifications continuent d'apparaître sur les "vues" suivantes

Dans ce scénario, une modification de test s'affiche dans la vue (page) appropriée. Mais, lors de la visite de nouvelles (pages) vues, le changement ne disparaît pas. Cela se produit car sur un site SPA, les modifications ne sont pas supprimées lors du rechargement d'une nouvelle page.

Le script Convert supprime le code ajouté lorsque les conditions de l'expérience ne correspondent pas à la vue suivante dans laquelle les modifications ont été déployées lors de l'appel de l'interrogation. Cependant, cela ne suffit pas car les modifications de jquery ne disparaîtront pas même lors de la suppression du code de test de la page.

Vous devrez exécuter du code qui annule les modifications apportées par l'expérience.

À vous de jouer : évitez ces erreurs lors de l'optimisation de votre SPA

En raison des progrès dans la manière dont les informations sont traitées et fournies, les SPA peuvent devenir plus communément acceptés, mais il est crucial de noter que cette nouvelle technologie a des problèmes lors de l'intégration avec des plates-formes d'optimisation et d'expérimentation, qui fonctionnent normalement avec des configurations plus classiques.

Nous espérons que cet article a couvert les différentes composantes des SPA ainsi que certaines solutions pour surmonter ces obstacles dans votre quête pour offrir aux visiteurs des expériences numériques plus rapides, plus intuitives et personnalisées.

Cependant, vous feriez mieux de travailler avec un fournisseur de solutions qui peut fournir une prise en charge transparente des SPA, comme la capacité de détecter les changements dans les composants de l'interface utilisateur et les types de page pour une personnalisation dynamique sans modifier le code source. Comme celui dans l'encadré ci-dessous.