Notifications are one of the most powerful ways to reach your users. But they're also one of the easiest ways to annoy them if handled poorly. I built the Notifications dashboard as a complete project, and added web push to Esma3 Radio, learning many lessons about the Web Push API and user experience along the way. In this article, I'll share the journey from VAPID keys to notifications that actually get through.
The first step was understanding how Web Push works. The system needs three parties: your application (the Client), the Push Service (the intermediary that delivers the notification), and the Service Worker (which receives and displays the notification). When a user agrees to notifications, the app communicates with the Push Service and creates a Subscription — this returns an object containing an Endpoint and Keys. You send this object to your server so you can use it later to send notifications.
VAPID keys were one of the things that gave me the most trouble initially. VAPID (Voluntary Application Server Identification) is the authentication method that assures the Push Service you're the legitimate sender. You need to generate a key pair — the public key you register with the Push Service, and the private key you keep on the server. If the private key leaks, anyone can send notifications in your name. In the Notifications dashboard, I stored the private key in Environment Variables and rotated it periodically.
Managing Subscriptions was a challenge on its own. Each user has a different Subscription, which means you need to store all Subscriptions in the database. But the problem is that Subscriptions can expire — the browser sometimes updates the Endpoint, the user might revoke permission, or delete the Service Worker. That's why I built a cleanup system that removes invalid Subscriptions daily. When I send a notification and get a 410 (Gone) error, I delete that Subscription from the database.
In the Notifications dashboard, I built a complete admin interface that allows sending customized notifications. The admin can choose the target audience (all users, specific users, or those who purchased a particular product), write the title and content, and set the sending time. I also added scheduling — you can write a notification now and set it to be sent tomorrow at 10 AM. The system uses Cron Jobs to check scheduled notifications every minute and send those whose time has arrived.
In Esma3 Radio, I used notifications differently. Instead of sending marketing notifications, I send notifications with real value: when a new station is added, when there's a special subscription offer, or when there's an important update. Our service allows the user to choose what type of notifications they want — new stations only, updates only, or everything. This customization noticeably increased notification engagement rates.
The biggest challenge was convincing users to agree to notifications. The web notification opt-in rate is much lower than native apps — only about 10-15%. To increase this, I used a "delayed ask" strategy — I don't request notification permission as soon as the user visits the site. Instead, I wait until the user does something that shows interest, then ask for permission. For example, in Esma3 Radio, after a user listens to radio 3 times, I show a message "Would you like to receive notifications when new stations are added?" The rate increased to 35% with this strategy.
Notification fatigue is a real problem. If you send too many notifications, the user will revoke permission or block the site. I made a rule: no more than 2 notifications per day per user. I also choose appropriate times — I don't send notifications in the middle of the night! I use the user's local time zone to ensure the notification arrives at a suitable time. In the Notifications dashboard, I added simple analytics: number of notifications sent, click rate, and number of users who unsubscribed. This data helps me improve notifications over time.
The difference between Web Push and in-app notifications is important. Web Push reaches the user even when the site is closed — that's its core strength. But in-app notifications are clearer and easier to interact with. In my projects, I use both together: Web Push for important events that need immediate attention, and in-app notifications for regular updates the user sees when they open the app.
My advice: if you're adding web notifications, think about the user's first experience. Don't ask for permission on the first visit — it scares people. Choose the right times to send, and minimize the number of notifications as much as possible. Every notification must provide real value to the user. And always use a dashboard to monitor notification performance — Click Rate and Unsubscribe Rate are your best indicators.
Powered by Ziad Amr
Top comments (0)