The meter resets for anyone who opens a private window

It is not broken. A meter that resets in a private window is device storage behaving the way device storage behaves, and every implementation keeping its count in a cookie or local storage has this property by construction. The useful question is not how to stop it, but how much of your metered traffic actually starts from zero, and whether the fix costs less than the leak.

The instinct — detect the private window, block it, escalate — loses. The evader's next move costs them 4 seconds; the innocent reader you challenge has a next move that costs you a subscriber. Below: the measurement, the 4 mechanisms that produce a fresh count, and the threshold at which identity-bound counting pays.

What share of your metered sessions start from zero

You cannot measure this exactly, and a team insisting on an exact number will spend a quarter not getting one. Anonymous readers with no prior state are indistinguishable from cleared ones, so the honest output is a floor and a ceiling — which is enough to decide.

1. Log 2 things per metered session: the count at session start, and whether the browser presented first-party state older than the session — a consent choice, a dark-mode preference, a newsletter dismissal.
2. Classify. Zero count with a consent choice recorded 4 months ago is a returning reader whose meter cookie specifically is gone. Zero count with no prior state at all is unclassifiable — new reader, cleared browser or private window.
3. The floor is the first group as a share of all metered sessions; the ceiling adds the unclassifiable ones. The gap between them measures how blind your first-party data is.
4. Split both by browser and by acquisition source. A gap concentrated on 1 browser is usually a partitioning fault; a gap spread evenly is usually behaviour.

The count is somewhere the reader can reach, which was the trade

The largest cause is the design itself. A cookie or a local-storage key costs nothing to run, keeps every article render cacheable at the edge, and works for readers who have never given you an email address. Those are real properties, and the storage decision sets everything else — the full comparison is in where the meter count lives and what it counts.

The cost is that the count is deletable, per device, by anyone who wants it gone. Private browsing is the visible version; the invisible ones are larger — a second device, a work laptop, a browser clearing storage on quit, privacy tooling clearing cookies on a schedule.

The browser partitioned your storage and nobody shipped anything

This leak has nothing to do with evasion, and it is the one most often missed because it looks like reader behaviour. If your meter is a vendor script running in an iframe on a domain that is not yours, its storage is third-party storage — and browsers key third-party state to the top-level site as well as to the resource origin.

Mozilla documents this as state partitioning: localStorage, sessionStorage, IndexedDB, DOM Cache, service workers and shared workers partitioned by top-level site, with cookies dynamically partitioned and unpartitioned access granted only through the Storage Access API. Firefox enabled network partitioning by default from version 85 and dynamic partitioning from version 103. Other engines have equivalents on their own timelines, so confirm each vendor's current documentation rather than assuming parity.

• Symptom. Counts reset for readers doing nothing unusual, correlated with 1 browser rather than spread evenly.
• Test. Read the meter's storage key from the top-level document. If your own origin cannot see it, the count lives in a partition you do not control.
• Fix. Write the count as first-party state from your own domain and let the vendor read it rather than own it. A cookie set by a server response survives more of this than one written by a third-party script.
• Consequence. Moving the write to your origin puts the meter into your cache story — the tension behind subscribers hitting the wall on popular stories.

Nothing asks who the reader is, so there is nothing to count against

A meter that never requires identity can only count devices. That is a coherent position, and it is where most publishers start, but it means the count is a property of a browser profile rather than of a person — and a person has 3 or 4 browser profiles without trying. Storage hardening does not touch this, because the identifier itself is scoped to the device.

So the honest name for the durable fix is not anti-evasion. It is identity acquisition, with its own success metric and its own owner — the registration wall is not a cheap paywall. Once identity exists the meter is 1 input to a decision rather than the decision, and that decision belongs in one access check every surface can call.

Somebody found the exemption list and posted the recipe

Every meter carries exemptions: search referrals, newsletter clicks, campaign parameters, section fronts, breaking-news overrides. Each is defensible alone. Together they are a documented set of ways to read without being counted, and any of them keyed to a signal a reader can forge — a referrer header, a query parameter — will eventually be forged at scale.

The rule in that table: an exemption keyed to a property of the content is safe, and an exemption keyed to a claim the reader makes about themselves is a shared password. If you keep the second kind, do not trust the claim directly — exchange it once at the edge for a signed, short-lived cookie.

Why detecting the private window is a trade you lose

Detection is available. Browsers have historically leaked behavioural differences in private modes, and each technique worked for a while before being closed. That is the problem: the technique has a half-life, the countermeasure does not, and you have signed up to maintain a probe that breaks on a browser release you did not schedule.

Every escalation costs a reader who did nothing and inconveniences an evader for an afternoon. That asymmetry does not improve with better detection. It improves with a reason to sign in.

The second problem is who you catch. A reader who opened a private window has already declined to pay at the current friction. Blocking converts a few, annoys the rest, and hits the wrong group hardest: shared computers, corporate machines with strict privacy policies, students on library terminals. Institutional readers should not be in this conversation at all, because they have a consented grant mechanism — seats, domains and IP ranges for institutional access.

The threshold at which identity-bound counting pays for itself

Server-side metering holds the count against a resolved reader id rather than a device, so it survives private windows, second devices and cleared storage. It also requires a registration step, puts a lookup in the path of every article render, adds a dimension to the cache key, and creates a reader-level behavioural record you now have to govern. 4 costs, none of them a sprint.

The middle rows are where most publishers sit, and the answer there is uncomfortable: the meter is not the project. Identity first, then counting bound to it, then whatever wall model the catalogue justifies — decided on catalogue composition in hard versus metered access for a news archive.

What identity-bound counting still will not stop

It will not stop a second account on a second email address, it will not stop password sharing, and it will not stop a reader consuming the first 3 paragraphs your degraded render serves to search engines. Nor will it tell you whether the reader who stopped at the wall would ever have paid, which is the number the whole argument turns on.

So spend the effort elsewhere. A propensity model ranking readers by likelihood to subscribe beats an evasion detector, because it acts on the population you can convert — ordinary AI agents and automation work. If it will be trained on reader-level behaviour, where it runs is a separate decision, with 4 options in private and on-premises LLM deployment. Whether to own the paywall at all splits by component — build or buy as the estate grows — inside paywalls, subscriptions and entitlements and our media and publishing practice.

• paywall
• metering
• subscriptions
• diagnostics