Replay des sessions

Lunetric reconstruit le DOM et ses évolutions avec rrweb. Il ne filme pas l'écran, n'enregistre pas les touches brutes et ne permet pas de piloter le navigateur. La capture est désactivée par défaut, avec consentement distinct de l'analytics.

Préparer le serveurCopier le lien de cette section

En local, configurez REPLAY_ENABLED=true : les blocs vont dans .data/replays. En production, un stockage objet privé S3-compatible est obligatoire. Configurez les variables serveur REPLAY_S3_BUCKET, REPLAY_S3_REGION, éventuellement REPLAY_S3_ENDPOINT, REPLAY_S3_ACCESS_KEY et REPLAY_S3_SECRET_KEY. Les identifiants ne vont jamais dans le navigateur. Le bucket doit interdire l'accès public ; configurez aussi son lifecycle, ses versions et ses sauvegardes selon votre rétention.

Avec Cloudflare R2, utilisez REPLAY_S3_REGION=auto. Pour un bucket en juridiction européenne, l'endpoint est https://<account-id>.eu.r2.cloudflarestorage.com. Créez une clé Object Read & Write limitée au bucket de replay ; désactivez l'URL publique r2.dev et n'ajoutez aucun domaine public. Une règle d'expiration à 30 jours sur le préfixe replays/ complète la purge applicative, qui applique la conservation propre à chaque site. Consultez la configuration des juridictions R2 et les permissions des clés R2.

Dans Sessions → Paramètres de capture, le propriétaire active la fonctionnalité, choisit l'échantillonnage, la conservation (1–30 jours, 7 par défaut), les routes publiques autorisées et les exclusions. Un préfixe inclut ses sous-pages. / autorise tout ce qui n'est pas exclu : utilisez une liste de pages publiques spécifique dès que possible. Les visites déjà reçues ne possèdent pas de replay rétroactif.

Brancher deux consentementsCopier le lien de cette section

Le tracker analytics doit être chargé et avoir reçu une page vue avant le démarrage replay. Branchez ces appels aux catégories de votre gestionnaire de consentement, après chargement du script :

// Consentement analytics, indépendant du replay.
window.lunetric.grantConsent();
// Uniquement après accord explicite au replay.
window.lunetric.replay.grantConsent();
// Retrait du replay : arrêt et abandon des données en attente.
window.lunetric.replay.revokeConsent();
// Retrait analytics : arrête également le replay.
window.lunetric.revokeConsent();

window.lunetric.replay.getState() indique notamment recording, stopped, excluded, not-sampled, analytics-required, unavailable ou incomplete. La bibliothèque est téléchargée à la demande. N'enregistrez rien avant accord, même pour l'envoyer plus tard.

Protéger les contenusCopier le lien de cette section

Texte et champs sont masqués avant envoi ; attributs libres, URL sensibles et ressources distantes sont supprimés. Le rendu conserve une structure et des styles simples, pas une copie parfaite de toutes les applications. Les pages privées, l'authentification et les paiements restent à exclure. Ajoutez data-lunetric-replay-block aux régions à bloquer complètement :

<section data-lunetric-replay-block>Contenu privé à ne jamais enregistrer</section>

Le masquage des inputs seul n'est pas une politique suffisante : utilisez des données synthétiques pour vérifier le snapshot initial et les mutations réellement envoyés. Tester les transitions SPA vers les routes exclues est indispensable. Canvas, médias et iframes tierces ne sont pas capturés ; images/ressources externes deviennent des placeholders. Les changements de feuilles CSS après le snapshot ne sont pas encore restitués.

Le replay individuel n'est pas automatiquement exempté de consentement parce que les données sont pseudonymes ou les cookies first-party. Vérifiez les finalités, l'information et la configuration avec votre politique de confidentialité. Le retrait arrête la collecte future ; l'effacement des données déjà stockées est distinct.

Lire une sessionCopier le lien de cette section

Ouvrez Sessions, ou les replays depuis un parcours visiteur. Le lecteur propose pause, vitesse, position, document et zoom. La liste est filtrable par date (UTC), page anonymisée, appareil et état ; les événements corrélés sont paginés par 200. La navigation entre pages du même onglet conserve le recording tant que sa permission est valide : la CMP doit réappliquer le consentement explicite sur chaque document. « Rejoindre le direct » suit les blocs durables avec un petit délai. Une coupure peut déclencher une actualisation périodique. Une session inactive ou tronquée reste marquée comme telle, sans prétendre disposer d'une vidéo complète.

Les membres autorisés lisent les manifestes et chaque bloc sous la même origine privée. Le DOM rejoué reste dans une iframe sandbox sans scripts enregistrés. Les paiements associés uniquement au visiteur ne sont pas présentés comme causés par la session.

Limites et suppressionCopier le lien de cette section

Les limites initiales sont 30 minutes, 2 500 blocs et 25 MiB compressés par recording, 1 GiB de blocs par site et par jour, 10 000 démarrages/jour et des buffers navigateur bornés. Un bloc trop gros ou un quota dépassé arrête la capture et affiche un état incomplet. L'analytics continue indépendamment. Ces limites ne constituent pas un benchmark de capacité.

L'effacement du visiteur bloque immédiatement la lecture et met la suppression des objets privés en file durable. La tâche serveur tourne chaque minute ; une panne du bucket est reprise. Les fichiers orphelins anciens sont réconciliés. La purge effective et les versions/sauvegardes du bucket doivent être surveillées.

MCP expose seulement list_session_recordings et get_recording_metadata, avec la clé de lecture du site. Aucun DOM n'est ajouté aux exports publics de documentation ou aux réponses des outils.