Tests côté serveur

Les tests côté serveur consistent en des expérimentations où l'attribution et le rendu des variantes sont effectués sur le serveur avant que la réponse n'atteigne le navigateur. Le visiteur reçoit le balisage complet correspondant à la version qui lui a été attribuée, sans qu'aucun script côté client ne réécrive la page après sa réception. Cela contraste avec les tests côté client, où la page originale se charge d'abord, puis un script de test la modifie dans le navigateur.

Les avantages techniques sont considérables. Aucun scintillement n'est à déplorer, car le visiteur ne voit jamais la version originale avant l'affichage de la variante. L'exécution de JavaScript étant indépendante, les bloqueurs de publicités, les paramètres de confidentialité bloquant les scripts et les appareils lents ne faussent pas l'échantillon. Aucun script supplémentaire ne bloque le rendu, ce qui préserve la vitesse de chargement des pages et, par conséquent, n'altère pas les résultats. Plus important encore, la variante ne se limite pas aux éléments manipulables dans le DOM : les tests côté serveur peuvent modifier les prix, la logique d'inventaire, le classement dans les résultats de recherche, les modèles de recommandation, les réponses API, les règles métier et tout autre élément traité par l'application.

Les coûts sont d'ordre organisationnel plutôt que technique. Les tests côté serveur nécessitent des ressources d'ingénierie pour développer chaque variante, ce qui signifie que les expériences s'ajoutent au backlog de développement et entrent en concurrence avec d'autres tâches. Le délai entre l'idée et le test en production se mesure en sprints plutôt qu'en heures. Les équipes marketing et d'optimisation perdent l'autonomie dont elles disposent avec les éditeurs visuels, et le nombre d'expériences qu'un programme peut exécuter par trimestre est limité par la capacité d'ingénierie plutôt que par le trafic. Les organisations qui passent aux tests côté serveur sans adapter leur rythme de planification constatent généralement une chute brutale de la vitesse des expériences avant même que les gains de qualité ne soient visibles.

En pratique, les programmes matures utilisent les deux méthodes. Les tests côté client restent pertinents pour les modifications de contenu, de mise en page, de hiérarchie visuelle et de présentation pouvant être effectuées sans risque dans le navigateur et sur lesquelles les équipes marketing doivent itérer rapidement. Les tests côté serveur sont réservés à tout ce qui touche à la logique métier, à tout ce où un scintillement compromettrait le résultat, à tout ce qui se trouve sur un chemin à fort trafic où le coût en performances d'un script de test est inacceptable, et à tout ce qui doit fonctionner de manière cohérente sur le web, l'application mobile et par e-mail. Le choix de la catégorie à laquelle appartient un test relève de la conception de l'expérience et non d'une politique globale de la plateforme.

Les tests côté serveur modifient également les exigences de la couche analytique. L'attribution s'effectuant sur le serveur, l'identifiant de variante doit être transmis de manière fiable aux couches analytiques et d'entrepôt de données pour permettre l'analyse. De plus, il doit être associé systématiquement à chaque événement en aval, y compris ceux survenant plusieurs jours plus tard dans un e-mail ou une application mobile. La mise en place correcte de cette instrumentation représente généralement la partie la plus complexe de la migration ; une instrumentation incorrecte engendre des expériences dont l'attribution est techniquement valide, mais dont les résultats sont impossibles à reproduire.

Cette approche étend également l'expérimentation au-delà du site web, à des surfaces inaccessibles aux outils côté client. Les applications mobiles ne peuvent être modifiées après leur publication sans soumission à la plateforme de téléchargement ; toute expérimentation au sein de ces applications doit donc être pilotée par une configuration côté serveur. Le contenu des e-mails, les messages transactionnels, la logique de tarification, le classement dans les résultats de recherche et les modèles de recommandation sont également déterminés par le serveur. Une fois l'attribution centralisée, une même expérience peut être déployée sur le web, l'application et la messagerie avec un regroupement cohérent, permettant ainsi à une entreprise de tester l'impact d'une modification sur l'expérience client globale plutôt que sur son rendu sur un seul canal. Pour les organisations dont les clients naviguent régulièrement entre les canaux, cette cohérence n'est pas un avantage : une expérience qui attribue à un utilisateur une variante sur le site web et une autre dans l'application ne fournit aucune donnée interprétable.

Étant donné que cette transformation concerne à la fois l'architecture technique et le fonctionnement de la fonction d'optimisation, elle est généralement abordée comme un exercice conjoint. L'infrastructure est située au niveau de le développement de produits, la couche de mesure avec Analyse des données, et la conception et la priorisation des expériences avec le Service CRO Pour les organisations qui gèrent des activités commerciales à grande échelle, cette combinaison permet de tester les aspects de l'expérience qui génèrent réellement des revenus, et non seulement ceux qui sont modifiables dans un navigateur.