A fintech founder told us: "We only collect email, name, and transaction data. Everything else is anonymous." Two hours later we had a different list. Their product was sending full-page session recordings to Hotjar, firing events to Meta Pixel with user IDs in URL parameters, pushing error traces to Sentry containing request bodies, and mirroring signup events into Google Ads with email as the join key. The "anonymous" claim collapsed before lunch.
The Gap Between Intent and Infrastructure
Every modern SaaS is a small constellation of vendors wearing one domain name. You built the signup form. You did not write the session replay, the crash reporter, the A/B testing engine, the ad pixel, or the CRM sync - but they all live inside your product and they all see user data. The uncomfortable truth: the product team decides what to collect, but the tooling decides what to exfiltrate.
Five Collection Points You Probably Have Not Mapped
- Session Replay and Heatmaps: Hotjar, FullStory, Microsoft Clarity record actual user sessions. Unless you have explicitly configured input masking, they capture what users type into forms - including passwords and messages drafted before hitting submit.
- Analytics and Marketing Pixels: Meta Pixel, Google Ads tag, LinkedIn Insight Tag. Each fires on page load and forwards URL parameters, user agents, and (if you are careless) hashed emails or internal user IDs.
- Error and Performance Monitoring: Sentry, Datadog RUM, New Relic capture stack traces that routinely contain request payloads, query parameters, and local variables with PII.
- Embedded Third-Party Widgets: YouTube players, Google Maps, Typeform, Calendly, social share buttons - each sets cookies and phones home on page load, regardless of consent status.
- Customer Support and Chat: Intercom, Drift, Zendesk keep full transcripts linked to identified users, often retained indefinitely unless you set retention rules manually.
Why "Anonymous" Analytics Usually Is Not
An analytics event that captures an IP address, a device fingerprint, and a referring URL is - under GDPR - personal data. Combined with a timestamp and session ID, most events are trivially re-identifiable. European regulators (French CNIL, Austrian DSB, Italian Garante) have each treated Google Analytics outputs as personal data transfers. If your stack sends "anonymous" telemetry to a US-based vendor without SCCs, you have an undeclared international data transfer.
What You Think - vs What You Actually Do
| The Assumption | The Reality |
|---|---|
| We do not collect anything beyond the signup form | Your frontend fires 20+ third-party requests per page load |
| Our analytics are anonymous | IPs, device IDs, and session hashes make most events re-identifiable |
| Session recordings do not capture input fields | They do - unless you have explicitly masked every form element |
| Our error logs are just stack traces | Most tools capture request bodies and local variables by default |
| The vendor is GDPR compliant so we are covered | Their compliance does not replace your obligation as the controller |
How This Becomes a GDPR Problem
- Subject Access Request: You must return all personal data - including what is in analytics, chat, and error tools. If you do not know where it lives, you cannot return it.
- Erasure request: You delete from production but data in Mixpanel, Intercom, Sentry, and your warehouse survives. That is a violation.
- Regulator or journalist runs traffic analysis: They watch pixels fire to vendors you never disclosed in your privacy notice. Transparency breach - one of the most common causes of regulatory action.
What to Actually Do About It
- Run a tag inventory: Chrome DevTools, Ghostery, or OneTrust will show every domain your site contacts. Expect surprises.
- Map each tool to a lawful basis: Analytics on legitimate interests? Marketing pixels on consent? Document it.
- Mask inputs in session replay tools: Configure explicit allowlists rather than trusting defaults.
- Sign DPAs with every tool vendor: Not optional - you are the controller, they are the processor.
- Update your privacy notice to match your actual stack.
- Propagate deletion requests to every processor.
For the full definition of what counts as personal data, see our What Counts as Personal Data Under GDPR guide.
Frequently Asked Questions
Yes. European regulators have repeatedly confirmed that Google Analytics collects personal data - IP addresses, device identifiers, and session data that can re-identify individuals. The French CNIL, Austrian DSB, and Italian Garante have each issued decisions treating GA outputs as personal data, and in some cases as unlawful international transfers.
Yes. Session replays capture user interactions including mouse movements, clicks, scrolls, and - unless explicitly masked - text typed into form fields. This includes passwords, search queries, and messages. Under GDPR, this is personal data processing that requires a lawful basis, notice to the user, and a DPA with the replay vendor.
Yes. Under GDPR, you are the controller for data collected through your product - including data captured by third-party scripts you embed. The vendor is a processor. You need a DPA with each one, must disclose the processing in your privacy notice, and must honour deletion requests across all processors.
Run a tag inventory using browser developer tools (Network tab), Ghostery, or a dedicated tool like OneTrust or Cookiebot. This will show every domain your site contacts on page load. Then map each tool to the data it collects, the lawful basis for that collection, and the DPA status with the vendor.
A consent banner is necessary but not sufficient. You also need to actually block scripts from firing before consent is given (not just show a banner while scripts run), document the lawful basis for each tool, sign DPAs with all vendors, and propagate deletion requests to every processor. A banner that does not technically gate scripts is a transparency violation, not a solution.