Aller au contenu

Session replay

Le session replay enregistre le DOM des sessions échantillonnées et vous laisse les revoir dans le panel, côte à côte avec les événements de la session. Conçu pour le debugging et la recherche UX, avec des paramètres par défaut axés sur la confidentialité : les nouveaux projets enregistrent dès le départ, les champs de saisie sont masqués par défaut, et le toggle du projet est un kill switch distant.

Un seul interrupteur : les réglages du projet. Les nouveaux projets démarrent avec l’enregistrement activé à 100 % d’échantillonnage ; ajustez le taux ou désactivez l’enregistrement dans le panel, et le SDK le prend en compte tout seul (via /decide) — sans changement de code ni déploiement. Le même interrupteur est le kill switch distant : le désactiver arrête les nouveaux enregistrements en quelques secondes.

L’option sessionRecording de init du SDK sert aux overrides locaux — options de confidentialité, ou opt-out complet :

kilden.init('YOUR_WRITE_KEY', {
sessionRecording: {
sampleRate: 0.1, // enregistre 10 % des sessions
maskAllInputs: true, // défaut — voir la confidentialité plus bas
minimumDurationMs: 2000, // écarte le bruit sous 2 s
},
});

Un sessionRecording: false local gagne toujours sur la config distante — le code d’enregistrement n’est même pas téléchargé. Voir la référence du SDK pour le chargement eager vs lazy et les contrôles manuels startSessionRecording() / stopSessionRecording().

Les nouveaux projets démarrent à 100 % pour que vos premières sessions apparaissent sans réglage ; à mesure que le trafic augmente, baissez le taux dans les réglages du projet. Dès que /decide répond, la configuration distante l’emporte toujours, dans les deux sens : activée, elle applique le taux du projet ; désactivée, c’est le kill switch — l’enregistrement s’arrête et même un startSessionRecording() manuel est bloqué. Le sampleRate local du SDK (10 % par défaut) ne couvre que la fenêtre avant l’arrivée de la réponse. La décision est prise une fois par session et elle colle : les rechargements la conservent, et un nouveau tirage a lieu quand la session tourne après 30 minutes d’inactivité. Le taux d’échantillonnage effectif peut aussi être fixé à distance depuis les réglages du projet.

Les défauts du replay sont délibérément plus stricts que ceux de l’autocapture, parce qu’un enregistrement montre ce que l’utilisateur tape :

Contrôle Défaut Effet
maskAllInputs true Tout ce qui est tapé dans les champs de saisie est masqué. Le désactiver est une décision explicite
maskAllText false Masque tout le texte de la page, pas seulement les champs de saisie
blockSelectors Les éléments correspondant à ces sélecteurs ne sont pas enregistrés du tout
recordCanvas false Le contenu des canvas est ignoré

Deux attributs DOM fonctionnent à travers tout le SDK :

  • data-kilden-no-capture — exclut entièrement l’élément et ses descendants de l’autocapture et des enregistrements.
  • data-kilden-mask — enregistre la structure mais masque le contenu (texte et champs de saisie) de l’élément et de ses descendants.
<section data-kilden-mask>
<!-- structure visible dans le replay, contenu masqué -->
</section>

Un enregistrement partage son id de session avec les événements de la session, donc replays et timelines d’événements se joignent en 1:1 — “regarder les sessions de tous ceux qui ont abandonné le checkout” est une requête, pas une recherche. Quand l’enregistrement démarre, le SDK émet $session_recording_started dans votre flux d’événements. Un enregistrement ne franchit jamais une frontière de session : la rotation de session le coupe.

Les données de replay ne voyagent pas avec vos événements : les chunks sont compressés en gzip dans le navigateur et postés vers {apiHost}/replay (max 4 MiB par chunk), avec les métadonnées d’enregistrement dans des headers — jamais dans l’URL, pour que rien de sensible ne finisse dans les logs d’accès. Les sessions courtes (sous minimumDurationMs, 2 s par défaut) sont écartées. Les enregistrements sont conservés 30 jours.