Problèmes liés aux Enregistrements de Sessions

Toutes sortes de problèmes empêchant les rejeux d'être capturés ou correctement affichés.

Problèmes liés aux Enregistrements de Sessions

Les enregistrements apparaissent dans le tableau de bord quelques minutes (~4 min) après la fin d’une session. Une session est considérée comme terminée lorsque l’utilisateur ferme l’onglet ou le navigateur, est déconnecté (pendant plus de 2 min) ou dépasse 2 heures (auquel cas une nouvelle session démarre). Chaque onglet donne lieu à un nouvel enregistrement, tandis que le rechargement d’un onglet existant n’en déclenche pas un nouveau.

Cette section a pour but de vous aider à résoudre les problèmes courants liés aux rejeux de sessions.

Les rejeux n’apparaissent pas dans la liste

Section titled Les rejeux n’apparaissent pas dans la liste

Avant de commencer à déboguer les enregistrements de sessions, assurez-vous de capturer l’ensemble du trafic. Cliquez sur le bouton Manage dans la section Sessions et activez Capture All.

Une autre erreur courante consiste à démarrer le tracker deux fois, ce qui empêche l’enregistrement des sessions. Cela se produit généralement lorsque les développeurs passent de la configuration basée sur un script à l’utilisation du package npm, alors assurez-vous de n’avoir que l’un des deux.

Si vous n’êtes pas sûr de la configuration, ouvrez l’inspecteur du navigateur et vérifiez l’onglet Network pour voir s’il y a des requêtes XHR (recherchez “ingest”) effectuées vers votre IP/domaine (ou *.openreplay.com si vous êtes sur OpenReplay Cloud).

Une autre façon serait de mettre à jour le constructeur du tracker et de consigner un message au démarrage.

const tracker = new OpenReplay({
	projectKey: PROJECT_KEY,
	onStart: ({ sessionID }) => console.log("OpenReplay tracker started with session: ", sessionID),
});

OpenReplay a besoin d’un accès public pour copier certaines des ressources de votre application (CSS, polices et icônes) afin de rendre correctement les enregistrements. Votre site doit également utiliser SSL/HTTPS, sinon le tracker ne démarrera pas. Pour ces raisons, les sessions ne seront pas capturées en localhost, sauf si vous appliquez cette solution de contournement.

Pour des raisons de sécurité, le tracker ne fonctionne que sur les applications web qui utilisent SSL (HTTPS). Si votre site est en HTTP, le tracker ne démarrera pas.

Si vous voyez une erreur similaire à celle ci-dessous, alors OpenReplay n’a pas pu démarrer en raison d’une politique de sécurité du contenu manquante. Consultez ici la politique à ajouter.

CSP Issue

Le script d’enregistrement pourrait être bloqué par une extension de navigateur telle qu’un bloqueur de publicités. Utilisez l’inspecteur de votre navigateur pour vérifier si les requêtes échouent. Si c’est le cas, ajoutez une exception pour le domaine sur lequel le backend OpenReplay est installé (ou openreplay.com si vous êtes sur l’offre cloud).

En raison d’un navigateur non pris en charge

Section titled En raison d’un navigateur non pris en charge

OpenReplay lève une exception lorsqu’il s’exécute dans un navigateur non pris en charge. Consultez ici la liste des navigateurs pris en charge.

Les rejeux ne s’affichent pas correctement

Section titled Les rejeux ne s’affichent pas correctement

OpenReplay a besoin d’accéder à des ressources, telles que votre css, pour que les rejeux fonctionnent. En fait, ces fichiers sont copiés puis mis en cache par notre backend afin que vous puissiez voir d’anciens enregistrements même si votre application web a changé. C’est pourquoi vous devez vous assurer que vos styles (ainsi que les icônes et les polices) sont accessibles publiquement. Si vos ressources sont hébergées sur un domaine restreint (privé ou protégé), alors OpenReplay ne pourra pas les copier ni les utiliser dans les rejeux. Vous pouvez les copier vers un domaine accessible publiquement, puis utiliser l’option resourceBaseHref pour spécifier le domaine dans le constructeur du tracker.

Si vos iFrames de même origine comportent des frames imbriquées, veillez à utiliser des chemins absolus (dans les éléments <link> pointant vers vos fichiers CSS) dans chaque frame intégrée, ou utilisez l’option resourceBaseHref pour spécifier le domaine dans le constructeur du tracker.

Si vous effectuez des tests en localhost, les styles ne seront pas rendus car OpenReplay ne peut pas y accéder puisqu’ils se trouvent sur votre machine. Suivez ce guide pour corriger la situation.

Dans de rares cas, le rejeu peut apparaître vide (ou blanc). Bien que les pages ne soient pas rendues, vous pouvez toujours voir la souris de l’utilisateur se déplacer. Essayez de définir l’option disableStringDict sur true et voyez si cela aide avec les nouveaux enregistrements. Cela résout généralement le problème.

Si vous utilisez un canvas au-dessus de la couche de votre frontend (avec un zIndex plus élevé), vous pourriez remarquer un écran noir lors du rejeu des sessions enregistrées. Cela se produit parce que l’API web ne nous permet pas encore de capturer le canal alpha. Si c’est le cas avec votre application web, ajoutez l’attribut HTML data-openreplay-hidden à l’élément canvas problématique pour le masquer complètement de l’enregistrement de la session.

Les images ne s’affichent pas

Section titled Les images ne s’affichent pas

Contrairement aux styles, les images ne sont pas mises en cache par OpenReplay mais récupérées lors du rejeu d’une session. Elles doivent donc être accessibles publiquement. Si elles se trouvent sur un CDN, assurez-vous de conserver les anciennes versions de vos images afin de pouvoir rejouer correctement les anciens enregistrements de sessions.

Si votre application web inclut des iframes, vous ne pourrez pas en lire le contenu dans le cadre de vos enregistrements. Vous pouvez tout de même démarrer OpenReplay à l’intérieur d’un iframe en incluant tracker.start(), mais il sera considéré comme un onglet distinct, ce qui signifie qu’il sera capturé dans un enregistrement distinct.

Les rejeux sont défectueux entre les sous-domaines

Section titled Les rejeux sont défectueux entre les sous-domaines

Les sites répartis sur de nombreux sous-domaines généreront plusieurs sessions pour une même visite. Vous pouvez les assembler en un seul enregistrement en passant sessionHash à la méthode start() du tracker. Le sessionHash peut être conservé puis récupéré depuis votre stockage inter-domaines (par exemple, les cookies).

// Initialize the tracker as you would normally do
const tracker = new OpenReplay({
  projectKey: PROJECT_KEY
})
...
// Make sure the tracker is stopped when passing subdomains and collect the sessionHash
const sessionHash = tracker.stop(); // This can be saved in cookies or passed through URL (if needed)
...
// Initialize another tracker on the new subdomain with the same projectKey
const trackerNewDomain = new OpenReplay({
  projectKey: PROJECT_KEY
})
// Pass the sessionHash to the newly started session
trackerNewDomain.start({ 
  sessionHash, // This can be retrieved from cookies or URL (if needed)
})

Au cas où il ne serait pas possible de poursuivre la session (elle n’existe pas ou est terminée), le tracker en démarrera automatiquement une nouvelle.

Cela peut être repéré dans les rejeux qui n’ont qu’une seule page visitée et qui se terminent dès qu’un utilisateur navigue vers une autre page. Cela se produit généralement sur les sites web qui ne sont pas des applications monopages (SPA). Pour corriger cela, tracker.start() doit être appelé sur chaque page.

Si vous n’auto-hébergez pas OpenReplay mais utilisez plutôt notre solution hébergée, il est probable que certaines sessions ne soient pas enregistrées car les requêtes vers nos serveurs peuvent être bloquées. Cela est généralement causé par des bloqueurs de publicités, des VPN ou des extensions de navigateur.

Si vous avez des questions sur ce processus, n’hésitez pas à nous contacter sur notre Slack ou à consulter notre Forum.