Présentation

Les tests A/B ou la technique de déploiement Canary permettent aux développeurs d'expérimenter deux ou plusieurs variantes d'une page Web. Les variantes sont présentées de manière aléatoire aux utilisateurs, puis une analyse statistique est utilisée pour déterminer quelle variante est la plus performante pour un objectif commercial donné. Par exemple, une variante de l'interface utilisateur d'une page de produit peut être testée dans le but d'augmenter les ventes de produits.

Décisions architecturales

Vous pouvez implémenter les tests A/B de différentes manières en fonction de vos exigences techniques et commerciales. L'une des principales décisions techniques est de savoir où exécuter la logique de sélection des variantes : côté client, côté serveur en périphérie (au niveau du CDN) ou côté serveur d'origine.

Sélection de variantes côté serveur d'origine. Dans cette approche, la sélection A/B est exécutée directement sur le serveur d'origine hébergeant votre application Web. Bien que cette approche soit indépendante du CDN, elle est incompatible avec la mise en cache du CDN ou avec l'hébergement de fichiers statiques. Il s'agit d'une option pour les applications Web rendues côté serveur qui sont entièrement dynamiques.

Sélection de variantes côté serveur en périphérie. Dans cette approche, vous prenez la décision de sélection de la variante au niveau du CDN. Cette approche nécessite peu ou pas de modifications de l'application et est compatible avec la mise en cache du CDN. Dans CloudFront, vous pouvez mettre en œuvre la logique de test A/B en utilisant des fonctions de périphérie. Une fonction de périphérie peut utiliser les attributs de la demande (pays, cookie, etc.), en plus d'une API de test A/B externe pour sélectionner l'une des variantes et demander à CloudFront de la diffuser depuis le cache.

Sélection de variantes côté client. Dans cette approche, votre interface envoie d'abord une demande à une API de test A/B pour décider de la variante à servir, ensuite, en fonction de la réponse, télécharge la variante, puis l'affiche dans le navigateur. Dans cette approche, vos tests A/B sont indépendants du CDN, mais ils sont étroitement liés à votre application et introduisent une latence supplémentaire en raison des étapes supplémentaires du côté client. Notez également que ce n'est pas toujours une option, comme pour les tests A/B de sites générés statiquement (SSG). Pour implémenter des tests A/B côté client, vous pouvez utiliser CloudWatch Evidently. Il fournit le kit SDK client et l'interface utilisateur permettant de contrôler les expériences de tests A/B. Pour un didacticiel pratique sur CloudWatch Evidently, pensez à cet atelier.

Concentrons-nous sur les tests A/B côté serveur en périphérie. Pour concevoir la meilleure implémentation pour votre entreprise, posez-vous les questions supplémentaires suivantes :

  • Avez-vous besoin d'une continuité (par exemple, le même utilisateur bénéficiera toujours de la même variante) ? La continuité est généralement mise en œuvre à l'aide de cookies.
  • Quelles dimensions sont utilisées pour sélectionner une variante pour un utilisateur ? pays, identifiant utilisateur, etc.
  • À quelle fréquence faites-vous des tests A/B ? L'utilisation intensive des tests A/B, avec de nombreuses expériences exécutées en parallèle par différentes équipes, nécessite une implémentation plus sophistiquée par rapport à des tests A/B plus simples et occasionnels.

Pour en savoir plus sur certaines implémentations de tests A/B côté service en périphérie utilisant les fonctions de périphérie de CloudFront, découvrez cet atelier pratique. Dans la section suivante, nous allons partager deux implémentations courantes des tests A/B à l'aide de CloudFront, issues de l'atelier susmentionné.

Cas d'utilisation courants des tests A/B côté serveur en périphérie

Tests A/B occasionnels

Pour les besoins occasionnels en matière de tests A/B, tels que l'amélioration trimestrielle de la conception d'un site Web institutionnel, envisagez une solution basée sur les fonctions CloudFront pendant la durée de votre test. La solution repose sur deux fonctions configurées sur le comportement du cache qui correspond à la page pour laquelle vous souhaitez effectuer des tests A/B :

  • Une fonction de demande d'utilisateur, qui inspecte la valeur du cookie d'expérience des demandes entrantes et, en fonction de celle-ci, réécrit l'URL vers la variante de page sélectionnée. Si le cookie n'est pas présent, la fonction sélectionne la variante en utilisant votre logique personnalisée, par exemple 60 % pour la variante A et 40 % pour la variante B, uniquement pour les demandes provenant de France.
  • Une fonction de réponse du spectateur, qui place le cookie sur le client en fonction de la variante sélectionnée, si le cookie n'était pas déjà présent. Le cookie expérimental est utilisé pour s'assurer qu'un seul utilisateur reçoit toujours la même variante de la page afin de ne pas perturber son expérience Web.

La modification de la logique de sélection de la variante, par exemple pour augmenter le pourcentage de la variante B, nécessite une mise à jour du code de fonction de l'événement de visualisation, qui prend généralement quelques secondes. Lorsque vous avez terminé l'expérience des tests A/B, vous pouvez supprimer les fonctions périphériques pour réduire les coûts.

Tests A/B fréquents

Si vous effectuez régulièrement des tests A/B sur votre site Web, avec des expériences effectuées quotidiennement, vous pouvez toujours utiliser l'ancienne solution basée sur la fonction CloudFront. Cependant, il est recommandé de découpler les paramètres de sélection des variantes (par exemple, les pondérations des variantes) du code de fonction. Vous pouvez utiliser un CloudFront KeyValueStore pour stocker ces paramètres, en dehors du code de fonction. Le KeyValueStore est idéal pour une lecture globale (chaque PoP) à faible latence,
entrepôt de données de clé-valeur à grande échelle (millions de requêtes par seconde).

Notez que votre cas d'utilisation doit respecter les quotas KeyValueStore, tels que la taille maximale (5 Mo) ou la limite de vitesse de modification de quelques appels d'API par seconde.

Étude de cas CapitalOne : tests A/B avec les fonctions CloudFront et KeyValueStore

Tests A/B avancés

Envisagez une solution basée sur Lambda@Edge si une solution basée sur la fonction CloudFront ne répond pas à vos besoins en matière de tests A/B, par exemple si les quotas KeyValueStore sont limités pour votre cas d'utilisation. Cela peut être le cas si vous exploitez un grand site Web de commerce électronique, où de nombreuses équipes exécutent des expériences simultanées sur différentes parties du site Web à une vitesse élevée.  Dans ce scénario, utilisez Lambda@Edge au lieu de la fonction CloudFront, avec une source de données externe (par exemple DynamoDB Global Tables) pour stocker les paramètres des tests A/B. Les outils de gestion des fonctionnalités tels que LaunchDarkly proposent des intégrations avec DynamoDB afin de conserver les paramètres des tests A/B.

Ressources

Cette page vous a-t-elle été utile ?

 Commentaires