Blog · Privacy
GDPR and push notifications: consent, data and responsibilities
What personal data a push subscription holds, when the browser prompt is not enough, how to make opting out easy and who is responsible for what. Informational guide.
In the EU, push notifications fall under two sets of rules: the ePrivacy Directive, because subscribing stores and reads information on the user's device, and the GDPR, because the subscription and everything you attach to it is personal data. In practice that means informed consent before the browser prompt, an opt-out as easy as the opt-in, minimal data and a proper contract with your provider. This article is for information only and is not legal advice.
In short:
- A subscription endpoint is an online identifier: treat it as personal data, especially once you link it to a user ID.
- The native browser prompt says nothing about who you are or what you will send; your own pre-prompt is what makes consent informed.
- Keep transactional and promotional messages apart: they rest on different legal bases.
- Unsubscribing must be as easy as subscribing, and dead subscriptions should not linger in your database.
- The push platform you use is a processor: you need an Article 28 data processing agreement.
What personal data a push subscription contains
When someone subscribes, the browser creates a subscription made of three parts: an endpoint (a unique URL on that browser's push service) and two encryption keys, p256dh and auth. None of them contains a name, but the GDPR explicitly lists "online identifiers" in its definition of personal data (Art. 4(1)), and once you tie them to an account, identification is direct. Then comes everything you add yourself:
| Data | Why you need it | Recommendation |
|---|---|---|
| Endpoint and keys | Sending and encrypting each push | Essential; delete them once they expire |
| User ID | Reaching the account on every device | Use your internal ID, not an email address |
| Tags (language, plan, interests) | Segmenting sends | Only the ones you actually use; nothing sensitive |
| Delivery and click logs | Measuring and debugging | Set a retention period |
| IP and browser at signup | Security or proof of consent | Keep them only for a clear purpose |
Apply data minimization (Art. 5(1)(c)): a tag like "interested in diabetes products" reveals health information, a special category under Art. 9, and has no place in your notification system.
Why the browser prompt alone is not enough
Article 5(3) of the ePrivacy Directive requires consent to store or access information on a device, unless it is strictly necessary for a service the user explicitly asked for. The native prompt covers part of that: nobody subscribes without clicking "Allow." But all it says is that the site wants to show notifications. It does not say who you are, what you will send or how often, and the GDPR requires consent to be freely given, specific, informed and unambiguous (Art. 4(11)).
The usual answer is your own pre-prompt, shown before the browser dialog:
- Say what they will get: "We'll tell you when your order ships and when it arrives. No ads."
- Link your privacy policy from the pre-prompt itself.
- Offer a real "Not now": do not lock content behind acceptance (Art. 7(4)).
- Keep proof: the date, the text shown and its version, because you must be able to demonstrate consent (Art. 7(1)).
In castly the pre-prompt is configured per project, with English and Spanish texts and the number of days to wait after a "Not now" before showing it again; the opt-in prompt docs list every setting. Note that the GDPR also reaches companies outside the EU when they offer services to people in the EU (Art. 3(2)), so a US-based product with European users is not exempt.
Transactional and promotional messages: different legal bases
Not every message rests on the same lawful basis:
- Transactional (your order shipped, your appointment is tomorrow): processing can rely on performance of a contract (Art. 6(1)(b)), because the message is about something the user signed up for. The push channel itself still requires the user to accept the browser permission.
- Promotional (offers, product news, abandoned carts): these need consent (Art. 6(1)(a)). National marketing laws can add to that; Spain's LSSI, for example, bans promotional messages by email "or other equivalent electronic communication means" without prior request or authorization, and the cautious reading applies the same rule to push.
If one permission covers both, make it clear in the pre-prompt that promotions are included. Better still, ask for promotional consent separately and store it as a subscriber tag such as promos: "yes", so every campaign targets only people who agreed. Service messages are covered in depth in transactional push notifications.
Opting out and deleting: as easy as subscribing
Article 7(3) requires withdrawing consent to be as easy as giving it. Blocking notifications in browser settings works, but it is buried. Add a toggle on your site, in account settings or the footer, that cancels the subscription in one click, and describe the browser route in your privacy policy too.
- Remove expired subscriptions. When a push service answers 404 or 410, the subscription no longer exists and there is no reason to keep it. castly marks those as expired automatically; you decide when to delete them from your own systems.
- Set retention for logs. castly keeps delivery logs for 30 days; if you copy events into your database through webhooks, apply your own retention period there.
- Handle access and erasure (Arts. 15 and 17): you must be able to find every subscription belonging to a person by user ID and delete it.
What to put in a notification, and what not to
A push payload travels end-to-end encrypted under RFC 8291: the browser's push service carries it without being able to read it and only sees metadata such as the endpoint, size, time and expiry. The exposure is at the other end, because the notification appears on a lock screen, a shared monitor or in the middle of a screen share.
- "You have an appointment tomorrow at 10:00" beats "Your fertility clinic appointment is tomorrow."
- "Your payment didn't go through" beats "Your $1,240 payment to Smile Dental Clinic failed."
- Never send one-time codes or magic sign-in links: anyone who sees the screen could use them.
Keep the details on the page that opens on click, behind the user's session.
Who is responsible for what
| Party | Role | What to do |
|---|---|---|
| Your company | Controller: decides what is sent, to whom and why | Privacy notice (Art. 13), records of processing (Art. 30) and a lawful basis per purpose |
| The push platform you use | Processor: stores subscriptions and sends on your behalf | Data processing agreement (Art. 28), security measures, list of subprocessors and data location |
| Browser push services (Google, Mozilla, Apple, Microsoft) | Carry the encrypted message to the device; their legal role is less clear-cut | Mention them in your privacy notice as the delivery channel |
If any of them processes data outside the European Economic Area, check which mechanism covers the transfer, such as an adequacy decision or standard contractual clauses, and state it in your privacy notice.
Frequently asked questions
Is a push subscription endpoint personal data?
It is a unique identifier tied to a specific browser, and the GDPR includes online identifiers in its definition of personal data. Once you link it to an account there is no doubt, so treat it accordingly.
Does the browser permission prompt count as GDPR consent?
It is required, but on its own it does not tell people who is sending or why. Pair it with a pre-prompt that states the purpose and links your privacy policy, and keep a record of what you showed.
Do transactional notifications need consent?
Users always have to accept the browser permission to receive push at all. For the data processing itself, contract-related messages can rely on performance of the contract, while promotional ones require consent.
How long can I keep push subscriptions?
As long as they are active and the user has not opted out. Delete the ones a push service reports as gone (404 or 410) and set a retention period for logs and per-device statistics.
Do push notifications leave the EU?
They can: browser push services and some providers operate outside the EEA. The content is encrypted but the metadata is not, so document those transfers in your privacy notice and verify their legal basis.