Consent for Push Notifications: The Permission Prompt That Is Not a Cookie Banner

A visitor lands on your site, and a browser prompt asks if they want to receive notifications. They click Block, because they have not yet decided whether they trust you, and they have not yet seen anything worth being notified about. On iOS, that decision is effectively permanent. On Android 13 and above, it is a runtime permission, which means the same prompt, and the same risk. The permission is gone, and with it, the channel.

Push notification consent is not cookie consent. It is a browser permission, governed by a different set of rules, and it is a separate consent from marketing consent under the GDPR and the ePrivacy Directive. The UK GDPR and PECR both apply, and the marketing consent must be kept separate from the notification permission. A cookie banner that covers push notifications is not a consent mechanism for push notifications, and a push prompt that appears before the visitor has seen any value is not a consent mechanism either.

The one-shot problem

On iOS, the push permission prompt is effectively one-shot. If the user denies it, the only way to re-enable notifications is to go into Settings, find the site, and toggle notifications on manually. Almost nobody does that. On Android 13 and above, the permission is a runtime permission, which means the app must request it at runtime, and the user can deny it, and the system will remember the denial. The permission is not a cookie that can be re-asked. It is a system-level decision, and it sticks.

The fix is a soft ask: a custom in-page prompt, in your own design, that explains what the notifications are for and asks the user if they want them, before the system prompt appears. The soft ask is not a browser permission. It is a question, and if the user says no, you have not burned the system prompt. You can ask again later, after they have seen more of the site, or after they have completed a purchase, or after they have read a post. The system prompt is the last step, not the first.

What to ask, and when

Ask after value, not before it. A visitor who has just landed on the homepage has no reason to say yes to notifications, because they have not yet seen what the site does. A visitor who has just completed a purchase, or read a post, or added an item to a cart, has a reason: they want to know when the order ships, or when the next post is published, or when the price drops. The prompt should say what the notifications are for, in one line, and it should be specific: order updates, new posts, price drops, not notifications.

Keep the marketing consent separate. The push permission is a browser permission, and the marketing consent is a GDPR consent, and they are not the same thing. A user who grants the push permission has not consented to marketing emails, and a user who consents to marketing emails has not granted the push permission. The two consents must be collected separately, and the records must be kept separately.

Use the right transport. Push notifications on the web use the Push API and the Notifications API, with a VAPID key for authentication, and they are delivered via APNs on iOS, FCM on Android, and the browser's own push service on desktop. The VAPID key is a public-private key pair, and it must be generated and stored securely. If the key is lost, the push subscription is lost, and the channel is gone.

The permission prompt is not a cookie banner. Treat it like a system permission, because that is what it is, and ask for it after value, with a soft ask, or do not ask for it at all.

Keep reading: Consent for Chat Widgets: The Conversation Starts After Permission, Consent for A/B Testing Tools: The Experiment Starts After the Opt-In, How Much Does Your Consent Banner Weigh? Script Cost in Milliseconds.

Frequently asked questions

Is push notification consent the same as cookie consent?

No. Push is a browser permission, governed by the Push API and the Notifications API, and it is a separate consent from marketing consent under the GDPR and the ePrivacy Directive. A cookie banner does not cover it.

What happens if a user blocks push notifications on iOS?

On iOS, the permission is effectively one-shot. If the user denies it, the only way to re-enable is to go into Settings manually. Almost nobody does that, so the channel is lost.

What is a soft ask for push notifications?

A custom in-page prompt in your own design that explains what the notifications are for and asks if the user wants them, before the system prompt appears. If the user says no, you have not burned the system prompt and can ask again later.

When should I ask for push notification permission?

After value, not before it. Ask after a purchase, after reading a post, or after adding to cart, when the user has a reason to say yes, and say what the notifications are for in one line.