Ce que la digital experience analytics couvre et que le web analytics manque

Qu'est-ce que la digital experience analytics ?

Les équipes produit et UX utilisent la digital experience analytics, ou analyse de l'expérience numérique, pour reconstruire le déroulé réel d'une visite unique, en combinant session replay, heatmaps, détection de friction et analyse de parcours dans une seule vue, au lieu de compter combien de fois un événement s'est déclenché. Un tableau de bord de trafic rapporte que 4,000 personnes ont atteint le paiement et que 1,200 l'ont terminé. La digital experience analytics montre le champ où les 2,800 autres se sont arrêtées, le bouton qui a avalé leurs clics, et l'erreur que le navigateur a levée pendant qu'elles attendaient. L'unité d'analyse est la visite, pas la métrique.

Un checkout, en chiffres

Ont atteint le checkout4 000

Ont terminé le checkout1 200

Se sont arrêtés avant la fin2 800

Que recouvre réellement cette catégorie ?

Quatre capacités composent la catégorie, et un outil qui livre les quatre la couvre de bout en bout. Le session replay stocke les changements nécessaires pour rejouer une visite dans un navigateur. Les heatmaps agrègent clics, taps et profondeur de défilement de nombreuses visites sur une seule mise en page. La détection de friction signale rage clicks, dead clicks, erreurs et étapes abandonnées sans que personne ait à regarder un enregistrement d'abord. L'analyse de parcours met dans l'ordre les pages et les événements d'un visiteur, pour qu'une équipe lise la route plutôt que la destination.

Capacité	Ce qu'elle capture	Question à laquelle elle répond
Session replay	Changements du DOM, saisies, défilement et événements de pointeur d'une visite	Qu'a vu et fait cette personne ?
Heatmaps	Clics, taps et profondeur de défilement agrégés sur de nombreuses visites	Où l'attention se pose-t-elle sur cette page ?
Détection de friction	Rage clicks, dead clicks, erreurs JavaScript, étapes abandonnées	Quels moments ont mal tourné, et pour combien de personnes ?
Analyse de parcours	Pages et événements ordonnés pour un visiteur	Quelle route a mené à l'abandon ?

Traitez le terme comme cet ensemble de capacités, puis vérifiez lesquelles des quatre un outil donné livre. Un produit qui enregistre des sessions sans jamais signaler un moment de blocage vous laisse tout le travail de visionnage.

En quoi la digital experience analytics diffère-t-elle du web analytics et du product analytics ?

Les trois répondent à des questions différentes parce qu'elles travaillent sur des unités différentes. Le web analytics agrège le trafic en comptages et en taux pour une page ou une source. Le product analytics agrège des événements nommés en entonnoirs, cohortes et courbes de rétention pour une fonctionnalité. La digital experience analytics garde la visite intacte et lit ce qui s'est passé dedans.

	Unité d'analyse	Artefact principal	Réponses
Web analytics	Page et source de trafic	Comptages, taux, tendances	Combien, et d'où
Product analytics	Événement nommé	Entonnoirs, cohortes, rétention	Quelle étape a perdu les gens
Digital experience analytics	Une visite	Relecture, heatmap, signal de friction, parcours	Ce qui a mal tourné dans cette étape

Utilisez les trois ensemble. Le web analytics vous dit que le trafic vers la page de tarifs a chuté, le product analytics vous dit que la chute a commencé au sélecteur de forfait, et la digital experience analytics montre le sélecteur qui rejette une saisie valide.

Comment un outil reconstruit-il une visite sans enregistrer de vidéo ?

L'enregistreur prend un instantané complet de la structure de la page, puis diffuse chaque changement ultérieur comme un événement incrémental, si bien que la relecture reconstruit la page au lieu de jouer des images. Le projet open source rrweb documente cette séparation dans son README : le paquet snapshot convertit le DOM et son état en une structure de données sérialisable, et le paquet record "s'appuie sur un instantané initial pour enregistrer tous les changements d'état HTML (mutations) et les interactions utilisateur pendant que l'utilisateur parcourt la page web".

Ces mutations viennent d'une API du navigateur. MDN décrit MutationObserver comme une interface qui offre la possibilité de surveiller les changements apportés à l'arbre DOM, couvrant les ajouts et suppressions de nœuds enfants (childList), les changements d'attributs (attributes) et l'ensemble du sous-arbre d'un nœud cible (subtree). Les notes d'observateurs de rrweb ajoutent le reste du flux : mouvement et interaction de la souris, défilement, redimensionnement de la fenêtre, et saisie sur les éléments input, textarea et select, y compris les changements programmatiques attrapés en accrochant le setter de la propriété.

La conséquence pratique est qu'une relecture est un journal d'événements textuel, pas un film. Une machine peut le lire, le chercher et le résumer, et c'est ce qui rend l'AI session replay possible tout court.

Comment mesurer la friction à partir d'un ensemble de sessions ?

Comptez les sessions qui contiennent au moins un signal de friction et divisez par toutes les sessions de la fenêtre.

friction rate = (sessions with at least one friction signal / total sessions) x 100

Prenez 12,000 sessions dans une semaine, dont 840 contenaient un rage click, un dead click ou une erreur JavaScript non attrapée :

840 / 12,000 = 0.07, et 0.07 x 100 = 7 pour cent

Un taux de friction de 7 pour cent est un chiffre de départ, pas une conclusion. Découpez-le par page, par élément et par message d'erreur, puis classez les groupes selon le nombre d'utilisateurs distincts touchés par chacun. Deux rage clicks sur le même bouton font un seul bug ; deux rage clicks sur des boutons différents en font deux. L'analyse de la friction utilisateur est l'étape qui transforme le taux en file de travail.

Qu'est-ce que cela change à un rapport de bug ?

Le rapport arrive avec les preuves attachées au lieu d'une description écrite de mémoire. Flowsery regroupe les sessions correspondantes en un seul incident, classe les incidents selon le nombre d'utilisateurs touchés, et envoie chacun d'eux dans Slack, Linear ou Jira avec la relecture et les étapes de reproduction. Mentionnez @flowsery dans Slack sur cet incident et il ouvre une pull request en brouillon dans le dépôt GitHub de l'équipe.

Cela referme la boucle que la catégorie laisse ouverte. La détection, le regroupement et le classement sont la partie analytique ; un ticket sur lequel un développeur peut agir est la raison pour laquelle on la fait tourner.

Comment l'utiliser sans collecter de données personnelles ?

Masquez les champs avant que les données quittent le navigateur, et jetez les identifiants dont vous n'aviez pas besoin. Le masquage de confidentialité du session replay remplace le contenu des champs et des éléments marqués par des caractères de remplacement au moment de l'enregistrement, si bien que les valeurs n'atteignent jamais le serveur. Flowsery est sans cookies, hébergé dans l'UE et RGPD par conception, tourne depuis un seul script de moins de 10 KB, et n'applique aucun échantillonnage de données, donc les chiffres de friction ci-dessus viennent de chaque session plutôt que d'un sous-ensemble.

Décidez les règles de masquage avant d'activer l'enregistrement. Une règle ajoutée après coup ne nettoie pas les enregistrements que vous avez déjà stockés.

Questions fréquentes

La digital experience analytics est-elle la même chose que le session replay ?

Non. Le session replay est l'une des quatre capacités de la catégorie, aux côtés des heatmaps, de la détection de friction et de l'analyse de parcours. Un outil peut enregistrer des sessions sans détecter le moindre moment de blocage, ce qui vous laisse regarder des enregistrements à la main. La catégorie est la combinaison, pas l'enregistreur.

Faut-il encore du web analytics à côté de la digital experience analytics ?

Oui, parce que les deux travaillent à des échelles différentes. Le web analytics répond à combien de personnes sont arrivées et d'où, sur tout le site, en agrégé. La digital experience analytics répond à ce qui s'est passé à l'intérieur d'une de ces visites. Flowsery livre les deux, avec le trafic en temps réel, les entonnoirs, les objectifs et les revenus par source à côté des relectures.

Quelle équipe est propriétaire de la digital experience analytics ?

Le produit, le design et l'ingénierie la lisent tous, et le propriétaire est celui qui répare ce qu'elle trouve. Les designers utilisent heatmaps et parcours pour juger une mise en page. Les ingénieurs utilisent relectures et signaux d'erreur pour reproduire un défaut. Donnez à une personne la charge de trier la liste d'incidents classés chaque semaine, sinon la file grossit et personne ne la vide.

Combien de sessions un taux de friction demande-t-il pour être lisible ?

Le taux est une fraction, donc un petit dénominateur le fait sauter. Calculez-le par page et par étape plutôt que pour tout le site, et lisez le nombre d'utilisateurs touchés à côté du pourcentage. Une étape à 9 pour cent de friction sur 40 sessions est un signal plus faible qu'une étape à 4 pour cent sur 6,000.

La digital experience analytics peut-elle tourner sans cookies ?

Oui. Enregistrer une visite demande un moyen de rattacher les événements à une session, et cet identifiant n'a pas besoin d'être un cookie stocké d'une visite à l'autre. Flowsery est sans cookies et hébergé dans l'UE, et ses limites de forfait fonctionnent par quotas sur les sessions d'analytics, les enregistrements et la rétention.

Faut-il un nouveau code de tracking sur chaque page ?

Flowsery s'installe comme un seul script de moins de 10 KB. Si une équipe enregistre déjà des sessions dans PostHog ou Amplitude, Flowsery se connecte à ces relectures existantes sans réinstrumentation, si bien que l'analyse tourne sur des enregistrements que l'équipe possède déjà.

Comment la digital experience analytics explique-t-elle un abandon au checkout ?

Un tableau de bord de trafic peut montrer que 4 000 acheteurs ont atteint le checkout et que 1 200 l'ont terminé, sans dire pourquoi 2 800 sont partis en cours de route. La digital experience analytics lit ces mêmes sessions et montre le champ où ils se sont arrêtés, le bouton qui a avalé leurs clics, ou l'erreur que le navigateur a levée pendant qu'ils attendaient. L'explication vient de la visite elle-même, pas d'une couche de métriques séparée.

Que se passe-t-il une fois que Flowsery a regroupé des sessions dans un issue ?

Flowsery regroupe les sessions correspondantes dans un seul issue, classe les issues selon le nombre d'utilisateurs touchés, et envoie chacun vers Slack, Linear ou Jira avec le replay et les étapes de reproduction. Mentionner @flowsery dans Slack sur cet issue ouvre une pull request en brouillon dans le dépôt GitHub de l'équipe. Le rapport arrive avec des preuves jointes, pas une description écrite de mémoire.

En quoi un session replay construit à partir de mutations diffère-t-il d'un enregistrement vidéo ?

L'enregistreur prend un instantané complet de la structure de la page, puis diffuse chaque changement suivant comme un événement incrémental, exactement la répartition que rrweb documente dans son README. Un replay construit ainsi est un journal d'événements en texte, pas un film, donc une machine peut le lire, le rechercher et le résumer. C'est ce qui rend l'AI session replay possible.

Pourquoi masquer les champs avant que les données ne quittent le navigateur ?

Le masquage de confidentialité du session replay remplace le contenu des champs de saisie et des éléments marqués par des caractères de substitution dès l'enregistrement, si bien que les valeurs n'atteignent jamais le serveur. Les règles de masquage doivent être décidées avant d'activer l'enregistrement, car une règle ajoutée après coup ne nettoie pas les enregistrements déjà stockés. Flowsery associe cela au fait d'être cookie-free, hébergé dans l'UE et GDPR by design.