Les enregistrements apparaissent dans le tableau de bord quelques minutes (~4 min) après qu’une session est terminée. Une session est considérée comme terminée lorsque l’utilisateur ferme l’onglet ou le navigateur, est déconnecté (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 de nouveau.

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

Avant de commencer à déboguer les enregistrements de sessions, assurez-vous de capturer tout le 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. Veillez donc à 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 ») envoyées à votre IP/domaine (ou *.openreplay.com si vous êtes sur OpenReplay Cloud).

Une autre manière serait d’utiliser le callback de démarrage du tracker et de consigner un message au démarrage.

const tracker = new OpenReplay({
	projectKey: PROJECT_KEY,
});

tracker.start().then(({sessionID}) => console.log("OpenReplay tracker started with session: ", sessionID))
// OR you can use startCallback method
tracker.start({
	startCallback: ({ sessionID }) => console.log("OpenReplay tracker started with session: ", sessionID)
});
// for snippet, just add startCallback to initOpts

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, faute de quoi le tracker ne démarrera pas. Pour ces raisons, les sessions ne seront pas capturées en localhost, sauf si vous ajoutez l’option inlineCss: 3 au constructeur du tracker afin que les feuilles de style soient alors capturées dans le cadre de chaque relecture (au lieu d’être mises en cache de manière centralisée par le serveur).

Pour des raisons de sécurité, le tracker ne s’exécute 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 semblable à celle ci-dessous, cela signifie qu’OpenReplay n’a pas pu démarrer en raison de l’absence d’une politique de sécurité du contenu. Consultez ici la politique à ajouter.

Le script d’enregistrement peut être bloqué par une extension de navigateur comme 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).

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.

OpenReplay a besoin d’accéder à des ressources, telles que votre css, pour que les relectures 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. Même s’ils le sont, certains CDN (comme CloudFlare) considèrent que nos requêtes de cache proviennent d’un bot et les bloquent donc. Si c’est le cas, veillez à ajouter à la liste blanche l’IP source de votre VM (si vous utilisez notre édition open source), de votre instance dédiée (si vous êtes sur notre offre cloud dédiée) ou les IP suivantes (si vous êtes sur notre offre cloud serverless) : 18.197.95.153 et 18.197.221.118.

Si vos ressources sont hébergées sur un domaine restreint (privé ou protégé), OpenReplay ne pourra pas les copier ni les utiliser dans les relectures. Vous avez 2 options :

• (Recommandé) Ajoutez l’option inlineCss: 3 au constructeur du tracker afin que les feuilles de style soient capturées dans le cadre de chaque relecture (au lieu d’être mises en cache de manière centralisée par le serveur).
• Ou vous pouvez copier vos ressources sur 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 contiennent des frames imbriqués, veillez à utiliser un chemin absolu (dans les éléments <link> pointant vers vos fichiers CSS) dans chaque frame intégré, 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, la relecture peut apparaître vide (ou blanche). 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 votre couche frontend (avec un zIndex plus élevé), vous pourriez remarquer un écran noir lors de la relecture 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 pour votre application web, ajoutez l’attribut HTML data-openreplay-hidden à l’élément canvas problématique afin de le masquer complètement de l’enregistrement de la session.

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

Si votre application web comprend des iframes, vous ne pourrez pas relire leur 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 sites qui s’étendent 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
import { tracker } from '@openreplay/tracker'

tracker.configure({
  projectKey: PROJECT_KEY
})

// or with class instance:
import OpenReplay from '@openreplay/tracker'

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
// then Pass the sessionHash to the newly started session
trackerNewDomain.start({ 
  sessionHash, // This can be retrieved from cookies or URL (if needed)
})

Si la poursuite de la session n’est pas possible (elle n’existe pas ou est terminée), le tracker en démarrera automatiquement une nouvelle.

Cela peut se repérer dans les relectures 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’hébergez pas OpenReplay vous-même mais utilisez plutôt notre solution hébergée, il est possible que certaines sessions ne soient pas enregistrées, car les requêtes vers nos serveurs peuvent être bloquées. Cela est généralement dû aux bloqueurs de publicités, aux VPN ou aux extensions de navigateur.

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