Test côté client Vs. Test côté serveur : les deux sont gagnants.
Publié: 2020-05-28
Lorsqu'il s'agit d'exécuter des expériences, les optimiseurs peuvent choisir entre des tests côté client et côté serveur.
Bien que vous puissiez exécuter presque tous les tests côté client côté serveur et quelques expériences backend légères via des tests côté client (en utilisant des URL fractionnées ou des expériences de redirection), cela ne sera pas aussi faisable ou robuste que vous ' j'aime… parce que, pour toute hypothèse, une seule des deux marche le mieux .
Et choisir le bon nécessite un examen attentif. Il y a de nombreux aspects à peser lors de ce choix. Examinez l'impact de la configuration sur la vitesse et le référencement, les efforts et le temps requis pour le cycle de vie de l'expérience, l'objectif de l'expérience et plus encore.
Passons en revue ces facteurs et voyons en quoi les tests côté client diffèrent des tests côté serveur, ainsi que les avantages et les inconvénients de chacun.
Test côté client Vs. Test côté serveur
Quelle est la différence entre les tests côté client et les tests côté serveur ?
Dans les tests côté client, une fois qu'un utilisateur demande une page, votre serveur la livre. MAIS, dans ce cas, votre outil d'expérimentation implémente du Javascript dans le navigateur de votre utilisateur pour modifier le contenu fourni par le serveur afin que l'utilisateur final obtienne la variation appropriée en fonction de vos règles de ciblage. (Le navigateur est le « client ».)
Dans les tests côté serveur, en revanche, une fois qu'un utilisateur demande une page, votre serveur détermine la version à fournir et la fournit exactement. Votre outil d'expérimentation fonctionne sur le serveur et non dans le navigateur de votre utilisateur.
Étant donné que les tests côté client ne se produisent qu'avec l'exécution JS au niveau du navigateur, vous ne pouvez tester que des éléments au niveau de la surface tels que les mises en page, les couleurs et la messagerie. Certains optimiseurs qualifient ces tests de tests « cosmétiques ».
Cependant, cela reviendrait à escompter les tests côté client.
Les tests côté client peuvent sembler simples, mais ils sont puissants.
Il est facile de rejeter les tests A/B côté client comme étant les « tests faciles » que tout le monde peut faire. D'accord: c'est facile à mettre en œuvre. Et parfois, cela peut être aussi simple que de tester une couleur ou une copie différente du bouton CTA.
Mais qu'il s'agisse de cela ou de quelque chose d'aussi important que de tester une refonte ou une page remaniée, les tests côté client ont un impact sur les résultats d'une entreprise .
Qu'est-ce que le test côté client ?
En un mot : les tests côté client signifient que l'optimisation a lieu au niveau du navigateur. En fonction des règles de ciblage que vous avez définies, le navigateur du visiteur modifiera le contenu pour fournir la version souhaitée.
Dans cette étude de cas, une entreprise SaaS a utilisé Convert Experiences comme outil de test A/B côté client pour augmenter la croissance des prospects de 61 % sur sa page d'accueil :
Voici une autre expérience de test A/B utilisant Convert Experiences comme outil de test côté client pour la même société SaaS sur sa page de tarification qui a conduit à une augmentation de 57 % des prospects :
La plupart des histoires de réussite d'optimisation de conversion que vous voyez en ligne sont des tests côté client qui ont réussi à optimiser une expérience au niveau de la surface et à gagner gros.
Mais les tests côté serveur vous permettent en effet de tester davantage.
Lorsque vous avez besoin de tester plus profondément que le frontend, vous devez opter pour des tests côté serveur.
Qu'est-ce que le test côté serveur ?
Les tests côté serveur sont un type d'expérience où le serveur Web détermine la version du contenu à diffuser. Dans les tests côté serveur, toute l'optimisation est mise en œuvre directement dans les serveurs plutôt que dans les navigateurs des visiteurs.
Mettons cela en perspective avec quelques scénarios.
Si vous étiez une entreprise de commerce électronique, vous pourriez utiliser une expérience de test A/B côté client pour savoir si une barre de recherche repensée pourrait augmenter vos recherches en magasin (et entraîner plus de ventes).
Mais si vous vouliez tester un nouvel algorithme de recherche qui pourrait apporter des résultats de recherche plus pertinents (et qui, à long terme, entraînerait plus de ventes), vous auriez besoin d'exécuter une expérience de test A/B côté serveur. .
Si vous étiez plutôt une entreprise B2B SaaS, vous seriez en mesure d'effectuer une expérience côté client pour déterminer si un certain UVP fonctionne mieux sur votre page d'accueil. Ou si une version longue pouvait battre une version abrégée.
Mais si vous vouliez tester un backend plus rapide et voir s'il pouvait améliorer la rétention ou l'engagement, vous auriez besoin d'exécuter une expérience côté serveur. Si vous vouliez tester une nouvelle séquence d'intégration, encore une fois, vous devrez opter pour une expérience côté serveur. Parce qu'en plus de prendre en charge votre nouveau flux de travail d'intégration, les tests côté serveur vous permettraient également d'orchestrer une expérience multicanal couvrant les e-mails, les SMS et autres qui se déroulent sur différents appareils.
De même, si vous étiez une entreprise B2C SaaS, vous seriez en mesure d'effectuer une expérience côté client pour savoir si un certain plan tarifaire pourrait mieux fonctionner que les autres.
Cependant, si vous vouliez tester un meilleur moteur de recommandation, vous devriez opter pour des tests côté serveur.
Comme vous pouvez le comprendre à partir des différents cas d'utilisation des tests côté serveur, ils sont davantage axés sur la création de meilleurs produits plutôt que sur l'obtention de conversions immédiates. Contrairement aux expériences côté client qui se concentrent sur les ventes ou les conversions immédiates, les expériences côté serveur se concentrent sur l'optimisation du produit ou de la solution afin que la valeur client à vie augmente.
On pourrait dire que si les tests côté client sont destinés aux spécialistes du marketing, les tests côté serveur sont principalement destinés aux équipes de produits et d'ingénierie. Et les outils de test A/B comme Convert Experiences offrent des tests côté client et côté serveur pour répondre aux besoins des équipes marketing et d'ingénierie.
Essayez-le gratuitement pendant 15 jours !
Étant donné que tester des modifications aussi profondes au niveau du produit nécessite beaucoup plus qu'une simple manipulation JS basée sur un navigateur, cela ne peut pas se produire à l'intérieur du navigateur et doit être abordé au niveau du serveur.
Alors que les tests côté serveur ont leurs cas d'utilisation uniques, certaines entreprises l'utilisent même pour exécuter des tests cosmétiques - des tests qui s'exécuteraient parfaitement sans problème, même côté client.
Ils le font souvent pour éviter le « scintillement » ou le phénomène « Flash of Original Content ». Le scintillement se produit lorsque l'outil d'expérimentation modifie le contenu original servi par le serveur après que les utilisateurs finaux l'ont déjà vu. Imaginez que vos utilisateurs voient un certain titre, puis le voient passer en un éclair à un autre. (Oui, le scintillement peut sérieusement compromettre l'expérience d'un utilisateur !)
À d'autres moments, ils le font pour améliorer la vitesse. Bien que les tests ne ralentissent pas un site Web ou ne causent pas de graves problèmes de performances, ils ajoutent une seconde ou deux à l'expérience de chargement perçue d'un site Web. Le côté serveur peut rendre cela plus rapide.
Parfois, une entreprise peut exécuter une expérience côté serveur à la place d'une expérience côté client en raison de problèmes de confidentialité ou de sécurité. Comme le ciblage de l'audience se produit sur le serveur et que le code d'expérimentation réside sur le serveur lors des tests côté serveur, les entreprises obtiennent un meilleur contrôle sur ses aspects de confidentialité et de sécurité.
Mais la mise en œuvre d'une expérience côté serveur n'est pas toujours réalisable, en particulier lorsqu'un côté client ferait tout aussi bien.
Implémentation d'expériences côté serveur
Dans les tests côté client, vous n'avez besoin que de ressources de conception et de développement limitées pour créer vos expériences et les exécuter. Vous n'en aurez même pas besoin si vous ne modifiez que du texte ou changez la couleur d'un bouton. Tout ce que vous auriez à faire est de :
1. Connectez-vous à un outil comme Convert.
2. Utilisez l'éditeur WYSIWYG et créez les variantes.
3. Configurez l'expérience (définissez les conditions de ciblage de l'audience, la durée de l'expérience, la taille et la répartition de l'échantillon, le niveau de confiance, etc.)
Saisissez le code JS et ajoutez-le à votre site Web.
Et.. Voila.
Vous chercheriez alors une aide au développement pour déployer la version gagnante si le contrôle venait à perdre.
Les tests côté serveur, cependant, ne sont pas si simples.
Ici, vous devrez :
1. Créez votre expérience dans Convert Experiences
2. Développez et déployez toutes les variantes de votre expérience sur votre serveur.
3. Mappez vos expériences déployées sur le serveur dans Convert Experiences à l'aide d'un code personnalisé (en utilisant l'identifiant de votre expérience, les identifiants des variantes définis dans votre outil d'expérimentation, etc.).
Dans de telles expériences côté serveur, votre code doit indiquer au serveur quelle variante montrer à un utilisateur actuel. Vous pouvez utiliser des cookies pour faciliter cela. Par exemple, pour implémenter un test côté serveur A/B avec Convert, vous devrez configurer un cookie avec les données suivantes :
Le serveur lira alors votre cookie et
servir une version (et toutes les sessions suivantes) en conséquence.
Étant donné que votre serveur détermine la version à envoyer à un utilisateur, le ciblage se produit au niveau du serveur (et non à l'intérieur du navigateur comme avec les tests côté client). La précision de vos tests dépendra de votre capacité à coder vos conditions de ciblage sur votre serveur. Avec les tests côté client, vous pouvez cibler votre public au laser pour toutes vos expériences.
De plus, les tests côté serveur peuvent devenir plus complexes dans une configuration multi-serveurs et également lorsqu'un CDN doit être intégré.
4. Exécutez l'expérience.
5. Déployez la version gagnante et faites reculer les perdants.
Vous devrez peut-être également nettoyer vos serveurs, publier le déploiement/la restauration finale.
Comme vous pouvez le voir, le cycle de vie d'une expérience côté serveur est long et complexe contrairement à celui côté client. C'est pourquoi les tests côté serveur nécessitent une certaine réflexion.
En général, vous n'exécuteriez pas une expérience côté serveur si une expérience côté client le faisait…
Exécuter ne serait-ce qu'une seule expérience côté serveur est un défi, car son développement et son déploiement sont un processus plus gourmand en ressources et en temps.
De plus, si vous utilisez des tests côté serveur pour tester des modifications qui peuvent être facilement validées côté client, il sera difficile d'atteindre une bonne vitesse de test et un programme d'expérimentation robuste.
De plus, pour de telles expériences, opter pour une expérimentation côté serveur lorsque vous disposez de quelques excellents outils de test A/B côté client qui vous permettent de les exécuter sans scintillement sans affecter votre référencement ou votre vitesse ne promet pas la meilleure utilisation de vos tests. bande passante.
Les expériences côté serveur ne doivent être préférées que lorsqu'elles étayent solidement l'hypothèse donnée. Et ils le font plusieurs fois, car de nombreuses expériences qui ont un impact sur les résultats d'une entreprise ne peuvent se produire que du côté serveur.
Alors dites-nous… avez-vous effectué des tests côté serveur ? Si oui, quelle a été la partie la plus difficile du processus ? Oh, et si vous souhaitez exécuter un test A/B côté serveur, consultez Convert (c'est gratuit pendant 15 jours !)
