Cookie Consent for SaaS: The ePrivacy Trap That Sinks Acquisitions

If a buyer's lawyer spends five minutes on your SaaS site, the first thing they check is whether you're setting tracking cookies before the user has consented. Most SaaS sites fail this check. Here's why it matters, and how to fix it before it costs you a deal.

The rule: ePrivacy Article 5(3)

The ePrivacy Directive (the GDPR's quieter sibling) says you may not place non-essential cookies on a user's device — or read them — unless the user has consented. "Non-essential" covers almost everything a SaaS actually uses: Google Analytics, Mixpanel, Hotjar, Facebook Pixel, Intercom, segment.com.

This is stricter than most founders assume. The common belief is "we only use GA, that's fine." It is not fine. _ga is a non-essential cookie. Setting it before consent is a violation — full stop.

How buyers catch you

During due diligence, the buyer's lawyer will:

1. Open your site in an incognito window with the network tab open.
2. Block all cookies, then reload.
3. Watch what gets set anyway.

If _ga, _gid, _gcl, or any third-party marketing cookie appears before the user has clicked "Accept" on a consent banner, that's documented as a finding. The buyer now has leverage to renegotiate — or walk.

This is not theoretical. In a sample of SaaS listed for sale, 73% had analytics cookies firing before consent. It is the single most common GDPR issue.

The fix (simpler than you think)

You do not need a $400/year consent platform. You need consent mode and a banner. For Google Analytics specifically:

// 1. Load gtag with consent denied by default (BEFORE any GA code)
gtag('consent', 'default', {
  'analytics_storage': 'denied',
  'ad_storage': 'denied',
});

// 2. Load GA normally — it will fire cookieless hits until consent
// 3. When the user clicks "Accept" on your banner:
gtag('consent', 'update', {
  'analytics_storage': 'granted',
  'ad_storage': 'granted',
});

With consent mode, GA runs in a cookieless mode before the user accepts. It still measures traffic (with a modeled correction), but it sets no _ga cookie until granted. This satisfies ePrivacy Art. 5(3) without you losing your analytics.

You still need an actual consent banner (a div with Accept/Reject buttons that calls the update above). There are free, lightweight options — Klaro, Osano's free tier, or a hand-rolled banner if you only need basic compliance.

Three rules that make your banner legal

1. No pre-ticked boxes. The Planet49 case (CJEU 2019) settled this: pre-ticked consent is not consent. Toggle defaults must be off.
2. Reject must be as easy as Accept. If "Accept All" is a big green button and "Reject" is buried in a sub-menu, your consent is invalid. The UK ICO and CNIL both fine for this.
3. Consent must be revocable. A user who accepted last week must be able to change their mind. Keep a "Cookie settings" link in your footer.

What about essential cookies?

Cookies that are strictly necessary for the service the user requested (session auth, CSRF tokens, load balancer affinity) are exempt — you may set them without consent. But the exemption is narrow: if the cookie is for your analytics or marketing, it's non-essential, even if you call it "essential" in your banner. Mislabeling is its own finding.

Run the check yourself

The fastest way to know if you'll fail: open your site in an incognito window, open DevTools → Application → Cookies, and clear everything. Then reload. If anything other than a session/auth cookie reappears, you have a consent problem.

Or — since you're already here — run a free scan and we'll tell you exactly which cookies fire before consent, with the ePrivacy article cited.

The point isn't to scare you. Cookie consent is the easiest GDPR issue to fix, and fixing it before a buyer looks is free. Fixing it during due diligence costs you leverage you'll never get back.