- Session recording captures page structure changes—not screenshots or video—producing tiny data payloads (~50–200KB per session minute)
- Installation requires a single asynchronous script tag that won't slow down your site
- Password fields are automatically excluded from recording; additional controls let you mask, ignore, or censor any element
- Ethical recording means giving users clear notice, meaningful opt-out options, and recording only what you need
- GDPR and CCPA compliance requires consent management, data minimization, and a clear legal basis for processing
- You can control recording frequency, target specific pages, filter by session length, and identify users with custom metadata
Why Record Website Visitors?
Analytics tools tell you what happened on your site—page views, bounce rates, conversion funnels. Session recording tells you why. When your checkout abandonment rate spikes to 68%, analytics can confirm the trend, but only a session recording shows you the user staring at a confusing shipping form for 40 seconds before giving up.
The specific problems session recording solves that other tools cannot:
- Identifying friction points that don't show up in quantitative data. A user might complete a form successfully but struggle for two minutes on a single field—that frustration doesn't register in your conversion rate.
- Diagnosing bug reports with full context. Instead of asking users to describe what happened, you watch the exact sequence of actions that led to the issue.
- Validating design changes with real behavior, not opinions. A/B tests tell you which variant won; recordings show you how users interact with each variant differently.
- Understanding mobile behavior that is fundamentally different from desktop. Pinch-zoom, scroll patterns, and tap targets all behave differently on touch devices.
The key insight is that session recordings provide qualitative data at scale. You're not running a five-person usability test—you're observing thousands of real users in their natural environment, on their own devices, with their own goals.
How Session Recording Actually Works
A common misconception is that session recording tools capture video of your website—like a screen recording running in the visitor's browser. That would be bandwidth-intensive, privacy-invasive, and technically impractical. Modern session recording works differently, and understanding the mechanism matters for both performance and privacy decisions.
Page Structure Capture, Not Video
When a session recording tool loads on your page, it takes an initial snapshot of the page's HTML structure. From that point forward, it observes changes to the page using the browser's MutationObserver API—a built-in interface that efficiently reports when elements are added, removed, or modified.
Every time the page changes (a dropdown opens, text updates, a modal appears), the tool records the change, not a new screenshot. It also captures user interaction events: mouse movements, clicks, scrolls, and keyboard input (with configurable privacy filtering on the input capture).
This produces remarkably compact data. A typical one-minute session generates roughly 50–200KB of recording data, compared to the megabytes a screen-capture video would require. The recording is a structured log of changes and events, not a media file.
Replay Reconstruction
When you watch a session recording in your dashboard, the tool reconstructs the page in a sandboxed iframe. It loads the original page structure from the initial snapshot, then replays each change and event in sequence with correct timing. The result looks like a video, but it's actually a live reconstruction—which means you can inspect elements, resize the viewport, and search for text within the replay.
Because recording uses the browser's native MutationObserver rather than capturing pixels, the performance overhead is minimal. The recording script loads asynchronously and processes changes on a separate microtask queue. Most sites see less than 1ms of additional frame time when recording is active.
Step-by-Step Setup
Recording website visitors with Inspectlet requires a single code snippet added to your site. The entire installation takes under two minutes.
1. Add the Tracking Script
After creating your Inspectlet account, you'll receive a snippet like this to add inside your <head> tag:
<script type="text/javascript">
(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);
document.readyState == "complete"
? ldinsp()
: window.addEventListener
? window.addEventListener("load", ldinsp, false)
: window.attachEvent("onload", ldinsp);
})();
</script>
Replace YOUR_SITE_ID with the numeric site ID from your Inspectlet dashboard. The script is fully asynchronous—it won't block page rendering or delay your site's load event.
2. Verify the Installation
Visit your website, interact with a few pages, then check your Inspectlet dashboard. A new session should appear within 30 seconds. If you don't see it, check your browser's developer console for errors and verify the site ID matches your dashboard.
3. Configure Recording Targeting
By default, Inspectlet records sessions across all pages on your domain. In your dashboard's site settings, you can narrow this down:
- Page targeting: Record only specific URL patterns (e.g., only your checkout flow or onboarding pages)
- Recording frequency: Record a percentage of visitors instead of all of them—useful for high-traffic sites where you don't need every session
- Minimum session length: Skip sessions shorter than a threshold (e.g., ignore bounces under 5 seconds)
4. Identify Users (Optional)
If your site has logged-in users, you can associate recordings with user identifiers:
__insp.push(['identify', 'user-12345']);
You can also tag sessions with custom metadata for filtering:
__insp.push(['tagSession', {plan: 'enterprise', role: 'admin'}]);
This makes it easy to find recordings for specific users or user segments later—for example, filtering to see only sessions from users on your free plan who visited the pricing page.
5. Single-Page Application Support
If your site uses a JavaScript framework like React, Vue, Angular, or Next.js, Inspectlet automatically detects virtual page navigations via the browser's History API. You don't need to add extra code for route changes—each navigation is captured as a page view within the same continuous session recording.
Start Recording in Under 2 Minutes
One script tag. No configuration files, no build steps, no server-side changes required.
What Gets Recorded (and What Doesn't)
Understanding exactly what a session recording captures is essential for both privacy decisions and setting expectations.
What IS Recorded
- Page structure and changes: The HTML layout of each page, and every change that occurs (elements appearing, disappearing, changing text or style)
- Mouse movements and clicks: The full cursor path, including where the user pauses and where they click
- Scroll behavior: How far users scroll, how fast, and where they stop
- Form interactions: Which fields the user interacts with, focus/blur events, and input values (subject to privacy controls)
- Page navigation: Full URL changes, including query parameters
- Console errors: JavaScript errors that occur during the session, with stack traces
- XHR/network requests: API calls made during the session (can be disabled)
- Viewport and device info: Screen resolution, browser, operating system
What is NOT Recorded
- Password field content: Automatically excluded, regardless of configuration. Password inputs are never captured.
- Content outside the page: Browser chrome, other tabs, desktop activity, or anything outside the web page itself
- File uploads: The content of uploaded files is not captured
- Third-party iframe content: Cross-origin iframes (payment processors, embedded videos) are recorded as opaque boxes
Privacy Controls & Ethical Recording
This is the most important section of this guide. Recording website visitors without proper privacy controls isn't just unethical—it exposes your organization to legal liability and erodes user trust. Every session recording deployment should start with a privacy-first configuration.
Automatic Protections
Inspectlet applies several protections by default, before you configure anything:
- Password fields are never recorded. Any
<input type="password">element is automatically excluded from capture. This protection cannot be overridden. - Credit card fields are detected and masked in most payment form implementations
Element-Level Privacy Controls
You can control recording behavior at the individual element level using CSS classes:
<!-- Completely exclude an element from recording -->
<div class="inspectletIgnore">
This content will not appear in session recordings at all.
</div>
<!-- Mask the content (shows placeholder instead of real text) -->
<div class="inspectlet-sensitive">
User's real name will appear masked in recordings.
</div>
<!-- Whitelist: exception when global censoring is enabled -->
<div class="inspectlet-whitelist">
This element's content will still be visible even with global censoring on.
</div>
The inspectletIgnore class is the strongest protection—the element and all its children are completely omitted from the recording data. It's never sent to the server. Use this for sections containing personal data you have no reason to record: account settings forms, profile information, medical or financial details.
The inspectlet-sensitive class is a lighter touch. The element's position and dimensions are recorded (so you can see the user interacting with it in replay), but the actual text content is replaced with masked characters. This is useful for form fields where you want to see that the user typed something but not what they typed.
Global Input Censoring
In your Inspectlet dashboard settings, you can enable "Censor all inputs" as a global setting. When enabled, every text input, textarea, and select field on your site is automatically masked in recordings. You can then use the inspectlet-whitelist class to selectively un-censor specific fields where visibility is needed (like a search box).
This is the recommended approach for most sites. It's a deny-by-default model: nothing sensitive gets through unless you explicitly allow it.
Enable global input censoring, then whitelist only the specific non-sensitive fields you need to see (search, navigation filters, non-PII dropdowns). This inverts the risk model: instead of hoping you remembered to mask every sensitive field, you start fully censored and only reveal what's safe.
IP-Based Exclusions
Inspectlet supports IP blocking in your site settings. You can exclude specific IP addresses or use wildcard patterns (e.g., 192.168.*.*) to prevent recording for certain networks. Common uses:
- Excluding your office IP range so internal traffic isn't recorded
- Excluding known bot or crawler IP ranges
- Excluding specific geographic regions if required by local regulations
Visitor Opt-Out
Inspectlet provides two levels of opt-out that you should make available to your users:
- Per-site opt-out: Directing a visitor to
/exclude/{your_site_id}sets a cookie that permanently excludes them from recording on your specific site - Global opt-out: The page at
/optouton inspectlet.com allows users to opt out of all Inspectlet recording across every site that uses the platform
Link to these opt-out pages from your privacy policy. Making opt-out easy and accessible isn't just a legal requirement in many jurisdictions—it signals to users that you take their privacy seriously.
Network Request Recording
By default, Inspectlet can record XHR (API) requests made during a session, which is useful for debugging. If your API responses contain sensitive data, you can disable XHR recording entirely in your site settings. This is a binary toggle—when off, no network request data is captured.
GDPR, CCPA & Compliance Considerations
Session recording intersects with data protection regulations because it processes personal data—even when you mask form inputs, mouse movement patterns and browsing behavior can constitute personal data under GDPR's broad definition.
GDPR (European Union)
Under GDPR, you need a lawful basis for processing personal data through session recording. The two most viable options:
- Consent (Article 6(1)(a)): You ask the user for explicit consent before recording begins. This is the cleanest approach and the one most privacy authorities prefer. Implement this through your cookie consent banner—don't load the Inspectlet script until the user has opted in to analytics/functional cookies.
- Legitimate interest (Article 6(1)(f)): You argue that improving website usability is a legitimate business interest that doesn't override the user's rights. This requires a documented Legitimate Interest Assessment (LIA) and stronger privacy controls (global censoring, minimal data collection). Many organizations use this basis, but it carries more regulatory risk than consent.
Regardless of your legal basis, GDPR requires you to:
- Disclose session recording in your privacy policy, including what data is collected and why
- Provide a way for users to exercise their right to deletion (you can delete individual sessions from the Inspectlet dashboard)
- Ensure data processing agreements are in place with your recording provider
- Apply data minimization—don't record more than necessary for your stated purpose
CCPA (California)
The California Consumer Privacy Act requires you to disclose categories of personal information collected and the business purpose. Session recording data falls under "internet or other electronic network activity information." Your privacy policy must list session recording and its purpose, and you must honor "Do Not Sell My Personal Information" requests if applicable.
Practical Consent Implementation
The most common approach is conditional script loading through your consent management platform (CMP):
// Only load Inspectlet after the user consents to analytics cookies
if (userHasConsentedToAnalytics()) {
window.__insp = window.__insp || [];
__insp.push(['wid', YOUR_SITE_ID]);
// ... rest of the Inspectlet snippet
}
If you use a tag manager like Google Tag Manager, configure the Inspectlet tag to fire only when the analytics consent trigger is active. This ensures zero recording happens before consent is given.
This guide provides general information about privacy regulations and session recording. It is not legal advice. Consult with a qualified privacy attorney to determine the specific requirements for your jurisdiction, industry, and use case.
Best Practices for Ethical Session Recording
Beyond legal compliance, these practices build the kind of recording program that respects users while delivering actionable insights.
1. Record with Purpose, Not by Default
Don't record 100% of traffic across your entire site because you can. Define what you're trying to learn first, then configure recording to capture that. If you're investigating checkout drop-off, record only the checkout flow. If you're testing a new feature, target only pages where that feature appears.
Use Inspectlet's recording frequency setting to sample a percentage of visitors. For a site with 100,000 daily visitors, recording 10% gives you 10,000 sessions per day—more than enough for any analysis while reducing data collection by 90%.
2. Apply Data Minimization from Day One
Enable global input censoring before your first recording session. Add the inspectletIgnore class to page sections that contain personal data you don't need to observe: user profiles, account settings, billing information, messaging interfaces.
If you don't need to see network requests for your analysis, disable XHR recording. Every piece of data you don't collect is data you don't have to protect, disclose, or delete.
3. Be Transparent About Recording
Your privacy policy should explicitly mention session recording. Go beyond the legal minimum—explain in plain language what you record, why, and how users can opt out. A dedicated section titled something like "Session Recording & Analytics" is better than burying it in a generic "cookies we use" list.
Consider adding a visible indicator when recording is active. While not legally required in most jurisdictions, a small "Session recorded for quality improvement" notice builds trust, especially for SaaS products where users have ongoing relationships with your platform.
4. Limit Who Can View Recordings
Not everyone in your organization needs access to session recordings. Limit dashboard access to the teams that actually use the data: UX researchers, product managers, and developers debugging specific issues. The fewer people with access, the lower the risk of sensitive data exposure.
5. Set Data Retention Policies
Don't keep recordings indefinitely. Define a retention period based on how long recordings remain useful for your analysis. Most teams find that recordings older than 30–90 days rarely get watched. Shorter retention reduces your data liability surface and keeps your recording library manageable.
6. Audit Your Configuration Periodically
Websites change. New features get deployed, new forms get added, new data gets displayed on pages. Review your privacy configuration quarterly to ensure:
- New form fields containing sensitive data are properly masked or ignored
- New page sections with personal information have the appropriate CSS classes
- Recording targeting still matches your current analysis needs
- Your privacy policy still accurately describes what you record
Common Mistakes to Avoid
Recording Everything with No Privacy Controls
The most dangerous mistake is installing a recording script with default settings and never configuring privacy controls. Default settings are designed to capture maximum data for debugging convenience—not for privacy compliance. Before recording a single real user session, configure input censoring, add ignore classes to sensitive sections, and verify the output by recording your own test session.
Skipping Consent in Regulated Markets
If your site serves EU visitors, you need a consent mechanism. Loading the recording script unconditionally, even with strong privacy controls, is not GDPR-compliant under the consent legal basis. Integrate with your cookie consent platform before launching recording.
Not Updating Your Privacy Policy
Many teams add session recording and forget to update their privacy policy. This is both a legal risk and a trust issue. Users who discover they're being recorded without prior disclosure react much more negatively than users who were told upfront.
Using Recordings for Surveillance Instead of UX Improvement
Session recordings should improve the product experience, not monitor individual users. Watching recordings to evaluate specific employees, track individual user behavior for non-UX purposes, or build behavioral profiles crosses an ethical line—even when it's technically legal. Define clear internal policies about acceptable uses of session recording data.
Ignoring Single-Page App Considerations
If your site is a single-page application, verify that virtual page navigations are being captured correctly. While Inspectlet's History API integration handles this automatically for most frameworks, custom routing implementations or hash-based navigation may need testing. Record a test session that navigates through your app's key flows and verify the recording captures each page transition.
Not Testing Your Privacy Controls
After configuring privacy settings, record a test session and review it. Verify that masked fields actually appear masked. Verify that ignored sections don't appear in the recording. Verify that password fields show no content. It takes five minutes and prevents the worst-case scenario: discovering months later that sensitive data has been recorded and stored.
Privacy-First Session Recording
Inspectlet gives you granular control over what gets recorded. Start with global censoring, then fine-tune from there.
Frequently Asked Questions
Does session recording slow down my website?
No. The recording script loads asynchronously and won't block page rendering. The actual recording uses the browser's native MutationObserver API, which adds negligible overhead—typically less than 1ms per frame. The data transmitted is also minimal at 50–200KB per session minute, compared to megabytes for a video-based approach.
Can visitors see that they're being recorded?
Not by default. Session recording operates silently in the background. Whether to display a notice is your decision—some organizations add a small disclosure in their cookie banner or footer for transparency. Visitors can always check the page source or their browser's network tab to detect recording scripts.
Does it work with React, Vue, Angular, and other frameworks?
Yes. Because session recording captures page structure changes at the HTML level rather than hooking into framework internals, it works with any JavaScript framework. Inspectlet automatically detects History API navigations used by React Router, Vue Router, Angular Router, and Next.js, so single-page application transitions are recorded seamlessly.
How long are recordings stored?
This depends on your plan and configuration. You can set retention periods in your dashboard settings. Most teams find 30–90 days sufficient for UX analysis. Shorter retention is better for privacy compliance.
Can I record only specific pages or user segments?
Yes. Use page targeting in your site settings to record specific URL patterns. Use the tagSession API to add metadata, then filter recordings by those tags in the dashboard. Combined with recording frequency controls, you can precisely target the sessions most relevant to your analysis.