A push notification is a message an app shows on the phone screen even when the app is closed, and only to people who allowed notifications. That permission is the first constraint teams forget: on Android 13 and later notifications are off by default for a newly installed app, and on iOS they are switched on by a system prompt. Everything after that comes down to the segment, the reason and the timing.
Key takeaways
Ask for permission at the moment when the benefit is obvious, not on the first screen. On Android the rule is written down plainly: if a user installs your app on a device running Android 13 or higher, notifications are off by default, and you may only send them after the user grants permission. On iOS notifications are likewise switched on only by explicit permission: the app shows a system prompt, and the answer to it shapes the whole channel.
The cost of a refusal on Android is higher than it looks. The documentation states that if an app targets Android 12L or lower and the user taps "Don't allow" even once, they are not prompted again until the app is reinstalled or updated to target Android 13.
So the first metric of the channel is not opens but the share of users who allowed notifications out of those who installed the app. While that share is low, working on copy is pointless: there is nobody to show the messages to.
A user switches off a specific type of notification rather than the whole app — provided you separated them. Since Android 8.0 every notification must be assigned to a channel; in an app targeting Android 8.0 or higher a notification without a channel simply does not appear, and the system logs an error.
The practical conclusion is straightforward. You need as many channels as you have distinct reasons to write: "Orders", "Delivery", "Reminders", "Promotions". Then a person tired of promotions switches off promotions rather than the status of their own order.
Tip Never put advertising in the same channel as order statuses. Having switched off a mixed channel once, a person stops receiving the very thing they installed the app for — and you cannot bring them back into notifications: channel settings belong to the user, not to the app.
The ones tied to a person's action work, not the ones tied to a marketing plan. Every such scenario has a trigger event, an understandable reason and a metric that shows whether it is worth keeping.
| Event | Example message | When to send | Scenario metric |
|---|---|---|---|
| Order placed | "Order No. 1284 accepted. We will write when the courier leaves" | Immediately | Delivery rate and opens |
| Delivery status changed | "The courier is on the way and will arrive within the hour" | At the moment of the event | Opens |
| Basket abandoned | "Two items are still in your basket. Keep them until tomorrow?" | After two to four hours | Basket visits and orders |
| Subscription ending | "Your subscription ends on 24 September. Renew now?" | Three days before and on the day | Renewals |
| Support reply | "An agent has replied to your request" | Immediately | Opens and time to reply |
| No activity | "A week without you. Delivery terms have changed" | On a schedule, no more than weekly | Returns and opt-outs |
Every notification should open the right screen rather than the home screen: an order opens the order, a basket opens the basket. How such links into an app are built and how not to lose the source of the visit is covered in our article on deep links and visit attribution.
The main restriction concerns advertising. The App Store Review Guidelines, clause 4.5.4, state that push notifications must not be required for the app to function and should not be used to send sensitive personal or confidential information; promotions and direct marketing require explicit opt-in through consent language shown in the app's interface, and the app must provide a way to opt out of such messages.
Three things follow, and they are designed in advance: a separate consent for promotions on top of the system permission, a separate toggle to opt out, and the understanding that nothing sensitive belongs in the text — it is visible on a locked screen.
Personalisation by date of birth, purchase history or city means processing personal data, which calls for consent and a clear statement of why the data is collected. What usually goes wrong here is covered in our article on personal data leak risks. Store requirements for describing data collection are covered separately, in our article on publishing in the App Store and Google Play.
Push has its own funnel, shorter than the product one: permission, delivery, open, target action. Opt-outs and deletions belong in the same table, because without them the picture looks better than it is.
| Metric | Formula | What it tells you |
|---|---|---|
| Permission rate | allowed ÷ installed | The moment and the wording of the prompt |
| Delivery rate | delivered ÷ sent | The state of the token base and live devices |
| Open rate | opens ÷ delivered | How well the reason, copy and timing landed |
| Target action | orders ÷ opens | The value of the scenario, not of the broadcast |
| Opt-outs | switched notifications off ÷ received | Fatigue caused by frequency |
| Deletions after a send | deleted the app ÷ received | Overheating: the message was unwanted |
Delivery rate is not measured straight away. A message that could not be delivered is stored and sent again once the device is back online: by default Firebase Cloud Messaging keeps it for four weeks, while with a zero lifetime an undeliverable message is discarded immediately. So urgent messages get a short lifetime: a "the courier is at your door" notification arriving the next day does more harm than silence.
General product metrics — daily and monthly active users, retention by day — are counted separately and do not replace push metrics. They describe the state of the product, not the work of the channel.
Bases are lost to frequency rather than to one unfortunate message. The rule is simple: one reason, one message, and the reason must belong to the person rather than to the marketing team.
The quiet window is skipped more often than the other points, and it costs dearly: a night-time promotion produces a spike in opt-outs that is later blamed on the copy.
A Telegram bot covers the same job: segmented broadcasts, booking reminders, order status. Permission here is granted by the very act of starting the bot, and segments are assembled from a person's answers and actions in the conversation.
At the UzFranchise Expo communications worked exactly that way: a message went to the right group, and those who did not come on the first day received an invitation for the second. The audience was split by interest, so broadcasts went to individual segments rather than to everyone at once.
The channel has one limitation, and it is a hard one: a bot cannot message a person first — the user has to start the bot themselves. So the broadcast base is built only from people who already opened a conversation. What else this channel can and cannot do is covered in our article on Telegram bots for business.
We do not sell "push setup" as a separate service: notifications are designed together with the product scenario. On our service pages the three closest formats are these.
The budget rises above the starting figure with the number of scenarios, the number of interface languages and the demands of segmentation: a segment based on one attribute is quick to set up, while a behavioural segment needs events the product may not have yet. What the work includes is set out on our bots and AI assistants page.
Syntra Systems starts with a map of reasons rather than with copy. We work out which events in the product deserve a message at all, what the person should do afterwards and which screen that action lives on. We then build the scenarios, spread them across notification channels and agree the frequency and the quiet window up front.
After that we connect delivery, tag the transitions so it is clear which message led to an action, and set up the report: permissions, delivery, opens, target actions, opt-outs. When there is no app yet, we build the same logic in a Telegram bot — with segments and the same metrics.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Push is free for the sender, arrives instantly and opens the right screen of the app, but it reaches only those who granted permission and kept the app. SMS reaches almost everyone and costs money, while email gives more room for text. These channels do not replace one another: critical messages are duplicated, promotions stay in push.
There's no ready-made rule — it's tuned to your own audience: after every promotional send, watch opt-outs and app deletions and settle on the frequency where they stop rising. The limit applies only to promotional messages — order statuses and support replies aren't part of it.
Leave them alone and work through other channels: email, a bot message, an in-app banner. Repeated system prompts will not help, and on Android with an outdated target the prompt will not appear at all. What sometimes works is a rewritten benefit screen plus a toggle in the settings.
One table is enough: the share who granted permission out of those who installed the app, delivery rate, opens, opt-outs and deletions after a send. The first matters more than the rest — while few people have granted permission, the wording of the message changes nothing.
Three reasons: the person switched notifications or the channel off, the device stayed offline longer than the message lifetime, or the device token went stale after a reinstall. The first is handled by segmentation and frequency, the second by a short lifetime for urgent messages, the third by regular cleaning of the token base.
Whoever owns the product, not the advertising. Notifications are part of the user scenario: they depend on events in the system, on access rights and on the wording in the interface. Marketing suggests reasons to write, but decisions on frequency and on the set of channels stay with the product.
Check two things. On Android 13 and later, notifications for a new app are switched off until the person grants permission themselves. And from Android 8.0 onward, every notification has to be tied to a channel — a separate category such as "Orders" or "Promotions" — and without one it simply won't appear on screen.
