FullStory Digital Experience and Session Replay Cookie Consent Integration Guide: 2026 Playbook
FullStory is the dominant platform in the digital experience analytics category for one reason: it captures everything by default. Where traditional analytics tools record discrete events the developer has instrumented, and where product analytics platforms record interactions plus an autocaptured supplement, FullStory captures the full rendered DOM, the cursor trail, the keystroke timing, the scroll behaviour, the rage clicks, the dead clicks, the network requests, and the JavaScript errors — and stitches them into session recordings the analyst can scrub through frame by frame. That coverage is the product. It is also why FullStory sits at the intersection of the most rigorous consent rules in every modern privacy regime. The EDPB's 2023 session-replay guidance and the 2026 task force priorities treat session-replay as a distinct, stricter consent category. The CNIL has been the most public regulator on the topic but is not alone — the Garante, the ICO, the Spanish AEPD, and the Dutch AP have all issued aligned positions. A FullStory deployment that has been configured for consent-first capture, with the correct masking, the correct gating, and the correct audit trail, is one of the more powerful tools a publisher can run; one that has not been so configured is one of the easiest targets a regulator will find.
Why FullStory sits in the strictest consent category
A default FullStory initialisation does what every session-replay tool does plus more. It sets first-party cookies under the fs_uid and fs_lua namespace containing the persistent visitor identifier and last-active timestamp, generates a session identifier under fs_session, and begins streaming the rendered DOM to rs.fullstory.com within milliseconds of page load. The stream includes every input event, every mouse movement, every scroll position, every page transition, and — when the network capture module is enabled — every XHR and fetch response that the page issues, with response bodies included unless the operator has configured suppression. The stream is what gets reconstructed into the pixel-perfect session replay the FullStory analyst sees in the dashboard.
Each of those captures engages a separate consent gate. Persisting the visitor identifier is a storage-and-access operation under Article 5(3) of the ePrivacy Directive requiring prior, freely given, specific, informed, and unambiguous consent across the EEA, the UK, and any jurisdiction that has imported the same standard. Recording the rendered DOM is processing of personal data under the GDPR because the visual record is sufficient to identify and to reveal substantive content about the user. Capturing the keystroke stream is a particular sensitivity: anything the user types in a form field is captured frame by frame, and if the field is unmasked the recording includes the typed content. The EDPB has been explicit that session-replay capture is a category requiring explicit, granular consent distinct from generic analytics consent — and that masking is a complement to consent, not a substitute for it.
What FullStory writes before consent — and what must be suppressed
The standard FullStory quickstart installs the tracking snippet directly into the page <head>. That works as documented and is the source of the most common compliance failure: the snippet runs before the cookie banner has rendered, the fs_uid and fs_session cookies are written within milliseconds, and the session-replay stream begins flowing to rs.fullstory.com regardless of what the user later decides. Every European regulator that has ruled on this pattern has ruled the same way: cookies set before consent are unlawful, the recording captured before consent is unlawful processing, and the publisher carries the liability.
A compliant integration must therefore prevent the FullStory snippet from initialising until the relevant consent category has been granted. The pattern that works in production is the FS.consent() API combined with deferred recording: the snippet is loaded with FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) and FS.shutdown() called immediately, then FS.restart() and FS.consent(true) called only after the CMP signals that the session-replay category has been granted. The alternative pattern is conditional script injection — the FullStory snippet is added to the DOM only after consent has been granted — which is cleaner but requires the operator to lose any pre-consent identity stitching FullStory might otherwise provide.
The cookies and storage FullStory writes
The FullStory snippet writes the following identifiers on initialisation, all of which are non-essential and require consent: fs_uid with a multi-year expiry containing the persistent visitor identifier, fs_lua with the last-user-activity timestamp, fs_session with the session identifier, and the recording-state markers FullStory uses internally. Withdrawing consent must therefore both expire those cookies and call FS.consent(false) followed by FS.shutdown() to stop further capture, and the publisher must dispatch a deletion request through FullStory's privacy endpoint for the user's prior recordings.
Mapping FullStory to consent frameworks
FullStory does not natively implement IAB TCF or the IAB Global Privacy Platform — it is a first-party digital experience platform, not an ad-tech vendor. It does expose a native consent API and supports a private-by-default masking model that operates regardless of consent state. The pattern that survives a regulator's review treats each FullStory module as a separate gate bound to a specific CMP signal.
- Session replay and the full DOM stream bind to a dedicated session-replay or research category that is distinct from generic analytics. The EDPB's guidance is explicit on this point — replay consent must be separate and granular, not bundled with analytics or marketing.
- Network capture sits behind a stricter sub-gate within the same category because it captures HTTP response bodies that may contain personal data unrelated to the visible interface. Network capture should default to off and be enabled only for specific application paths where the operator has confirmed the response bodies do not include sensitive data.
- Identity stitching via FS.identify() can run with an ephemeral session identifier under a legitimate-interest basis when the user is anonymous, but stitching identification to a persistent first-party identifier across sessions requires the same consent as session replay.
- Heatmaps and conversion analytics derived from the session-replay stream inherit the gate from the upstream stream — they are not separate consent surfaces, they are downstream products of the same captured data.
The integration pattern that works
The reference deployment has four parts: a CMP that exposes a real-time consent change event, a deferred bootstrap that initialises FullStory with capture suppressed via FS.shutdown(), a consent listener that calls FS.consent(true) and FS.restart() when the session-replay gate opens, and a private-by-default masking configuration that hard-suppresses every input field unless explicitly opted in.
Private-by-default masking
FullStory's masking layer operates independently of consent and should be configured aggressively even when consent has been granted. The fs-mask CSS class on any element suppresses that element's content from recording; the fs-exclude CSS class excludes the element entirely from the DOM stream; the fs-block class blocks both content and structure. Under the GDPR's special-category rules and the CCPA's sensitive-personal-information definition, any field that could capture health information, financial detail, government identifiers, biometric data, precise geolocation, or contents of private communications must use the masking attributes regardless of the user's consent state. The recommended posture is to apply fs-mask at the form level rather than the field level — a developer adding a new field to an existing form is much less likely to remember to mask it individually than they are to be operating within a form-level masking wrapper that catches it automatically.
Region selection and data residency
FullStory operates separate US and EU ingestion endpoints. For EEA and UK traffic the EU endpoint is the right default — it keeps ingestion, processing, and storage inside the EEA and reduces the Schrems II exposure that any US-region session-replay deployment would carry. The endpoint is configured per FullStory organisation and cannot be changed retroactively, so the region choice must be made before scaling and documented in the privacy notice so the lawful-basis chain is clean from collection through to storage.
Validating the integration and the audit trail
The validation step is what regulators check and what publishers most often skip on session-replay tools. A correctly integrated FullStory deployment must pass four tests in sequence. First, a clean browser session with the banner shown but no choice made must produce zero requests to rs.fullstory.com beyond the SDK file fetch and zero fs_ cookies in document.cookie. Second, declining session-replay consent must keep that state — no capture, no identifier, no recording. Third, accepting session-replay consent must produce the expected fs_uid cookie, a single FS.consent(true) event, and the DOM stream flowing to the configured region endpoint, with masked fields confirmed to capture only the mask placeholder. Fourth, withdrawing consent must immediately stop further capture, expire the fs_ cookies, and trigger a deletion request via FullStory's privacy endpoint for the user's prior recordings.
The audit-trail expectation is where session-replay tools face the strictest scrutiny. The EDPB's 2023 cookie banner guidelines and the renewed 2026 task force priorities are explicit that the publisher must be able to prove, for any specific session recording in the FullStory project, that the user who generated it had given valid session-replay consent at the moment of capture. The standard pattern is to set the consent version and timestamp as user variables on the FullStory identifier via FS.setUserVars({ consent_version: 'v3', consent_ts: ts }) so that any individual recording is traceable back to a specific consent log entry. A correctly gated deployment, paired with masking attributes that default to private and a deletion path that activates on withdrawal, is what turns FullStory's coverage from a regulatory concentration risk into a defensible part of a publisher's digital experience stack.