Cookieless tracking: what still works, what changes and what to measure

Last updated: 2 September 2026.

Ask what “cookieless” means in this product

A vendor can use the word for several different designs. One sends events without browser storage. Another estimates visitor counts from short-lived server-generated identifiers. Another moves an existing identified event to a server. Those designs have different capabilities and privacy implications.

Ask four questions before evaluating a dashboard:

• Does the SDK read or write cookies, local storage, session storage or another identifier on the device?
• What information leaves the browser, including automatically added properties?
• How does the system decide that two events belong to the same visitor, and for how long?
• What information is retained, joined or forwarded after collection?

The answer should describe the configured product, not just its default marketing claim. A persistent account ID sent with every event creates continuity even if no analytics cookie exists. Replacing a cookie with local storage changes the storage mechanism, not the purpose of the identifier.

Write those answers into the tracking plan. They explain which analyses the data can support and stop a later team from treating a deliberately limited dataset as a complete customer history.

Do not confuse first-party cookies with third-party cookies

GA4's JavaScript tags use first-party cookies to distinguish users and maintain session state. Google also says the libraries can transmit data without setting cookies. These are separate facts: using GA4 does not automatically mean depending on a third-party cookie, and transmitting an event does not necessarily mean observing a persistent person. GA4 cookie documentation.

There is also no sound basis for planning around an old headline that every Chrome third-party cookie disappears on one universal 2026 deadline. Google's October 2025 update retained its approach to user choice and announced retirement of several Privacy Sandbox technologies. Google's update.

The current status page lists Attribution Reporting, Topics and Protected Audience among technologies being deprecated and removed. Do not build a new measurement plan around their old launch documentation without checking status. Privacy Sandbox feature status.

For the business, the practical issue remains: browser behaviour, consent choices and identity availability vary. Build a measurement plan that states where observations are incomplete instead of betting the entire plan on a browser roadmap.

What cookieless measurement means in GA4

Consent Mode changes tag behaviour according to the consent state. In basic mode, Google tags are blocked before consent. In advanced mode, tags can send consent signals and measurements without cookies while the relevant storage consent is denied. Google's Consent Mode overview.

That does not create the same dataset as a consented, persistently identified journey. Receiving several events without persistent identifiers does not establish how many people produced them or which visits belong together.

GA4 can use behavioural modelling to estimate otherwise unobservable user and session behaviour. The property needs a compatible implementation, enough observed and denied-consent data and model eligibility; meeting published thresholds alone does not guarantee availability. Modelled results are estimates, not reconstructed records identifying each non-consenting visitor. GA4 behavioural modelling.

For a small website, verify whether modelling is actually available before promising a replacement for missing reports. A valid consent implementation can exist without enough volume for the model. The GA4 troubleshooting guide explains the relevant checks.

Also specify which surface you are analysing. A raw export and an interface report containing modelled data need not reproduce the same number. Label observed records, modelled estimates and operational business totals distinctly in recurring reporting.

Use advanced mode only when its actual collection behaviour fits the reviewed requirements. “Denied” in a storage field is not a statement that no network request occurs.

PostHog: choose the mode and accept the identity limits

PostHog documents cookieless_mode: 'always' and 'on_reject'. The project must also enable cookieless server hash mode; its SDK reference says events are ignored if that project setting is missing. In always mode, measurement begins without cookies or local/session storage. The configuration reference also exposes controls for person profiles and capture behaviour.

The cookieless tutorial explains that on_reject waits for a consent decision before capture, then uses cookies after acceptance or cookieless measurement after rejection. That is not the same as stopping all analytics after rejection. Make sure the choice wording and approved behaviour match it.

PostHog creates a server-side identifier from inputs including project, daily salt, IP address, user agent and hostname. The daily rotation breaks continuity across days. Similar visitors sharing inputs can also be grouped together. Session replay and surveys are unavailable without cookie consent, and feature-flag caching behaviour changes.

Avoid adding persistent identity back accidentally. The tutorial recommends person_profiles: 'never' to make identify() a no-op when identification is not intended; cookieless alias events are dropped. Check your application wrapper and integrations too, rather than assuming the initialization setting removes custom identifying properties.

PostHog's data-storage documentation adds another practical limitation: cookieless mode strips the IP before transformations, so IP-based GeoIP enrichment and bot detection do not enrich those events. That differs from its ordinary discard-IP setting, where those transformations can run first.

These details matter when choosing a mode. A location dashboard, recorded-session workflow or returning-user retention report cannot be promised on the strength of a cookieless pageview demo.

Plausible: useful website statistics with a shorter identity horizon

Plausible's current data policy describes a daily, site-specific identifier derived from request information and a rotating salt. It does not use cookies or browser storage for this identifier and says raw IP addresses and user-agent strings are not retained. It cannot recognise the same visitor across days, websites or devices. Plausible data policy.

The policy also states that individual event and session records are stored to calculate the aggregated dashboard. “Aggregate reporting” should not be mistaken for “only aggregate records ever exist.” The configured collection can include page paths, referrals, campaigns, custom events, properties and revenue.

For a content or marketing site, that can support useful questions about page demand and observed goal completions. It does not provide a dependable month-long person history by itself. Review what your custom events and properties contain before adopting a general privacy claim from the product page.

Choose this kind of design when the required decision fits the shorter identity horizon. Do not buy it to answer an account-level product question, then quietly recreate persistent identification inside custom properties.

Choose the measurement unit before choosing the tool

Different questions can remain useful at different levels of detail.

Content demand: pageviews, traffic sources and engagement trends can help identify which guides deserve improvement. Check bot handling, event definitions and collection coverage before interpreting changes.

A short conversion path: a same-visit signup funnel may be measurable if the chosen mode can connect the relevant events through that visit. Test the actual embedded form or cross-domain route; do not assume continuity from the dashboard's funnel feature alone.

Returning-user retention: this requires an identity definition that remains meaningful over the retention window. Daily rotating anonymous identifiers do not establish that someone returned next week.

Account activation and churn: these usually depend on known product, billing or CRM entities. Use appropriately governed operational identities and purpose-specific product measurement. An account identifier is not made anonymous by transporting it without an analytics cookie.

Advertising impact: observing a visit or conversion does not show what would have happened without the advertising. Cookieless collection cannot, on its own, turn attribution into causal evidence. Use the incrementality decision guide when the question is whether the spend creates additional business.

The point is to preserve the least detailed evidence that can answer the real question. Some decisions need durable identity; many website improvements do not.

Open full diagram

Understand how a new identifier changes the denominator

Consider a fictional dataset in which the same 100 people visit on Monday and Tuesday. Assume each person is counted once per day, with no collisions or missing visits. A daily rotating identifier creates 200 distinct visitor-day identifiers across those two days, even though the example contains 100 people.

Now suppose ten of those people complete one signup each during the period. Dividing ten signups by 200 visitor-day identifiers gives 5%. Dividing ten by the 100 known people in this fictional example gives 10%. The arithmetic is straightforward; the denominators answer different questions.

In a real anonymous dataset, you may not know the 100-person denominator. Do not relabel a visitor-day ratio as a person-level conversion rate or infer that conversion performance halved after migration. The identity definition changed.

The reverse problem can occur when different people produce the same short-lived identifier. Counts can merge as well as split. This is why a dashboard label such as “unique visitors” needs a documented implementation definition.

Keep the comparison honest: daily visitor estimates against daily visitor estimates, event counts against the same event definition and operational signups against reconciled signup records. Annotate the change date and explain which historical trend lines are no longer directly comparable.

Server-side tracking is a separate architectural choice

A server container receives requests, processes events and forwards selected data. It can provide control over routing and fields, but it does not automatically remove browser storage or identity. Google's server-side tagging introduction describes that processing model.

For example, a browser can still send a cookie-derived identifier to a first-party collection endpoint, which then forwards it. The hostname changed; the identity did not. A backend purchase event can also carry a stable customer identifier without involving an analytics cookie at all.

Use server-side processing where it solves a defined problem, such as validating an outcome, reducing unnecessary fields or controlling destinations. Check logs and onward requests as well as the final analytics table. Removing a field before storage does not mean the collection server never received it.

The server-side GTM guide covers the implementation sequence. Its controls complement a reviewed collection policy; they do not replace that policy or justify rebuilding identities a visitor has refused for the relevant purpose.

Likewise, hashed identifiers used in enhanced conversions serve an advertising-matching purpose. They are not equivalent to an anonymous daily audience count just because the raw email is not transmitted in plain text.

Review more than the cookie jar

An empty analytics-cookie list is useful evidence about storage. It says little by itself about what an event contains, who receives it or how long it is retained.

Inspect URLs, referrers, query parameters, custom properties, user IDs and automatically captured text. A page URL containing an email address or sensitive search can undermine the intended design even when no persistent analytics cookie exists. Remove unnecessary information before sending it to the collector.

Check the actual processing purpose and retention. The UK ICO's statistical exception, for example, has conditions concerning service improvement, aggregation, objection and third-party use; “cookieless” is not itself the exception. ICO exception guidance.

Use the country-by-country consent guide to prepare the implementation assessment. Obtain review for your actual configuration rather than applying a vendor's broad legal claim to every custom property, integration or market.

Do not repair a deliberate identity limit with covert fingerprinting. If the business needs known-customer measurement, state that purpose and govern it explicitly. If it needs aggregate website statistics, keep the collection aligned with that narrower job.

Validate a migration against questions, not visual similarity

Choose a representative set of routes before switching: landing page, internal navigation, form submission, payment completion and a return visit on another day. Add any cross-domain or single-page-app transitions that matter to your business.

For each route, record expected events, expected storage, identity continuity and permitted recipients. Test fresh state, existing state, refusal and acceptance where the design includes those choices. Verify whether the event reaches the correct project and whether unwanted fields are present.

Compare operational outcomes, not just analytics totals. Ten accepted demo requests provide a concrete set of records to investigate. A similar-looking line chart can hide a missing embed event and a duplicate pageview cancelling each other out.

Where a temporary parallel collection period is approved, use it to explain differences rather than forcing equality. Keep collection appropriate and time-bounded. Record whether the difference comes from identifiers, filters, bot handling, event definitions, consent or actual delivery failure.

Define acceptance in terms of the decisions that remain supported. For example: the team can compare daily guide engagement and observed booking completions, while returning-person counts across weeks are explicitly out of scope for the anonymous mode. That is a usable result with a clear limitation.

Build a reporting system that admits what it cannot see

A practical small-team setup can combine aggregate website measurement with separately governed product and operational reporting. The public website answers which pages attract useful activity. The application and billing records answer whether known accounts activate, renew or cancel. Advertising experiments address the value of spend.

Keep the boundaries visible. Do not imply that those separate datasets reconstruct every anonymous pre-signup touchpoint. Join only where there is a valid identifier and an approved purpose, and state what remains unknown.

An analytics and tracking review should leave you with that measurement contract and a verified configuration. The useful outcome is a smaller set of trustworthy answers, with enough detail to make decisions and no claim that missing identity has somehow disappeared as a limitation.