The registration wall is not a cheap paywall
In short
A registration wall asks for an identity instead of a payment, and the thing it produces is a reader record that survives cookie loss, a new device and a browser's storage rules. Its success metric is the share of reading you can attribute to a known reader — not revenue. Run it as a discount paywall and you get a gate that costs traffic and returns identities nothing downstream can use.
Key takeaways
- A regwall buys identity, a paywall buys revenue. Measure the regwall on known-reader coverage of reading, not on subscriptions started.
- An identity that cannot be matched to a subscriber record later is not identity, it is an email address in a silo.
- Registering does not have to mean signing in every time — the durable object is the reader record, and the session is a separate problem.
- Registration counts as gated content for search engines, so the same structured-data declaration a paywall needs applies here too.
A registration wall trades access for an identity: an email address, a verified account, sometimes a sign-in with an existing provider. It exists because an anonymous reader is a device with a cookie, and Safari, Chrome and Firefox each apply their own storage-lifetime and partitioning rules, which change without asking you. A reader record with a sign-in survives all of that, on any device.
The failure here is not building one. It is building one with a paywall's goals. A regwall judged on subscriptions started always looks like an underperforming paywall, so it gets tuned like one — more aggressive, earlier in the session, on the stories the paid wall should cover — and ends up costing reach while producing records nothing downstream can join.
What the gate actually buys: a reader who is still there next month
The asset is a durable, resolvable identity, and its value is that everything else attaches to it: consent, preferences, reading history, newsletters, and later a payment. The metric is coverage — the share of article reads happening against a known reader id rather than an anonymous device. Set it as a target with a horizon, such as 12% to 30% over 2 quarters, and it behaves like a number you can manage.
- Coverage of reading beats registered-user count. 200,000 accounts that read once are worth less than 40,000 that account for a third of your article views.
- The record makes a later merge possible. A reader who registers in July and subscribes in November must end up as 1 person — the merge problem in one reader, three accounts across print, app and newsletter.
- Identity is not a session. A reader can be known without being signed in on this device right now, and conflating the 2 produces gates that ask a loyal reader to log in weekly.
- Verification is a policy choice with a cost. Requiring a confirmed address removes throwaway entries and some genuine readers with them, so decide which error you prefer before shipping.
The minimum record a registration has to create
| Field | What it must hold | What breaks without it |
|---|---|---|
| Reader id | A stable internal identifier, never the email address itself | Nothing survives an address change, and every join downstream is on a mutable key |
| Verification state | Whether the address was confirmed, and when | Deliverability decays quietly and nobody can tell a real reader from a typo |
| Consent and purpose | Which permissions were given, in which wording, at which timestamp | The marketing team cannot prove a lawful basis, and a later audit has to assume the worst |
| Acquisition context | The story, section and gate variant that produced the registration | You cannot tell which gate placement recruits readers who come back |
| Source system | Whether the record came from the site, the app, an event or a newsletter import | Duplicates accumulate and nobody knows which record is authoritative |
None of those fields is expensive at the moment of registration, and all of them are expensive to reconstruct later. Acquisition context is the one most often skipped and most often wanted — usually the first time somebody asks whether the gate on the archive recruits better readers than the gate on breaking news.
What goes wrong when it is run as a discount paywall
Run the regwall on paywall instincts and 3 things follow. It lands on the stories with the highest conversion potential, which are the ones the paid wall should cover — a placement argument belonging with who decides which stories stay outside the wall. It gets tuned for submissions rather than durable accounts, so throwaway addresses count as wins. And it is measured over a 6-week campaign, when coverage only moves over quarters.
The wall-model decision underneath comes first: whether your catalogue supports a hard wall or needs a meter is settled by what the archive contains — hard wall or meter for a news archive. A regwall is a layer in front of either, not an alternative to choosing.
Three engineering consequences people discover after launch
- Registration status is a cache dimension. A page rendering differently for known and anonymous readers has the same cacheability problem as a paid gate, and fails the same way — subscribers hitting the wall on popular stories is that diagnostic, caused by a cache key that never included reader state.
- Search engines treat registration as a gate. Google's paywalled-content documentation covers content requiring a subscription or a registration, via an `isAccessibleForFree` flag and a `hasPart` block of type `WebPageElement` marking the gated section; confirm the current property list in Google's own reference, because this markup is what separates a deliberate gate from cloaking.
- Old pages return to circulation. A regwall works best on evergreen and archive stories, which puts pages nobody has opened in 6 years back in front of readers — and those pages carry rights obligations that must still fire, as in image licence expiry that actually fires.
The third one surprises people. A gate is a reason to promote old work, and old work is where expired image licences, superseded corrections and dead embeds live. Auditing the archive belongs in the regwall project even though it appears in no requirements document — plumbing that fits our internal tools and ops work rather than the front-end build.
What happens the day a registered reader pays
Nothing about their identity should change. The reader record stays, a grant appears against it, and the access check starts returning a different answer. If subscribing creates a second account, the regwall was built as a separate product rather than the front of 1 identity system. When a payment later fails, the same principle holds in reverse: the identity persists while the grant moves through the states in dunning as a state machine.
A paywall asks a reader to decide whether you are worth paying for. A registration wall asks whether you are worth being known by. The second question has a much higher yes rate, and a much longer payback.
Judge it on coverage, build the record properly on day 1, and keep it in front of the access check rather than inside it. The rest of this silo sits under paywalls, subscriptions and entitlements, inside our media and publishing practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a registration wall on a news site?
A registration wall is a gate that asks for an identity rather than a payment before continuing to read — typically an email address or a single sign-in. Its purpose is to turn an anonymous device into a reader record that survives cookie loss and works across devices, so consent, reading history, newsletters and any later subscription attach to the same person.
How is a regwall different from a paywall?
The regwall takes identity, the paywall takes money, and they are measured on different things. A regwall's target is the share of reading attributable to a known reader; a paywall's target is subscription revenue and retention. They also sit in different places: registration is an input to the access check, while a paid grant is what the access check returns.
Does a registration wall hurt search visibility?
Not inherently, but it has to be declared. Serving a different render to crawlers than to readers is the shape of cloaking, which is why structured-data properties exist for content that requires a subscription or registration. Implement the markup Google documents for paywalled content, and check its current form in Google's own reference rather than copying an old example.
Should a registered reader get extra free articles?
Usually yes, and that allowance is a meter setting rather than a property of the registration. Keep the 3 tiers separate — anonymous, registered, subscribed — so counting stays in the meter and identity stays in the reader record. Changing the registered allowance is then a policy edit rather than a code change in 3 systems.
- registration wall
- identity
- publishing
- audience data
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- The meter count: where it lives, what it counts and who can reset itA meter is not a number. It is 4 decisions — countable event, storage location, reset window and exemptions — and most implementations make only the first one consciously.definition
- Dunning as a state machine: retries, grace and when access stopsDunning is not a sequence of emails. It is a state machine, and every state must be written into the entitlement record so access, messaging and reporting cannot drift.definition
- Paying subscribers are hitting the wall, and only on the popular storiesThe symptom tracks popularity because the hit ratio is the exposure: the more cacheable a story is, the more likely a subscriber gets served the anonymous copy of it.diagnostic
- Renewals that never reached the access systemCount the gap between what the provider sent and what you processed. Its size and shape separate delivery loss from processing loss, and only one of them is fixed by a better handler.diagnostic
- The app says subscribed, the site says notCross-surface disagreement is three causes wearing one complaint: two identities, two authorities, or two caches. Resolving the identifier on each surface eliminates the first in minutes.diagnostic
- The meter resets for anyone who opens a private windowA meter stored in the browser can be cleared by the browser. Measure the leak first, then decide whether identity-bound counting is worth what it costs.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation