Push Notifications Are Not Cookies: The Permission Prompt That Still Needs a Consent Decision
A site added push notifications and watched the subscriber list grow. The prompt appeared on first visit, the visitor tapped allow, and the marketing messages started the same day. Nobody asked whether the tap meant yes to marketing. It did not. The tap meant yes to receiving notifications from the browser. The marketing consent was a separate question, and nobody had asked it.
Push notifications sit in a gap between two systems. The browser owns the permission: a system prompt that asks whether the site may send notifications. The privacy law owns the consent: a decision about personal data and direct marketing. The two look alike, and teams treat them as one thing. They are not. A visitor can allow notifications and still have said nothing about marketing, and a site that reads the permission as a marketing consent is sending marketing to people who never agreed to it.
What the permission actually is
On iOS the permission is effectively one shot. The system asks once, and if the visitor declines, re-prompting is blocked or requires sending them into system settings, and almost nobody goes. Android 13 and above ask at runtime, and users can mute one notification channel without muting the rest. On the web, the prompt requires HTTPS, a service worker, and a user gesture, and browsers penalise sites that prompt immediately on arrival.
The permission also says nothing about what the notifications contain. The operating system controls the format, not the content or the frequency. A site that gets the permission and then sends three marketing messages a day is using a permission the visitor granted for something else. The Adalo guide to push notifications and GDPR compliance puts the standard plainly: consent has to be freely given, specific, informed, and unambiguous, and a pre-ticked box or a system prompt does not meet it.
The soft ask that saves the permission
The better sequence is a soft ask. Explain in your own interface what you would send and why, and only trigger the system dialogue once the visitor has said yes to that. If they decline your own screen, you have lost nothing and can ask again later. If you trigger the system prompt on first visit and they decline, the permission is gone, and you cannot get it back without a trip to settings that almost nobody makes.
Separate the marketing consent from the notification permission in the same flow. The soft ask should say what kind of messages the visitor will get, and the marketing messages should have their own consent, logged with what was agreed and when. The Make IT Simple guide to push notifications insists on two things in any build: keep marketing consent separate from the notification permission, and log what somebody consented to and when. That log is the record a regulator asks for, and most sites do not have it.
Withdrawal has to be as easy as the tap
A visitor who allowed notifications has to be able to stop them as easily as they started them. The system settings let them block notifications, but that is the operating system's off switch, not the site's. The site should offer its own unsubscribe, in the same place the subscription happened, and it should work immediately. A site that makes unsubscribing hard is keeping a consent that no longer exists, and the messages it sends after that are marketing without a basis.
Refresh the consent periodically. The ICO suggests doing so about every two years, and some technologies need it more often. A permission granted in 2024 for order updates does not cover marketing messages in 2026. When the consent expires, ask again, and treat a non-answer as a no. The subscriber list will shrink. The list that remains will be people who actually want the messages, and those are the only ones worth sending to.
Keep reading: how mobile webviews handle consent blocking, how consent works in progressive web apps, and how to make a banner work with screen readers cover the nearby cases in this series.
Frequently asked questions
Is tapping allow on a push notification prompt the same as consenting to marketing?
No. The tap is a browser permission to receive notifications. Marketing consent is a separate decision about personal data and direct marketing, and it has to be freely given, specific, informed, and unambiguous. A site that reads the permission as a marketing consent is sending marketing to people who never agreed to it.
Why should I use a soft ask before the system prompt?
Because the system prompt is effectively one shot, especially on iOS. If the visitor declines it, re-prompting is blocked or requires a trip into system settings that almost nobody makes. A soft ask in your own interface lets you explain what you would send, and if the visitor declines that screen, you lose nothing and can ask again later.
How often should push notification consent be refreshed?
The ICO suggests about every two years, and some technologies need it more often. A permission granted for order updates does not cover marketing messages two years later. When the consent expires, ask again, and treat a non-answer as a no.
What should the consent record for push notifications contain?
What the visitor agreed to, when they agreed, and which kinds of messages the agreement covers. Marketing consent and notification permission are separate records. The log is what a regulator asks for, and most sites do not have it.