Web Push Notifications: What They Can and Cannot Do

Push notifications come up in about one conversation in three once somebody knows a website can behave a bit like an app. The pitch they have in their head is a good one: send a message straight to a customer's phone, no email, no social platform in the middle, no algorithm deciding who sees it. That part is real. The bits either side of it are where people get caught out.

So here is the honest version, without the marketing copy.

What web push actually is

A website can ask permission to send you notifications. If you say yes, the site can then send a message to your device even when the browser is shut, and it turns up in the normal notification tray next to everything else.

The mechanism behind it is the same one that lets a site work offline. A small script sits on the device, stays running in the background, and wakes up to handle the incoming message. I have written that bit up separately in what a service worker actually does if you want the mechanics.

The iPhone catch, which is the big one

On Android this all works in a normal browser tab. On iPhone it does not.

For push to work on an iPhone, the person has to add your site to their home screen first, through the share menu. Only then can it ask for notification permission at all. That is not a bug and it is not something a developer can work around. It is how Apple has set it up.

This matters more than any technical detail on this page, because it changes the numbers completely. Adding a site to the home screen is a deliberate, slightly obscure thing to do. Most people never will. So on iPhone your reachable audience is not your visitors, it is the small subset of your visitors who liked you enough to install you.

If a chunk of your customers are on iPhones, and in the UK that is a very large chunk, plan for push to reach fewer people than you expect. It can still be worth it. Just do not build the campaign around it.

Permission is a one shot thing

The browser gives you one clean chance to ask. If somebody hits block, that is largely it, and getting it undone means talking a customer through a settings screen they have never opened, which nobody is going to do.

So do not ask on arrival. A prompt that fires while somebody is still working out what your business does gets blocked almost every time, and you have burned the only ask you get.

Ask when the answer is obviously yes. After an order is placed, if you are going to send them delivery updates. After a booking, if you are going to remind them. And say what you are going to send before the browser dialogue appears, in your own words, on your own page, so the actual permission box is a formality rather than an ambush.

What they are good for

• Something the person is waiting for. Order shipped, appointment tomorrow, table ready, job finished. Genuinely useful, genuinely time sensitive, and nobody minds getting it.

• Something that expires. A slot that has come free, a limited run of something. Works because there is a real reason it arrived now.

• An internal tool. Honestly this is where I see the most value and the least excitement. A small team, a shared job list, a notification when something needs picking up. No marketing involved at all.

What they are bad for

Anything that is really a newsletter. If the content would have been fine as an email tomorrow, send an email tomorrow. Push is the most interruptive channel you have access to, sitting on the same tray as somebody's messages and their alarm, and people are quick to switch off anything that abuses it.

The failure mode is not that people complain. They just turn it off, quietly, and you never get it back.

The bit nobody costs in

Sending a notification is easy. Deciding what to send, to whom, and when, is the actual work, and it is ongoing work rather than a build task.

You need somewhere to store who has agreed, a way to stop sending to devices that have gone away, and a decision about what happens when somebody taps the thing. If a notification opens your homepage rather than the specific order it was about, it feels broken, and that plumbing takes longer than the notification itself.

Budget for the second half. Most of the push projects I have seen go quiet after three months went quiet because nobody owned the sending, not because the code stopped working.

Should you bother?

Rough test. If you have something genuinely time sensitive to tell individual people, and a decent share of those people are already coming back to your site regularly, push is worth doing. Start small, on one message type, and see whether anybody acts on it.

If you are hoping push will bring back people who have drifted off, it will not. They have to opt in while they still care, which means you needed them engaged before push was ever on the table.

And if what you actually want is an icon on somebody's home screen and a proper app feel, that is a slightly different conversation, which I have had a go at in do you need an app or a PWA and in building for real people on imperfect networks.

If you want to talk through how it fits what you are doing, I run a free thirty minute surgery. Get in touch and I will tell you straight, including if the answer is do not bother.