Heatmaps & session replay

Heatmaps show where people click and how far they scroll; session replays show what one visitor saw. Both wait for the visitor’s consent on a new website, both depend on your plan, and both are sampled per session so you control how much data they produce.

Heatmap data is extra data on events the SDK sends anyway — never an event of its own:

• On every click event: a selector path of the element (without ids, classes or text), the position inside the element, and the kind — CLICK, RAGE_CLICK (three clicks within a second on one spot) or DEAD_CLICK (a click on a passive element that changed nothing within 500 ms).
• On every pageleave event: the deepest scroll position.

It is attached only when all of this holds:

1. Your plan includes heatmaps.
2. Automatic interactions are collected for the visitor (Settings › Data collection & privacy › Collection and consent): the group is on Always, or on Only with consent and the visitor consented. Heatmaps have no mode of their own — they are the positions of the clicks and scrolls that group collects.
3. The session is in the heatmap sampling (Settings › Data collection & privacy › Heatmaps › Sampled sessions, 100 % on a new website). The SDK and the server pick the same page loads from the page view id.
4. No rule with No heatmaps matches the page.
5. The SDK has heatmaps on (data-heatmaps="false" / heatmaps: false switches them off).

Sampling below 100 % makes heatmaps lighter but does not change the number of click events — goals, funnels and Explore stay complete.

Under Behaviour › Heatmaps you pick a page and a viewport class. Desktop (from 1024 px), tablet (from 600 px) and phone are shown separately, because the same page has a different layout on each. The map is drawn on the page as it looked in the latest replay of that viewport class, so a page needs at least one recording to show it as background; the element list and the scroll depth work without one. Clicks are placed relative to the element they hit, so the map survives small layout changes.

Every click, first click, last click: by default the click map shows every click. First click keeps only the first click of each session on the page — where people look for their way in — and Last click only the last one before they left or moved on. The totals above the map keep counting every click.

A replay records the page with rrweb and plays it back in the dashboard under Behaviour › Replays, with a timeline of pages, clicks, errors, failed requests and rage clicks. While you watch, the player loads the images and fonts of the recorded page, and stylesheets the recording could not read, from their original addresses — see Replay limits.

A visit is recorded when your plan includes session replay, the group Session replay is not off (Settings › Data collection & privacy › Collection and consent), the visitor consented or the group is set to Always, no rule with No session replay matches, and one of these triggers fires:

trustanalytics.startReplay();          // record this session now
trustanalytics.pauseReplay();          // e.g. while a sensitive dialog is open
trustanalytics.resumeReplay();
trustanalytics.stopReplay();
await trustanalytics.isReplayRecording();

• The SDK loads the replay module trustanalytics-replay.min.js from the directory of trustanalytics.min.js only when a session is recorded (data-replay-script / replayScriptUrl to load it from elsewhere). data-replay="false" / replay: false disables it.
• Every loaded page is a recording of its own; the dashboard files them under the visit and plays them one after another. Navigation inside a single-page app stays in one recording, which ends after 60 minutes.
• Recordings are uploaded in compressed chunks, the first one after a second, then about every ten seconds.
• Minimum duration (Settings › Data collection & privacy › Session replay › Minimum duration, 5 seconds on a new website): the recordings of a sampled visit shorter than that are deleted once the visit is over and never counted. Recordings after an error or startReplay() are always kept.
• Recorded visits are counted, however many pages they have; replays never count as events.
• Withdrawing the consent stops a running recording at once, unless the group is set to Always.

A rule with No session replay is checked for every part of a recording against the page it was recorded on. In a single-page app all routes share one recording, so the recording ends when the visitor reaches an excluded route and a new one starts with the next full page load. For content that must never be recorded, mark it with data-ta-block as well: that removes it in the browser, whatever the route.

Masking happens in the visitor’s browser, before anything is sent — masked content never reaches our servers. The server stores a recording as the SDK sent it and does not mask it a second time, so use the SDK we publish; a changed build decides itself what it sends.

Choose the preset under Settings › Data collection & privacy › Session replay › Masking. In your markup:

<h1 data-ta-unmask>Pricing</h1>            <!-- readable even in Strict -->
<p data-ta-mask>Hello, Jane Doe</p>         <!-- masked even in Balanced -->
<div data-ta-block>…</div>                  <!-- left out of the recording entirely -->

data-ta-mask-url hides addresses: on an element it reduces its links, sources and form actions to the origin in the recording, on <html> or <body> it hides the page address too. Set it before the navigation it should mask, see Keeping personal data out.

Urls in the recording — links, sources, form actions and the page address — keep only the query parameters the website keeps (Settings › Data collection & privacy › Pages › Query parameters); technical parameters such as utm_*, click ids and session ids are removed in every mode, while stylesheet and font links keep their query so they still load. Mail and phone links keep only their scheme (mailto:, tel:).

Input values are always masked, in every preset. Use data-ta-block for areas that must not appear at all — a payment iframe, an account summary, a chat.

• Assets are loaded live. A replay stores the page structure and the stylesheets the browser could read; images and fonts, and stylesheets it could not read (other origins without CORS), are loaded from their original hosts when you watch, so the browser of the person watching contacts those hosts, third parties included. If they changed or disappeared since, the replay looks different, and the player shows a notice for assets it could not load. Nothing is archived on our side.
• The player runs in a sandbox without scripts — your page’s JavaScript is never executed in the dashboard.
• Canvas, video content and cross-origin iframes are not recorded.
• Content Security Policy: if your site restricts scripts, allow cdn.trustcomponent.com for trustanalytics.min.js and trustanalytics-replay.min.js, and api.trustcomponent.com in connect-src. See Troubleshooting.
• Retention: recordings are kept as long as Settings › Retention & deletion › Replays says, within your plan. Keep in the player protects a recording: it stays beyond the replay retention until you release it again, at most 365 days after its start, up to 100 kept recordings per website, and protecting or releasing it is written to the audit log. You can delete a single recording in the player — its chunks are removed at once, it stays counted, and the deletion is written to the audit log. Erasure removes all recordings of a visitor, user or session, kept ones included. A deleted recording that is still running stops.