Understanding Session Recording

How our session recordings work

Session recording is a key part of how we give context to support agents that helps them respond faster and better to customers. From a technical standpoint, it's important to understand how our session recording works so that you can make sure it doesn't impact your site performance or data privacy.

Here are the most common questions we get:

what is sent to the server by default?

The DOM model, CSS, and all DOM and CSS updates, including mouse movements, mouse clicks, keypresses, window resizes, scrolls, console logs, XMLHttpRequests and fetch requests (only urls, method and response status code, not payloads).

what is not sent to the server by default?

Any input elements with attributes input[type=password], [name*=ssn] and children of .atlas-mask inputs values get masked (replaced with ***). Children of .atlas-hide are not recorded at all.

how often is data sent?

Every 3 seconds and before page unload (when the tab is closed or user navigates to another page via link).

how much data is sent?

It depends. As an example, in  our own app  we send about 1.3 MB in the first request and ~30kB in subsequent ones depending on user actions.

will it slow down my app?

We use Web Workers so that our session recording happens in a non-blocking, parallel manner to guarantee minimal to no impact to app performance. The exceptions here are any apps that have streaming content as a core feature (eg, video games, video streaming sites, etc.). In these cases, we recommend  hiding the elements  that contain streaming content.