22. Privacy, Security & Compliance
FullSession records real user sessions, so controlling what gets captured is essential. This chapter covers the privacy tools FullSession provides — masking and excluding content, IP and geolocation controls, excluding internal users, and managing the data you send — plus an honest account of FullSession's security posture and where your own responsibilities lie.
Most of these controls live under Settings → Privacy Rules, Settings → Excluded Users, and Settings → Custom Attributes, each gated by its own permissions ([Chapter 16 — Team & Account Management]).
22.1 What FullSession Records — and the Privacy Toolkit
FullSession's tracker reconstructs what a visitor saw and did: the page's DOM and styles, mouse movement, clicks, scrolls, navigation, console and network activity, and any identity, events, or attributes you choose to send (Chapters 3–7).
Because that includes whatever text is on the page, FullSession gives you controls to keep sensitive content out:
Element recording rules
Mask or exclude specific page elements
Settings → Privacy Rules
IP Address Collection
Stop collecting visitor IPs
Settings → Privacy Rules
Lon/Lat recording
Stop collecting precise geolocation
Settings → Element Tracking
Total session length limit
Cap how long a session records
Settings → Privacy Rules
Excluded emails
Stop recording specific people
Settings → Excluded Users
Custom attributes
Review/remove the data you send
Settings → Custom Attributes
The Talk to User chat widget
If you use Talk to User, the chat widget is recorded like any other element on the page. You'll see the chat panel replayed inside a session, and what a visitor types into it is captured by the recorder, subject to the masking rules in section 22.2. The conversation transcript is still kept separately with the conversation in the inbox. Two consequences worth knowing:
Anything a visitor types into the chat — including personal details they volunteer — is captured in the session recording just like other page text, so make sure your masking rules (section 22.2) cover the widget if it collects sensitive fields. It's also kept in the conversation transcript, stored separately from the session.
If you turn on Ask for name and email before the first message, you are collecting those details deliberately. Treat them as you would any other contact data you gather — and remember they may also appear in the recording since the widget isn't excluded.
The most important takeaway of this chapter: by default, FullSession does not mask most input text — it only protects a few built-in fields (section 22.2). If your pages contain other sensitive data, you must add masking rules. Read the next section carefully.
22.2 Masking & Excluding Page Elements
Element recording rules are your primary privacy tool — "Mask or fully exclude specific DOM elements so their content is never sent to FullSession." You target an element by CSS selector and choose how it's treated.
The three actions
Exclude element entirely
The element is omitted completely from recording
Nothing — it isn't in the recording at all
Mask element
Text is hidden
Text is omitted, but interactions and change events are still captured
Unmask element
The element is fully captured
All text, interactions, and change events — an exception within a masked area
Exclude is the strongest (the element doesn't exist in the replay); Mask preserves the layout and interaction signals while hiding the actual text; Unmask is used to re-enable a specific element inside a broader masked region.
What's protected out of the box
FullSession ships with three built-in, non-editable masking rules that protect the most common sensitive fields automatically:
input[type=password]— password fieldsinput[type=hidden]— hidden inputs[autocomplete*=cc-]— credit-card fields
These can't be removed.
⚠️ Everything else is captured by default
Inputs and on-page text are NOT masked by default beyond the three built-in rules above. FullSession captures the text a visitor sees and types unless you add a rule. If your pages show or collect other sensitive information — names, emails, addresses, phone numbers, account numbers, health or financial data — you must add masking or exclusion rules for those elements. Don't assume sensitive data is hidden automatically.
Adding a rule
Go to Settings → Privacy Rules → Element recording rules.
Add a rule with:
Selector (required) — the CSS selector for the element(s), e.g.
.account-numberor#ssn-field.Action — Exclude, Mask, or Unmask.
Rule Exception Element Selectors (optional) — selectors to exclude from this rule.
Note (optional) — context for your team.
Save. New rules apply to sessions going forward.
Discovering elements to mask
If you're unsure which elements on your site may be exposing PII, the AI-powered Suggest Rules feature can scan a set of recorded sessions and propose selectors automatically — see [Chapter 7, section 7.3] for how to start a scan and review suggestions.
Tip — coordinate with engineering to add stable hooks (a class or
data-attribute) to sensitive elements, and review masking after any site redesign so a markup change doesn't expose newly sensitive content. Masking is also covered from the configuration angle in [Chapter 7, section 7.3].
AI Recommended Rules
If you're not sure which elements to target, the Recommended Rules tab (next to Element recording rules in Privacy Rules settings) can help. It scans a selection of already-recorded sessions with AI and proposes candidate selectors for elements containing likely PII — names, emails, payment data, government IDs, and more. Evidence previews are always redacted; no raw PII is shown. See [Chapter 7, section 7.3] for how to review, accept, and dismiss recommendations.
22.3 IP, Geolocation & Recording Scope
IP Address Collection
A simple toggle controls whether IPs are stored: "Choose whether visitor IP addresses are collected alongside session data."
On — IP and the geolocation derived from it are collected.
Off — IP addresses are not collected. (Location detail that depends on IP is correspondingly reduced.)
Precise geolocation (Lon/Lat)
Separately, under Settings → Element Tracking → Data Recording Rules, the Lon/Lat Recording toggle controls whether precise longitude/latitude coordinates are recorded. With it disabled, FullSession falls back to coarser IP-based location only.
The same panel includes a toggle for recording frustration signals on short text elements, letting you tune how much per-session detail is captured.
Limiting recording length
The Total Session Length Recording Rule caps how long a single session records: "Set a maximum recording duration — sessions that exceed it are automatically stopped."
Toggle it on, enter a value, and choose Seconds or Minutes.
The maximum is 2 minutes (120 seconds); the default is no limit.
Limiting which pages record
To keep entire pages out of recording (e.g. an account or admin area), use Page recording rules — covered in [Chapter 7, section 7.2].
22.4 Excluding Internal Users
To keep your own team's testing out of your data, use Excluded Users (Settings → Excluded Users) — "Block specific email addresses from being recorded — useful for excluding internal team traffic."
How it works
Click Add Email and enter an address (e.g.
qa@yourcompany.com).When a visitor is identified ([Chapter 4 — Identifying Users]) with a matching email, their entire session is excluded from recording and processing — it's never sent, and doesn't count toward your quota.
You can edit or remove entries at any time.
Exclusion is by email, so it relies on the user being identified with that email. For broader patterns, see how identification and exclusion work together in [Chapter 4, section 4.4].
Exclusion happens at recording time and can't be undone. An excluded session is never captured, so you can't retrieve it later. If you need to record your own sessions for debugging, remove yourself from the list temporarily.
22.5 Custom Attributes & Avoiding Sensitive Data
The Custom Attributes page (Settings → Custom Attributes) lets you "View and manage custom properties passed via your JS snippet." It lists every attribute you've sent through the tracker ([Chapter 4, section 4.3]), with its name and type, and lets you delete ones you no longer want.
A privacy checkpoint
Because attributes are data you choose to send, this page is a useful audit point:
Review what's being sent — make sure no attribute is carrying sensitive PII it shouldn't (e.g. don't send raw government IDs or full payment details as attributes).
Delete attributes that are unnecessary or were sent by mistake.
Remember attribute values must be strings ([Chapter 4, section 4.3]), and that whatever you send becomes searchable across the app — so send only what you genuinely need.
Tip — keep identity to what you need (the built-in
name/identify, plus a stable user ID), and avoid putting sensitive personal data into custom attributes or custom-event properties in the first place.
22.6 Data Retention & Deletion
How long sessions are kept
Recorded sessions are retained for a period determined by your plan (see [Chapter 5, section 5.7] and [Chapter 17 — Billing & Subscriptions]). Retention isn't a per-site setting you configure — it follows your plan.
Automatic clean-up
FullSession automatically removes sessions that have little value or have aged out, for reasons such as no recorded events, missing page data, a deletion rule, an expired session, or manual deletion. This keeps your data focused on sessions worth reviewing.
Deleting a specific person's data
There is no self-service "delete this user's data" / right-to-erasure button in the app. If you need to erase a specific individual's recorded data (for example, to fulfill a data-subject request), this isn't something you can do yourself in the settings — work with FullSession to action it. Plan your processes accordingly.
22.7 Compliance & Security — and What's Your Responsibility
It's important to be clear about what FullSession provides versus what you must handle.
What FullSession provides
Privacy controls — masking/exclusion, IP-off, geolocation-off, excluded emails, session-length and page limits (this chapter and Chapter 7).
Access security — role-based access control (Chapter 16), SSO/SAML (Chapter 18), and an audit log of administrative actions ([Chapter 16, section 16.6]).
Encryption — customer data is encrypted in transit and at rest.
What FullSession does not provide (you handle these)
Be explicit with your own privacy/legal teams — the following are not built-in product features:
No consent-management / cookie-consent UI inside FullSession. If your jurisdiction requires consent before recording, gate the tracker yourself — for example, only load the snippet (or fire the GTM tag) after the visitor accepts analytics consent ([Chapter 3, section 3.2]).
No data-residency / region-selection options.
No in-app DPA, privacy-policy, or consent-record management.
No "Do Not Track" honoring, visitor opt-out widget, or automatic anonymization toggle.
No self-service data erasure (section 22.6).
Your responsibility checklist — mask sensitive elements (22.2), decide on IP/geolocation collection (22.3), exclude internal users (22.4), avoid sending sensitive data as attributes (22.5), gate recording behind consent if required, and route any data-subject/erasure requests to FullSession.
The big picture — FullSession gives you concrete tools to control capture: Exclude/Mask/Unmask element rules (with built-in protection only for password, hidden, and credit-card fields — everything else is captured unless you mask it), an AI-powered Suggest Rules scan to help identify what needs covering, an IP toggle, a Lon/Lat toggle, a session-length cap, page rules, and excluded emails, plus a Custom Attributes audit page. Access is secured with RBAC, SSO, audit logs, and encryption. But consent management, data residency, anonymization, DNT/opt-out, and self-service erasure are not product features — so handle consent and data-subject requests through your own processes and with FullSession directly.
Next up: [Chapter 17 — Billing & Subscriptions] covers plans, member-seat limits, and the subscription controls referenced throughout this chapter.
Last updated
Was this helpful?