Exatom is a cookieless, privacy-first platform by design. We also took that route whilst developing our Session Replay product.

Exatom's default privacy measurements for Session Recordings, all occurring locally within the user's browser before any data is sent to Exatom:

• All data within forms is never recorded and replaced with * characters

  • Regardless of whether data was pre-filled, auto-filled or manually entered by the customer

• All numeric data is replaced with # characters (this includes phone numbers and other possible numeric sensitive data points)

• All numeric dates are replaced with the date 01/01/1970

• All email addresses are replaced with privacy@exatom.io
  

• The following non-end-user visible data within the HTML code is also removed, as this could contain personal data
  

• HTML attributes: alt, placeholder, title, value, checked
  

• HTML data attributes: any attribute of this type starting with data-
  

• All data of an HTML element is removed if it has the attribute 'itemprop'
  

Consult our data journey to learn more about the data captured for Session Replays.

Additional privacy measures

Additional measures can be taken by the content management team by adding a CSS class to HTML elements that will instruct Exatom not to record certain HTML elements or mask the texts within those.

For teams that are upgrading or already have implemented blocking or masking measures from other providers like FullStory, Hotjar, or rr-web; We automatically include those, and no changes need to be made. This includes the following CSS classes (rr-block, fs-exclude, fs-block, data-hj-suppress, fs-mask, rr-mask).

Blocking complete parts of your page with ex-block

This option is best suited for pages or sections where the nature of the information, even in masked form and/or customer behaviour with the element, makes it possible to infer personal details about the customer.

Text replacement for part of your page with ex-mask

To Mask or Block: best practices

Careful consideration is needed when deciding whether to mask or block an element from Session Recordings. There are a few scenarios where blocking (most strict) may be preferable to masking:

Blocking is advisable if the element contains regulated information like health, education, financial or other personal data. Personal details like Social Security numbers, license numbers, bank accounts or passwords should also be excluded.

Even with masking, some elements could allow inferences if the customer interacts with them. For example, masking the checkboxes on health sites where users select medical conditions may still reveal conditions chosen if interaction data is recorded. Similarly, account balances masked with placeholders of varying lengths could identify accounts.

Examples that help illustrate this:

1. A health site uses checkboxes for conditions. Masking text alone wouldn't prevent determining a user's health issues from interaction data. Blocking is better to avoid inferences.

2. Financial apps show account balances. Even masked with placeholders, longer placeholders could identify larger balances than shorter ones. Fields like balances should be upgraded to blocking.

3. Masking usernames but keeping following/follower counts on social networks could still help identify accounts based on their level of influence. Removing such engagement data reduces re-identification risk.

In summary, blocking should be considered when user privacy could be compromised even after masking - through regulated data, personal details or inferences from interactions. If unsure, use blocking.

Important note: Whilst Exatom implements a good set of first-line privacy measures and controls for Session Recordings, it's crucial for teams to create an inventory of what resembles personal data in their legal jurisdiction and make sure no personal data is being transferred to Exatom.