Web push and GDPR: what you are responsible for

This guide is not legal advice. I am a founder, not a lawyer, and your setup depends on your country, your market and what you send. Talk to whoever handles data protection where you work.

What I can do is describe the moving parts, because a lot of people assume the browser's permission dialog takes care of everything. It doesn't.

What the browser prompt covers

When a visitor clicks allow, they give the browser permission to show notifications from your site. That is a clear, active choice, and it is a good foundation.

It does not tell the visitor who you are in a legal sense, what you will send, what data you keep about them or who else processes it. The browser can't know any of that. Those parts are yours.

A push subscription is personal data

When someone subscribes, the browser creates a subscription: an endpoint address at the browser vendor's push service and keys to encrypt messages for it. That subscription identifies one browser on one device.

It is safest to treat it as personal data, along with anything you attach to it: what pages the subscriber read, which segments they are in, their language or country, when they clicked.

That means the usual GDPR obligations apply to it.

The things you are responsible for

A legal basis. For marketing notifications this is usually consent, which the opt-in gives you when it is informed. Informed is the important word. A prompt that says what people will get is better than one that just says "Allow".

Transparency. Your privacy notice should say that you use browser notifications, what you send, what data you keep about subscribers, how long, and which providers are involved.

Easy withdrawal. People must be able to stop as easily as they started. In practice, blocking notifications in the browser stops delivery. Make sure your notice explains how, and remove subscriptions that come back as expired or gone.

Minimization. Keep what you need to send relevant messages and measure them. Avoid collecting things "just in case".

Processors. Your push provider processes subscriber data on your behalf, so you need a data processing agreement with them and you should know which subprocessors they use.

Retention and deletion. Decide how long you keep data about people who unsubscribed or whose subscription stopped working, and be able to delete a subscriber when asked.

The browser vendor is part of the chain

Web push messages are delivered through the push service run by the browser vendor. The Web Push standard encrypts the message content between your server and the subscriber's browser, so the push service carries a message it can't read. It still sees that a message is being delivered to an endpoint.

That is part of how web push works for every provider, and it is worth knowing when you describe the flow in your privacy notice.

Things to avoid

• Prompts designed to look like system dialogs, or that hide what people are agreeing to.
• Sending categories of content people didn't sign up for. A subscriber to match results didn't agree to shopping offers.
• Building detailed profiles you don't need for sending relevant messages.
• Keeping dead subscriptions forever because the list looks bigger.

What EngageNudge does

EngageNudge is built in Sweden, EU-first, with data minimization as a default. Push subscription endpoints are stored encrypted. Each customer's data is isolated, and customers use their own VAPID keys.

For location we store country and region at subscription, not IP addresses or raw user agents. Subscriptions that come back as expired or gone are cleaned out automatically and are never billed. Audience export and deletion paths are documented, and the DPA and subprocessor list are public on this site.

None of that replaces your own privacy notice or legal assessment. It means the tool doesn't make the job harder.