Table of Contents:
- What is a Web Push Notification?
- How Web Push Notifications Work
- Web Push vs Mobile Push Notifications
- Web Push Notification Examples
- Web Push Notification Best Practices
- Web Push Notifications with evamX
Web push notifications are short, clickable messages delivered directly to a user's browser on their desktop or mobile device, even when they are not actively visiting the website that sent them. They appear as native browser notifications, in the corner of the screen on desktop or in the notification tray on mobile, and they work across all major browsers including Chrome, Firefox, Safari, and Edge.
The defining characteristic of web push notifications is their independence from both the mobile app ecosystem and the email channel. A user does not need to have an app installed to receive a web push notification. They do not need to have provided an email address. They only need to have visited a website and opted in to receive notifications from that site through their browser. This makes web push a uniquely accessible channel for reaching users who engage primarily through the web rather than through installed applications.
For organizations in banking, retail, and telecommunications, web push notifications extend real-time engagement capabilities to a segment of the customer base that other mobile channels cannot reach. A customer who uses internet banking through their browser but has not installed the mobile app is unreachable through push notifications from the app channel. Web push bridges that gap, enabling real-time transactional alerts, personalized offers, and behavioral triggered messages for web-first customers who would otherwise receive only email or SMS communications.
What is a Web Push Notification?
A web push notification is a message sent by a website to a subscribed user's browser. It appears as a browser-level notification regardless of whether the user currently has the website open. The notification typically includes a title, a short message body, an icon, and optionally an image or action buttons that allow the user to take a specific action directly from the notification without navigating to the site.
Web push notifications require an explicit opt-in: when a user first visits a website that has web push configured, the browser presents a permission prompt asking whether the user wants to allow notifications from that site. If the user accepts, they become a web push subscriber and the site can send them notifications through the browser's push service. If they decline, the site cannot send them web push notifications.
This opt-in requirement is both a limitation and a quality signal. The subscriber base for web push is typically smaller than the total addressable audience for paid advertising or even email, but subscribers have explicitly chosen to receive communications from the brand, which means their engagement rates are significantly higher than those of audiences reached through non-permissioned channels.
How Web Push Notifications Work
Web push notifications operate through a technical infrastructure that connects a website to the browser's native notification system. When a user opts in, the browser generates a unique subscription token for that user and registers it with the browser's push service, which is operated by the browser vendor. Google manages Firebase Cloud Messaging for Chrome, Apple manages APNs for Safari, and Mozilla manages its own push service for Firefox.
When a website wants to send a notification to a subscribed user, it sends the notification payload to the appropriate push service along with the user's subscription token. The push service delivers the notification to the user's browser, which displays it as a native notification. This delivery mechanism works even when the website is not open in the browser, as long as the browser itself is running in the background.
A service worker, which is a JavaScript file registered in the background of the user's browser session, handles the receipt and display of web push notifications on behalf of the website. This technical requirement means that web push is only available on websites served over HTTPS, and it requires a modest amount of front-end implementation by the development team.
Web Push vs Mobile Push Notifications
Web push and mobile push notifications share the same fundamental purpose, delivering real-time messages directly to a user's device, but they differ in their delivery mechanism, their audience, and their technical characteristics.
Mobile push notifications are delivered through installed mobile applications via the device's operating system. They require the user to have installed the app and granted notification permissions within that app. They work regardless of which browser the user prefers and can deliver rich media, deep links, and interactive elements native to iOS and Android.
Web push notifications are delivered through web browsers, independent of any installed application. They work on desktop and mobile devices wherever a supported browser is present, and they reach users who have opted in through a website visit rather than through an app install. They are technically simpler to implement than mobile push, since they do not require a native app, but they have more limited rich media capabilities in some browsers and their delivery depends on the browser being able to run in the background.
The practical implication is that web push and mobile push serve complementary audience segments. Mobile push reaches app users with the richest notification experience. Web push reaches browser-first users who have not installed the app. For organizations managing customer engagement across both channels, using both in coordination ensures that real-time messaging capabilities extend to the full addressable web and mobile audience rather than only to app users.
Web Push Notification Examples
In banking, web push notifications enable real-time transactional alerts for customers who manage their accounts through internet banking in the browser rather than through a mobile app. A customer who logs in through their browser to check their account balance can opt in to web push and subsequently receive instant notifications when a significant transaction occurs, when their balance crosses a threshold, or when a relevant product offer becomes available based on their account activity.
In retail, web push notifications are most commonly used for cart abandonment recovery, price drop alerts, and back-in-stock notifications. A customer who browses a product, adds it to their cart, and leaves without purchasing can receive a web push notification reminding them of the abandoned cart within minutes of leaving the site. A customer who viewed a product that was out of stock receives a web push notification the moment it becomes available again.
In telecommunications, web push notifications extend real-time engagement capabilities to subscribers who manage their account through the operator's web portal. A subscriber whose data balance is running low receives an instant web push notification with a top-up offer, even if they are not currently visiting the operator's website. A subscriber approaching contract renewal receives a timely renewal offer through the browser channel that would otherwise only be deliverable via email.
Web Push Notification Best Practices
Permission prompt timing is the single most important variable in web push opt-in rates. Presenting the permission prompt the moment a user arrives on the homepage, before they have had any chance to engage with the site or understand why notifications from it would be valuable to them, produces very low opt-in rates and a high proportion of permanent dismissals. Waiting until the user has demonstrated engagement, completing a login, viewing multiple pages, or reaching a specific point in a transaction flow, before presenting the permission prompt consistently produces higher opt-in rates and a more engaged subscriber base.
Message relevance determines whether web push subscribers remain engaged over time or progressively ignore and eventually block notifications. Web push subscribers who receive irrelevant, excessive, or poorly timed notifications will revoke notification permissions, which is a permanent loss of that communication channel for that user. Every web push notification should pass a simple relevance test: would this specific user find genuine value in receiving this message at this moment?
Personalization based on behavioral signals is the most effective lever for improving web push engagement. A notification triggered by what a specific user just did, or what they are likely to need based on their history, converts at a significantly higher rate than a broadcast notification sent to all subscribers simultaneously. Connecting web push delivery to a behavioral data layer that captures user activity in real time and triggers contextually relevant notifications is the difference between a web push program that builds the customer relationship and one that gradually erodes it.
Web Push Notifications with evamX
evamX supports web push notifications as part of its omnichannel real-time engagement platform. Web push in evamX is triggered by the same behavioral event stream and decisioning logic that governs all other engagement channels, ensuring that web push notifications are coordinated with mobile push, email, and in-app messages rather than operating as a separate, siloed channel.
When a user's behavior on a connected website triggers an engagement condition, evamX evaluates whether web push is the appropriate channel for that specific user at that moment, based on their channel engagement history, their current context, and any active frequency caps. If web push is selected, the notification is delivered immediately through evamX's web push infrastructure, with content personalized to that user's profile and a clickthrough destination configured to take them directly to the relevant page or action rather than to the site homepage.
Frequency management and suppression logic apply across web push alongside all other channels, ensuring that a user who has already received communications through email or mobile push that day is not additionally over-messaged through the web push channel simply because they have visited the website.



