Session replay and GDPR

Is a session recording personal data?

Usually, yes. A recording is linked to a session ID, often to an account ID, and may show names, addresses or order details on screen. Under GDPR, data that can be linked to a person, directly or indirectly, is personal data. Treat recordings that way even after masking.

Do you need consent?

Two separate rules apply.

The ePrivacy rules (the “cookie law”) require consent before you store or read information on the visitor’s device, unless it is strictly necessary for a service they asked for. Replay is not strictly necessary. Whether a given script triggers this rule depends on what it stores. Replayowl’s recorder sets no cookies and does not use localStorage; it keeps a session ID, the time of the last activity and the user ID you pass in sessionStorage, which is cleared when the tab closes. Regulators read the rule as covering any storage on the device, so many sites ask for consent anyway.

GDPR requires a legal basis for processing. For replay this is usually consent, or legitimate interest backed by a written assessment. Which one fits depends on your country’s regulator, your purpose and how intrusive the recording is.

If you decide to ask for consent, start the recorder only after the visitor agrees:

// Load recorder.js without data-endpoint, then:
onConsent(() => ReplayOwl.start({ endpoint: "https://replay.example.com/api/ingest" }));

Collect less

• Mask in the browser. Masking on the server is too late, since the data has already left the device. Replayowl masks every text input, email addresses and runs of 12 to 19 digits before upload. Password and card fields can never be unmasked.
• Block whole areas. Mark account pages, health data or messages with data-ro-block so they are not recorded at all.
• Record only where it helps. Put the script on the pages you need to debug, not on every page by default.

Details are in masking and privacy.

Know who processes the data

With a hosted replay tool, the vendor receives every session. You need a data processing agreement, a transfer mechanism if the data leaves the EEA, and a line in your privacy notice. Some vendors are not even your processor: Microsoft Clarity’s terms make you and Microsoft independent controllers. See Replayowl vs Clarity.

With a self-hosted tool, recordings go only to infrastructure you control. Your hosting and storage providers are processors you probably already have agreements with, and there is no additional vendor in the chain. You can pick a bucket region in the EU and keep the whole flow there.

Keep it short

Decide how long you keep recordings and write it down. Thirty to ninety days is common for debugging and support. Replayowl keeps recordings until you delete them, so set a lifecycle rule on your bucket and a scheduled job that removes old database rows. See storage and your data.

Answer access and deletion requests

If someone asks for their data or asks you to delete it, you need to find their sessions. Passing your own user ID to the recorder with ReplayOwl.identify() makes that a search instead of a guess. Delete a session from the dashboard or with DELETE /api/sessions/:id, which removes both the recordings and the database rows.

Checklist

1. Decide your legal basis, and whether you ask for consent before recording.
2. Mention session replay in your privacy notice: what, why, how long, and who processes it.
3. Keep default masking on, and block sensitive areas.
4. Know where recordings are stored, and sign processor agreements where needed.
5. Set a retention period and enforce it.
6. Make sure you can find and delete one person’s sessions.

For how Replayowl handles each of these, read security and privacy.