When should a Chrome extension show its paywall? The evidence

TL;DR: The two best-replicated findings in monetization research pull in opposite directions, and the right paywall timing for a Chrome extension is the synthesis of both:

• Defer identity. Forced account creation before value measurably kills conversion (Baymard: ~26% of US shoppers have abandoned a purchase over it). Never force sign-in standalone; chain it to actions that need it.
• Don’t defer monetization visibility. Subscription-app data (RevenueCat, 115k+ apps) shows roughly half of all download-to-paid conversions happen on day 0, and trial starts collapse after day 3. A paywall hidden for weeks is revenue you never see.
• Stay inside Chrome Web Store policy. The functionality in your listing must work on a fresh install, which is exactly what a review account is. Walls should be dismissible; core value stays usable pre-wall.

The default that satisfies all three: identity friction late, monetization visibility early: a dismissible paywall at the first premium-feature moment or after ~10 actions / 3 days, with sign-in only ever chained into checkout. That’s the value-first preset in ExtensionStart, and this guide is the reasoning behind its numbers.

The question nobody publishes data on

Every developer shipping a paid extension makes a timing decision, usually implicitly: wall at install? After a trial period? Only when a premium button is clicked? There is, as far as we could find, no published quantitative study specific to browser extensions, so the honest approach is to reason from the two adjacent bodies of evidence that do exist (e-commerce checkout research and mobile subscription-app benchmarks), keep the thresholds configurable, and say clearly where the extrapolation is.

Evidence 1: forced sign-up kills conversion, so defer identity

The strongest replicated result in the set comes from e-commerce checkout research. Across Baymard Institute’s long-running cart-abandonment surveys, “the site wanted me to create an account” is consistently a top reason US shoppers abandon a purchase: around 26% of shoppers report having abandoned an order specifically because of forced account creation.

The canonical case study is Jared Spool’s “$300 Million Button”: a retailer whose pre-checkout login wall drove massive abandonment: about 40% of users hitting it requested password resets, and 75% of those never completed their purchase. Replacing the “Register” requirement with a guest “Continue” produced a measured ~$6M sales lift in the first week. (Popular retellings claim a “45% conversion lift”; that figure doesn’t survive verification, so we don’t cite it; the verified framing above is dramatic enough.)

The extension translation: an extension that demands an account before doing anything useful is running the exact experiment those studies measured, on an audience with even less patience; uninstalling an extension takes two clicks. Sign-in should appear only when an action genuinely requires an account: paying, or syncing across devices.

Evidence 2: paying happens early or not at all, so don’t hide the paywall

The opposite pull comes from subscription-app benchmarks. RevenueCat’s State of Subscription Apps (data across 115,000+ apps) found that download-to-paid conversions concentrate overwhelmingly at the start: roughly half of all conversions happen on day 0, and daily trial starts fall below 5% after day 3. If your paywall first appears in week two, most of the users who would ever have paid you have already come and gone.

The same dataset’s 2026 benchmarks compare paywall aggressiveness directly: hard-paywall apps convert about 5× better than freemium (10.7% vs 2.1% median at day 35) and generate roughly 8× the revenue per install at day 60 ($3.09 vs $0.38), while 12-month retention is statistically identical (27% vs 28%). Aggressive monetization, in this data, does not measurably burn the user base.

Two honest caveats. First, these are observational benchmarks over self-selected apps (apps confident enough to hard-paywall may simply be better products), so they are not the expected effect of switching strategies. Second, this is mobile-app data, not extension data. What the day-0 concentration does establish, robustly, is a timing claim: whatever your paywall is, it must be visible early. Visible, not blocking.

The synthesis: identity friction late, monetization visibility early

Both bodies of evidence fit one design without tension:

1. Install → full value immediately. No wall, no account. (An anonymous auth session in the background gives you a stable user ID for server-side counters without asking the user for anything.)
2. Paywall surfaces in the first sessions, at the moment a premium feature is tapped or after enough real usage to prove value, and is dismissible, with a real cooldown after dismissal.
3. Sign-in appears only inside flows that need it: chained into checkout, never standalone. Account linking preserves the anonymous user’s data, so signing in late costs the user nothing.

How ExtensionStart’s value-first preset implements this

In the kit, wall timing is configuration, not architecture. This is the actual default from apps/extension/entrypoints/background/gates.ts:

gates: valueFirst({
  premiumFeatures: PREMIUM_FEATURES, // gateFeature with these ids → paywall immediately
  paywallAfterActions: 10, // …or on the 10th recorded gateAction
  paywallAfterDays: 3, // …or 3 days after install
  cooldownMinutes: 60 * 24, // a dismissal silences the paywall for 24h
  // escalateAfterDismissals: 0 — default: walls never turn non-dismissible
}),

Each number maps to the evidence:

• Premium-feature moments fire immediately: the day-0 data says the moment of intent is when conversion happens, so tapping a premium feature is the paywall’s best possible entrance.
• 10 actions / 3 days is the usage-based backstop for users who never tap a premium feature. The 3-day figure mirrors where trial starts collapse in the RevenueCat data; the 10-action count is a value-first judgment call, not a measured optimum, which is exactly why it’s a config field (and remote-configurable), not a constant.
• 24-hour cooldown after a dismissal keeps the wall an offer rather than a nag; escalation to non-dismissible exists but is off by default.
• Sign-in is defined as manual(); it can never fire on its own, only chained when the paywall’s checkout needs an account.

Because client-side counters can be wiped or forged, every gate event is also mirrored to the backend, keyed by user ID: anything with stakes (trial-once, credits, abuse caps) is enforced server-side. The wall is UX; the server is authority.

Three other presets cover the cases where the evidence points elsewhere: day-zero (dismissible paywall in the first session, for products betting fully on the day-0 concentration), metered (credit-based, for AI/usage products), and silent (nothing fires automatically; maximum review safety).

The Chrome Web Store policy guardrails

Conversion timing has a hard boundary: store review. Chrome Web Store’s quality guidelines require an extension to have a single, clearly disclosed purpose, and reviewers evaluate whether the listing matches what a user actually gets (policy FAQ). A review account is a fresh install; if the functionality your listing advertises sits behind a wall the reviewer can’t pass, that reads as bait-and-switch and is a rejection/suspension class of problem.

The guardrails ExtensionStart bakes into every preset:

• Core listed functionality works pre-wall. Gate premium extras; never put the action from your listing’s first sentence behind a paywall trigger. If your entire product is paid, disclose it in the listing (“subscription required”): that’s allowed; hiding it is not.
• Walls are dismissible by default. Escalation to blocking is opt-in and belongs only on non-core features.
• No hard wall at install. No preset combines an install-time trigger with a non-dismissible wall, and you shouldn’t hand-write one.
• Sign-in is never forced standalone; the policy-friction risk and the abandonment evidence point the same way.
• Thresholds change without review. Remote configuration (gate thresholds, kill switches) is store-compliant; remote code never is. The kit serves gate config from the backend so you can tune timing post-release without a store round-trip.

Where the evidence is thin, and what to do about it

To be explicit about the limits: there are no published browser-extension-specific conversion studies, no rigorous comparisons of action-count vs time-based triggers, and the strongest numbers come from adjacent industries under observational conditions. The defaults above are a reasoned extrapolation, not a measured optimum. The practical consequence is baked into the design: every threshold is configuration, gate events are logged server-side per user, and thresholds are remote-tunable, so your own extension’s data, not this guide, gets the final word.

---

The gate engine, its presets, and the tests that pin this behavior ship in ExtensionStart; you can see the walls in action in the demo.