I first encountered push notifications while developing mobile applications. Later, the same principle expanded to the web: a visitor allows messages and the browser can display them even when they do not currently have the site open.
It is technically interesting. From a marketing standpoint, another question matters more: do we have something so useful and time-sensitive that we are entitled to interrupt someone for it? If not, we do not need another channel.
What web push actually is
A web application typically works with notification permission, a service worker, and the browser's push service. A subscription is tied to a specific browser and device, not automatically to a person in the CRM. MDN Push API describes the technical foundations and the role of the service worker.
That has a practical consequence: the number of subscriptions is not the number of customers. One person may have multiple devices, reinstall their browser, or revoke permission at any time. Without a signed-in account and careful linking, you generally do not know who owns a device. I would not try to conceal that uncertainty with an overly precise persona.
Ask for permission only with context
The worst option is the system prompt immediately upon arrival on a website. The person does not yet know what you offer, and the browser is asking them for long-term permission. If they choose to block it, you will often not get a second chance without them manually changing the settings.
I therefore explain a specific benefit first: notification of a change in order status, an available appointment, the start of a broadcast, or the return of a watched product. Only after a deliberate user action do I open the browser's actual request. The Notifications API documentation on MDN likewise recommends tying the request to a user gesture.
When push makes sense
- Status and availability: an order, reservation, appointment, or product has changed.
- Time-sensitive content: a broadcast is starting, an auction is ending, or an event the person chose themselves has occurred.
- A recurring work tool: the user expects operational alerts as part of the service.
- Deliberate tracking: the person has actively turned on a specific topic, rather than vague “news”.
The closer the message is to behaviour the user explicitly set up, the easier it is to justify the interruption. A general discount for everyone is a weaker reason than an alert someone asked for.
When I would stick with email
Email is better suited to a longer explanation, a document, a recap, and communication that someone can deal with later. Push has little space, disappears quickly, and should not lead on click to a page where the user has to search again for the message's meaning.
If a company cannot manage relevant email, another channel often only multiplies the problem. I would first bring the database, offering, and process into order using the article on email marketing. I would then choose tools according to a specific scenario, not by the number of icons in the price list.
What every message must contain
- a clear reason why it arrived right now;
- a recognisable sender;
- a concise message without false urgency;
- a destination page that follows the message exactly;
- an option to adjust topics or end the subscription;
- a frequency limit and quiet period based on the user's situation.
I would not send the same message simultaneously through push, email, SMS, and chat merely because the integration exists. Orchestration means choosing the appropriate channel, not using all of them.
How to measure push
Delivery and clicks are operational signals. Business value only arises with the next step: completing a reservation, returning to the app, purchasing a watched product, or reducing the number of support enquiries.
I also track negative signals: revoked permission, topic unsubscribes, a quick return without action, and complaints. A high click-through rate may be the result of aggressive wording while destroying the channel in the long term.
I tag links with consistent UTM parameters, but I account for the fact that part of the measurement will be limited by the browser, consent, and the device lifecycle. Dashboard accuracy is not a reason to expand data collection without benefit to the person.
A small pilot instead of a site-wide launch
- I select a single event scenario with clear value.
- I describe who can turn on the subscription and at what moment.
- I set a frequency limit, message expiry, and a switch-off option.
- I test different browsers, devices, and the situation without permission.
- I measure the completed task as well as negative reactions.
- After several cycles, I decide whether to expand, adjust, or switch off the channel.
My conclusion
Push notifications are not a cheaper newsletter. They are brief, justified interruptions. They work well for an event a person chose themselves and needs to know about in time. They work poorly as another surface for general promotion.
If you want to decide whether push belongs in the whole customer journey, start with a review of your marketing system. You can describe your specific situation through contact.