Two Web Properties, Two Consent Strategies
Most SaaS companies run at least two separate web properties: a public marketing site designed to attract and convert visitors, and a logged-in application dashboard where paying customers actually use the product. These two environments have fundamentally different relationships with cookies, and treating them identically is a common compliance mistake.
Your marketing site behaves like any other commercial website. It sets analytics cookies such as _ga and _gid, retargeting pixels from Meta or LinkedIn, and conversion tracking scripts. Every one of these requires prior consent under the ePrivacy Directive Article 5(3) before being placed on a visitor's device.
Your application dashboard is different. A logged-in user has explicitly requested your service, and the cookies that keep them authenticated, remember their preferences, and maintain their session may fall under the "strictly necessary" exemption. But the line between essential and non-essential is narrower than most product teams assume.
What Counts as a Strictly Necessary Cookie in a SaaS Dashboard
Article 5(3) of the ePrivacy Directive provides two exemptions from the consent requirement. A cookie is exempt if it is used solely to carry out a communication over a network, or if it is strictly necessary to provide a service the user has explicitly requested. The EDPB and national data protection authorities interpret this exemption narrowly.
Authentication cookies fall squarely within the exemption. When a user logs in, the session cookie (often named something like PHPSESSID, connect.sid, or a custom JWT token cookie) is strictly necessary to deliver the service. Without it, the dashboard cannot function.
Security cookies also qualify. CSRF tokens, rate-limiting cookies, and cookies that detect suspicious login attempts serve a protective function that the user implicitly expects. The same applies to load-balancing cookies that distribute traffic across servers.
User preference cookies sit in a greyer area. A cookie that remembers whether a user prefers a dark theme or a collapsed sidebar is arguably necessary to provide the service as requested. But if that same cookie also feeds data into a product analytics pipeline, it no longer qualifies for the exemption.
Dashboard Cookies That Still Require Consent
Product analytics tools are the most common pitfall. If your dashboard loads Hotjar for session recordings, Mixpanel for event tracking, or Google Analytics for usage metrics, those cookies serve your business interests rather than the user's explicit request. They require consent.
The CNIL has been particularly clear on this point. In enforcement actions throughout 2024 and 2025, the French regulator repeatedly held that analytics cookies - even when used to improve the product - do not qualify as strictly necessary. The cookie must serve the user's immediate, explicit request, not the company's interest in understanding user behaviour.
Feature-flagging tools that set cookies also need scrutiny. If your feature-flag service (LaunchDarkly, Unleash, or a custom solution) stores identifiers in cookies to track which variant a user sees, and those identifiers feed into analytics or experimentation reports, consent is required.
A/B Testing in the Dashboard
A/B testing within a SaaS application raises the same question. Running experiments on dashboard layouts or onboarding flows often involves cookies that track which variant a user was assigned to. If the experiment data is used for product analytics, the cookie is not strictly necessary for delivering the service the user requested.
Classifying Cookies Across Both Properties
The table below illustrates typical cookies found on SaaS marketing sites and application dashboards, along with their likely classification.
| Cookie / Script | Property | Category | Consent Required? |
|---|---|---|---|
PHPSESSID / connect.sid | Dashboard | Strictly necessary | No |
| CSRF token cookie | Dashboard | Strictly necessary | No |
| Load-balancing cookie | Both | Strictly necessary | No |
_ga / _gid | Marketing site | Analytics | Yes |
_ga / _gid | Dashboard | Analytics | Yes |
_fbp / Meta Pixel | Marketing site | Marketing | Yes |
Hotjar (_hj*) | Dashboard | Analytics | Yes |
| Mixpanel / Amplitude | Dashboard | Analytics | Yes |
| Feature-flag identifier | Dashboard | Functional or Analytics | Depends on use |
| UI preference (theme) | Dashboard | Strictly necessary | No |
li_fat_id (LinkedIn) | Marketing site | Marketing | Yes |
Running Separate Consent Banners for Each Property
Because your marketing site and dashboard have different cookie profiles, many SaaS companies benefit from running separate consent configurations. Your marketing site needs a full consent banner with categories for analytics and marketing cookies. Your dashboard may need a simpler banner - or potentially no banner at all if every cookie on it is genuinely strictly necessary.
That second scenario is rare in practice. Most SaaS dashboards include at least some analytics tracking. If yours does, you still need a consent mechanism within the authenticated application, even though the user has already logged in.
Placing the consent banner only on the marketing site and assuming it covers the dashboard is a mistake. Consent must be specific to the processing purpose. A visitor who consented to analytics cookies on your homepage has not consented to session-recording cookies inside your dashboard - those are different cookies, on a different subdomain, for a different purpose.
Subdomain Considerations
SaaS companies typically host their marketing site on example.com and their application on app.example.com. Cookies set with a domain attribute of .example.com are readable across both. This means a _ga cookie set on the marketing site may follow the user into the dashboard, creating a tracking link between the two properties that requires its own consent basis.
Configuring cookies with the most restrictive domain scope possible reduces this risk. Set marketing cookies only on the marketing domain and dashboard cookies only on the application subdomain.
GDPR Considerations Beyond the ePrivacy Directive
The ePrivacy Directive governs whether a cookie may be placed on a device. The GDPR governs what happens with the personal data collected through that cookie. Even if a cookie qualifies as strictly necessary under ePrivacy, the GDPR still requires a valid lawful basis for processing the personal data it contains.
For authentication cookies, the lawful basis is straightforward: performance of a contract under Article 6(1)(b). Your user signed up for a SaaS product, and the session cookie is necessary to deliver it.
For analytics cookies in the dashboard, you need either consent under Article 6(1)(a) or a legitimate interest argument under Article 6(1)(f). Legitimate interest for product analytics is theoretically possible, but it does not override the ePrivacy consent requirement for placing the cookie. You still need consent to set the cookie, even if you rely on legitimate interest for the subsequent data processing.
Practical Architecture for SaaS Cookie Compliance
A clean approach starts with a thorough cookie audit of both properties. Scan your marketing site and your application dashboard separately. Identify every cookie, its purpose, its duration, and whether it is first-party or third-party.
Once classified, implement consent controls that match each property's profile. On the marketing site, use a full cookie banner with granular categories. On the dashboard, present a lighter consent notice that covers only the non-essential cookies present in the application.
Script Blocking Before Consent
Both properties must block non-essential scripts until consent is granted. On the marketing site, this typically means conditionally loading Google Analytics, the Meta Pixel, and any advertising tags. On the dashboard, it means deferring product analytics scripts such as Mixpanel, Amplitude, or Hotjar until the user has opted in.
Google Consent Mode v2 can help bridge the data gap on your marketing site by providing modelled conversions when users decline analytics cookies. For your dashboard, consider whether privacy-preserving analytics tools that operate without cookies might reduce your consent burden altogether.
What Regulators Check in SaaS Applications
The EDPB's Cookie Banner Taskforce report, published in January 2023, set out common violations that apply equally to SaaS dashboards. Regulators look at whether cookies are set before consent is collected, whether the reject option is as easy to find as the accept option, and whether consent is freely given rather than bundled with terms of service.
A SaaS company that forces users to accept analytics cookies as a condition of using the dashboard risks violating GDPR Article 7(4), which states that consent must not be a condition for the performance of a contract. If your product works perfectly well without Mixpanel tracking, then making consent to Mixpanel a prerequisite for using the product is not freely given consent.
The CNIL fined SHEIN EUR 150 million in September 2025 for, among other violations, installing cookies before users granted permission. Similar principles apply to SaaS dashboards: if your analytics script fires on page load before the consent mechanism has rendered, you are in breach regardless of whether a banner eventually appears.
Frequently Asked Questions
Do SaaS dashboards need a cookie consent banner?
Yes, if the dashboard sets any non-essential cookies such as analytics, session recording, or A/B testing cookies. Only cookies that are strictly necessary to deliver the service the user requested are exempt from consent.
Are authentication cookies exempt from consent under GDPR?
Authentication and session cookies are exempt from the ePrivacy Directive's consent requirement because they are strictly necessary to provide the service. The GDPR lawful basis for processing the data they contain is typically performance of a contract under Article 6(1)(b).
Can I use one consent banner for both my marketing site and SaaS dashboard?
Technically possible if both run on the same domain, but not recommended. Each property typically has different cookies and purposes. A single banner may not accurately describe the cookies on each property, and consent collected on the marketing site does not automatically extend to a different subdomain.
Does Google Analytics require consent on a SaaS dashboard?
Yes. Google Analytics sets cookies like _ga and _gid that are classified as analytics cookies, not strictly necessary. This applies whether the analytics run on a public marketing site or within a logged-in dashboard.
Is product analytics like Mixpanel considered strictly necessary?
No. Product analytics tools serve the company's interest in understanding user behaviour, not the user's explicit request to use the service. Regulators such as the CNIL have consistently classified analytics cookies as non-essential, requiring consent before they are set.
How do I handle cookies that cross between marketing site and dashboard subdomains?
Set cookies with the most restrictive domain scope possible. Avoid setting marketing cookies on the root domain where they become readable by the application subdomain. Each property should have its own isolated cookie scope to prevent unintended cross-property tracking.
Take Control of Your Cookie Compliance
If you are not sure which cookies your SaaS product sets across marketing and application domains, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie on both properties - so your users get a clear choice, and you stay on the right side of the law.
