How to set up PostHog: GDPR, CCPA, and global privacy laws | Probo

Get compliant

About The people and vision powering Probo Blog The latest news from Probo Stories Hear from our customers Changelog Latest product updates Docs Documentation for Probo GitHub Explore our open-source compliance tools<br>Back to Blog<br>May 27, 2026, by Émile RÉ<br>How to set up PostHog: GDPR, CCPA, and global privacy laws<br>Two clean ways to wire PostHog into a website that respects GDPR, CCPA, UK GDPR, LGPD, PIPEDA, and the rest of the alphabet soup of privacy laws — without losing analytics.<br>You want to put PostHog on your site. Your legal team mentioned GDPR. Your US sales lead just learned about CCPA. Your support team asked about that LGPD thing in Brazil. Now you’re staring at a “cookieless mode” setting and wondering if you have to throw the whole analytics stack away.

You don’t. There are two clean ways to do this, and your choice depends on a single question: do you care about anything beyond counting unique visitors and pageviews?

This guide walks you through both, with the minimum amount of code, the configuration knobs that actually matter, and the regulation-aware bits Probo handles for you so you don’t have to.

TL;DR

PostHog cookieless mode removes the consent gate around PostHog itself — but you lose identify(), session replay, surveys, persistent feature flags, and GeoIP enrichment. You still need the banner for everything else on the site (fonts, embeds, error tracking, ads…).

If you need any of those , run PostHog with consent. The Probo cookie banner picks the right mode (opt-in for GDPR / UK GDPR / ePrivacy / LGPD / FADP / POPIA / PIPL / PIPA / DPDP / PDPL, opt-out for CCPA / CPRA / PIPEDA / LFPDPPP / APPI) per visitor based on their country, so you don’t write a country table in your codebase.

Existing consent always wins over the regulation default — if the visitor has already accepted or rejected on a previous visit, that decision is honored. The previous decision is read from the probo_consent cookie, which is itself strictly necessary (it exists to enforce compliance) and therefore allowed to be set without consent.

Never initialize PostHog — or set any non-essential cookie — before the banner has resolved (1) the applicable regulation / consent mode and (2) the visitor’s existing consent. Wait for the probo-ready event. Initializing too early either drops a cookie on an opt-in visitor without consent (out of step with GDPR’s prior-consent requirement) or fires a $pageview you can’t recall for an opt-out visitor who already rejected on a previous visit.

Don’t forget the PostHog project setting : even with cookieless_mode enabled in the SDK, you must turn on Cookieless server hash mode under Project Settings → Web Analytics, otherwise unique-user counts won’t be computed for rejected/anonymous visitors.

Custom events that carry user data must be gated on posthog.has_opted_in_capturing() (or a consent-check helper — covered below) — don’t trust the SDK to scrub PII for you.

The shape of the problem

PostHog-js, by default, drops a first-party cookie and writes to localStorage so it can give every visitor a stable distinct_id. Under GDPR’s ePrivacy Directive, that counts as accessing terminal equipment and requires prior consent. Under CCPA/CPRA it doesn’t require prior consent, but you must offer an opt-out. Under LGPD, opt-in. Under PIPEDA, “meaningful consent” which in practice means opt-out is fine. And so on for a dozen more regulations.

There are essentially two ways out of this maze:

Don’t store anything. Use PostHog’s cookieless mode and count visitors with a server-side hash. PostHog itself no longer triggers a consent requirement — but you still need a banner for the rest of the page (fonts, embeds, support widgets, error tracking, marketing tags), so don’t read this as “no banner needed.”

Store stuff, but only with the right consent. Run PostHog normally where the regulation allows it (or where the visitor agreed), and degrade gracefully to cookieless where it doesn’t.

Pick one based on what you actually need from analytics. In both cases, the Probo cookie banner stays on the page.

Decide which track you’re on

You’re on Track 1 (cookieless-only) if all you need from PostHog is:

Pageviews and basic web analytics (referrers, top pages, bounce rate)

Custom events that contain no user-level data

Top-level conversion funnels measured per-day

You’re on Track 2 (consent-aware) if you need any of:

identify() to tie behavior to a known user (sign-up, login, account ID)

Session replay

Surveys

Feature flags with caching (no extra round-trip on each page load)

Cross-day or cross-device user journeys (weekly/monthly retention, attribution)

GeoIP enrichment, bot detection, or the web analytics world map

Person profiles linking multiple events to one human

If you tried to claim Track 1 but you also want session replay, you can’t have both. Pick again.

In practice, most companies need both —...