Atlas

Atlas Help Center

New Ticket

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:

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).

 inputs values get masked (replaced with ***). Children of 

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

 we send about 1.3 MB in the first request and ~30kB in subsequent ones depending on user actions. 

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 

Understanding Session Recording

There is some customer information you may not want to have exposed to your team or to other vendors (eg, Atlas). The best practice is to limit the transmission of this data. We help you achieve this by providing the ability to hide, or redact, customer information from our session recordings.

While what is considered sensitive varies on a case-by-case basis, these items are generally considered sensitive data:

personally identifiable information (PII): eg, name, address, social security number or other identifying number or code, telephone number, email address, etc.) 

payment card industry (PCI) data: credit card/payment information, eg, name, card number, expiration date, and security code

banking information: account name, account address, account type, account number, routing number

By default, we try to redact any of the above information based off of standard web security best practices. Specifically, any input setup like 

We'd strongly recommend you go through a test of your site using fake data and then reviewing the associated session recording so you are aware of what is (and isn't) being tracked.

To customize what is and isn't tracked, you can use the 

 classes. Any inputs that are children of elements with the 

 class are masked (replaced with ***). Any elements that are children of elements with the 

Adjust what is tracked in your session recordings for privacy or performance