LogRocket and Data Protection – What Belongs in the Privacy Policy

When a website operator uses LogRocket, the operator typically processes web server log data, click paths, interaction data, device data, browser information, coarse location data and technical telemetry data for the purpose of user-specific product improvement, error diagnostics and reach analysis – regularly on the basis of consent under Art. 6 (1) (a) GDPR in conjunction with Section 25 (1) TDDDG (German implementation of the ePrivacy rules). This page summarises which data processing LogRocket triggers according to the publicly available statements of the provider and which mandatory disclosures need to appear in the website's privacy policy.

A. Purpose and How LogRocket Works

LogRocket is a U.S. software-as-a-service solution for session replay, frontend performance and error monitoring, heatmaps as well as funnel and conversion analytics. The website operator embeds a JavaScript snippet (SDK) into the website or web application. The snippet records how visitors interact with the page and transmits the captured data to the provider's servers, where it is aggregated, made searchable and made available as a replay (a pixel-accurate playback of the session).

According to the provider's documentation, the feature set in particular comprises recording DOM changes via the MutationObserver API, mouse movements, scrolling, clicks and keystrokes (unless masking is active), instrumentation of XMLHttpRequest and fetch calls to capture network requests including headers and – unless excluded – request/response bodies, capturing console logs, Redux or state snapshots, as well as collecting technical performance metrics (Core Web Vitals, long tasks, crashes).

This page covers the typical web integration via the LogRocket JavaScript snippet on publicly accessible websites. Parallel use in native mobile apps or the on-premise / private cloud variant offered by the provider is not covered here.

B. Mandatory Disclosures in the Privacy Policy When Using LogRocket

In addition to general information about the website operator, data subject rights and the supervisory authority, the GDPR requires specific mandatory disclosures regarding tools such as LogRocket. These include the purposes of processing (Art. 13 (1) (c) GDPR), the legal bases (Art. 13 (1) (c) GDPR), where processing is based on a balance of interests, the specific legitimate interests pursued (Art. 13 (1) (d) GDPR), the recipients or categories of recipients (Art. 13 (1) (e) GDPR) and information about third-country transfers and the safeguards in place (Art. 13 (1) (f) GDPR). In addition, the storage period or the criteria for determining it (Art. 13 (2) (a) GDPR) must be stated, and – where data is not collected directly from the data subject – the categories of personal data (Art. 14 (1) (d) GDPR).

The following sections break these mandatory disclosures down for LogRocket.

In practice, attempts are often made to dedicate an individual text snippet to every single tool – including LogRocket – within the privacy policy. This "snippet-per-tool" approach has established itself as poor practice: privacy policies become long, redundant and hard to maintain, which conflicts with the transparency requirement of Art. 12 (1) GDPR (concise, transparent, intelligible, easily accessible). A more appropriate approach is topic-oriented: processing activities are described in cross-cutting topic blocks (server operation, newsletter, tracking, sales …) and the actual service providers used – including LogRocket – are merely listed in a recipient appendix.

C. Provider of LogRocket

According to the provider's statements, the contracting party for a German website operator is LogRocket, Inc., a corporation organised under the laws of the U.S. state of Delaware with its main office at 87 Summer St, Boston, MA 02110, USA. According to the publicly accessible sources, no separate EU establishment is identified as a contracting party. Whether an EU representative within the meaning of Art. 27 GDPR has been appointed needs to be verified by the website operator on a case-by-case basis.

LogRocket, Inc. states in its privacy policy that it has self-certified to the U.S. Department of Commerce its adherence to the principles of the EU-U.S. Data Privacy Framework (DPF), the UK Extension and the Swiss-U.S. DPF. Before deployment, the website operator should verify the current certification status in the directory at https://www.dataprivacyframework.gov/list. According to the provider, data transfers to the United States take place; standard contractual clauses (SCC) are used in addition.

• Privacy Policy: logrocket.com/privacy
• Security and privacy documentation: docs.logrocket.com/docs/security, docs.logrocket.com/docs/privacy
• GDPR/CCPA notes: docs.logrocket.com/docs/gdpr

D. Data Processing by LogRocket – Step by Step

E. Data Collected by LogRocket

According to the provider's documentation, LogRocket typically captures: the IP address and HTTP request data on page load, a device and session ID, browser and operating system information, screen resolution, a coarse location derived from the IP address, the URLs called and click paths, mouse movements, scroll behaviour, clicks and keystrokes (unless masked), DOM contents (including text and images, unless excluded via data-private), network requests including headers and – if not excluded – request/response bodies, console logs, Redux state snapshots and technical telemetry and performance data (Core Web Vitals, long tasks, crashes).

These data points fall into the following standardised data category classes:

• Web server log data: IP address, date/time, URL of the requested content, referrer, transmitted browser/OS information, server response status code.
• Click paths: Pages of the website visited including the referrer, links and buttons clicked together with date and time, forms and functions invoked.
• Device data: Device type, operating system, screen resolution and size, device orientation, touch support.
• Browser information: Browser name, browser version, possibly installed extensions.
• Coarse location data: Coarse location derived from the IP address at the city or municipality level.
• Interaction data: Scroll movements, mouse movements, cursor movements, touch movements on mobile devices, keys pressed (possibly already before submitting an entry), clicks – each with date and time.
• Technical telemetry data: Technical error messages, loading times, data volumes, performance metrics (Core Web Vitals, long tasks, crashes).
• Conversion events: Interactions defined as relevant by the website operator, e.g. registration, basket creation, product purchase, contact request, visit to a thank-you page after a download.
• User content: Unless excluded via data-private or input sanitisation, entries in form fields, text and any uploaded content – with an increased risk that special categories of personal data or sensitive content may also be captured (password fields are excluded by the provider by default).

F. Purposes of Use When Deploying LogRocket

The website operator typically uses LogRocket to diagnose frontend errors (reproduction via replay), to improve usability based on real usage sessions, to identify friction points in funnels, to evaluate conversion paths and heatmaps, and for performance optimisation. The data also feeds into general reach analysis and business steering.

The purposes fall into the following standardised purpose classes:

• Functionality provision: Error detection, error correction, error prevention, maintaining and stabilising the website function.
• Security and abuse protection: Detecting, preventing and stopping abusive use, bot detection, session management.
• General product improvement: Demand-oriented optimisation of the website based on frequently accessed content, improving user-friendliness of the interface (input masks and flows), general business planning.
• User profiling: Assignment to segments or target groups based on behaviour patterns, where activated.
• User-specific product improvement: Adaptation of the online services to interests and behaviour of the individual user, pre-selection of settings.

G. Legal Bases for the Use of LogRocket

By virtue of how it works, LogRocket primarily falls into the tool category Session Replay / Tracking (Statistics) and is comparable with solutions such as Hotjar or FullStory.

Because the LogRocket SDK regularly stores or reads information on the user's device (session IDs, possibly cookies or local storage values) and goes beyond merely providing the function actively requested by the user, consent under Section 25 (1) TDDDG typically comes into consideration. As a matter of substantive data protection law, Art. 6 (1) (a) GDPR (consent) then applies. Consent is regularly collected via a consent management platform that loads LogRocket only after consent has been given.

Reliance on legitimate interests under Art. 6 (1) (f) GDPR (e.g. in improvement, business steering or efficiency) is controversial in supervisory authority practice with regard to session replay and only comes into consideration in strictly anonymised, cookie-less configurations. Given the depth of data captured – in particular DOM contents, inputs, mouse movements – consent is generally recommended.

The actual legal basis depends on the individual case and is to be reviewed by the website operator on a case-by-case basis, in particular with regard to the LogRocket configuration scope (masking, network sanitisation, recording depth).

H. Particularities and Notes Regarding LogRocket

• PII masking configuration: LogRocket provides several masking mechanisms, the careful configuration of which by the website operator is in practice essential:
  • HTML attribute data-private to exclude individual DOM elements and their children from recording.
  • Input redaction modes (default redact; alternatively lipsum for Lorem Ipsum substitute display).
  • SDK options to automatically sanitise all text, inputs and images.
  • Network sanitiser to exclude request/response bodies, headers and URLs.
  • Redux state sanitiser to filter sensitive keys.
  • PII labelling API for client-side identification and blocking of PII before it leaves the device.
  • Password fields are excluded from recording by default according to the provider.
• Third-country transfer / DPF: LogRocket, Inc. states that it has self-certified under the EU-U.S. Data Privacy Framework; the current status is to be verified at https://www.dataprivacyframework.gov/list. According to the provider, standard contractual clauses are used in addition.
• EU data residency: According to the publicly accessible statements of the provider, standardised EU data residency is not offered. Anyone requiring EU residency is referred to the private cloud / self-hosted variant, which has to be requested individually.
• DPA: According to its own statements, the provider makes a Data Processing Addendum available to customers processing personal data of EU or Swiss citizens. Concluding a data processing agreement under Art. 28 GDPR is typically mandatory when deploying.
• Sub-processors: The general privacy policy does not publish a named sub-processor list; the provider names the Google Cloud hosting platform in particular. A complete list is to be requested via the provider's support.
• Settings for the website operator: Before going live, the website operator should carefully configure recording depth, masking rules, network sanitiser, retention period and ensure the snippet is loaded only after consent has been granted.
• Opt-out for website visitors: A user-side opt-out is regularly handled via the website operator's consent management (revocation of statistics consent); a central provider-side opt-out page is not standardised.

I. Frequently Asked Questions on LogRocket and Data Protection

J. Conclusion on LogRocket – and the Next Step

LogRocket is a powerful session replay and frontend monitoring tool that – due to the depth of the data captured (DOM mutations, network traffic, inputs, state snapshots) – is demanding from a data protection perspective. Website operators should base its use on consent, carefully configure the masking and sanitisation options, conclude a data processing agreement and document the third-country transfer safeguards (DPF, SCC).

For the privacy policy: it is mostly of little benefit to add a separate text snippet for every single tool – including LogRocket. Doing so makes privacy policies long, redundant and hard to read and is in tension with Art. 12 (1) GDPR. A more appropriate approach is a structured, topic-oriented one, which describes processing in cross-cutting topics (server operation, newsletter, tracking, sales …) and references actually deployed tools such as LogRocket only in the recipient appendix. This is precisely the methodology pursued by the matterius generator.

Authorship

This knowledge article is provided by matterius GmbH. matterius is not a law firm and does not provide legal advice.

matterius is editorially accompanied by Dr. Thomas Helbing, a German-based lawyer specialised as Fachanwalt für IT-Recht (certified specialist for IT law) in Munich.

Dr. Helbing has been continuously recognised by Handelsblatt since 2020 through to today (2026) as one of "Germany's best lawyers" in the fields of IT law and data protection law.

According to Kanzleimonitor.de (editions 2024–2026), he ranks among the leading lawyers for data protection and IT law and is listed in the Top 100 lawyers in Germany. Kanzleimonitor is regarded as a particularly meaningful market study, as it is based exclusively on personal recommendations from in-house counsel.

Dr. Helbing has many years of advisory experience in data protection and IT law and advises clients of all sizes — from startups to high-growth SaaS companies and unicorns through to international corporations.

His professional background covers the full spectrum of practice in IT and technology law. He began his career at an international major law firm, subsequently gained in-house experience at a DAX corporation, and is himself an entrepreneur and founder of several digital projects. He also has hands-on programming experience, allowing him to understand technical systems, software architectures, and digital business models not only from a legal but also from a technical perspective.

For many years his clients have included technology companies and SaaS providers, leading German research institutions, and a systemically important German major bank. His advisory focus lies in particular in the areas of GDPR compliance, the data economy, SaaS, AI regulation, and IT contract law.

More about Dr. Helbing: www.thomashelbing.com