Website Visitor Recording: Privacy & Compliance (GDPR)

The Privacy Landscape for Session Recording

Session recording captures how real users interact with your website—clicks, scrolls, mouse movements, form interactions, and page navigation. This data is extraordinarily valuable for improving user experience, diagnosing bugs, and optimizing conversions. But because it involves observing user behavior, it sits squarely within the scope of modern privacy regulations.

Three regulatory frameworks matter most for organizations using session recording tools:

• GDPR (General Data Protection Regulation) — Applies to any organization that processes personal data of individuals in the EU/EEA, regardless of where the organization is based. It is the most comprehensive and restrictive framework.
• CCPA/CPRA (California Consumer Privacy Act / California Privacy Rights Act) — Applies to businesses that collect personal information from California residents and meet certain revenue or data-volume thresholds.
• ePrivacy Directive (Cookie Law) — Governs the use of cookies and similar tracking technologies in the EU. Often the reason you need a cookie consent banner in the first place.

The good news: these regulations don’t prohibit session recording. They require you to do it responsibly—with transparency, purpose limitation, data minimization, and appropriate safeguards. A privacy-conscious recording setup often produces better data anyway, because it forces you to focus on the behavioral signals that actually matter rather than hoarding raw input data you’ll never use.

What Session Recording Actually Captures (and Doesn’t)

Understanding what a session recording tool collects is the first step toward a compliant implementation. Session recording is not a screen capture or video feed. Instead, it records structured interaction events—mouse coordinates, scroll positions, click targets, page changes—and reconstructs a visual playback from those events.

Here’s what a typical session recording includes:

• Page structure — the layout of each page the user visits (HTML structure, CSS styles)
• Mouse movements and clicks — cursor position over time, click locations and targets
• Scroll behavior — how far the user scrolled and at what speed
• Form interactions — which fields were focused, typed into, or submitted (content can be masked)
• Page navigation — URLs visited within the session, timestamps of transitions
• Viewport size and device info — screen resolution, browser type

What session recording does not capture (when configured properly):

• Passwords — never, under any configuration (see automatic protections below)
• Off-site activity — only pages with the tracking script installed are recorded
• System-level activity — no access to other tabs, applications, files, or camera/microphone
• Personally identifiable input — when masking controls are applied, form values are replaced with placeholder characters

GDPR Compliance for Session Recording

GDPR requires a lawful basis for processing personal data, limits the data you can collect to what is necessary, and gives users specific rights over their data. Here’s how each principle applies to session recording.

Lawful Basis: Legitimate Interest vs. Consent

Under GDPR, you need one of six lawful bases to process personal data. For session recording, two are relevant:

Legitimate interest (Article 6(1)(f)) is the basis most commonly used for analytics and session recording. The argument: your organization has a legitimate interest in understanding how users interact with your website in order to improve it. To rely on legitimate interest, you must:

1. Conduct a Legitimate Interest Assessment (LIA) documenting why recording is necessary, what data you collect, and how you protect user rights
2. Demonstrate that the user’s rights and expectations are not overridden by your interest
3. Apply data minimization—collect only what you need and mask everything else
4. Provide a clear and accessible opt-out mechanism

Consent (Article 6(1)(a)) is the most conservative approach and is required by some interpretations of the ePrivacy Directive for non-essential cookies. If you choose consent as your lawful basis:

• Recording must not start until the user explicitly opts in
• Consent must be freely given, specific, informed, and unambiguous
• Users must be able to withdraw consent as easily as they gave it
• You cannot bundle analytics consent with essential-cookies consent

Data Minimization

GDPR’s data minimization principle (Article 5(1)(c)) requires that you collect only what is adequate, relevant, and limited to what is necessary. For session recording, this means:

• Mask or exclude form fields that contain personal data (names, emails, phone numbers)
• Use global input censoring to default to masked content
• Record only a sample of sessions if full coverage isn’t needed for your analysis
• Set appropriate data retention periods so recordings are deleted when no longer useful
• Disable XHR/AJAX payload recording unless you specifically need to debug API interactions

Right to Erasure

Under Article 17, users can request deletion of their personal data. If a user contacts you requesting erasure, you need a process to identify and delete any session recordings associated with that user. This is easier when recordings are associated with a user identifier (such as a logged-in user ID) and harder when the only identifier is an anonymous session cookie.

Data Processing Agreements

When you use a third-party session recording tool, that tool is a data processor under GDPR, and you are the data controller. Article 28 requires a written Data Processing Agreement (DPA) between controller and processor. Your DPA should address where data is stored, who has access, security measures, sub-processors, and breach notification procedures.

CCPA Compliance for Session Recording

The CCPA takes a different approach from GDPR. Rather than requiring opt-in consent, it gives California consumers the right to know what data is collected, the right to delete it, and the right to opt out of sale of their personal information.

For session recording, CCPA compliance typically involves:

• Disclosure — Your privacy policy must describe that you use session recording technology, what categories of information it collects, and the business purpose
• Do Not Sell — If recorded session data is shared with third parties in a way that constitutes “sale” under CCPA, you must honor opt-out requests. Most session recording use cases (where you use the tool to improve your own site) do not constitute a sale.
• Deletion requests — Honor requests to delete recorded session data associated with a given consumer

The CPRA (effective January 2023) adds the right to correct inaccurate data and introduces the concept of “sensitive personal information,” which requires additional protections. Session recordings that capture sensitive fields (health information, financial data) fall under heightened scrutiny.

Inspectlet’s Built-In Privacy Controls

Inspectlet provides a layered set of privacy controls that let you tailor recording to collect only the behavioral data you need. Here’s a detailed walkthrough of each control.

Automatic Protections

Inspectlet’s tracking script has a hard-coded rule: password fields are never recorded. Any <input type="password"> element is automatically excluded. No keystrokes, no masked values, no data at all. This protection cannot be overridden—it is baked into the script itself, not a configurable setting.

Element-Level Masking with CSS Classes

You can control exactly how individual elements are handled during recording using CSS classes:

Exclude an element entirely with inspectletIgnore:

<!-- This element will not be captured in the recording at all -->
<div class="inspectletIgnore">
    <input type="text" name="ssn" placeholder="Social Security Number">
</div>

Any element with the inspectletIgnore class is completely excluded from the recording. The recording will show a blank space where the element exists. This is the strongest protection—use it for elements containing highly sensitive data like government IDs, financial account numbers, or health information.

Mask element content with inspectlet-sensitive:

<!-- Input values will be replaced with X characters in the recording -->
<input type="text" name="email" class="inspectlet-sensitive"
       placeholder="Email address">

<!-- Text content is also masked -->
<span class="inspectlet-sensitive">John Smith</span>

The inspectlet-sensitive class replaces the content of the element with X characters in the recording. The element is still visible in playback (so you can see that the user interacted with the email field), but the actual value they typed is never transmitted or stored. This is ideal for fields like email, name, phone number, and address—where you want to see the interaction pattern without the personal data.

Whitelist specific elements with inspectlet-whitelist:

<!-- When global censoring is ON, this field is still recorded in clear text -->
<select class="inspectlet-whitelist" name="country">
    <option>United States</option>
    <option>United Kingdom</option>
</select>

The inspectlet-whitelist class is used in combination with global input censoring (see below). When you enable censor-all mode, every input is masked by default—but elements with inspectlet-whitelist are exempted. This is useful for non-sensitive fields like country selectors, language preferences, or sort options where the values help you understand user behavior.

Global Input Censoring

Inspectlet’s dashboard includes a Censor All Inputs toggle for each site. When enabled, every input field, textarea, and select element on your site is masked by default—values are replaced with placeholder characters in the recording. This is the most privacy-conservative approach: you start from a position of “record nothing” and selectively whitelist the specific fields where you need to see values.

This approach aligns directly with GDPR’s data minimization principle. Rather than auditing every form on your site and adding masking classes to sensitive fields (risking that you miss one), you mask everything and then make deliberate exceptions.

IP Blocking

Inspectlet’s site settings include an IP blocking feature where you can enter IP address patterns with wildcard support. Visitors whose IP matches a blocked pattern are not recorded at all. Common uses include:

• Excluding internal employees and QA teams from recording
• Blocking known bot traffic ranges
• Excluding traffic from specific geographic regions where you don’t have legal basis to record

Recording Frequency

A percentage slider (0–100%) in your site settings controls what fraction of visitors are recorded. If your site has high traffic, recording 10–20% of sessions gives you more than enough data for analysis while significantly reducing the volume of personal data you process. This directly supports data minimization—you collect only the sample size you need.

Opt-Out Pages

Inspectlet provides two levels of opt-out for visitors who do not wish to be recorded:

• Per-site opt-out — The URL /exclude/{site_id} presents the visitor with a clear explanation and an exclude button. Clicking it sets a cookie (optout_{site_id}) on .inspectlet.com that prevents recording on that specific site.
• Global opt-out — The URL /optout allows a visitor to opt out of all Inspectlet-powered recording across every website. A single cookie prevents the tracking script from initializing on any Inspectlet-enabled site.

Both opt-out pages clearly explain what the cookie does and provide buttons to opt out or opt back in. You can link to these pages from your privacy policy or cookie notice to give users direct control.

XHR Recording Controls

Inspectlet can optionally record AJAX request and response payloads. This is powerful for debugging (you can see exactly what API data was returned during a user’s session), but it can also capture sensitive data if your API responses include personal information. A toggle in your site settings controls whether XHR payloads are saved. When disabled, network requests are not logged in the recording.

If you enable XHR recording, audit your API responses to ensure they don’t return data you wouldn’t want in a recording (e.g., full user profiles with email and phone number in the JSON response).

Page and Visitor Targeting

Inspectlet’s targeting tool lets you define rules for which pages and visitor segments are recorded. You can whitelist specific pages (record only the checkout flow) or blacklist pages that contain sensitive content (exclude the account settings page). Combined with visitor-segment rules, this gives you precise control over the scope of your recording.

Additional Controls

• Minimum session length — Discard sessions shorter than a threshold. Reduces stored data and filters out bounces that provide little analytical value.
• URL display controls — Configure whether the domain, path, query string, and hash are shown in recorded URLs. Useful if your URLs contain user identifiers or sensitive parameters.
• Iframe control — Add the class inspectlet-disable-iframe-inject to any iframe element to prevent its content from being recorded. Essential for iframes that load third-party content you don’t control.
• Data retention — Recordings are automatically purged after your plan’s retention period. Shorter retention periods reduce your data liability surface.

Privacy Policy Requirements

Both GDPR and CCPA require transparency about your data processing activities. If you use session recording, your privacy policy should disclose:

1. That you use session recording technology and name the provider (e.g., “We use Inspectlet for session recording and analytics”)
2. What data is collected — mouse movements, clicks, scrolls, page views, form interactions (noting that sensitive fields are masked)
3. The purpose — improving website usability, diagnosing errors, optimizing conversion funnels
4. The lawful basis (for GDPR) — legitimate interest in improving the user experience, or consent if that’s your chosen basis
5. Data retention period — how long recordings are stored before deletion
6. How users can opt out — link to the Inspectlet opt-out page and describe any cookie-banner controls
7. Third-party data sharing — clarify that session data is processed by your recording provider and note any sub-processors

Consent Implementation Patterns

If your legal basis is consent (or if the ePrivacy Directive requires cookie consent for your analytics tools), you need to integrate session recording with your consent management platform. Here are the two most common patterns.

Conditional Script Loading

The simplest approach: don’t load the Inspectlet tracking script until the user has consented to analytics cookies.

<!-- Only load Inspectlet after analytics consent is granted -->
<script>
window.addEventListener('analytics_consent_granted', function() {
    window.__insp = window.__insp || [];
    __insp.push(['wid', YOUR_SITE_ID]);
    var ldinsp = function(){
        if(typeof window.__inspld != "undefined") return;
        window.__inspld = 1;
        var insp = document.createElement('script');
        insp.type = 'text/javascript';
        insp.async = true;
        insp.id = "inspsync";
        insp.src = ('https:' == document.location.protocol ? 'https' : 'http')
            + '://cdn.inspectlet.com/inspectlet.js?wid=' + YOUR_SITE_ID
            + '&r=' + Math.floor(new Date().getTime()/3600000);
        var x = document.getElementsByTagName('script')[0];
        x.parentNode.insertBefore(insp, x);
    };
    setTimeout(ldinsp, 0);
});
</script>

This pattern ensures zero data is collected before consent. The recording script simply does not exist on the page until the consent event fires.

Cookie Banner Integration

Most cookie consent platforms (Cookiebot, OneTrust, Osano, etc.) support categorized consent. Map Inspectlet to your “Analytics” or “Performance” category, then gate script loading on that category’s consent status:

<!-- Example with a generic consent manager -->
<script>
if (consentManager.hasConsent('analytics')) {
    // User has already consented — load immediately
    loadInspectlet();
} else {
    // Wait for consent
    consentManager.on('consent_update', function(categories) {
        if (categories.analytics) {
            loadInspectlet();
        }
    });
}

function loadInspectlet() {
    window.__insp = window.__insp || [];
    __insp.push(['wid', YOUR_SITE_ID]);
    var insp = document.createElement('script');
    insp.type = 'text/javascript';
    insp.async = true;
    insp.src = 'https://cdn.inspectlet.com/inspectlet.js?wid='
        + YOUR_SITE_ID + '&r=' + Math.floor(new Date().getTime()/3600000);
    var x = document.getElementsByTagName('script')[0];
    x.parentNode.insertBefore(insp, x);
}
</script>

Industry-Specific Considerations

Beyond GDPR and CCPA, certain industries face additional privacy regulations that affect how session recording can be used.

Healthcare (HIPAA)

If your website collects Protected Health Information (PHI)—patient names, diagnoses, appointment details, insurance information—HIPAA applies. Session recordings that capture PHI constitute an electronic health record disclosure. To use session recording in healthcare:

• Enable Censor All Inputs to ensure no form data is captured in clear text
• Use inspectletIgnore on any page sections that display PHI (patient portals, appointment details)
• Verify that your recording provider will sign a Business Associate Agreement (BAA)
• Consider limiting recording to public-facing marketing pages and excluding authenticated patient areas entirely via page targeting

Financial Services

Banking and financial websites handle account numbers, balances, transaction histories, and Social Security numbers. In addition to GDPR/CCPA:

• Apply inspectletIgnore to elements displaying account numbers, balances, and transaction details
• Use inspectlet-sensitive on account login forms (beyond the already-excluded password field)
• Disable XHR recording to prevent API responses with financial data from being logged
• Consider recording only pre-login marketing pages and the application funnel, not authenticated banking sessions

Education (FERPA)

Educational institutions handling student records must comply with FERPA. Student grades, disciplinary records, and enrollment information are protected. If your educational platform uses session recording:

• Exclude student-facing dashboards that display grades or records from recording via page targeting
• Enable global input censoring on any forms where students enter personal information
• Limit recording to publicly accessible pages or anonymized usage patterns

E-Commerce (PCI DSS)

Any site that processes payment card data must comply with PCI DSS. Session recording of checkout pages requires special care:

• Most modern checkout implementations use hosted payment fields (Stripe Elements, Braintree Hosted Fields) that render card details in an iframe from the payment processor’s domain. These iframes are not accessible to session recording scripts.
• If you use a custom payment form, apply inspectletIgnore to the entire card input area
• Add inspectlet-disable-iframe-inject to payment processor iframes as an additional safeguard
• Never record CVV, full card numbers, or expiration dates—even masked versions should be excluded, not just masked

Building a Privacy-First Recording Strategy

A privacy-first approach isn’t just about compliance—it’s a better way to use session recording. Here’s a framework:

1. Define your questions first. Before enabling recording, identify the specific questions you want to answer. “Why are users abandoning the checkout?” is a good question. “Let’s record everything and see what happens” is not. Purpose limitation is a core GDPR principle, and it also makes your analysis more focused and productive.
2. Start with maximum restrictions. Enable Censor All Inputs. Set recording frequency to 10–20%. Disable XHR recording. Use page targeting to record only the pages relevant to your analysis. You can always loosen restrictions later if you need more data—but it’s much harder to retroactively mask data you’ve already collected.
3. Audit your forms and pages. Walk through every page that will be recorded and identify elements that display or collect personal data. Apply inspectletIgnore or inspectlet-sensitive classes as appropriate.
4. Document everything. Maintain a record of your privacy settings, your lawful basis assessment, the pages you record, and the data you mask. This documentation is required under GDPR (accountability principle, Article 5(2)) and invaluable if you receive a data subject request or regulatory inquiry.
5. Review periodically. As your site evolves, new pages and forms are added. Include session recording privacy in your regular security and compliance reviews. A new feature that adds a health questionnaire form needs recording controls before it ships, not after.

Checklist: Privacy Audit for Session Recording

Use this checklist to audit your session recording implementation. Address each item to build a compliant, privacy-respecting setup.

Legal Foundation

• Lawful basis documented — You have a written Legitimate Interest Assessment or use consent-based recording
• Privacy policy updated — Your policy discloses session recording, the provider, data collected, purpose, retention period, and opt-out instructions
• DPA in place — You have a signed Data Processing Agreement with your recording provider
• Cookie notice updated — If using consent-based loading, your cookie banner includes session recording in the correct category

Technical Controls

• Password fields — Verified excluded (automatic in Inspectlet, but confirm for custom implementations)
• Global input censoring — Enabled as default, with only necessary fields whitelisted
• Sensitive elements masked — All elements displaying PII (names, emails, addresses, IDs) use inspectletIgnore or inspectlet-sensitive
• Page targeting configured — Recording limited to pages relevant to your analysis; sensitive pages excluded
• XHR recording — Disabled unless explicitly needed, with API responses audited for PII
• Iframe control — Third-party iframes (especially payment processors) have inspectlet-disable-iframe-inject
• Recording frequency — Set to the minimum sample size that supports your analysis goals
• IP blocking — Internal team IP ranges excluded from recording

User Rights

• Opt-out accessible — Link to the Inspectlet opt-out page is included in your privacy policy or cookie notice
• Erasure process defined — You have a documented procedure for deleting recordings associated with a specific user upon request
• Consent mechanism working — If using consent-based loading, verified that the recording script does not load until consent is granted (test with browser dev tools)

Ongoing Governance

• Retention period set — Recordings auto-expire after your configured retention period
• Review schedule — Privacy settings reviewed quarterly or when new pages/features launch
• Team training — Staff who view recordings understand data handling obligations and know not to screenshot or export PII from recordings
• Incident response — You have a process for responding to a data breach that includes session recording data

Frequently Asked Questions

Does session recording require cookie consent under GDPR?

It depends on your lawful basis. If you rely on legitimate interest for the processing itself, you may still need cookie consent under the ePrivacy Directive if your recording tool sets non-essential cookies. Many organizations include session recording under their “Analytics” cookie category. If you rely on consent as your GDPR lawful basis, you definitively need cookie consent before loading the script.

Is IP address considered personal data under GDPR?

Yes. The GDPR explicitly classifies IP addresses as personal data because they can be used (sometimes in combination with other data) to identify an individual. This is one reason IP blocking and recording frequency controls are important—they reduce the volume of IP addresses you process.

Can I use session recording on a site with users under 16?

GDPR provides heightened protection for children’s data (Article 8). If your site is directed at or knowingly used by children, you need parental consent for data processing. In practice, most organizations that serve minors either exclude authenticated minor user sessions from recording or avoid session recording on child-directed content entirely.

What should I do if I accidentally record sensitive data?

Delete the affected recordings as soon as possible, document the incident, and add the appropriate masking classes (inspectletIgnore or inspectlet-sensitive) to prevent recurrence. If the data involved constitutes a personal data breach under GDPR (risk to individuals’ rights and freedoms), you may need to notify your supervisory authority within 72 hours.

Does Inspectlet work with Google Consent Mode?

You can implement conditional loading of the Inspectlet script based on Google Consent Mode signals. When the analytics_storage consent type is granted, load the Inspectlet script; when denied, do not load it. This gives you a unified consent experience across all your analytics tools.