What share of visitors typically opts into push notifications in a PWA?

It varies heavily by vertical, geo and how the prompt is framed — a well-built pre-permission screen that explains the value can multiply opt-in rate compared to a raw native prompt with no lead-in.

Can I re-ask for permission if a user declined?

No, the browser blocks a repeat native prompt on that domain — the only way to reach that user again is to bring them to a different domain later.

Do I need a separate app to collect a push subscriber base?

No, the mechanic runs through the browser at the PWA level with no store install required — that's the whole advantage of web-push over classic mobile push.

How often should the subscriber base be cleaned?

Periodically — inactive and dead subscriptions should be excluded from active segments so deliverability and CTR metrics reflect reality instead of being diluted by dead weight.

Can one base serve multiple offers at once?

Yes, but only with geo and vertical segmentation built in from the start — otherwise sends become irrelevant to part of the base, which quickly drives up unsubscribes and spam complaints.

How to Build a Push Subscriber Base in Your PWA

A push subscriber base is traffic you stop paying the ad platform for — capture the subscriber once, then re-engage them for free. But opt-in rate depends heavily on how and when you ask for notification permission. Here's how the subscription mechanic works, what actually raises the opt-in rate, and how to segment the base by offer.

How web-push subscriptions work in a PWA

The browser shows a native permission prompt, and once the user accepts, they land in the subscriber base — no app-store install required, which is exactly what makes PWA a convenient channel. The subscription is tied to a browser-plus-device pair, not an account, so the same person can end up in the base more than once across different devices — that's normal and worth factoring into how you read base size. Declining (or blocking notifications in browser settings) can't be reversed programmatically — you can't re-prompt the same user the same way unless you move them to a different domain.

When and how to ask for permission

A native prompt fired the instant someone lands on the page usually gets a low opt-in rate — the user hasn't seen any value yet and reflexively hits "Block." A better pattern is showing a custom pre-permission screen first ("be the first to know about bonuses") and only triggering the browser's native prompt after the user clicks "Allow" on that screen. This lifts opt-in because the decision becomes a deliberate one instead of a reaction to a surprise pop-up.

What actually moves the opt-in rate

Specificity in the pre-permission screen helps — not "enable notifications" but "be first to hear about bonuses and promos," tied to the offer's vertical. Timing matters too: it's better to ask after the user has spent at least a little time on the page or completed a target action (opened a wheel-of-fortune prelander, say) rather than in the first second of the visit. In APEX these flows are configured at the PWA level with no extra development — the display timer, custom screen and prompt copy are all set up in the builder.

Segmenting the base by geo and vertical

An unsegmented subscriber base turns into noise fast — a send that doesn't match the offer or language kills CTR and drives up unsubscribes. APEX's push engine segments the base automatically by geo, source and offer vertical right at the collection stage, so sends can target precisely instead of blasting the whole list. It's also worth segmenting by activity — "new," "clicked but never deposited," "deposited once" behave differently and need different messaging.

Common mistakes when building a subscriber base

The most common mistake is asking for push permission the instant someone lands, before they've seen anything of value — that burns through a big chunk of the potential base on one badly timed pop-up. The second is never pruning dead subscriptions (browser uninstalled, device no longer used), which makes deliverability and CTR metrics look worse than the real picture. The third is reusing the same pre-permission copy across every vertical instead of adapting it to the specific offer.

What to do with the base once it's built

A collected base isn't a one-off blast — it's an asset that keeps working for weeks, since some users who didn't deposit on the first visit convert later through regular pushes. From there the base feeds into triggered sequences (a welcome series, reactivation) and scheduled sends tied to specific events — in APEX both scenarios run through the same push engine, with no need to export the base to a third-party service.

FAQ

What share of visitors typically opts into push notifications in a PWA?: It varies heavily by vertical, geo and how the prompt is framed — a well-built pre-permission screen that explains the value can multiply opt-in rate compared to a raw native prompt with no lead-in.
Can I re-ask for permission if a user declined?: No, the browser blocks a repeat native prompt on that domain — the only way to reach that user again is to bring them to a different domain later.
Do I need a separate app to collect a push subscriber base?: No, the mechanic runs through the browser at the PWA level with no store install required — that's the whole advantage of web-push over classic mobile push.
How often should the subscriber base be cleaned?: Periodically — inactive and dead subscriptions should be excluded from active segments so deliverability and CTR metrics reflect reality instead of being diluted by dead weight.
Can one base serve multiple offers at once?: Yes, but only with geo and vertical segmentation built in from the start — otherwise sends become irrelevant to part of the base, which quickly drives up unsubscribes and spam complaints.

Build your PWA in APEX in minutes

Cloaking, anti-bot, push, split tests and your own domains — in one service.

Get started free