Un guide pratique de Tests A/B côté serveur avec Deno et

Ce guide explique Tests A/B côté serveur avec Deno et de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

Les tests A/B côté serveur choisissent la variante avant le rendu de la page. Cela en fait un bon choix pour Deno Fresh, qui est d'abord serveur et envoie du JavaScript uniquement pour les îles interactives. La documentation sur l'architecture de Fresh décrit les pages telles que rendues sur le serveur avec uniquement des îlots hydratés sur le client. Voir la documentation Fresh sur architecture.

Cette approche évite le problème de test classique client-side : une page se charge, un script de test s'exécute et l'utilisateur voit un scintillement lorsque la variante change.

Que tester côté serveur

Les bons tests server-side incluent :

• Mise en page des tarifs.
• Longueur du formulaire d'inscription.
• Copie de héros.
• placement CTA.
• Structure de navigation.
• Ordre des étapes de paiement.
• Parcours d'intégration.

Évitez de tester de petites modifications, sauf si vous avez un volume élevé. Pour les sites à faible trafic, testez les différences significatives ou utilisez la recherche qualitative au lieu de prétendre que de petits changements de couleur produiront des conclusions fiables.

Stratégie d'affectation

Vous avez besoin d’une affectation de variantes cohérente. Possibilités :

1. Cookie anonyme de courte durée.
2. Session côté serveur.
3. Compte authentifié ID.
4. Hachage déterministe d'un first-party ID stable.

Pour un site Web public, un cookie first-party de courte durée est simple, mais il peut néanmoins soulever des questions de consentement en fonction de la juridiction et de l'objectif. Si vous souhaitez éviter complètement les cookies, attribuez par demande des tests de contenu à faibles enjeux, mais comprenez que les visiteurs peuvent voir différentes variantes au fil des visites.

Pour les expériences de produits authentifiées, utilisez l'attribution au niveau du compte ou de l'utilisateur dans le cadre de votre gouvernance d'analyse de produits, et non des analyses de marketing publiques.

Fresh Forme d'implémentation

Le middleware Fresh peut s'exécuter avant une route et transmettre l'état via le contexte de la demande. La documentation Fresh explique que le middleware reçoit un contexte avec la requête et renvoie une réponse, et que le routage du système de fichiers peut définir le middleware dans les fichiers _middleware.ts. Voir Fresh documentation middleware.

Un flux typique :

1. Le middleware vérifie si la demande est éligible à l'expérimentation.
2. Il lit une affectation de variante existante si elle est présente.
3. En cas d'absence, il attribue une variante en utilisant une méthode aléatoire stable.
4. Il stocke la mission dans un cookie ou une session serveur de courte durée.
5. Il transmet le nom_expérience et la variante au contexte de route.
6. L'itinéraire restitue immédiatement la version correcte.
7. Un événement d'exposition est enregistré une fois par session ou mission.
8. Les événements de conversion incluent les mêmes métadonnées de test.

Conception d'événements respectueux de la confidentialité

Envoyez des métadonnées de test, pas d'identité :

Event: experiment_exposed
Properties:
- experiment_name = pricing_page_layout
- variant = compact
- page_template = pricing
 
Événement : demo_requested
Propriétés :
- nom_expérience = pricing_page_layout
- variante = compacte
- form_type = démo

N'envoyez pas d'e-mail, de nom, de société, d'utilisateur ID, d'adresse IP ou de contenu de formulaire en texte libre à l'analyse du site Web.

Évitez de compter les rechargements comme des expositions

Une exposition devrait signifier que le visiteur a eu une réelle chance de voir la variante. Si vous déclenchez un événement à chaque rendu du serveur, les rechargements augmentent le nombre.

Meilleures options :

• Définir un indicateur d'exposition au niveau de la session.
• Exposition au feu une seule fois par mission d'expérimentation.
• Suivez page_view normalement et gardez experimental_exposed séparé.
• Excluez les robots et les demandes de prélecture lorsque cela est possible.

Résultats de mesure

Pour chaque variante, comparez :

• Expositions.
• Nombre de conversions.
• Taux de conversion.
• Progression de l'entonnoir.
• Mélange d'appareils.
• Mélange de sources.
• Mesures de garde-fou telles que les erreurs de formulaire ou le rebond.

N'utilisez pas uniquement le nombre de conversions brut. Une variante avec plus de conversions peut simplement avoir reçu plus de trafic ou un meilleur mix de sources.

Mises en garde statistiques

Les tests A/B nécessitent suffisamment de volume. Si chaque variante compte quelques dizaines de visiteurs, les analyses peuvent toujours indiquer une direction, mais elles ne peuvent pas prouver grand-chose. Décidez à l'avance :

-Conversion primaire.

• Durée d'exécution minimale.
• Taille minimale de l'échantillon ou seuil pratique.
• Segments à surveiller.
• Métriques de garde-corps.
• Règle d'arrêt.

Évitez de jeter un coup d’œil quotidiennement et de déclarer un gagnant lorsque le graphique semble passionnant.

Pourquoi le côté serveur s'adapte aux analyses axées sur la confidentialité

Les outils de test côté client ajoutent souvent des scripts, des cookies, des requêtes third-party et un scintillement visuel. Une configuration server-side peut être plus petite :

• Pas de script de test third-party.
• Pas de réécriture de DOM après chargement.
• Moins de JavaScript expédié.
• Les métadonnées des expériences restent minimes.
• Les conversions peuvent être comptabilisées globalement.

Le modèle d'îles de Fresh est utile car le JavaScript interactif est optionnel. La documentation Fresh décrit les îlots comme les parties interactives du client de la page, tandis que le reste reste rendu par le serveur. Voir Fresh documentation des îles.

Conclusion

Les tests A/B côté serveur ne consistent pas à ajouter plus de suivi. Il s'agit de prendre des décisions contrôlées en matière de produits ou de marketing avec moins de frais généraux. Attribuez des variantes avant le rendu, gardez les métadonnées propres, mesurez les conversions globales et arrêtez le test uniquement lorsque le résultat est suffisamment solide pour modifier ce que vous expédiez.

Cachez soigneusement

Les expériences côté serveur et la mise en cache peuvent entrer en conflit. Si un CDN met en cache la première variante rendue pour tout le monde, votre test est interrompu. Soit vous modifiez le cache en fonction de l'affectation de l'expérience, soit vous désactivez la mise en cache pleine page sur les routes d'expérimentation, soit vous déplacez la partie variable derrière une décision Edge ou serveur qui n'est pas mise en cache de manière incorrecte.

Documenter le comportement du cache avant le lancement. De nombreux tests A/B échouent non pas à cause de statistiques, mais parce que l'infrastructure a servi la variante A à presque tout le monde.

Terminez le test proprement

Lorsqu'un gagnant est choisi, supprimez la logique d'affectation, les cookies obsolètes et les propriétés d'événement spécifiques à l'expérience. Conservez une annotation dans Analytics avec la date de lancement. Les expériences obsolètes depuis longtemps rendent les tableaux de bord plus difficiles à lire et peuvent maintenir en vie des cookies ou des branches inutiles.

Gardez les expériences suffisamment petites pour pouvoir être maintenues

Chaque expérience ajoute une logique de branchement. Nommez clairement les expériences, définissez une date d'expiration et attribuez un propriétaire. Si un test ne peut pas être surveillé, terminé et nettoyé, il ne doit pas être lancé. Les meilleurs systèmes de test server-side sont ennuyeux : un point de décision, une métrique principale, un ticket de nettoyage.

Liste de contrôle des expériences de pré-lancement

Avant la mise en ligne d'une expérience server-side, confirmez la méthode d'affectation, le comportement du cache, l'événement d'exposition, la conversion principale, les métriques de garde-fou, la règle de taille d'échantillon, le propriétaire et la date de nettoyage. Si un cookie ou une session de serveur est utilisé pour l'affectation, documentez pourquoi il est nécessaire et combien de temps il dure.

Après le lancement, comparez le nombre d'expositions avec le trafic des pages et le nombre de conversions avec les enregistrements backend. Si l’expérience ne peut pas se terminer proprement, ou si ses événements révèlent des données de formulaire personnel, le test n’est pas prêt.