How MousePlayer Works
A simple guide to our tracking architecture, screen resolution handling across devices, and system boundaries.
1. Why We Don't Use Video Recording
A common misconception is that visual analytics tools record standard video files (like MP4 or WebM) of a visitor's screen. Doing so would consume massive bandwidth, drastically slow down your website, and create blurry, unreadable text.
Instead, MousePlayer uses a lightweight technology known as DOM Snapshot Telemetry. Here is how it works on a ground level:
The Blueprint Snapshot
When a visitor opens your page, our script takes a text-based "blueprint" of your HTML and styling structure. It records where elements are located without copying your page's image or video files; the player loads images from their original address during replay. The exception is canvas elements, whose content is transmitted as an image (see below).
Coordinate Telemetry
As the user interacts, we record a stream of events: mouse positions, scroll depth, click targets and browser resizing, plus the changes to the page itself and, depending on the settings, console messages, failed or slow requests and loading-time measurements (Web Vitals). Movements and clicks are small; page snapshots and page changes can be considerably larger depending on the page and are transmitted compressed.
The Theatre Replay
When you watch a session in your dashboard, our player re-creates the page using the recorded blueprint and moves a virtual cursor across it in real time, keeping text crystal sharp.
Built to stay light: the script loads asynchronously and transmits small numerical data points rather than video, which keeps its own footprint small. What that means for your Core Web Vitals depends on your pages, your hosting and your visitor's network, so measure it on your own site rather than taking a figure from us. No particular loading speed is warranted – see section 20 of the Terms of Service.
2. Navigating Screen Resolutions & Mobile Devices
Today's users browse on everything from compact smartphones to ultra-wide 4K desktop monitors. Websites automatically shift, fold, and re-arrange their layouts to fit different screen widths—a concept known as Responsive Web Design.
How We Match the Visitor's Exact Viewport
To ensure a replay doesn't look distorted, MousePlayer records the visitor's exact viewport dimensions (e.g., 390x844 for a smartphone or 1920x1080 for a desktop monitor). When you open the Theatre player, our engine creates a scaled sandbox that perfectly mirrors the visitor's original screen ratio.
Desktop & Laptop Screens
On standard computers, we capture continuous mouse movement and multi-tab navigation within the same browser session. Menus that open on hover appear in the replay where the page changes its document in doing so; a pure CSS hover effect is not visible in the document and is not reproduced in the replay.
Smartphones & Tablets
Touchscreens do not have a hovering mouse cursor. MousePlayer automatically adapts by recording tap gestures, swipe scrolling, and orientation changes (portrait vs. landscape).
The Challenge of Mid-Session Resizing
If a visitor rotates their tablet or resizes their desktop browser window mid-session, the website layout changes dynamically. MousePlayer captures these window resizing events and adjusts the playback canvas seamlessly on the fly so that the context of the interaction is preserved.
3. System Limits & Technical Boundaries
To respect user privacy, maintain browser security, and keep data processing fast, MousePlayer operates within defined technical boundaries:
| System Boundary | How MousePlayer Handles It |
|---|---|
| iFrames | iframes of the same origin as your page are recorded together with their content and the interaction inside them. Embedded content of another origin (e.g., YouTube players, Stripe payment forms) cannot be recorded internally because of browser security policies (Same-Origin Policy); it appears as a placeholder in the replay and is not loaded there. |
| Sensitive Input Fields (PII) | Password and payment fields are masked on the visitor's device at every masking level, and full masking of all form input is the default for every property. You see that typing occurred, not what was typed. Two limits apply: the two weaker masking levels are enabled only on our written approval, and masking never reaches what your own page prints into the document – a confirmation page showing an address is part of the snapshot. Both are set out in the DPA. |
| Canvas & WebGL Elements | The content of a canvas is recorded as an image: once with the page snapshot and again whenever it changes, at most about once per second and with a size limit. Smooth animations therefore appear as a sequence of frames. No image is transmitted in masked areas or for canvas elements containing images of another origin; WebGL content may stay empty. |
| Web Components (Shadow DOM) | Open shadow roots are recorded together with their content. Closed shadow roots are inaccessible to scripts; their content is missing from the replay. |
| Transport & Browser Storage | Data is sent over an encrypted WebSocket connection (HTTPS/WSS). If it cannot be established, for example because of a proxy, the script falls back to an encrypted HTTP route; very large page snapshots are uploaded separately over HTTPS. MousePlayer sets no cookies; it uses the browser's local storage and session storage on your site. |
| Idle AFK Periods | If a visitor leaves their tab open and walks away for 20 minutes, our engine automatically detects inactivity and compresses the idle gap during replay so you don't waste time watching static screens. |