Personal data handling

The Contentsquare tag masks Personal Data before it leaves the browser and offers configurable commands, HTML attributes, and encrypted-collection modes to control what is sent and stored.

Personal Data handling on the Contentsquare tag relies on three layers:

1. Automatic Personal Data Redaction — the tag detects common patterns (emails, JWTs, OAuth tokens, credit card numbers) and redacts them before any data leaves the browser. See Automatic Personal Data Redaction.
2. Masking features you configure — commands and HTML attributes to mask or strip Personal Data from URLs, API error URLs, DOM content, and clicked element text. See Masking features.
3. Controlled Exposure — collect and encrypt selected values client-side so Contentsquare cannot see them, and decrypt only with your private key when reviewing replays. See Controlled Exposure.

Some data is sent as-is and is not automatically masked — most notably identity strings (identify), user properties, event names, event/pageview properties, and ecommerce item data. You are responsible for ensuring these do not contain Personal Data. See Data sent as-is.

The Contentsquare tag automatically detects and replaces certain types of personal data before any information leaves the browser. This happens without any configuration.

The types of personal data that are detected depend on the data channel.

Not every detection applies everywhere. The table below shows exactly which personal data types are masked in each data channel.

Also, the following data-specific protections are always applied:

• JavaScript errors: form field values (patterns like value="...") are redacted in error messages.
• Custom errors: phone numbers and name patterns (for example firstName=, lastName=, userName:"...") are also redacted in error messages.
• API errors: the query string is stripped entirely from the collected URL, in addition to the masking listed above.
• Clicked element text: if the text of a clicked button or link contains an email address or a credit card number, the entire text is dropped and not collected.

The following data is transmitted without any Automatic Personal Data Redaction. If these channels may contain personal data, you are responsible for ensuring it is removed before sending it to Contentsquare.

Beyond Automatic Personal Data Redaction, Contentsquare provides several commands and HTML attributes to mask or strip Personal Data from specific channels. This section lists every available feature and explains how and where to use them.

The following commands and attributes are available to control Personal Data collection. Each is detailed in the corresponding section below or in the Command Reference.

The tag exposes several commands to attach identity or attributes to a user. None of these values are automatically masked — what you pass is what is sent and stored.

• identify: associates an identity string with the current user. The value is sent as-is unless you use the { hash: true } option, which hashes it client-side. Prefer non-directly-identifying values (UUIDs, account numbers) over emails or phone numbers. See Track Users → Best practices for the trade-offs of client-side hashing.
• resetIdentity: clears the identity associated with the current user. Use it on logout so a subsequent user on the same device does not inherit the previous identity.
• addUserProperties, customProperties:visit:add, customProperties:page:add: attach custom properties to the user, visit, or pageview. Keys and values are sent verbatim — do not pass Personal Data in either.

For the full API, see Track Users.

Sessions will be collected for Session Replay if:

• The Session Replay feature has been enabled for your account
• The threshold set by the Session Replay Collection Rate is not exceeded

For the HTML content to be sent, all these conditions must be true:

• The user hasn't opted out
• The session is being tracked
• The browser is compatible
• The session has been flagged as "Collected for Session Replay", using the _cs_s cookie

If Session Replay is turned on and data collection is active for the session, the HTML content of the page is sent after every pageview (both natural and artificial) and every DOM change (only the updated elements are sent).

The Page Masking setting controls how much of the page content is collected.

The following protections apply regardless of Page Masking state: Contentsquare never collects the actual text typed into any <input> or <textarea> field.

• The content of <input> elements with type text, email, password, search, tel, url or <input> elements without a type attribute are replaced with bullets before the HTML is sent
• Every figure of <input> elements with type number are replaced by 0
• The content <textarea> elements is replaced with bullets before the HTML is sent
• The content inside any element with the contenteditable property as "true" is replaced with bullets before the HTML is sent
• The content of <script> elements is emptied
• Except for the items listed previously, all the HTML content is sent, including <head>
• The content of every element marked with the data attribute data-cs-mask is removed (see the Tagging DOM elements section)

The following protections apply regardless of Page Masking state: Contentsquare never collects the actual text typed into any <input> or <textarea> field.

• The content of <input> elements with type text, email, password, search, tel, url or <input> elements without a type are replaced with bullets before the HTML is sent
• Every figure of <input> elements with type number are replaced by 0
• The content <textarea> elements is replaced with bullets before the HTML is sent
• The content inside any element with the contenteditable property as "true" is replaced with bullets before the HTML is sent
• The content of <script> elements is emptied
• The content of every element marked with the data attribute data-cs-mask is removed (see the Tagging DOM elements section)
• The content of every element marked with the data attribute data-cs-capture is collected and shown unless it falls under the excluded elements listed above (<input>, <textarea>)
• Every character of the text content included in the elements sent is replaced by "A"
• Attributes unrelated to layout are removed. Only id, class, style, src, srcset, href, rel, and type are kept

In case your site displays Personal Data only on a specific set of pages, you can decide to run the Page Masking process only on a pre-defined set of pages, so that you won't have to apply the masking across the whole site. These can only be configured by your dedicated Success Manager.

There are two available options:

• Mask all pages except: All pages will be masked except the ones defined by a Regex Pattern agreed with your Success Manager.
• Unmask all pages except: All pages will be collected with clear content except from the ones defined by a Regex pattern agreed with your Success Manager

Use the excludeURLforReplay command to block data collection on pages based on their URL. Use cases include:

• Personal data has been exposed
• Exclude whole parts of your website from being collected for Session Replay
• Some page replays for Session Replay cause performance issues (when the page contains many images or videos, for instance) — you can block these pages until the problem is fixed

window._uxa = window._uxa || [];
window._uxa.push(["excludeURLforReplay", "URL_REGEX"]);

This command is scoped to the current pageview and must be rerun every time the tag loads.

Using this command does not block pageviews for the given pages — it only blocks data collection for Session Replay.

There are two methods to remove content from the collected HTML:

1. Using the Contentsquare Personal Data Selector
2. Tagging DOM Elements

Each DOM element to be masked is identified by its CSS selector, and those selectors are pushed to the API via a JavaScript object. The content of the identified element is removed from the replay.

Push the following object containing CSS selectors for text and attributes to the API, before firing the main tag:

window._uxa = window._uxa || [];
window._uxa.push(['setPIISelectors', PIIObject]);

The structure of the PII Object is as follows:

• PIISelectors: Comma-separated list of CSS selectors which allow the matching DOM elements to be masked by the tag.

• Attributes: Using this key, you can remove the defined attributes of the DOM elements from the elements matching the CSS selectors. You can use an array of attribute names as shown in the example above.

Keep in mind that using both PII Selectors and Attributes is optional, meaning you can use either full element selectors, specific attribute selectors or both in the same object:

{
  PIISelectors: [".css-selector, selector"], // DOM elements to be masked
  Attributes: [
      {
          selector: "select#month option, select#year option", // CSS selector(s)
          attrName: 'id' // Attribute name you want to mask
      },
      {
          selector: ".link-page-7", // CSS selector(s)
          attrName: ['href','name'] // Array attribute names you want to mask
      }
  ]
};

To exclude content from being collected, use the data-cs-mask attribute on selected elements:

Content before
<p data-cs-mask>emailaddress@sentitivedata.com</p>
Content after

Their content is removed in the browser before it is sent to Contentsquare:

Content before
<p data-cs-mask>emailaddress@sentitivedata.com</p>
Content after

You can also add the data-cs-mask attribute with JavaScript provided you do it before any pageview is sent.

Events on removed HTML — Events (click, hover, etc.) will still be collected and sent to our servers even if they are targeting removed HTML elements. They will be visible in the application using Live Resources (as named in the platform).

There are two methods to display content in a masked HTML page:

1. Using the Contentsquare Personal Data Selector
2. Tagging DOM Elements

Each DOM element to be displayed is identified by its CSS selector, and those selectors are pushed to the API via a JavaScript object. The content of the identified element is displayed in Session Replay.

The string which contains comma-separated CSS selectors for text and for attributes must be pushed to the Contentsquare API, before firing the main tag, as follows:

window._uxa = window._uxa || [];
window._uxa.push(["setCapturedElementsSelector", "#capture-me, .show-me"]);

To display an HTML element in a masked page, add the data-cs-capture attribute to the HTML elements:

Sensitive Content before
<p data-cs-capture>some piece of text that is not sensitive</p>
Sensitive Content after

Content that is part of the tagged element is captured as is:

AAAA AAAA AA
<p data-cs-capture>some piece of text that is not sensitive</p>
AAA AAA AA

It can also be added with JavaScript, but attributes must be added before any pageview is sent.

• Have Google Chrome installed
• Download the Contentsquare Tracking Setup Assistant ↗ Chrome Extension
• Mask elements from the replay using CSS selectors or the data-cs-mask attribute — <input> elements are not captured by default, except dropdowns which still need masking
• Activate full session masking
• If you have already provided us with a list of your internal/office IPs for us to add to our exclusion list, inform your Contentsquare Success Manager to temporarily pause that exclusion list. Otherwise, sessions run from such an IP will not be collected by Contentsquare

1. Start a journey on your website, featuring the elements to be masked.

2. In the Contentsquare Tracking Setup Assistant extension, select Turn off automasking to prevent 'AAA' masking from affecting your local session.

   

3. Select Collected for Session Replay to enable Session Replay data collection for your session.

   

4. Select Trigger testing pageEvent to create the SR Testing page event which identifies your current session.

   

5. Make sure that the elements to be masked are visible as you progress along your testing journey. If required, fill out any test personal information. You will be able to check this information has been masked in the resulting replay.

6. Once you are done testing, close your session by either closing the session's tab or deleting your cookies.

   

7. Watch the replay and look for all the areas where Personal Data could appear:

• ❌ If Personal Data is visible, update your masking and test again.
• ✅ If there were no Personal Data, you are covered in terms of Privacy compliance.

If you are currently in the initial implementation phase of your project, inform your Success Manager about the results so they can double-check and then turn Page Masking off for you to use full Session Replay.

If you are not in implementation and your tests are successful, you can update the Page Masking rules directly from the Console in Contentsquare if you are an Admin, by going to the Page Masking tab.

For instructions, see the Help Center article ↗.

HTML content is sent via requests to one of the endpoints listed below, based on where data is stored for your project:

• https://k.aeu1.contentsquare.net/{apiVersion}/recording
• https://k.aus1.contentsquare.net/{apiVersion}/recording
• https://k.eu1.az.contentsquare.net/{apiVersion}/recording
• https://k.us1.az.contentsquare.net/{apiVersion}/recording
• https://k.ba.contentsquare.net/{apiVersion}/recording
• https://k.bf.contentsquare.net/{apiVersion}/recording
• https://k.aa.contentsquare.net/{apiVersion}/recording
• https://k.af.contentsquare.net/{apiVersion}/recording

The request is sent when the 2nd value of the _cs_s cookie (Session Replay data collection state) is 3 (collected) or 5 (collected after a specific trigger) or when ETR is enabled on the project. The request contains all the DOM.

Personal data appears in more places than just the HTML content.

For a given page, you also need to mask Personal Data found in:

• The path of the current page
• The query string parameters of the current page
• The referrer of the next visited page

Unmasked data could be exposed in the Error Analysis module.

To remove Personal Data in the URL of the current page, rewrite the URL of the pageview before the tag collects it, using the setPath command.

The setPath command takes as a parameter the exact new path to collect as a URL.

window._uxa = window._uxa || [];
window._uxa.push([
  'setPath', <NEW_PATH_TO_COLLECT>
]);

Call this command on every page where the URL contains Personal Data, before the main Tracking tag is loaded. Only the path is to be configured, not the whole URL.

window._uxa = window._uxa || [];
window._uxa.push(["setPath", "/users/CS_ANONYMIZED_USER_ID"]);

When Personal Data can be found in the query parameters of an URL, use the setQuery command to replace the query string within the URL with a new masked one.

window._uxa = window._uxa || [];
window._uxa.push([
  'setQuery',
  <ANONIMYZED_QUERY_STRING>
]);

The setQuery command takes as a parameter the exact new query string to display within the URL. This command instructs the tag to replace the part of the URL after the ? with masked values.

Call this command on all pages where the URL contains Personal Data, and before the main tag is loaded. Only the query string is to be configured, not the whole URL.

window._uxa = window._uxa || [];
window._uxa.push(["setQuery", "?user_id=CS_ANONYMIZED_USER_NAME&address=CS_ANONYMIZED_ADDRESS"]);

Customize the masked term according to the type of the parameter to replace, so that the result is explicit:

• CS_ANONYMIZED_USER_ID
• CS_ANONYMIZED_EMAIL
• CS_ANONYMIZED_ADDRESS

...and more.

Even when you have masked Personal Data in URLs and query parameters on a page, they propagate to the next visited page through the referrer ↗. To handle this use case, use the referrer: commands below.

Consider this journey:

1. Users navigate from https://www.example.com/users/123456/products/ABCDEF to https://www.example.com/.
2. A pageview is sent on https://www.example.com/.
3. The referrer value in both the browser and in the pageview request is https://www.example.com/users/123456/products/ABCDEF.

To mask Personal data in the URL within the referrer, use the referrer:maskUrl command:

var referrers = [
  "https://www.example.com/users/:USER_ID/products/:PRODUCT_ID",
  "https://www.example.com/account/cancelOrder/:ORDER_ID",
  "https://www.example.com/order/:ORDER_ID/merge/:ORDER_ID",
];
window._uxa = window._uxa || [];
for (var i = 0; i < referrers.length; i++) {
  window._uxa.push(["referrer:maskUrl", referrers[i]]);
}

The referrer value in the pageview request for https://www.example.com/ will be:

• https://www.example.com/users/CS_ANONYMIZED_USER_ID/products/CS_ANONYMIZED_PRODUCT_ID
• https://www.example.com/account/cancelOrder/CS_ANONYMIZED_ORDER_ID
• https://www.example.com/order/CS_ANONYMIZED_ORDER_ID/merge/CS_ANONYMIZED_ORDER_ID

Consider this journey:

1. Users navigate from https://www.example.com/confirmation?firstname=jon&lastname=snow to https://www.example.com/.
2. A pageview is sent on https://www.example.com/.
3. The referrer value in both the browser and in the pageview request is https://www.example.com/confirmation?firstname=jon&lastname=snow.

To mask Personal data in the query string part of the referrer, use the referrer:removeQueryString command:

window._uxa = window._uxa || [];
window._uxa.push(["referrer:removeQueryString"]);

The referrer value in the pageview request for https://www.example.com/ will be:

https://www.example.com/?

Use the networkRequest:maskUrls command to rewrite the URL before the tag collects the API error URL.

The command takes as parameter one or several masking patterns to apply to URLs containing Personal Data. Patterns can match the full URL of the page or only a part of it.

window._uxa = window._uxa || [];
window._uxa.push([
  'networkRequest:maskUrls',
  <PATTERN>
]);

Patterns include the URL fragments to mask as variables prefixed by a colon. Such variables are replaced by CS_ANONYMIZED_{FRAGMENT}:

• :user_id becomes CS_ANONYMIZED_USER_ID
• :address becomes CS_ANONYMIZED_ADDRESS
• :email becomes CS_ANONYMIZED_EMAIL

Call this command on all pages containing Personal Data which call the Contentsquare API, and before the main tag is loaded.

window._uxa.push([
  "networkRequest:maskUrls",
  ["order/:order_id/merge/:order_id", "order/:order_id/item", "cancelOrder/:order_id"]
]);

When clicked element collection is turned on and data collection is active for the session, the tag collects the text payload of the buttons and links being clicked as part of other analytics payloads (see /events request).

The clicked element will be collected except if it is masked by data-cs-mask.

The clicked element will not be collected except if data-cs-capture is present on the clicked button or link.

You can also mask specific elements on the webpage. This masking takes priority over Page Masking configuration. For more information, see personal data selector section.

The Contentsquare Tracking Tag does not collect any text typed into input or textarea fields.

If you need to display the personal data of a user, such as shipping/delivery addresses, names, phone numbers, email addresses, or text inputs in a form field, use the collect and encrypt mode.

With the collect and encrypt mode, you can collect, store, and display text in input, textarea fields, or any other element within a page that is usually masked by the tag, before it is sent to Contentsquare's servers.

There are two methods to collect and encrypt personal data from the collected HTML:

• Using the Contentsquare Encryption Selector
• Tagging DOM Elements

Each DOM element to be collected and encrypted is identified via its CSS selector. These selectors are pushed to the API via a JavaScript object. The content of the identified element is then encrypted and collected for Session Replays.

The following object that contains CSS selectors for text should be pushed to the API as follows, before firing the main tag:

window._uxa = window._uxa || [];
window._uxa.push(["setEncryptionSelectors", "#cart, .total-items"]);

The data-cs-encrypt attribute can be added on an input field, textarea field, or any other element. Instead of being masked, the text in the tagged element is encrypted, stored, and made available for exposing under specific conditions.

The encryption process happens on the innerText property of the tagged element. It does not apply on nested elements: the text of the nested element won't be masked nor encrypted. Make sure to add the data-cs-encrypt attribute on the most granular elements that must be collected.

<h2 class="welcoming">
  Welcome back
  <span class="user_name" data-cs-encrypt>John Doe</span>
</h2>

You can also add the data-cs-encrypt attribute with JavaScript provided you do it before any pageview is sent.

To use Controlled Exposure, obtain a combination of encryption keys:

• Public key: used by the Tracking Tag to encrypt the data
• Private key: used by the app for decryption

1. Copy the following script:

   function arrayBufferToString(buffer) {
     const byteArray = new Uint8Array(buffer);
     let byteString = "";
     for (let i = 0; i < byteArray.byteLength; i += 1) {
       byteString += String.fromCodePoint(byteArray[i]);
     }
     return byteString;
   }
   
   crypto.subtle
     .generateKey(
       {
         name: "RSA-OAEP",
         hash: "SHA-256",
         modulusLength: 4096,
         publicExponent: new Uint8Array([1, 0, 1]),
       },
       true,
       ["encrypt", "decrypt"],
     )
     .then((keysObject) => {
       crypto.subtle.exportKey("pkcs8", keysObject.privateKey).then((result) => {
         const privateKey = btoa(arrayBufferToString(result));
         console.log(`Private key: `, privateKey);
       });
       crypto.subtle.exportKey("spki", keysObject.publicKey).then((result) => {
         const publicKey = btoa(arrayBufferToString(result));
         console.log(`Public key: `, publicKey);
       });
     });

2. Paste the script in the Chrome console.

3. Press enter on the keyboard.

On linux/Mac, you can use OpenSSL:

openssl genpkey -out mykey.pem -algorithm RSA -pkeyopt rsa_keygen_bits:4096
openssl rsa -in mykey.pem -pubout > mykey.pub

On Windows you will need to install WSL ↗.

1. Go to the Contentsquare Console > Choose the account > Choose the project > "Encryption management" tab.
2. Select "Store public key".
3. Paste your preferred public key.
4. Select "Store key".

1. Select the key icon and select Unmask on-screen text
2. Enter in the private key and select decrypt (all replays will be exposed)

With the User Identifier feature, you can search for replays belonging to specific users using a unique identifier. You can search and access all sessions associated with a specific user, for example john@gmail.com, within the selected date range. Use this feature in the case of user feedback or complaints.

The user identifier can be any value which uniquely identifies a user such as a username, an account number, email address, phone number, CRM ID, or loyalty system ID. It is immediately hashed and encoded in a one-way format before it is sent to Contentsquare.

When filtering Session Replays with a user identifier in Contentsquare, the same hashing algorithm is used and both hashes are compared to match the user identifier with its associated replays.

1. Choosing the right User Identifier: Opt for a unique identifier like the email address, username, or account number that is available on the front-end.

2. Collecting User Identifiers: To collect the user identifier, you need to send a page event using the trackPageEvent command, with the prefix @user-identifier@:

   window._uxa = window._uxa || [];
   window._uxa.push(["trackPageEvent", "@user-identifier@user_email"]);

   Or if you pull the identifier from the data layer:

   window._uxa = window._uxa || [];
   window._uxa.push(["trackPageEvent", "@user-identifier@" + dataLayer.Name]);

   The user identifier value is limited to 100 characters.