GDPR-Compliant Session Recording with First-Party Infrastructure

Why Traditional Session Recording Tools Are a GDPR Problem

Session recordings inevitably capture personal data: mouse movements combined with page content, filled-in form fields, clicked elements. Under GDPR, this constitutes processing of personal data that requires a legal basis. Most providers rely on consent (Art. 6(1)(a) GDPR), which presupposes a cookie banner with active opt-in.

Yet even with consent, significant risks remain with traditional tools. When the recording library is loaded from an external CDN, a data transfer to third countries occurs, which under the Schrems II ruling requires additional measures. When recording data is stored on US servers, a Data Processing Agreement (DPA) alone is typically insufficient. European data protection authorities have repeatedly clarified that transferring personal data to the US without supplementary measures constitutes a GDPR violation (DSK, 2024).

• External JavaScript: The recording library is loaded from a third-party CDN. The request alone transmits the visitor's IP address to the third party.
• US data storage: Recording data is processed and stored on servers outside the EU. A standard DPA is typically insufficient under Schrems II.
• Recognisable file names: Files like rrweb.min.js or session-replay.js appear on filter lists of uBlock Origin and EasyPrivacy and are blocked, even when loaded from your own domain.
• Missing PII masking: Without active configuration, passwords, credit card numbers and personal data are recorded in plain text.
• Consent loss: Between 30 and 50% of visitors typically decline tracking (Usercentrics). These visitors are not recorded, systematically skewing the data.

The First-Party Approach: Session Recording Without Third Parties

First-party session recording eliminates all the above risks by routing every component of the recording chain through your own infrastructure. No external CDN request, no data transfer to US servers, no recognisable tracking file names. The technical architecture consists of three layers:

Technical Architecture in Detail

rrweb as Open-Source Foundation

rrweb (Record and Replay the Web) is an open-source library (MIT licence) that records DOM mutations, mouse movements and interactions as compact JSON events. Unlike video-based approaches, no pixels are recorded, but structured data that requires significantly less storage and can be filtered retrospectively. XICTRAQ uses rrweb as a foundation and extends it with automatic PII masking, chunk-based streaming and compression.

Obfuscated File Names Against Adblockers

A frequently overlooked problem: even if you serve rrweb from your own domain, adblockers like uBlock Origin recognise the file by its name. rrweb.min.js is on the EasyPrivacy filter list and is blocked regardless of origin. XICTRAQ solves this by serving the library under obfuscated file names: rx.js for the recording library, rxp.js and rxp.css for the player. These names are not on any known filter list (as of 2026).

First-Party Proxy via Nginx

The first-party proxy ensures that all data flows between visitor and recording server pass through your own domain. A simple Nginx location block forwards the /a/ path to the XICTRAQ API server. For the visitor and their browser, every request appears to go to your domain. This has three advantages: no third-party request in the browser DevTools console, no cross-origin issues with CSP headers, and no entry on adblocker filter lists. The proxy setup typically takes just a few minutes.

NDJSON Streaming and Compression

XICTRAQ uses NDJSON (Newline-Delimited JSON) for streaming recording data. Each interaction is sent as a single JSON line, enabling robust chunk-based streaming. If the connection drops, only data since the last chunk is lost, not the entire recording. After the recording ends, data is automatically compressed via gzip, which typically yields around 70% storage savings.

Automatic PII Masking: Mandatory, Not Optional

Personal data in session recordings is the biggest GDPR risk. If a password, IBAN or credit card number is recorded in plain text, a reportable data breach has occurred. Manual PII masking configuration is error-prone because every new form field must be individually marked.

XICTRAQ employs multi-layered automatic PII masking that works without manual configuration:

• Input type detection: All input[type=password], input[type=email], input[type=tel] and textarea fields are automatically masked. Content is replaced with placeholder characters.
• Attribute-based detection: Fields with name or id attributes like iban, credit-card, date-of-birth, social-security are masked regardless of input type.
• CSS class whitelist: The data-private CSS class can be used to manually mark additional elements as sensitive. Conversely, elements without this marking remain visible.
• Regex-based post-filtering: Patterns like IBAN (country code + digits), credit card numbers (16 digits) and email addresses are detected and masked server-side before storage.

Opt-in Model: data-record as Consent Gate

Session recording in XICTRAQ is disabled by default. Activation is controlled via the HTML attribute data-record="1" in the tracker snippet. This attribute can be set dynamically, for example after the visitor has actively consented via a cookie banner. Without data-record="1", no recording library is loaded, no DOM observer is started, and no recording event is sent.

<script defer src="https://www.your-site.com/t.js"
        data-site="YOUR_SITE_ID"
        data-record="1"></script>

Recording starts only after a xictraq.consent('granted') call, regardless of which consent mode is stored in the dashboard: the stored mode could only open the gate, and recording without consent is not covered by § 25 TDDDG. The cookieless aggregate measurement keeps running alongside it in both modes, because it is exempt from consent under § 25(2)(2) TDDDG. The combination of opt-in recording and consent gate follows the recommendations of European data protection authorities for GDPR-compliant website tracking.

Practical Setup: Three Steps

Setting up first-party session recording with XICTRAQ requires three steps, typically completed in under 15 minutes:

1. Include tracker snippet: Add the XICTRAQ snippet with data-record="1" to your website's <head>. The tracker automatically detects the base URL and loads the recording library (rx.js) from your domain. No separate script inclusion is required.
2. Configure first-party proxy: Set up a reverse proxy in your Nginx or Apache configuration for the /a/ path, forwarding requests to api.xictraq.com. Detailed instructions are available in the proxy documentation. Alternatively, recording works without a proxy — data is then sent directly to the XICTRAQ API.
3. Consent integration: Connect your cookie banner with the XICTRAQ consent API call xictraq.consent('granted'). Recording only begins after this call. With cookieless base tracking without a banner, recording is controlled separately via the data-record attribute.

Evaluating Recordings in the Dashboard

The XICTRAQ dashboard displays all recorded sessions in a filterable list. Each session contains metadata such as start time, duration, page count, device and operating system. The integrated player replays the recording as a DOM replay — no video files, but an exact reconstruction of visitor interaction.

Automatic tags classify sessions by behavioural patterns: rage_click (multiple rapid clicks on the same element), error (JavaScript errors during the session) and conversion (completed purchase or form submission). These tags are updated every 30 minutes via cron job and enable targeted filtering for problematic sessions. Combined with heatmaps, this provides a complete picture of user interaction.

Data Protection Legal Assessment

Session recording with first-party infrastructure and opt-in consent can be based on two GDPR legal grounds:

• Consent (Art. 6(1)(a) GDPR): The safest approach. The visitor actively agrees to recording before the recording library is loaded. The xictraq.consent('granted') call technically enforces this flow: without it, no recording starts.
• Legitimate interest (Art. 6(1)(f) GDPR): Theoretically possible if recording is limited to what is technically necessary (own domain only, no third-party transfer, complete PII masking). In practice, data protection authorities typically still recommend consent.

The crucial point is that all three prerequisites are met: First, no data transfer to third countries (EU hosting and first-party proxy). Second, automatic PII masking that anonymises sensitive fields before storage. Third, technically enforced opt-in that only starts recording after active consent. XICTRAQ fulfils all three prerequisites architecturally, not through retrospective configuration.

Comparison: Third-Party vs. First-Party Session Recording

Storage Efficiency and Data Retention

Session recordings generate substantial data volumes. A single 5-minute session can produce between 2 and 10 MB of uncompressed NDJSON data, depending on page complexity and interaction frequency. XICTRAQ compresses completed recordings via an hourly cron job to .ndjson.gz, which typically yields approximately 70% reduction.

Data retention is plan-dependent, ranging from 7 days (Starter) to 2 years (Enterprise). Older recordings are automatically deleted, serving both storage efficiency and the GDPR data minimisation principle (Art. 5(1)(c) GDPR). The current pricing overview shows retention periods per plan.

UX Optimisation with Session Recordings: Practical Examples

The most valuable insights from session recordings often lie in details that quantitative analysis cannot capture. Here are some typical use cases:

• Identify rage clicks: A visitor clicks rapidly multiple times on an element that does not respond. This indicates a UX problem — a supposed button that is not one, or a loading process without feedback.
• Understand form abandonment: Why do visitors abandon a checkout form at field 4 of 6? The form field may require a format that is not communicated, or the error message is not visible.
• Test mobile navigation: How do visitors interact with the hamburger menu? Do they find the subpages? Combined with click heatmaps, mobile navigation weaknesses become visible.
• Contextualise JavaScript errors: An error log shows TypeError: undefined is not a function. The session recording shows which action triggered the error and whether the visitor left the page afterwards.

Session Recording as Part of a Privacy-First Analytics Strategy

Session recording is not an isolated tool but part of a comprehensive analytics strategy. Combined with cookieless base tracking, click heatmaps, form analytics and A/B testing, it creates a complete picture of user behaviour — without sending a single data point to third parties.

XICTRAQ's unified tracker approach means all analytics features are controlled through a single script snippet (t.js). Session recording is toggled on demand via the data-record attribute, without needing to include an additional library. This reduces complexity and ensures all data flows pass through the same first-party proxy. Detailed information about all analytics features is available on the feature page, and a free demo is available without registration.

Frequently Asked Questions About GDPR-Compliant Session Recording