TL;DR
SaaS platforms aren't typical websites. You're running analytics on your own app, embedding third-party tools, processing data for customers across borders, and listing sub-processors in your DPA. Your consent setup needs to account for all of that. This guide walks through what's different for SaaS and how to handle it.
Why SaaS Consent Is Different
If you're running a SaaS product, your cookie consent situation is different from a brochure website or even an e-commerce store. Here's why:
- Your app IS the product. You're not just collecting visitor data on a marketing site. You're running analytics, error tracking, feature flags, and user identification inside the application itself.
- You have customers in multiple jurisdictions. One customer might be a German enterprise subject to GDPR. Another is a California startup under CCPA. A third is in Brazil under LGPD. Your consent setup needs to handle all of them.
- You embed third-party tools. Intercom for support, Stripe for payments, Segment for analytics, Hotjar for session recording. Each one drops cookies and sends data to external servers.
- You have sub-processors. Your DPA lists the services that process customer data on your behalf. Your consent banner needs to reflect that reality, not just your own cookies.
The Two Consent Surfaces: Marketing Site vs. App
Most SaaS companies have at least two distinct web properties that need consent management:
- The marketing site (e.g., yourproduct.com) where prospects land. This has Google Analytics, Meta Pixel, LinkedIn Insight Tag, and marketing automation tracking. It's a standard consent scenario.
- The application (e.g., app.yourproduct.com) where authenticated users work. This has product analytics, error monitoring, feature flags, and embedded third-party widgets.
These two surfaces have fundamentally different consent needs. Your marketing site follows the standard pattern: show a banner, block non-essential cookies until consent, fire Consent Mode signals. Your application is trickier.
Application Consent: What's Essential vs. What Needs Consent
Inside your app, you need to distinguish between cookies and tracking that are strictly necessary for the service to function and those that aren't.
| Tool | Purpose | Category | Needs consent? |
|---|---|---|---|
| Session cookie | Authentication | Necessary | No |
| CSRF token | Security | Necessary | No |
| Stripe.js | Payment processing | Necessary | No |
| Feature flags (LaunchDarkly) | Product function | Necessary | No (if no PII) |
| Sentry / Datadog RUM | Error monitoring | Analytics | Depends on config |
| Mixpanel / Amplitude | Product analytics | Analytics | Yes |
| Hotjar / FullStory | Session recording | Analytics | Yes |
| Intercom | Support chat + tracking | Preferences / Analytics | Partially |
| HubSpot tracking | CRM enrichment | Marketing | Yes |
| LinkedIn Insight Tag | Ad attribution | Marketing | Yes |
The Intercom trap
Intercom is one of the trickiest tools for SaaS consent. Its chat widget is essential for customer support (arguably "necessary"), but it also sets tracking cookies for lead scoring and visitor identification. You'll need to either load Intercom in a privacy-safe mode without tracking cookies, or categorize it as a preference cookie and accept that some users won't see the chat bubble until they consent.
Handling Multi-Jurisdiction Customers
Your SaaS app serves users from different privacy regimes. A single consent banner config doesn't work because the rules differ:
- EU/EEA (GDPR): Prior consent required for non-essential cookies. Must offer granular category choices.
- California (CCPA/CPRA): No prior consent needed, but must offer opt-out of sale/sharing. "Do Not Sell My Personal Information" link required.
- Brazil (LGPD): Consent is one of ten legal bases. You likely need consent for analytics, but the framework is more flexible.
- UK (UK GDPR + PECR): Nearly identical to EU GDPR for cookies.
The solution: regional consent rules. A consent management platform like CookieBeam lets you configure different banner behavior per visitor region. EU visitors see a GDPR opt-in banner. US visitors see a CCPA opt-out notice. Rest-of-world visitors see your default behavior. This is configured once and applied automatically based on geolocation.
Read our regional consent guide for the full setup.
Sub-Processors and Your DPA
If you offer a B2B SaaS product, your enterprise customers will ask you to sign a Data Processing Agreement (DPA). That DPA includes a list of sub-processors: every third-party service that handles their end-user data.
Your consent banner should reflect this reality. If Mixpanel is in your sub-processor list because it processes end-user behavioral data, then Mixpanel's cookies in your app need consent. If you claim Mixpanel is "necessary" in your consent banner while your DPA lists it as a data processor, you've got a contradiction that a diligent customer's legal team will catch.
The practical fix:
- Audit your sub-processor list against the cookies and scripts in your app
- Map each sub-processor to a consent category
- Make sure your consent banner's categories match what your DPA says
- Use automated cookie scanning to catch new cookies that sub-processors add in updates
Google Consent Mode v2 for SaaS
If you're using Google Analytics 4 in your SaaS app (and most platforms are), you need Consent Mode v2. Here's how it works in a SaaS context:
- Before the user interacts with the consent banner, GA4 runs in a restricted mode. It sends "cookieless pings" that let Google model conversions without storing identifiers.
- When the user grants analytics consent, GA4 switches to full mode with cookies.
- If the user rejects analytics, GA4 stays restricted. You still get aggregated data through Google's modeling, but no user-level tracking.
This matters for SaaS because your GA4 data feeds into Google Ads attribution (if you're running search or display campaigns) and into BigQuery exports (if you're doing product analytics there). Consent Mode ensures you're not silently dropping data while staying compliant.
Setting Up Consent for Your SaaS App
Scan your app for cookies and scripts
Run a cookie audit on both your marketing site and your application. CookieBeam's scanner will discover every cookie, script, and connection your site makes, including ones you forgot about.
Classify what needs consent
Sort everything into necessary, analytics, preferences, and marketing. Cross-reference with your DPA sub-processor list. Be honest: if a tool tracks users, it's not "necessary" just because your product team relies on the data.
Configure regional rules
Set up region-specific banner behavior. EU visitors get a prior-consent banner with category toggles. US visitors get a CCPA-style opt-out link. Other regions follow your default. CookieBeam handles the geolocation and rule matching automatically.
Implement script blocking
Configure your consent banner to actually block non-essential scripts until consent is given. This means analytics tags, session recording, and marketing pixels won't fire until the user opts in. CookieBeam uses automatic script blocking so you don't need to manually tag every script.
Wire up Consent Mode v2
Enable Google Consent Mode v2 signals so GA4 and Google Ads receive consent state updates. CookieBeam sends these signals automatically when a visitor makes a consent choice.
Test the authenticated experience
Log in to your own app as a test user, clear cookies, and verify: does the banner appear? Do analytics scripts stay blocked until consent? Does the app still function (auth, payments, core features) without analytics consent? Fix anything that breaks.
Document it for customers
Update your privacy policy and DPA to reflect your consent practices. Enterprise customers will ask how you handle cookies in your app, which sub-processors are involved, and what data flows to each one.
Common Mistakes SaaS Companies Make
After working with hundreds of SaaS platforms, these are the patterns we see most often:
- Treating the app like the marketing site. Copying your marketing site's consent banner onto your app without thinking about what's different. The tool mix is different, the user context is different, and the legal basis might be different.
- Claiming everything is "necessary." Mixpanel isn't necessary for your service to function. Neither is Hotjar. Calling them necessary because you use the data internally is not what GDPR means by "strictly necessary."
- Forgetting about SDKs. Your mobile app or Electron wrapper might include tracking SDKs that aren't covered by your web consent banner. Mobile consent is a separate problem.
- Not scanning regularly. A dependency update or a new Intercom feature might start setting new cookies tomorrow. Automated scanning catches these before a customer's audit does.
- Ignoring the DPA consistency. Your consent categories and your DPA sub-processor list need to tell the same story. Auditors check both.
SaaS Cookie Consent FAQ
Do I need a cookie banner inside my SaaS application?
Yes, if your app sets non-essential cookies (analytics, session recording, marketing tracking) for users in jurisdictions that require consent, such as the EU. The banner can be less intrusive than on a marketing site since users are authenticated, but it still needs to be present and functional.
Can I rely on my Terms of Service instead of a cookie banner?
No. Under GDPR and the ePrivacy Directive, consent for non-essential cookies must be freely given, specific, and revocable. Burying it in ToS doesn't meet that standard. You need an active consent mechanism.
What about single-page applications (SPAs)?
SPAs work fine with modern consent management platforms. CookieBeam's banner integrates with React, Next.js, Vue, and Angular apps. The banner renders as a component and manages consent state across route changes without reloading.
How do I handle consent for users who signed up before I added a cookie banner?
You can't retroactively claim consent. Show the banner to existing users on their next visit and respect their choice going forward. For analytics data collected before the banner, document the legal basis you relied on at the time (likely legitimate interest) and note when the switch to consent happened.
Do error monitoring tools like Sentry need consent?
It depends on the configuration. If Sentry only captures error stack traces and metadata without user identifiers or cookies, it can be classified as necessary. If it's configured with user context, session replay, or performance monitoring that sets cookies, it needs consent. Check your Sentry config specifically.
Next Steps
Getting consent right for a SaaS platform takes more thought than a standard website, but the payoff is real: enterprise customers trust you, audits go smoothly, and you're not scrambling when a new privacy regulation drops.
Start with a cookie audit of your app, then set up regional consent rules to handle your global user base. CookieBeam's quickstart guide walks you through the full setup in under 10 minutes.