Session recording and the GDPR—where should you start?

Session recording may include data that makes it possible to reconstruct how someone used a website and, depending on the configuration, information linked to a visitor identifier. Before implementation, you therefore need to determine the specific purpose, necessary scope, legal basis, method of providing information, retention period and access rules. A masking feature alone does not demonstrate GDPR compliance.

What can a session recording actually include?

Session replay does not have to be a conventional screen video. A tool may record the events needed to reconstruct a visit later: page changes, clicks, scrolling, pointer movement or touch, window resizing and the appearance of the document. The scope depends on the particular technology and its settings.

The French data protection authority CNIL notes that these tools may reconstruct the full path through a website or application and—in some configurations—may also capture entered data. The authority also points to the potential intrusion into privacy caused by the level of detail observed.

This does not mean that every recording contains all of this information. It means that a controller should know what its configuration actually collects. You need to inspect not only what the player displays, but also identifiers, device metadata, URLs, page content and links to the customer profile.

From a usability perspective, analysis is best started with a specific question. Our guide to analysing user behaviour shows how to limit the scope to the visits needed to test a hypothesis instead of collecting data without a clearly defined purpose.

Chat creates its own, narrower dataset: pre-chat fields, message content and technical visit data. These decisions are worth making separately, using the checklist in our article on live chat and the GDPR.

Purpose and data minimisation should come before configuration

‘We want to understand users better’ is too broad an operational justification. A more specific purpose might be: ‘we want to identify order-form errors on mobile devices’ or ‘we want to check whether the new pricing-page layout makes it harder to initiate contact’. Only a description this specific lets you assess which pages, events and retention period are genuinely necessary.

• Page scopeDo you need to record the entire website, or only a selected stage of the process?
• Element scopeWhich forms, content or components should be excluded or masked?
• People and accessWho needs access to recordings, and for what professional purpose?
• Time scopeFor how long is the material useful for the stated purpose?

Data minimisation is not just about hiding passwords. If a website contains health or financial data, private messages or other particularly sensitive content, the first question should be whether that area ought to be recorded at all. Sometimes the right configuration is to exclude the entire page or component.

You must separately assess the legal basis for processing and the rules governing the storage of or access to information on a user’s device. There is no single answer that fits every website. The legal basis, the method of obtaining consent—if consent is required—and the information provided should follow from the specific configuration and a current legal analysis.

Masking reduces risk, but it does not ‘take care of the GDPR’

Masking alters or hides content that the player should not display. It is an important technical control, but it has limits. A selector may stop matching after a website change, a new form may fall outside the rule, and data may also appear in a URL, an error message or ordinary text.

Meetlead can mask input fields, all text or elements selected with selectors. The default configuration masks the contents of input fields. You still need to check your own website: run test visits, go through different form variants, verify the mobile version and repeat the test after changes to the site.

↔ Scroll the table sideways to see all columns.

It is also worth separating roles. Someone fixing a form may need selected recordings that concern the error, but not the full history of an identified customer. The principle of least privilege helps match access to the task.

Legal and organisational questions before launch

• What specific purpose does session replay serve, and how will we determine whether it has been achieved?
• Which categories of data and identifiers may appear in events, metadata and the replay?
• Who is the controller, who is the processor and which agreements are required?
• Which legal basis has been adopted, and is consent or another mechanism required before recording starts?
• How will the user receive clear information about the purpose, scope, recipients and their rights?
• Should a data protection impact assessment be conducted because of the scale, scope or risk?
• Where is the data stored, who receives it and are any international transfers involved?
• How long are recordings needed, and how are deletion and data-subject rights handled?
• Who has access, are actions accountable and when are permissions revoked?
• How often will masking, exclusions and new versions of the website be tested?

The answers should be reflected in processing documentation and the information provided to users. A general description of the principles applied by Meetlead is available in our privacy policy, but every website operator needs documentation tailored to its own implementation and role. When a customer asks for a copy of their data, recordings linked to their contact belong in the review too; our guide to subject access requests in customer support sets out the steps.

A safer six-step implementation process

1. Describe the purpose and owner.One sentence defining the problem, a person responsible and a point at which the analysis ends.
2. Review the data flow.Check events, identifiers, recipients, locations and links to other systems.
3. Conduct a legal assessment.Determine the legal basis, transparency requirements, rules for tracking technologies and any need for an impact assessment.
4. Limit the technical scope.Exclude unnecessary pages and elements, configure masking and set the shortest justified retention period.
5. Test as a user.Go through the website on mobile and desktop using test data only, then inspect the result.
6. Monitor changes.After every significant deployment, check selectors, forms, permissions and whether the information provided is still current.

Use purpose-related criteria to select sessions for analysis instead of opening random visits. Our guide explains how to analyse session recordings. The comparison of session recordings and heatmaps, meanwhile, helps you choose a less detailed source when an aggregate view is sufficient.

General legal basis: Regulation (EU) 2016/679 of the European Parliament and of the Council. This material does not replace an individual legal assessment.