Push Notifications for Rewards Apps Without Spamming

What is a good push notification strategy for a rewards app?

A good push notification strategy for a rewards app sends messages users would be annoyed to miss: a reward was credited, a pending reward became available, a bonus event is starting, a streak is about to end. Ask for permission after the user has seen value, send event-driven messages from your server instead of daily blasts, cap promotional pushes, respect local quiet hours, and give users a setting for each message type. Measure opt-outs per type, because one bad message can cost you the channel for good.

For the loops these messages point to, such as daily bonuses and streaks, see Rewards app retention: bonuses, streaks and levels.

When to ask for notification permission

Every major platform makes notifications opt-in and punishes a badly timed prompt, but the details differ.

Android 13 and higher

Android’s developer guide on the notification runtime permission says that on Android 13 (API level 33) and higher, a newly installed app’s notifications are off by default until you request POST_NOTIFICATIONS and the user grants it. If your app targets Android 13 or higher, you choose when the dialog appears. If it still targets 12L or lower, the system shows the dialog itself, usually at startup, and a user who taps “Don’t allow” even once is not asked again until they reinstall or you update the app to target Android 13. Google suggests asking from a user action, such as tapping a bell icon, or after the third or fourth launch.

iOS and iPadOS

Apple’s guide to asking permission to use notifications explains that the system prompts only the first time you request authorization, and later requests do not prompt again. Apple recommends asking in context rather than on first launch. It also offers provisional authorization: you can send notifications on a trial basis without a prompt, they arrive quietly in Notification Center history (no sound, no banner, not on the lock screen), and each one carries buttons to keep or turn off your notifications. For a rewards app, provisional delivery is a good fit for the first “reward credited” message, because the user sees a useful notification before deciding.

Web push

On the web, MDN’s page on Notification.requestPermission() notes that the API is available only in secure contexts (HTTPS) and that the request should be made in response to user interaction. Matt Gaunt’s permission UX article on web.dev calls a prompt on page load “the worst thing you can do” and points out that once a user blocks the prompt, the site cannot ask again.

WebKit’s announcement of web push for iOS and iPadOS 16.4 confirms the Home Screen requirement and that the request must follow direct user interaction. Platform rules checked on October 22, 2026.

Notifications worth sending in a rewards app

Rewards apps have an advantage: users are waiting for something. Offers take time to confirm, so the moment a reward lands is news. Build notifications around real events on your server, not a marketing calendar.

Build them from postbacks

The cleanest setup sends a notification as a side effect of crediting. Your postback handler verifies the signature, credits the user once per transaction ID, and then queues a notification job. Do not send the push inside the handler: offerwalls expect a fast reply. If the same transaction arrives twice, your duplicate check stops the second credit and the second notification together. What is a postback URL? covers the basics, and Postback security covers the signature check.

A few rules make postback-driven pushes feel good:

• Batch bursts. A five-step game offer can credit several steps close together. Wait a short window, then send one message: “You earned 1,250 coins from 3 rewards.”
• Say what is spendable. If you hold rewards before cashout, say “added to pending” rather than “ready to cash out”, then send a second message when the hold clears. Reward hold periods explains pending and available balances.
• Handle reversals quietly. Show them in the activity history with a clear reason, and email if the amount is large.

How many push notifications per day?

No platform publishes an official number, and any single figure you read is a vendor’s opinion. What the platforms do say is about quality: Apple’s Human Interface Guidelines for notifications warn against sending several notifications for the same thing, because people may turn off all notifications from your app. The practical answer is to cap promotional messages hard and let transactional ones through, batched.

Quiet hours and stale messages

Store each user’s time zone and hold non-urgent messages until their morning. Also stop messages from arriving late: Firebase Cloud Messaging’s guide to setting a message lifespan says messages without a time to live are kept for up to four weeks for offline devices, and that a collapse key replaces an older queued message with the newer one. Give a “bonus ends in 2 hours” push a short TTL so it never arrives the next day, and use one collapse key for balance updates so an offline phone shows only the latest total.

Use the right urgency level

Apple’s guidance on managing notifications defines interruption levels and says Time Sensitive notifications should be about something happening now or within an hour, and must never be used for marketing. A credited reward is a normal Active notification. A bonus event is promotional, so it should never use Time Sensitive.

Let users choose what they get

Give users a switch per message type. When the only option is “off”, an annoyed user turns off your useful messages with the noisy ones.

• Android: since Android 8.0, every notification must belong to a notification channel, and users can change each channel’s behavior. Create channels such as “Rewards and cashouts”, “Streak reminders” and “Bonus events”. You cannot change a channel’s importance after you create it, so choose carefully.
• iOS: Apple’s guidelines say that if you send marketing notifications, you must provide an in-app settings screen where people can change their choice.
• Web: web.dev suggests a settings panel or toggle so users can turn web push on and off without hunting through browser settings.

Personalize inside those choices, not around them. Send at the hour a user usually opens the app, in their language, and about the categories they actually complete. Offers depend on country and device, so check that an offer category is available to that user right before you mention it.

Example notification copy

Good rewards app notifications are specific, honest about status, and short enough to read on a lock screen. Apple’s guidelines also advise against putting sensitive or personal information in a notification, so keep balances vague if your users share devices.

Sample copy only. Coin amounts and names are made up.

Web push and email for rewards sites

A rewards website can use web push, but treat it as a bonus channel. Chrome gives you a reason to ask carefully: the Chromium blog post introducing the quieter permission UI says Chrome automatically shows a quieter, less visible prompt to users who usually block notification requests and on sites with very low opt-in rates. A site that prompts every visitor on arrival trains Chrome to hide its prompt from everyone.

Email is the fallback for users who said no to push, and the right channel for anything they must not miss, such as a cashout or an account notice. Keep transactional and marketing email separate. The FTC’s CAN-SPAM compliance guide requires a clear way to opt out of commercial email and says you must honor opt-outs within 10 business days. In the EU and the UK, marketing email usually needs prior consent; Offerwalls and GDPR covers the data side. Legal rules checked on October 22, 2026; ask a lawyer about your own markets.

App Store and Google Play rules for push

Store rules shape what a rewards app may push, and the most important one is short. Apple’s App Store Review Guidelines, section 4.5.4, say push notifications must not be required for the app to function, should not carry sensitive personal or confidential information, and should not be used for promotions or direct marketing unless customers have explicitly opted in through consent language in your app’s UI and you provide a way in the app to opt out.

On Android, Google’s core app quality guidelines say notifications should provide relevant information related to your app, and must not be used for cross-promotion or advertising of another product, which they describe as strictly prohibited by the Play Store. Google Play’s Ads policy adds that ads must not imitate app features such as notifications, and may only be shown inside the app serving them. Store policies checked on October 22, 2026.

The same logic applies to where the wall itself appears; Offerwall placement covers the store-safe entry points your notifications should link to.

Measure opt-outs and uninstall risk

The numbers that matter:

1. Permission opt-in rate per prompt placement. If you show the soft prompt after the first credit and after day 3, compare both.
2. Opt-out rate per message type. On each app open, check whether notifications are still enabled (Android’s guide recommends areNotificationsEnabled(); on iOS, read the current notification settings) and log the change against the last message type the user received.
3. Token loss. FCM’s error code reference says an UNREGISTERED error means a token is no longer valid, which can happen when the user uninstalls the app. A jump in these errors in the days after a campaign is an uninstall warning; remove those tokens as FCM advises.
4. Incremental retention. Keep a small random holdout group that gets no promotional pushes, and compare day 7 and day 30 retention and churn rate against everyone else. What is retention rate? explains the cohort method.

Change one thing at a time, such as send hour or copy; How to A/B test an earn page covers sample sizes and how long to run a test.

Frequently asked questions