Cookie Compliance for SaaS Companies: A Product-Led Guide

Your SaaS product tracks feature usage, measures activation funnels, and runs A/B tests across multiple subdomains. Your marketing site loads a dozen scripts to attribute signups. Your customer success team uses session replay to debug support tickets. Every one of these activities involves cookies or tracking technologies -- and every one is a potential compliance risk.

SaaS companies face a distinct set of cookie compliance challenges that generic guidance does not cover. Product analytics, multi-subdomain architectures, B2B consent ambiguity, and the sheer number of integrated tools create a compliance surface area that is larger and more complex than most other industries.

The Product Analytics Problem

Most SaaS products depend on analytics to make decisions. Tools like Amplitude, Mixpanel, Segment, PostHog, and Heap provide critical data about user behaviour -- which features get used, where users drop off, what drives retention.

The problem: under GDPR, these tools typically set cookies that require explicit consent before they can fire. This creates a tension that is unique to product-led companies:

Without analytics data, you cannot make informed product decisions
With pre-consent analytics, you are violating GDPR
With proper consent gating, you lose data from users who decline

This tension is real, but it is not unsolvable. The key is understanding exactly which tracking activities require consent and which can operate under alternative legal bases.

Multi-Subdomain Architecture

SaaS products commonly span multiple subdomains:

www.example.com -- marketing site
app.example.com -- product application
docs.example.com -- documentation
api.example.com -- API endpoints
status.example.com -- status page

Each subdomain can set cookies, and those cookies can be scoped to the parent domain (.example.com) or the specific subdomain. A cookie set on .example.com by the marketing site will be sent with every request to the app, docs, and API subdomains.

This has compliance implications:

Marketing cookies from the website may persist into the authenticated product experience
Analytics tracking may inadvertently cross consent boundaries between subdomains
Third-party scripts loaded on one subdomain may set cookies accessible from others

Many SaaS companies assume that because they sell to businesses, GDPR consent requirements are less strict. This is a dangerous misconception.

GDPR protects natural persons, not businesses. Even when your customer is an enterprise, the people using your software are individuals whose personal data you are processing. Their IP addresses, usage patterns, and behavioural data are personal data under GDPR -- regardless of whether they signed up with a corporate email.

B2B context does affect some aspects of consent:

Legitimate interest may be a viable legal basis for some processing activities in a B2B context
Contract performance can justify cookies necessary for delivering the service
But marketing cookies, analytics, and third-party tracking still require consent

Common SaaS Tracking Stacks and Their Compliance Risks

Segment and Customer Data Platforms

Customer Data Platforms (CDPs) like Segment, RudderStack, and mParticle act as intermediaries that route data to dozens of downstream tools. A single analytics.track() call can trigger data flows to your analytics platform, CRM, advertising networks, and email marketing tools simultaneously.

Compliance risks:

One Segment call can set cookies for multiple purposes (analytics, marketing, personalisation)
Downstream destinations may set their own cookies
Consent must be managed at the destination level, not just at the CDP level
Server-side Segment does not set browser cookies directly, but client-side libraries do

Mitigation: Configure your CDP to respect consent categories. Segment supports consent middleware that can block specific destinations based on user consent state. Implement this before any tracking fires.

Amplitude, Mixpanel, and Product Analytics

Product analytics platforms are the backbone of SaaS decision-making. But they present clear pre-consent risks:

Tool	Default Cookies	Consent Required	Server-Side Option
Amplitude	`amp_*` device/session cookies	Yes	Yes (with limitations)
Mixpanel	`mp_*` tracking cookies	Yes	Yes
PostHog	`ph_*` identification cookies	Yes	Yes (self-hosted option)
Heap	`_hp2_*` session cookies	Yes	No
Google Analytics 4	`_ga`, `_ga_*` cookies	Yes	Measurement Protocol

Every one of these tools sets cookies that identify or track users. Under GDPR, they require consent.

Session Replay and Heatmaps

Tools like Hotjar, FullStory, and LogRocket record user sessions for UX analysis and debugging. These tools:

Set persistent cookies to identify returning visitors
Capture mouse movements, clicks, scrolls, and form interactions
May inadvertently record personal data entered into forms
Require explicit consent under GDPR

Key risk: Session replay tools can capture sensitive data (passwords, credit card numbers, personal details) if not properly configured with data masking rules.

Feature Flags and Experimentation

Feature flag services (LaunchDarkly, Statsig, Optimizely, Split) present a nuanced compliance picture:

Feature flags for functionality (enabling/disabling features per user) may qualify as "strictly necessary" if they are essential to delivering the service
A/B testing and experimentation that measures user behaviour requires consent, as it constitutes analytics processing
Personalisation flags that tailor the experience based on user segments require consent

The distinction matters: a feature flag that controls a rollout is different from an experiment that tracks conversion rates.

Building a Compliant SaaS Analytics Stack

These activities can typically proceed without explicit consent:

Essential session cookies: Authentication tokens, CSRF protection, load balancing
Server-side analytics: Aggregated, anonymised metrics that do not use cookies or identify individuals
Feature flags for delivery: Binary on/off flags that do not track behaviour
Error monitoring: Tools like Sentry that capture errors without identifying users (when properly configured)
Infrastructure cookies: CDN, security, and performance cookies strictly necessary for service delivery

These activities require explicit opt-in consent before any cookies or tracking fires:

Product analytics: Amplitude, Mixpanel, PostHog, Heap, GA4
Session replay: Hotjar, FullStory, LogRocket
A/B testing with measurement: Optimizely experiments, Statsig experiments
Customer success tools: Intercom, Pendo, Gainsight (when they set cookies)
Marketing analytics: UTM tracking cookies, attribution cookies

These require specific marketing consent, separate from analytics:

Advertising pixels: Facebook Pixel, Google Ads, LinkedIn Insight Tag
Retargeting cookies: Criteo, AdRoll, programmatic advertising
Social media widgets: Embedded feeds, share buttons that track
Email tracking pixels: Open and click tracking in marketing emails

For SaaS applications, consent management typically needs to operate at two levels:

1. Marketing site consent (pre-login)

Your marketing site (www.example.com) should implement a standard CMP that:

Blocks all non-essential scripts until consent is given
Categorises cookies into clear groups (necessary, analytics, marketing)
Stores consent preferences in a first-party cookie

2. In-app consent (post-login)

Once a user is authenticated in your product (app.example.com), you have additional considerations:

Product analytics consent may be captured during onboarding
Consent state should be stored in your user database, not just in cookies
Users must be able to change their preferences at any time
Consent status must propagate to all tracking tools

If you use a parent-domain cookie for consent (.example.com), the same consent state is available across all subdomains. This simplifies implementation but requires:

Consistent consent categories across all subdomains
All subdomains respecting the same consent cookie
Clear documentation of which tools operate on which subdomains

Server-Side Tracking as a Partial Solution

Some SaaS companies move to server-side analytics to reduce their cookie footprint. This can help but is not a complete solution:

What server-side tracking solves:

Eliminates client-side cookies from analytics tools
Reduces the number of third-party scripts on the page
Gives you more control over what data is sent where

What it does not solve:

You still need consent to process personal data (IP addresses, user IDs)
Server-side tracking that identifies individuals is still analytics processing under GDPR
If you correlate server-side data with identifiable users, consent requirements apply

Marketing Site

CMP blocks all non-essential cookies before consent
No analytics scripts fire on page load (verify with a pre-consent scan)
Attribution cookies (UTM parameters) are only stored after consent
Third-party marketing scripts are consent-gated
Consent banner provides granular options and an equally visible reject button

Product Application

Authentication cookies are correctly classified as "strictly necessary"
Product analytics are gated behind consent
Session replay tools require consent before recording
Feature flags used for experimentation are consent-gated
User consent preferences are stored in the database
Users can modify consent preferences from account settings

Cross-Subdomain

Cookie domains are scoped appropriately (subdomain vs parent domain)
Marketing cookies from the website do not persist into the product
Consent state is consistent across all subdomains
Third-party scripts on one subdomain do not set parent-domain cookies

CDP and Data Pipeline

CDP respects consent categories before routing data to destinations
Downstream tools only receive data for users who have consented
Data deletion requests propagate through the entire pipeline
Consent audit trail is maintained

Documentation

Cookie policy lists all cookies across all subdomains
Privacy policy addresses product analytics processing
Data Processing Agreements cover all analytics vendors
Understand your Gretel Score and what it means for your overall compliance posture

Balancing Analytics With Compliance

The fear of losing analytics data is the primary reason SaaS companies delay cookie compliance. But the data loss is often overstated:

Well-designed consent banners in B2B SaaS products typically see 65-80% opt-in rates. The key factors:

Trust: Users who are already paying customers tend to trust the product
Value exchange: Explaining that analytics improve the product increases consent rates
Design: A clear, non-manipulative banner performs better than a dark pattern

Compliant Analytics Still Provides Insight

Even with 70% consent rates, you retain enough data to make product decisions. Consider:

Relative metrics (conversion rates, feature adoption percentages) remain valid with a representative sample
Server-side events for critical business metrics do not require cookies
Aggregated, anonymous usage data can supplement consented analytics

The Cost of Getting Caught

Compare the potential downside of reduced analytics data against the consequences of non-compliance. A single GDPR fine dwarfs years of analytics platform costs. And regulators are increasingly sophisticated at detecting violations -- automated scanning tools can identify pre-consent cookies within seconds.

Scan Your SaaS Application

SaaS products have complex cookie landscapes that are difficult to audit manually. Between your marketing site, product application, and documentation, there may be dozens of cookies and scripts firing before consent.

Run a compliance scan on your SaaS product →

Get your Gretel Score and a complete breakdown of every cookie and script firing before consent -- across all your subdomains. See the specific violations and get actionable remediation steps tailored to common SaaS tracking stacks.