Push Notifications for Your Business
A direct line to users who actually want it

What are push notifications?

Push notifications are short messages a device shows even when the website is not currently open. There are two worlds: app push from an installed native app, and web push that comes straight from the browser. For a Progressive Web App, web push is the decisive channel, because it works without an app store and without installation.

Technically, a push notification is at first just a delivery to the browser. Whether it becomes a visible message and how it looks is controlled by your service worker. That gives you control over the content, title, icon, and the destination behind the tap.

How push notifications work technically

At the centre sits the service worker, a script that runs in the background independently of the open page. Once the user consents, the browser creates an individual subscription and hands it to your server. Delivery itself runs through each browser's push service and is signed with the VAPID method, so that only your server may send for that domain.

The flow in four steps: the user gives consent, the browser creates a subscription, your server stores that subscription, and when needed the server sends a message that the service worker shows as a notification. Crucially, none of these stages works without consent.

On desktop and Android, web push is widely supported. On iOS, web push has been possible since iOS 16.4, but only if the site was first installed as a PWA via "Add to Home Screen". To reach iOS users more reliably, web push is therefore often combined with Wallet messages.

What the GDPR and German TDDDG require for push

Web push needs consent on two legal grounds: storing and reading the push subscription on the device falls under section 25 of the German TDDDG (the ePrivacy rules), processing the subscriber data falls under the GDPR. Before activation, users must know who is sending, about what, and how to opt out again. Withdrawing must be as easy as signing up.

Three obligations are missed most often in practice: the privacy policy must name the push service and the parties involved. Every processor that handles subscriber data needs a data processing agreement. And data minimisation applies, you store the subscription itself, not profiles without their own legal basis.

One point is regularly overlooked: many push solutions load their script or SDK on the first page view for every visitor, before any consent. That is the violation, not the sending of push itself.

Three ways to run push, and where the data lives

First, the technical truth that vendor pages rarely state: delivery runs through the browser vendors' push services for every web push provider in the world, Google for Chrome, Apple for Safari, Mozilla for Firefox. Nobody bypasses that transport. The difference lies in who manages the subscriber list and whether the content is readable in transit.

Honest marketing therefore does not claim "push without Google" but makes three verifiable statements: subscriber data on a server in Germany, content end-to-end encrypted per RFC 8291, no US SDK in the frontend before consent.

What about native apps from the stores?

For apps from the App Store and Google Play, the same logic applies with different technology. On iOS there is no way around the Apple Push Notification service, on Android Firebase Cloud Messaging is the standard. Here too, privacy is not decided by the transport route but at two other points.

First: the direct server connection. Instead of a push service provider in between, your server talks directly to APNs and FCM. The device tokens live in your database on a server in Germany, and the client contains no third-party SDK, only the operating system's push capability, which is there anyway.

Second, for elevated requirements: encrypted content. The server sends the message encrypted, and it is only decrypted and displayed on the device, on iOS via a Notification Service Extension, on Android via a data message with local decryption. Apple and Google then only transport an encrypted packet, which is how the secure messengers do it. What remains visible to the platforms is the timing and the recipient token, not the content.

Get a GDPR-compliant push setup

For websites with higher requirements, such as public administration, healthcare, or member organisations, I set up web push as a project so that the three statements above hold: standard web push with VAPID, subscriber management on a server in Germany, RFC 8291 encryption, and a consent gate that loads no third-party script before consent. This includes the building blocks for your privacy policy and, if needed, the data processing agreement for operations. For store apps, the same offer applies with the direct APNs and FCM connection from the previous section.

The scope depends on what you already run, from a single consent gate to a complete push backend on your own infrastructure. Tell me what is in place today and you will get an honest assessment of what is needed and what is not.

The user decides whether they want to be reached

Push only works well in one direction: thought through from the user's wish. Anyone who treats push as a pure broadcast channel and blasts everyone the same way loses subscribers faster than they gained them. They turn the messages off or block the site entirely, and then the channel is burned for good.

Three things decide success or failure. First: the user should be able to choose whether they want to be notified at all. Second: they should be able to choose the channel, that is, whether they would rather receive a message by email or as a push. Third: the message has to be relevant. A message with no connection to the recipient is a reason to unsubscribe, not added value.

In practice that means: offer a real choice instead of a blanket "allow notifications". Let users subscribe to the topics that interest them, and leave the channel up to them. Push is strong when it reflects a deliberate decision by the user, and weak when it is forced on them.

Why push notifications pay off for business

The biggest lever is re-engagement. Most visitors come once and never return. With a push subscription you bring back a share of those visitors without needing their email address and without depending on an algorithm.

Push is also a direct channel that belongs to you. Unlike reach on social networks, it does not depend on third-party platforms and their fees. And compared with email, a push message does not land in the spam folder but right on the lock screen, which, with the right content, leads to noticeably more returning visitors and conversions.

Typical use cases

In an online shop, push works well for availability and price alerts or a reminder about an abandoned cart. In newsrooms and on news sites, for new articles in subscribed sections. For clubs and organisations, for dates, cancellations, and short-notice announcements where email is too slow.

In a B2B context, push is useful more selectively, for example for status updates on a process or maintenance notices. The rule of thumb is the same everywhere: the more concrete the occasion and the clearer the relevance to the recipient, the better the channel performs.

Try it yourself

With a tap on the button you subscribe to this page's push notifications and see the flow from the user's perspective. Consent can be withdrawn again in the browser at any time.

Best practices for acceptance

Ask for consent at the right moment, not on the first page load. A user who does not yet know what your site offers will reflexively decline the request, and a permission that has been declined once is hard to win back. So ask only when there is a recognisable benefit.

Send only what you announced, and at a frequency that does not overwhelm anyone. Better rare and relevant than frequent and arbitrary. The legal obligations are covered above in the GDPR and TDDDG section.

Adding push notifications with miTT PWA

The miTT PWA for Joomla and the WordPress PWA bring web push straight into your CMS, including service worker setup, subscription management, and sending. You need no native app and no external service, and the user keeps full control over their subscription.