If you run a SaaS platform, you’ve probably heard that web push notifications are a “must-have” for user engagement. The reality? They’re powerful—but only if you set them up thoughtfully. Too many teams blast out annoying alerts that users click to block forever. This guide is for SaaS product folks, engineers, and marketers who want practical, no-nonsense advice for setting up web push in OneSignal without annoying your users or wasting time.
Step 1: Decide Why You're Sending Push Notifications
Before you paste any code, ask yourself: What’s the real point of these notifications on your SaaS platform? If your answer is, “Because our competitors do it”—stop. Push notifications are interruptive by nature. Use them to drive real value, not just vanity metrics.
Good reasons to use push: - Alerting users to time-sensitive events (e.g., approvals, new messages). - Reminding inactive users to finish setup or return to the app. - Announcing critical outages or policy changes.
What to skip: - “Check out our latest blog post!” — Nobody asked. - Generic marketing blasts. - Anything users wouldn’t miss if it was an email instead.
Pro tip: If you can’t explain the benefit to the user in one sentence, don’t send the notification.
Step 2: Set Up Your OneSignal Account and App
If you haven’t already, create a OneSignal account and set up a new app for your SaaS product. The setup wizard is straightforward, but a few things often trip people up.
Watch out for: - Platform confusion: Make sure you’re configuring “Web Push” and not mobile push unless you need both. - HTTPS requirement: Web push only works on HTTPS (except localhost during dev). If your site isn’t HTTPS, fix that first. - Subdomain questions: OneSignal gives you the option to use their subdomain or your own. If you care about branding or plan to migrate away someday, use your own domain.
Quick steps: 1. Log in, create a new app, and choose “Web Push.” 2. Fill out your site’s details, selecting HTTPS. 3. Choose your integration type (typical SaaS platforms use “Typical Site” or “Custom Code”).
Step 3: Integrate OneSignal with Your Frontend
Now you actually hook OneSignal into your app. Most modern SaaS platforms use React, Vue, or something similar, but the process is similar for any stack.
Basic integration:
- Paste the provided OneSignal JavaScript snippet into your site’s HTML, ideally right before the closing </body> tag.
- If you’re using a single-page app, make sure OneSignal initializes after your framework loads.
- For frameworks with server-side rendering, double-check that the push code only runs client-side.
Gotchas to avoid: - Repeated prompts: If you reload OneSignal on every route change, users may get asked for permission more than once. Only initialize once. - Non-secure origins: Again, no HTTPS = no push. Don’t waste time debugging this.
Pro tip: If you have a custom user authentication system, link OneSignal users to your app’s user IDs using OneSignal’s tags or external user ID features. This lets you target notifications to real users later.
Step 4: Customize the Permission Prompt (Don’t Just Use Defaults)
The default browser “Allow notifications?” popup is abrupt and easy to dismiss forever. Some users click “block” out of habit, and you’ve lost them for good. OneSignal offers a “soft prompt”—use it.
Best practices: - Use a custom pre-permission prompt explaining why you want to send notifications (“We’ll only alert you to new tickets assigned to you”). - Trigger the prompt at the right moment—not on page load. Wait until the user’s done something meaningful (e.g., finished onboarding, visited a key feature). - Keep the language honest and specific. No fake urgency.
What not to do: - Don’t show the prompt immediately on first visit. - Don’t promise more than you deliver (“We’ll never spam you!”—unless you really mean it).
Technical tip: OneSignal lets you customize the prompt UI and timing. Use their in-dashboard settings or their SDK for more control.
Step 5: Segment Your Audience From Day One
This is where most SaaS teams go wrong. If you treat all users the same, your push notifications will be ignored or blocked.
How to segment: - Use OneSignal’s tags or data attributes to label users by role (admin, user, guest), usage level, or features enabled. - Set up segments in OneSignal based on these tags—e.g., “Active paying users,” “Trial users,” “Admins only.” - When sending notifications, always target a segment, not “All Users.”
Examples: - Only alert admins to system outages. - Remind trial users about expiring trials, not paying customers. - Notify users about features they’ve actually enabled.
What to ignore: - Don’t over-complicate segmentation at launch. Start with 2–3 meaningful groups and expand later.
Step 6: Build and Test Your Notification Workflow
It’s easy to think, “I’ll just send a test notification and ship it.” Resist that urge. Real workflows need real testing.
What to do: - Set up test users with different roles/segments. - Send test notifications and check: - Are the right users getting the right messages? - Is the notification copy clear? - Does clicking the notification take the user to the right place? - Test opt-in and opt-out flows. Can users easily unsubscribe?
Things that break: - Single-page apps sometimes eat notification clicks (links don’t load as expected). - Cross-browser quirks: Chrome, Firefox, Edge, and Safari all handle web push a bit differently. - Ad blockers and privacy extensions can block push registration—don’t assume 100% delivery.
Pro tip: Don’t just test in dev. Stage your setup in a staging environment with real HTTPS and a real domain.
Step 7: Keep Notifications Useful, Brief, and Rare
Once you’re live, don’t turn on the firehose. You’ll quickly train users to ignore your notifications (or worse, block them).
Guidelines: - Only send notifications users actually want. - Keep the message short. The headline matters most; most users won’t read beyond it. - Limit frequency. Once a day is plenty for most SaaS use cases. - Make it easy to opt out (and honor the request).
What doesn’t work: - Sending “reminders” for trivial things. - Using push to replace email entirely. Each channel has its place.
Pro tip: Track notification stats in OneSignal—looks at open rates, blocks, and unsubscribes. If people are opting out, you’re sending the wrong stuff.
Step 8: Review, Iterate, and Don’t Be Afraid to Cut Back
Web push is easy to add, but easy to abuse. Set a calendar reminder to review your notification strategy every quarter.
What to review: - Are open rates dropping? Are more users blocking? - Which types of notifications get engagement, and which get ignored? - Are you sending more than you planned?
If in doubt, send less. It’s better to have users wishing they got more than searching for the “block” button.
Final Thoughts
Setting up web push notifications in OneSignal for your SaaS platform isn’t rocket science, but it’s easy to get wrong if you rush or follow hype instead of common sense. Start simple, focus on value for your users, and iterate as you learn. The best notification is the one that’s truly useful—and the rest are just noise.