Measuring Returning Visitors Without Cookies

The second visit is the number that matters

Reach can be bought, return cannot. It is the only signal that says directly whether content, a product range or a service was good enough to come back to. In the European Union, 78 percent of internet users aged 16 to 74 ordered goods or services online in 2025 (Eurostat). The rhythm matters: of those buyers, 62 percent bought within the three months before the survey, 11 percent between three and twelve months earlier, and for 6 percent the last purchase lay more than a year back (Eurostat). A third, precisely 34 percent, order only once or twice per quarter (Eurostat).

A purchase interval of four months fits into no seven-day window and into no thirty-day window either. The commercially most valuable group - people who buy rarely but deliberately - is exactly the one that cookie-based counting reports as a stream of first-time visitors, so the report shows new customer growth where regular customers were counted afresh.

• Does the content hold up? High reach with low return created attention but no attachment.
• Does the campaign work beyond the click? Only the second session separates bought attention from earned interest.
• How long is the decision path? The gap between first and repeat visit estimates the purchase cycle.
• Where does return collapse? A drop after a deploy is a product finding no availability check will surface.
• Which source delivers people who stay? Channel evaluation changes once returning cohorts rather than sessions are weighted.

Market research gathers these numbers differently: the German retail association bevh determines purchase frequency through a continuous survey of 40,000 private individuals aged 14 and over each year (bevh retail association). The most dependable figure on buying behaviour does not come from browser storage. How to build a workable analysis concept from this is described in the article on privacy-compliant website analytics.

What the browser does with the cookie

Shortened cookie lifetimes are not an announcement but shipped code. With Intelligent Tracking Prevention 2.1, WebKit capped all persistent client-side cookies - everything set through document.cookie - at seven days (WebKit). A few weeks later the stricter rule followed: if a visitor arrives through a cross-site navigation with a query parameter or fragment and the referrer is a domain classified as a tracker, the maximum lifetime drops to one day (WebKit). That hits the case where the most money is at stake: the paid campaign click.

The obvious workaround was closed in 2020. Since then WebKit treats every storage form a script can write to under the same rule: without user interaction, IndexedDB, LocalStorage, Media Keys, SessionStorage as well as service worker registrations and their cache are deleted after seven days of browser use (WebKit). An identifier in localStorage is not a substitute but the same mechanism under a different name. The cookie scan lists such fallback storage together with the scripts that set it.

Even the seemingly generous browser sets a ceiling. Since M104 in August 2022, Chrome no longer accepts an expiry more than 400 days in the future (Chrome for Developers). The figure was chosen deliberately: it is a bit over 13 months (Chrome for Developers) - the horizon European supervisory authorities name for consent-free audience measurement. In Firefox, access obtained through the Storage Access API expires after 30 days (MDN Web Docs). Three vendors, three limits, none longer than the purchase cycle of an average online buyer.

How large the gap actually is

The limits only bite as far as the affected browsers appear in your own audience. For Germany that can be quantified: in September 2026, 16.86 percent of page views came from Safari, and 20.97 percent on mobile devices (Statcounter Global Stats). Roughly one view in six overall and one in five from a phone is therefore subject to the seven-day rule - not a fringe group. Add the campaign case and those views get one day rather than one week.

On top of that comes the share that does not reach measurement at all. Content blockers are no niche tool: the most widely used blocking extension for a single browser reports 10,657,965 users on its vendor's extension page (Mozilla Add-ons). That counts worldwide installations, not a German blocking rate - an order of magnitude, not a quota. How to quantify and partly close the resulting loss is covered in the article on tracking loss caused by content blockers.

How strongly measurement depends on third-party code is shown by the Web Almanac 2025 across 16,213,084 websites (Web Almanac 2025): 75 percent of all pages carry at least one third-party tracker (Web Almanac 2025), and 90 percent embed at least one third party of any kind (Web Almanac 2025). Analytics is the most common category, on 64 percent of websites (Web Almanac 2025). A single corporation is present as a tracker on 61 percent of pages, the first-party cookie of one single analytics service on 46 percent, and a single advertising domain on 20 percent of desktop pages (Web Almanac 2025).

Section 25 TDDDG: what works without consent

The technical question cannot be answered without the legal one; both concern the same operation. In Germany, Section 25 paragraph 1 sentence 1 TDDDG governs it: both storing information in terminal equipment and accessing information already stored there require consent (TDDDG). It does not depend on whether personal data is involved - it attaches to the operation itself. A cookie with an anonymous random identifier is therefore covered, although it identifies nobody. A counting pixel, conversely, is no counter-example: the European Data Protection Board treats the mere delivery of such a pixel as storage in the terminal equipment, because the browser cache takes it in, and the return of the appended identifier as access (European Data Protection Board). What stays outside the provision is typically only what the server logs anyway, without a return channel into the terminal equipment.

The storage of information in the end user's terminal equipment or access to information already stored in the terminal equipment shall only be permitted if the end user has consented on the basis of clear and comprehensive information.

— Section 25 paragraph 1 sentence 1 TDDDG, translated from the German original

The exemption sits in Section 25 paragraph 2 number 2 TDDDG: it applies where the storage or access is strictly necessary to supply a digital service expressly requested by the user (TDDDG). Its direction matters: it justifies no additional access, only the access without which the requested service does not work. Audience counting is rarely part of what the user asked for.

German supervisory authorities take the same view. Their guidance for telemedia providers states that even simple visitor counting cannot be categorised wholesale as part of the basic service but depends on the specific purpose pursued (Datenschutzkonferenz). Relying on the exemption therefore needs a documented justification per purpose, not a general claim that statistics are necessary. What belongs in that documentation is shown in the article on the data protection impact assessment for web tracking.

The European Data Protection Board clears up a common misconception: access to IP addresses triggers Article 5(3) of the ePrivacy Directive where that information originates from the terminal equipment of the subscriber or user (European Data Protection Board). Cookieless therefore does not automatically mean consent-free. The distinction - information requested from the device, or part of the connection anyway - belongs in the record of processing activities, not in a marketing claim.

Recognition without storage access

The approach that works without read or write access inverts the logic: instead of placing an identifier on the device, it is recomputed server-side on every request - from attributes the request carries anyway and a secret the operator rotates daily. The result holds within a day and deliberately decays across days.

The trick lies on the second level: what is carried forward is not the identifier but membership of a cohort. Whoever appears for the first time on a given day joins that week's cohort; in the following weeks the question is not whether a particular person comes back but how many of a cohort reappear. The calculation stays at group level and needs no lasting link to an individual.

# Identifier without read or write access on the device.
# The salt rotates daily and is not logged anywhere; after the switch
# the previous day's value cannot be reconstructed.
import hashlib
import datetime

def daily_identifier(salt: bytes, site_id: str, network: str, client: str) -> str:
    day = datetime.date.today().isoformat()
    raw = "|".join([day, site_id, network, client]).encode("utf-8")
    return hashlib.blake2s(raw, key=salt, digest_size=16).hexdigest()

def assign_cohort(identifier: str, first_seen: dict) -> str:
    # first_seen keeps only the week key of the first appearance
    # per identifier - no history, no single events, no profile.
    today = datetime.date.today()
    week = "%d-W%02d" % today.isocalendar()[:2]
    return first_seen.setdefault(identifier, week)

Three properties distinguish this method from the cookie, all three deliberately accepted drawbacks. The identifier is not stable: a change of device, browser or network breaks it. It is not reversible; nobody can be identified from the value. And it ends when the secret rotates. For measuring individuals that is unusable; for return at cohort level it is sufficient.

1. Rotate the salt daily and discard it. Keeping the old value retroactively recreates the linkability you set out to avoid.
2. Do not store single events permanently. Aggregated cohort counters instead of raw logs limit the damage of any misconfiguration.
3. Do not pass the identifier to third parties. Once it leaves your own system, the necessity argument no longer holds.
4. Document the purpose per metric. Supervisory authorities require justification against the specific purpose, not against the tool (Datenschutzkonferenz).
5. Monitor the measurement path itself. If the endpoint fails, the return rate appears to fall - a case for cross-origin headers and embedding rules governing access to the collection route.

Cohorts instead of people: reading the matrix

The representation this method produces is the cohort matrix: each row an entry week, each column a distance from the first visit, each cell the share of the cohort that reappeared in that week. It is read in two directions: along the row for one cohort's trajectory, down the column to compare cohorts at the same distance.

The matrix separates two effects that merge inside a single return rate. When reach grows, the average return rate falls almost inevitably because a large fresh cohort dilutes the statistic. In the matrix the older rows keep their trajectory and the effect is visible for what it is: a shift in composition. How to sharpen the picture with paths inside the session is shown in the article on analysing user paths.

What distorts the number and how to quantify it

Cookieless return measurement is not more accurate than the cookie-based kind, it is inaccurate differently. With cookies the error comes from deletion, expiry and blocking: it understates return, systematically more so on mobile. With a computed identifier it comes from collisions and breaks: two devices behind the same network address with the same client profile can yield the same value, and a network switch mid-session yields two values for one device. Both errors can be bounded, neither disappears.

A third share hits both methods equally: automated traffic. A crawler stopping by weekly looks like an extraordinarily loyal visitor in any cohort matrix. Every interpretation therefore needs a documented, versioned bot exclusion - otherwise the return rate shifts with every filter change while the audience has not. The procedure for that is described in the article on bot filtering in analytics.

The value of this comparison lies in knowing the distance between both methods and watching it over time. If it grows, either the browser mix has shifted or a blocking rule newly took effect. If it stays stable, an older cookie-based series can be joined to the new one with a documented conversion factor instead of cut off. For campaign evaluation, clean parameter hygiene is a further prerequisite, as the article on UTM parameters and channel attribution shows.

Retention, comparability and the limits of the cohort

The length of the observation window is not freely chosen, for two independent reasons. Legally, the French supervisory authority recommends a lifetime of thirteen months for the attributes used in consent-free audience measurement and advises against extending it automatically on each new visit (CNIL). For the collected data itself the same recommendation sets a maximum storage period of 25 months (CNIL). A cohort view spanning more than two years is not a technical problem but a legal one.

Technically the limit is often tighter. In one widely used analytics tool, certain signal data is kept for at most 26 months regardless of the configured retention (vendor documentation); for large and very large properties retention is limited to two months (vendor documentation). Six following weeks is the most that tool yields there. Longer comparisons need your own aggregated store with documented limits, as described in the article on retention periods for monitoring and analytics data.

• Fix the window before the evaluation. Six following weeks suits most product ranges; changing it afterwards breaks the time series.
• Keep aggregates, not raw data. Cohort counters survive any deletion deadline, individual events do not.
• Do not silently extend attribute lifetimes. The supervisory authority expressly advises against automatic renewal on each visit (CNIL).
• Date every rule change. A bot filter, a salt rotation and a new endpoint belong marked in the time series.
• Replace outdated measurement components. An unmaintained library changes its behaviour unnoticed at some point - see end of life in the web stack.

Honesty also means naming what cohort measurement does not deliver. It answers no question about an individual, is no basis for individual outreach and merges nothing across devices. Treating a customer on the phone and at the desk as the same person needs a login - and a different legal basis. The advantage of the method is not that it could do more, but that it wants to do less.

Making return measurable without forcing consent

The consent route is no comfortable alternative but its own field of errors. Only 1.7 percent of sites implement the widespread industry standard for consent signals fully in line with its rules (Web Almanac 2025). Signals users send themselves are read mainly by the largest sites: detection reaches 44 percent among the 5,000 most visited sites and falls to 17 percent among the 50 million most visited (Web Almanac 2025). A dialogue alone therefore solves nothing.

The workable path starts not with the dialogue but with the question of which statement is needed. For most operators the answer is: the trajectory of a cohort over six weeks, cleanly separated from bots, with a known distance to the old series and without access to the device. Whether the cookieless audience measurement in use supports this scope depends on how long its identifier lasts. It is expressly no fingerprinting substitute - no shortcoming: the most widespread fingerprinting library appears on just 0.59 percent of mobile-crawled pages anyway (Web Almanac 2025), and it still requires consent.

In practice: quantify the distance to the previous counting once, set up the cohort matrix as a standing report, date every rule change. Anyone testing variants will find the consent-free scope in the article on A/B tests without a consent dialogue; anyone planning the move away from cookie-based counting, in the article on cookieless tracking. The scope for your own audience can be walked through in the demo; the tiers are on the pricing page.