Amélioration de la surveillance de l'expérience client chez Twitch : le parcours QoUX

À propos de l’auteur : je suis Chirag Sachdeva, un ingénieur aérospatial devenu ingénieur logiciel dans l’équipe des abonnements de Twitch. Je suis un membre fier de la famille Twitch depuis quatre ans, travaillant sur des initiatives telles que les abonnements, les cadeaux, Turbo et le badge de fondateur. Pour moi, l’expérience client est toujours une priorité absolue, et c’est l’un des facteurs qui guident mon travail chez Twitch.

Dans le monde effréné du streaming live, la qualité de l’expérience utilisateur influe directement sur la rétention et la satisfaction des viewers. Je suis ravi de vous présenter comment Twitch a transformé ses capacités de surveillance grâce à la qualité de l’expérience utilisateur (QoUX), une initiative qui nous a permis de comprendre le comportement des utilisateurs, de détecter plus rapidement et plus facilement les problèmes impactant les utilisateurs, et de réagir rapidement.

Le défi

Malgré une surveillance sérieuse en backend, nous avons rencontré un défi majeur : comprendre exactement comment l’expérience de nos utilisateurs sur notre plateforme en temps réel. Permettez-moi de vous présenter un exemple précis qui illustre ce problème.

Imaginez que vous êtes un viewer Twitch qui souhaite offrir un abonnement de plusieurs mois à votre streamer préféré. Vous cliquez sur le bouton « Offrir un abonnement », vous choisissez le destinataire, mais lorsque vous essayez de sélectionner une option d’abonnement de 3 mois, le bouton ne répond tout simplement pas. De votre point de vue, la fonctionnalité ne marche pas ; mais de notre point de vue en backend, tout semblait normal.

Ce même scénario s’est produit lorsque nous avons mis en place une fonctionnalité de cadeau qui a désactivé par inadvertance le bouton de sélection de plusieurs mois pour un petit groupe d’utilisateurs. Nos systèmes en backend n’ont signalé aucune erreur car, techniquement, aucune requête n’échouait ; le bouton n’envoyait tout simplement pas de requêtes. Le code sur l’appareil de l’utilisateur (le client) empêchait l’interaction d’atteindre nos serveurs.

Les données de mesure traditionnelles au niveau du serveur, bien que précieuses, ne pouvaient pas nous indiquer si un abonné rencontrait des difficultés pour finaliser un achat ou si le processus lié aux cadeaux échouait dans une région spécifique. Avant QoUX, nos systèmes de surveillance et d’alerte étaient principalement axés sur les services et l’infrastructure du service en backend, ce qui empêchait de détecter ces types de défaillances côté client.

Vous vous demandez peut-être : pourquoi n’avons-nous pas simplement effectué une surveillance côté client dès le début ? Nous devions faire des compromis importants :

1. Le volume de données. La surveillance côté client génère beaucoup plus de données que la surveillance côté serveur. Avec des millions d’utilisateurs, chacun effectuant des dizaines d’interactions, la quantité de données à analyser peut rapidement devenir écrasante.
2. Les considérations de confidentialité. La surveillance côté client nécessite une mise en œuvre minutieuse pour respecter la vie privée des utilisateurs et se conformer aux réglementations.
3. Le problème de fiabilité. Les systèmes de backend fonctionnent dans des environnements contrôlés, tandis que la surveillance côté client doit fonctionner sur d’innombrables types d’appareils, de navigateurs, de conditions de réseau et d’extensions susceptibles d’interférer avec le suivi.
4. La complexité du développement. La mise en œuvre d’une surveillance efficace côté client nécessite de la programmation supplémentaire pour chaque fonctionnalité, ce qui augmente le temps de développement et le risque de bugs.
5. Complexité de la surveillance : transformer des événements bruts en informations exploitables n’est pas une tâche facile. Ces éléments doivent être soigneusement agrégés et transformés pour éviter à la fois les faux positifs et les faux négatifs.

QOUX a été créée pour trouver un moyen de mieux analyser l’utilisation que font les clients des logiciels, tout en cherchant une solution à ces problèmes. Cette initiative est désormais au cœur des capacités opérationnelles de Twitch, ce qui nous permet de mieux comprendre le comportement des utilisateurs, tout en identifiant plus facilement les problèmes qui affectent les utilisateurs et entraînent des temps de réponse plus courts.

Qu’est-ce que QoUX ?

La qualité de l’expérience utilisateur (QoUX) est un environnement configurable conçu pour surveiller et analyser les expériences côté client. Il est fondé sur trois principes fondamentaux :

1. Côté client avant tout. Surveiller où l’utilisateur interagit effectivement avec Twitch
2. Visibilité en temps réel. Informations instantanées sur les expériences des utilisateurs
3. Indicateurs exploitables. Des données qui orientent directement les décisions relatives aux produits

Comment fonctionnent les événements côté client

Les éléments côté client sont au cœur de QoUX : des signaux de télémétrie spécialisés émis directement depuis les appareils des utilisateurs. Ces événements sont :

• Émis par l’application du client. Que ce soit l’application web Twitch, l’application mobile, ou l’application console, le code client génère lui-même ces événements.
• Déclenchés lors des interactions clés avec les utilisateurs. Les événements se déclenchent lorsque les utilisateurs effectuent des actions spécifiques, telles que cliquer sur des boutons, tenter d’effectuer des achats ou naviguer entre les pages.
• Enrichis en données contextuelles. Chaque événement contient des informations sur l’appareil de l’utilisateur, la région, et le composant ou la fonctionnalité spécifique utilisés.
• Conçus pour avoir un impact minimal sur les performances. Les événements sont regroupés et compressés pour ne pas affecter l’expérience utilisateur.

Permettez-moi de vous guider à travers un exemple concret de son fonctionnement :

1. Événement brut provenant du client : lorsqu’un utilisateur clique sur le bouton d’abonnement de plusieurs mois, un événement est déclenché contenant :
   • Type de bouton : « sélection_plusieurs_mois »
   • Identifiant de tunnel : « processus_abonnement_cadeau »
   • Type d’événement : « clic »
   • Informations client : version du navigateur/application mobile, type d’appareil
   • Région : localisation géographique de l’utilisateur
   • Horodatage : quand l’interaction a eu lieu
2. Après transformation + agrégation : ces événements bruts sont :
   • Diffusés vers Kinesis
   • Traités par des fonctions Lambda qui les filtrent, les transforment et les regroupent
   • Regroupés en intervalles de 5 minutes (l’intervalle varie en fonction du volume normal de ce type d’événement)
   • Enrichis avec un contexte supplémentaire issu de nos systèmes
3. Ce qui apparaît à la fin : les données traitées :
   • Sont envoyées aux tableaux de bord de CloudWatch avec alerte activée
   • Pour cet événement spécifique de bouton d’abonnement de plusieurs mois, si 5 points de données sont en dessous d’un seuil ou si aucun point de données n’est reçu (ce qui signifie qu’aucun clic n’a été effectué sur ce bouton) au cours des 25 dernières minutes, nos ingénieurs disponibles sont alertés.

La technologie derrière QoUX

Les capacités de surveillance de QoUX reposent sur un système qui permet la transformation, l’agrégation et la diffusion en continu des indicateurs d’événements. Mais pourquoi créer un système personnalisé au lieu de simplement envoyer des événements bruts aux équipes ?

Avantages du système QoUX :

• Gestion des volumes de données. Avec des pétaoctets de données, les équipes seraient submergées par le nombre d’événements bruts des clients. QoUX les regroupe et les filtre intelligemment pour fournir des informations pertinentes.
• Standardisation. QoUX garantit une structure et un traitement cohérents des événements au sein de toutes les fonctionnalités de Twitch.
• Efficacité opérationnelle. Les équipes n’ont pas besoin de construire leurs propres chaînes de traitement ou systèmes de surveillance.
• Importance de la confidentialité. QoUX gère les informations personnelles et les données sensibles de manière appropriée au niveau du système.

Les événements sont envoyés vers un flux Kinesis, où ils sont transformés, modélisés, filtrés et regroupés via des fonctions Lambda avant d’être publiés en tant qu’indicateurs personnalisés sur CloudWatch. Le système combine les données d’événements en distributions précises avec des dimensions définies par l’équipe concernée, compresse et inscrit ces données dans CloudWatch Metrics directement ou via Embedded Metrics Format (EMF, format d’indicateurs intégrés) pour les journaux à cardinalité élevée, permettant des analyses supplémentaires avec Log Insights (données de journaux) et des résumés top-N avec Contributor Insights (données de collaborateurs).

Surveillance en temps réel et alertes

Les alarmes CloudWatch ne sont pas simplement définies avec des seuils statiques. Elles sont entraînées grâce à :

• Des analyses historiques des habitudes d’utilisations ordinaires
• Des seuils adaptatifs qui prennent en compte les variations selon l’heure de la journée et le jour de la semaine
• Des modèles d’apprentissage automatique qui détectent les anomalies au-delà des simples dépassements de seuil
• Des analyses de corrélation pour réduire les faux positifs

Ces indicateurs comprennent :

• La disponibilité des composants. Indicateurs de disponibilité et de latence au niveau des composants, segmentés par région.
• Des actions d’utilisateurs. Données issues des actions des utilisateurs telles que les clics sur les boutons, les tentatives de paiement et les activités de cadeaux.
• Des défaillances. Alertes déclenchées par des défaillances dans ces opérations, y compris les raisons spécifiques de la défaillance.

Impact réel

Revenons à notre exemple de cadeau d’abonnement de plusieurs mois : lorsque nous avons lancé une fonctionnalité de cadeau qui a désactivé par inadvertance le bouton de sélection de plusieurs mois pour un groupe d’utilisateurs, QoUX a détecté le problème 25 minutes après le déploiement. Avant QoUX, nous n’aurions découvert ce problème qu’après avoir reçu les signalements des clients, ce qui aurait pu prendre des heures, voire des jours, en particulier pour les fonctionnalités utilisées par de plus petits segments de notre public.

Les alarmes personnalisées CloudWatch surveillent les pics de taux d’erreur, les échecs dans les actions critiques et les problèmes de latence, pour garantir une détection des défaillances côté client ou des chutes de performances plus rapidement que jamais.

Cas d’utilisation de QoUX

Surveillance en temps réel de l’expérience client

L’intégration de QoUX avec CloudWatch permet la surveillance en temps réel de fonctionnalités clés telles que les abonnements, les cadeaux et le paiement. En suivant la disponibilité régionale, les latences et les événements de défaillance de ces composants, nous pouvons rapidement identifier les interruptions et les défaillances qui affectent directement l’expérience client et les revenus. Cette approche a permis de détecter plusieurs défaillances critiques qui passaient inaperçues auparavant, en raison du manque de surveillance côté client.

Suivi du lancement de fonctionnalité

L’une des capacités remarquables de QoUX est sa capacité à surveiller les interactions des utilisateurs en temps réel lors des lancements de fonctionnalités. Par exemple, lors du lancement récent d’une fonctionnalité qui a modifié un élément clé de l’interface utilisateur, nous avons observé une augmentation inattendue des annulations d’abonnements parmi les utilisateurs de longue date. Grâce aux capacités de surveillance de QoUX, nous avons identifié ce problème dans les 10 minutes suivant le déploiement. Nous avons pu ajuster rapidement l’expérience utilisateur en modifiant la visibilité de l’élément problématique de l’interface utilisateur, réduisant ainsi considérablement l’impact négatif sur la rétention des utilisateurs. Cette capacité d’analyse et de réponse rapide illustre la puissance de notre système QoUX pour garantir une expérience utilisateur positive, même lors de déploiements majeurs de fonctionnalités.

Détection d’anomalie avancée avec Cloudwatch

Notre détection d’anomalies s’appuie sur le système de CloudWatch, qui utilise l’apprentissage automatique pour établir des bases de référence dynamiques pour les habitudes d’interaction des utilisateurs. Voici comment nous l’avons mis en œuvre :

• Création de base de référence. Nous configurons CloudWatch pour analyser de 2 à 4 semaines de données enregistrées pour chaque indicateur afin d’établir des types d’utilisation ordinaires
• Seuils adaptatifs. En plus des seuils statiques, nous utilisons les bandes de détection d’anomalies de CloudWatch qui s’ajustent automatiquement aux modèles d’heure de la journée et de jour de la semaine
• Alertes contextuelles. Lorsque des anomalies sont détectées, nos alertes incluent un contexte spécifique, comme les raisons de la défaillance, les régions concernées et les détails des composants.

Cette approche s’est avérée particulièrement efficace pour les indicateurs présentant des motifs cycliques ou des tendances graduelles qui déclencheraient de fausses alertes avec des seuils statiques traditionnels.

Surveillance et alertes interéquipes regroupées

QoUX a transformé nos capacités de surveillance organisationnelle en éliminant les cloisonnements traditionnels et en garantissant une visibilité fluide entre les différentes équipes. Grâce à la visibilité à travers différents comptes de CloudWatch, nous avons créé un environnement au sein duquel chaque équipe peut consulter, analyser et configurer indépendamment des alertes sur des indicateurs partagés, tout en conservant des limites claires de propriété.

Par exemple, lorsqu’un problème côté client survient dans le processus d’abonnement, l’équipe des abonnements et l’équipe des paiements ont un accès immédiat à la même source de vérité. Cette visibilité partagée permet une coordination plus rapide et une réponse plus efficace aux incidents, car les équipes peuvent voir exactement quels composants sont affectés et travailler ensemble pour trouver des solutions sans perdre de temps à concilier différents systèmes de surveillance.

L’approche unifiée a réduit notre temps moyen de détection d’environ 40 % et a amélioré la collaboration inter-équipes lors des incidents, car tout le monde travaille à partir des mêmes données en temps réel.

Leçons tirées et prochaines étapes

La mise en place d’une surveillance côté client avec QoUX a démontré à quel point la visibilité en temps réel dans les expériences des utilisateurs peut être puissante. En surveillant les espaces où les utilisateurs interagissent réellement avec l’application, on obtient des informations immédiates sur des problèmes que la surveillance traditionnelle du backend pourrait complètement rater.

Points clés

1. Commencez doucement et progressez au fur et à mesure. Commencez par instrumenter vos flux d’utilisateurs les plus critiques ; ceux directement liés aux revenus ou aux fonctionnalités de base. Dans notre cas, les flux d’abonnement et de paiement constituaient des points de départ évidents.
2. Choisissez les bons indicateurs. Concentrez-vous sur les indicateurs qui montrent directement le succès ou l’échec des expériences des utilisateurs, et pas seulement au niveau des performances techniques. Les clics sur les boutons, les taux de réussite et les fréquences d’erreurs révèlent souvent des données plus détaillées que les temps de réponse des serveurs.
3. Tirez parti des services AWS de manière efficace. La détection d’anomalies de CloudWatch représente une base efficace pour les alertes dynamiques sans nécessiter une expertise complexe en apprentissage automatique. La combinaison de Kinesis pour le streaming, de Lambda pour le traitement et de CloudWatch pour la surveillance crée une architecture flexible et évolutive.
4. Équilibrez le volume de données avec la capacité d’action. La surveillance côté client génère significativement plus de données que la surveillance côté serveur. Soyez stratégique quant à ce que vous collectez et à la manière dont vous l’agrégez pour éviter de surcharger vos systèmes et vos équipes.

Premiers pas avec votre propre implémentation de QoUX

1. Vérifiez votre surveillance actuelle. Identifiez les lacunes de votre stratégie de surveillance existante, notamment en ce qui concerne les composants et les interactions orientés vers l’utilisateur.
2. Instrumentalisez les parcours des utilisateurs clés. Ajoutez l’émission d’événements côté client aux chemins critiques de votre application, en vous concentrant sur :
   • Les tunnels de conversion
   • Les flux de connexion
   • Les processus de paiement
   • Les interactions des fonctionnalités essentielles
3. Créez votre file d’attente de traitement. Utilisez les services AWS tels que Kinesis, Lambda et CloudWatch pour collecter, traiter et visualiser vos événements côté client.
4. Établissez des références et configurez des alertes. Collectez des données pendant 2 à 4 semaines pour établir des schémas normaux avant de configurer des alertes de détection d’anomalies.
5. Créez une visibilité commune aux équipes. Veillez à ce que toutes les parties prenantes aient accès aux mêmes données de surveillance pour améliorer la collaboration lors d’incidents.

En implémentant votre propre version de QoUX, vous pouvez transformer votre compréhension et votre réponse aux expériences des utilisateurs, en détectant les problèmes avant qu’ils n’affectent votre entreprise et en créant une plateforme plus fiable pour vos utilisateurs.