Know what is on your site before a plaintiff’s firm does.Free website scanScan Your Site
Log in Sign up Book a demo
Home› Editorial› Does Rejecting Cookies Mean Rejecting Analytics? PostHog’s Cookieless…
COOKIES

Does Rejecting Cookies Mean Rejecting Analytics? PostHog’s Cookieless Mode Tests Privacy Law

PostHog Cookieless Tracking After Cookie Rejection: Is It Legal Under GDPR, CCPA and EU Privacy Laws?

Oct 31, 2026 20 min read

Know what’s on your site before a plaintiff’s firm does

A free privacy audit shows which cookies, pixels and trackers are running — and which ones commonly appear in privacy claims.

Get My Free Audit

PostHog Cookieless Tracking After Cookie Rejection: Is It Legal Under GDPR, CCPA and EU Privacy Laws?

When someone clicks “Reject All” on a cookie consent banner, should the website stop collecting analytics entirely? Or can the business continue measuring traffic if its analytics software does not store cookies, create persistent identifiers or record individual browsing sessions?

That question has become increasingly important as analytics providers introduce privacy-preserving alternatives to traditional browser tracking. One example is PostHog, a product analytics platform that offers a cookieless mode designed to measure website activity without placing tracking identifiers in a visitor’s browser.

PostHog’s approach is technically interesting. Instead of assigning a persistent browser identifier, it uses a server-generated hash that changes daily. Visitors who decline cookies can still contribute to audience measurements, but their activity is not connected across multiple days through that identifier. Session recordings are also disabled for users who have not consented.

The obvious question for privacy officers and website operators is whether this arrangement can operate legally after someone rejects optional cookies.

The answer is potentially yes, but cookieless analytics is not automatically consent-exempt analytics. The legal analysis depends on the information processed, how the technology obtains that information, the purpose of the processing, the jurisdiction and what the visitor was told when making their privacy choices.

Under GDPR and Europe’s ePrivacy framework, removing cookies does not necessarily remove the requirement to obtain consent. The United Kingdom has introduced a more explicit exemption for certain statistical analytics, while France has long permitted limited audience measurement without consent under specified conditions. In the United States, first-party audience measurement generally faces fewer restrictions, although state privacy laws still govern personal information and particular data uses.

Understanding these distinctions is essential for businesses looking to maintain useful website analytics without disregarding consumer preferences.

Posthog

What Is PostHog’s Cookieless Tracking Mode?

PostHog’s cookieless tracking documentation describes a configuration that allows websites to measure traffic without relying on traditional browser-based visitor identifiers.

PostHog supports two principal cookieless configurations. The first, called “always,” keeps the platform in cookieless mode continuously. The second, called “on_reject,” allows ordinary consented analytics while switching to a restricted cookieless configuration when a visitor declines tracking.

For businesses using a consent management platform, the second option is particularly relevant.

Under the documented “on_reject” configuration, PostHog does not collect analytics events while the visitor’s consent decision remains pending. Once a visitor consents, the website can enable its consented analytics configuration. If the visitor rejects, PostHog can instead operate in cookieless mode.

For visitors using the cookieless configuration, PostHog states that:

  • No PostHog tracking identifiers are stored in browser cookies, local storage or session storage.
  • Session recordings and surveys are disabled for visitors who have not provided the relevant consent.
  • A temporary identifier is generated on PostHog’s servers rather than persisted in the browser.
  • The identifier changes daily, preventing consistent identification of the same visitor across different days through that hash.
  • IP addresses are removed before certain downstream enrichment processes, including GeoIP enrichment.

The result is a substantially different analytics model from conventional persistent visitor tracking.

However, the absence of browser cookies is only one part of the legal analysis.

How PostHog Tracks Visitors Without Cookies

PostHog’s cookieless implementation generates a daily identifier from several inputs, rather than retrieving a stored browser identifier.

Its published calculation uses the following components:

hash(
  team_id,
  daily_salt,
  ip_address,
  user_agent,
  hostname
)

The team ID identifies the PostHog project. The hostname identifies the website. The IP address and user agent provide information associated with the visitor’s network connection and browser environment.

A daily salt changes the resulting hash over time. PostHog states that it deletes the salt after the relevant day’s events have been processed.

As a result, a visitor returning the following day will generally receive a different identifier. The platform cannot reliably use that daily hash to reconstruct a person’s browsing history across multiple days.

This comes with analytical limitations. Returning visitors can be counted as new visitors on subsequent days, and different people sharing the same IP address and browser characteristics may occasionally receive matching daily identifiers.

PostHog also loses certain capabilities associated with traditional analytics, including reliable cross-session retention measurement and some geographic enrichment.

These limitations are part of the privacy tradeoff. A company can retain basic audience measurement while giving up capabilities that depend on persistent visitor recognition.

Nevertheless, a daily rotating identifier is not the same thing as collecting no personal information.

PostHog still receives technical information, including the IP address and user agent, to calculate the hash. The fact that the resulting identifier changes every day does not automatically determine the legal status of the information processed beforehand.

Does PostHog’s Cookieless Mode Comply With GDPR?

There are two separate legal questions under the European privacy framework.

The first concerns the processing of personal data under the General Data Protection Regulation (GDPR). The second concerns access to or storage of information on a user’s device under Article 5(3) of the ePrivacy Directive, as implemented through national law.

These rules overlap, but they are not interchangeable.

A website may have a lawful basis for processing certain personal information under GDPR and still need consent under applicable ePrivacy rules for the technology used to collect it.

Conversely, a particular technical operation may fall outside Article 5(3) or qualify for an exemption, while the resulting personal data processing remains subject to GDPR obligations.

GDPR: Is the Daily Hash Anonymous Personal Data?

PostHog describes its daily hash as privacy-preserving and takes the position in its documentation that the resulting identifier is not personal data because the original inputs cannot be recovered from the hash.

That statement should not be treated as a universal legal determination.

Under GDPR, information can qualify as personal data when it relates to an identified or identifiable natural person. Identifiability must be evaluated in context, including the means reasonably likely to be used to identify someone.

Hashing personal information does not necessarily anonymize it. In many circumstances, hashed identifiers remain pseudonymous personal data because they can still be associated with an individual or combined with other information.

PostHog’s daily salt and deletion practices reduce that risk. However, the legal determination depends on the complete processing arrangement, including what additional event properties are collected, whether identifiers can be linked to other datasets and whether the data remains attributable to an individual.

IP addresses and user-agent information used to generate the hash can themselves constitute personal data. Their collection and processing therefore require appropriate GDPR analysis even if the final stored identifier is genuinely anonymous.

Where personal data is processed, businesses need an applicable Article 6 lawful basis and must satisfy relevant transparency, minimization, retention and security obligations.

Legitimate interests may be available for some limited first-party analytics processing, depending on the circumstances and the required balancing assessment. But legitimate interests cannot be used to bypass a separate ePrivacy consent requirement where that requirement applies.

The European Data Protection Board addressed this issue directly in its Guidelines 2/2023 on the Technical Scope of Article 5(3) of the ePrivacy Directive, finalized in October 2024.

The guidelines examine technologies that access or store information on user devices without necessarily using traditional cookies.

Examples include tracking pixels, URL-based tracking, local processing and techniques that rely on IP addresses.

The EDPB explains that Article 5(3) can apply to techniques that obtain information originating from a user’s terminal equipment, even when the collection mechanism is different from conventional cookie storage.

With IP-based tracking, the legal analysis includes whether the information originates from the user’s terminal equipment and whether the technical operation constitutes access within the meaning of the directive.

That distinction is highly relevant to PostHog because the server-generated identifier uses IP addresses and browser information.

It would be incorrect to conclude that every ordinary HTTP request automatically triggers consent requirements simply because a server receives an IP address. The EDPB’s analysis is more specific and depends on how information is obtained and used.

However, it is equally incorrect to assume that the absence of browser storage removes Article 5(3) from consideration.

If a cookieless analytics implementation involves regulated access to terminal information, the business must establish whether consent is required or whether an applicable exemption covers the operation.

Does Reject All Mean a Website Must Stop Every Analytics Request?

Not necessarily. The answer depends on what the visitor rejected and whether the remaining processing is legally permitted.

Consider two different consent banner messages.

The first says, “Reject optional cookies.”

The second says, “Reject all analytics and tracking.”

Those statements communicate different things.

A visitor selecting the first option might reasonably understand that optional browser cookies will not be used. A properly disclosed, genuinely cookieless form of audience measurement may be consistent with that statement, assuming it is otherwise lawful.

A visitor selecting the second option has been told they can refuse analytics itself. Continuing to send PostHog analytics events after that decision could contradict the interface, even when the technical implementation does not store cookies.

The important distinction is between declining a specific storage technology and declining a particular processing purpose.

A business cannot simply label its analytics “cookieless” and disregard the broader choice it presented to visitors.

Nor should businesses treat privacy-preserving analytics as strictly necessary by default. Audience measurement may provide operational benefits, but that does not automatically make it essential to deliver a service requested by the user.

In practice, a consent management platform should distinguish among analytics that require consent, analytics that qualify for a specific exemption and processing that is genuinely necessary for service delivery.

The United Kingdom offers an important example of how regulators are addressing privacy-preserving analytics.

Changes introduced through the Data (Use and Access) Act 2025 established additional exceptions to the UK’s Privacy and Electronic Communications Regulations (PECR).

In April 2026, the Information Commissioner’s Office finalized updated guidance on storage and access technologies, including a statistical purposes exception.

The exception can permit certain technologies to operate without consent where their sole purpose is collecting statistical information about how a website or service is used, with a view to improving that website or service.

Examples can include measuring visitor numbers, understanding which pages people access and assessing how visitors navigate a website.

However, the exemption does not provide blanket permission for analytics.

The ICO explains that the exception concerns aggregate statistical measurement, not the identification, tracking or monitoring of individual users for unrelated purposes. It also does not cover online advertising measurement simply because the resulting information can be expressed statistically.

Businesses relying on the exception must provide clear information about the processing and a simple, free means for users to object.

That last requirement is particularly important for PostHog implementations.

A website might lawfully operate a narrowly configured statistical analytics tool without prior consent under the UK exception, but it must still respect an objection made through the required mechanism.

If the website’s Reject All button is presented as an objection to analytics, continued collection could conflict with the visitor’s expressed choice and the conditions of the exemption.

Businesses must also consider UK GDPR requirements for any personal data processed as part of the statistical activity.

France’s CNIL Has Long Recognized an Exemption for Limited Audience Measurement

France provides another relevant regulatory model.

The French data protection authority, CNIL, permits certain audience-measurement trackers to operate without prior consent when they satisfy strict conditions.

Under CNIL’s published audience-measurement guidance, qualifying analytics must be limited to specified purposes such as audience measurement and A/B testing, with appropriate privacy protections.

Conditions include informing users, providing an opportunity to object, limiting the scope of tracking to a single publisher and avoiding combinations with unrelated datasets.

CNIL’s guidance also addresses IP address truncation, identifier lifetimes and restrictions on using the data for other purposes.

The regulator specifically warns that many mainstream analytics products do not qualify for its exemption merely because businesses configure them with fewer features.

PostHog’s daily rotating identifier and restrictions on persistent tracking are relevant to this analysis, but they are not sufficient on their own to prove compliance with CNIL’s conditions.

A business would still need to examine the exact events collected, processor arrangements, IP handling, identifier scope, retention settings and objection mechanism.

It would also need to establish that the data is not repurposed for advertising, cross-site tracking or other uses outside the exemption.

The French framework is therefore a possible route for limited analytics without prior consent, not an unconditional approval of PostHog or cookieless tracking generally.

In the United States, the legal analysis is different because most comprehensive state privacy laws do not impose a general opt-in cookie consent requirement comparable to the EU ePrivacy framework.

Under California’s Consumer Privacy Act, as amended by the California Privacy Rights Act, businesses must satisfy requirements concerning transparency, permitted uses, consumer rights and the sale or sharing of personal information.

Using a first-party analytics provider solely to understand website performance does not automatically constitute selling or sharing personal information for cross-context behavioral advertising.

That distinction can make PostHog’s restricted cookieless configuration considerably easier to justify in the United States than in some European jurisdictions.

However, the analysis must consider the actual vendor relationship and data flows.

If the analytics provider uses personal information for unrelated commercial purposes, combines it with information from other clients or participates in cross-context behavioral advertising, additional restrictions may apply.

Businesses should confirm whether the provider operates under appropriate service-provider or contractor terms where required, including restrictions on secondary data use.

The California Privacy Protection Agency also explains that consumers have rights concerning the sale and sharing of personal information, including the use of recognized opt-out preference signals.

Those rights must be respected regardless of whether a particular vendor uses browser cookies.

A cookieless analytics system may still process personal information, and some state laws impose additional obligations concerning sensitive information, disclosures, profiling or targeted advertising.

Website operators should therefore avoid treating the word “cookieless” as a substitute for reviewing the vendor’s contractual and technical practices.

In many cases, the privacy notice should be updated. Whether the initial banner must change depends on the jurisdiction, the nature of the remaining analytics and the choices currently presented to visitors.

The purpose of a disclosure is not merely to list cookies. It is to give consumers an accurate understanding of how their information is collected and used.

If a website continues processing technical information through PostHog after visitors decline optional cookies, its notice should explain that restricted analytics processing.

The disclosure should identify the relevant purposes, explain the absence of persistent browser identifiers, describe the use of temporary daily identifiers and state whether the analytics provider processes technical data such as IP addresses and browser information.

It should also distinguish ordinary site analytics from advertising and behavioral profiling.

Where an applicable analytics exemption requires an objection mechanism, the notice or privacy interface must provide an effective way to exercise that right.

A privacy notice alone does not cure an unlawful implementation. If consent is legally required for the technical processing, merely disclosing that the processing occurs is insufficient.

Example Privacy Notice Language for PostHog Cookieless Analytics

The following is an illustrative disclosure for a website that has validated the technical configuration and established an applicable legal basis or exemption:

Privacy-Preserving Website Analytics

We use PostHog to understand how visitors use our website and to improve its performance and functionality. When visitors decline optional analytics cookies, we may use a restricted cookieless analytics configuration where permitted by applicable law.

In this mode, PostHog does not store tracking identifiers in browser cookies or local storage, and session recordings are disabled. Instead, a temporary identifier is generated using technical information such as an IP address and browser information. This identifier changes daily and is not intended to recognize visitors across different days.

We use this information for website audience measurement and performance analysis, not for personalized advertising or cross-site behavioral profiling. Where consent is required, we do not conduct this processing without the necessary consent. Where applicable law permits limited statistical analytics without consent, visitors may exercise any applicable right to object through our privacy controls.

This wording should not be copied without checking the actual implementation. For example, a website that sends account IDs, email addresses or sensitive event properties to PostHog would need different disclosures and a separate legal assessment.

What Businesses Should Avoid When Implementing Cookieless Analytics

The greatest compliance risks often arise when a privacy-conscious analytics configuration operates alongside other tracking features that undermine its intended restrictions.

PostHog supports a broad range of product analytics capabilities, including user identification, event tracking, feature flags, experimentation and session replay.

Those functions can be useful for businesses, but not every feature is appropriate for a visitor who has rejected optional analytics or tracking.

For example, PostHog’s person profile documentation explains that identified events can create user profiles and connect activity with identifiable accounts. An implementation that sends stable user IDs or email addresses after rejection can undermine the privacy benefits of daily rotating identifiers.

Similarly, automatic event capture may collect more information than the business needs for basic audience measurement. URLs, search terms, custom event properties or other application data can contain personal or sensitive information.

Businesses should examine whether such properties remain present in cookieless events and remove unnecessary fields.

Another concern is the use of multiple analytics tools. Restricting PostHog does not automatically restrict Google Analytics, Meta Pixel, advertising tags or other applications operating on the same page.

A website could have a properly configured cookieless PostHog implementation while other integrations continue placing cookies or transmitting personal information contrary to the visitor’s choices.

Compliance must therefore be assessed across the complete tracking environment rather than one vendor’s settings.

For organizations using both a consent management platform and PostHog, the central implementation question is how the two systems communicate.

At Captain Compliance, our consent management software helps businesses control optional tracking, communicate visitor preferences and assess the technologies operating on their websites.

A PostHog integration can be designed around three different consent states: pending, accepted and rejected.

While consent is pending, collection should remain disabled when the applicable legal configuration requires prior permission.

After acceptance, the website can enable the analytics features covered by the visitor’s consent.

After rejection, the implementation should either disable PostHog analytics entirely or use a separately reviewed, restricted cookieless configuration where the processing is legally permitted and consistent with the visitor’s expressed choices.

That third state is important. A privacy platform should not assume that all cookieless technologies are strictly necessary, nor should it automatically block every form of genuinely consent-exempt audience measurement.

Instead, businesses need a policy-based approach that accounts for the purposes of processing, applicable jurisdiction, technical safeguards and required consumer controls.

Captain Compliance’s cookie scanning, consent management and script-control capabilities can help organizations inventory analytics technologies, implement appropriate consent states and test whether tracking behavior matches their privacy configuration.

Where PostHog requires custom consent synchronization or special treatment after rejection, that integration should be validated against the actual deployment rather than assumed to work automatically.

For organizations operating internationally, geo-adaptive consent management can help apply different policies in jurisdictions with different legal requirements.

For example, a business may elect to disable post-rejection analytics in EU jurisdictions unless a specific exemption has been established, while permitting narrowly configured first-party audience measurement in U.S. jurisdictions where the processing is otherwise lawful.

The objective is not to maximize the number of analytics events collected after rejection. It is to preserve legitimate measurement without overriding privacy choices or relying on unsupported assumptions about consent exemptions.

How to Audit a PostHog Cookieless Implementation

Before enabling PostHog after cookie rejection, a privacy or technical team should test the configuration in a controlled environment.

First, confirm that cookieless tracking is enabled in the PostHog project settings and that the JavaScript SDK is configured for the intended consent behavior.

Next, test the website in a fresh private browsing session with no existing PostHog identifiers or consent records.

While the consent decision is pending, examine browser storage and network requests to confirm that the website behaves according to the selected regional policy.

Then reject optional tracking and verify that PostHog does not write persistent identifiers to cookies, local storage or session storage.

Inspect the requests transmitted to PostHog. The relevant questions include which event properties are sent, whether any account identifiers are present, whether the user’s choices are respected and whether session recordings are disabled.

PostHog’s documentation states that cookieless events use server-generated daily identifiers and that IP addresses are stripped before specified downstream enrichment processes. Businesses should nevertheless review the data’s processing path, including any relevant server logs, retention arrangements and vendor contracts.

The team should also determine whether server-side integrations or other applications can send identified events independently of the browser consent state.

Finally, repeat the test after the visitor changes preferences. A user who initially accepts analytics but later rejects should not continue being tracked under the previous consent state.

Where a jurisdiction requires an objection mechanism for exempt statistical analytics, test that mechanism separately from ordinary cookie rejection if the interface treats them as distinct choices.

These tests should be documented and repeated when tracking configurations, application code or vendor integrations materially change.

Is Cookieless Analytics Truly Anonymous?

The terms “cookieless,” “anonymous” and “privacy-preserving” are sometimes used interchangeably in marketing materials, but they describe different properties.

Cookieless means the technology does not rely on cookies. It does not establish whether the information is personal data or whether consent is required.

Privacy-preserving describes an approach designed to reduce privacy risks. It is not a specific statutory exemption.

Anonymous information, in the GDPR context, is information that does not relate to an identified or identifiable individual, taking account of the applicable identifiability assessment.

A daily salted hash can reduce long-term linkability, particularly when it is generated server-side and the salt is destroyed. But the surrounding processing can still involve personal data, and other event properties may allow someone to be identified.

The legal classification should therefore be based on the complete dataset and processing architecture, not merely the mathematical properties of one identifier.

PostHog’s design represents a meaningful reduction in persistent tracking, but it should not be described as categorically anonymous or GDPR-exempt without further analysis.

Can PostHog Run After a Visitor Clicks Reject All?

Potentially. A restricted cookieless configuration may be permissible where the processing does not require consent or qualifies for an applicable exemption. The website must also honor the actual choice presented to the visitor and any applicable right to object.

Does PostHog Cookieless Mode Store Cookies?

PostHog states that its cookieless mode does not store its tracking identifiers in browser cookies, local storage or session storage. Businesses must still check whether other applications on the website store identifiers independently.

Does PostHog Collect IP Addresses in Cookieless Mode?

PostHog uses IP addresses, user-agent information and other inputs to generate its server-side daily hash. It states that IP addresses are removed before certain downstream enrichment stages. Businesses should distinguish this from a claim that IP addresses are never received or processed.

Does a Daily Rotating Identifier Eliminate GDPR Obligations?

No. A daily rotating identifier can reduce the ability to track people over time, but the associated processing may still involve personal data or regulated access to terminal information. GDPR and ePrivacy must be assessed separately.

Is Cookieless Analytics Considered Strictly Necessary?

Not automatically. Audience measurement usually benefits the website operator, and that alone does not make it strictly necessary to provide a requested service. Some jurisdictions permit limited analytics under specific exemptions, but those exemptions have their own conditions.

The website must provide accurate, legally sufficient information about its analytics processing. A detailed explanation may appear in the cookie or privacy notice, but the initial consent interface must not misrepresent what rejecting analytics actually does. Additional notice and objection controls may be necessary depending on the jurisdiction.

Can PostHog Session Recordings Continue After Rejection?

PostHog states that session recordings are disabled for visitors using its restricted cookieless configuration without the relevant consent. Businesses should verify this behavior and ensure that other session-replay technologies are not operating independently.

Possibly, but not solely because the mode is cookieless. PostHog supports an “always” cookieless configuration, yet businesses must still assess the relevant ePrivacy requirements, GDPR processing and transparency obligations. A consent-free deployment is defensible only where the specific processing is lawfully permitted without consent.

The Future of Web Analytics Is Less Persistent Tracking, Not Less Privacy Compliance

PostHog’s cookieless mode illustrates a useful direction for web analytics: businesses can obtain meaningful operational information without necessarily assigning every visitor a persistent identifier or recording individual sessions.

Daily rotating identifiers and reduced browser storage can significantly limit the ability to build long-term browsing histories. For organizations that primarily want to understand page traffic, navigation patterns and website performance, those tradeoffs may be acceptable.

But technical privacy improvements do not automatically create legal exemptions.

European ePrivacy requirements can apply to certain device-information collection techniques even without cookies. GDPR may apply to personal data processed before or during anonymization. The UK’s statistical purposes exception and France’s audience-measurement exemption permit certain processing without consent, but impose restrictions concerning purpose, transparency and objection rights.

In the United States, the analysis often focuses more heavily on personal information use, vendor relationships, advertising disclosures and applicable consumer opt-out rights.

For businesses, the most defensible approach is to evaluate each analytics configuration according to what it actually collects and how it operates.

The absence of cookies is not the absence of tracking. And the absence of persistent tracking is not, by itself, proof that consent is unnecessary.

Businesses that preserve that distinction can use privacy-conscious analytics without making promises to visitors that their websites do not actually honor.

if this question comes up with your chief privacy officer or legal team you can now reference this article or just get a free privacy audit from one of our privacy engineers and we’ll be glad to help guide you on best practices.

Put this into practice

Turn privacy guidance into working controls.

Captain Compliance helps teams discover tracking technologies, enforce consent, manage privacy requests and document the evidence behind every decision.

Book a demo Run a free scan