Push notifications: how they work and what to send

Push notifications are short messages your server sends to a user’s phone, even when the app is closed. Your server doesn’t deliver them directly — a platform service does: APNs for Apple, FCM for Google.

A push is the cheapest way to bring someone back to your product and the fastest way to lose them. One notification too many, and they switch off all of them, or delete the app.

How push notifications work

The flow is almost the same everywhere; only the names change:

The app asks the system for permission and gets a device token — a long string that addresses this app on this phone.
The app sends the token to your server, and you store it next to the user.
When there’s something to say, your server sends a message with that token to APNs or FCM.
The platform service delivers it to the phone whenever the phone is online.

You don’t keep a connection open to every phone — the platform does that. FCM can also send to iPhones by passing messages on to APNs, so many teams use it as a single entry point for both platforms.

The message itself is a small JSON: a title, a body, and data the app uses to decide which screen to open.

{ "title": "Your order is on the way", "body": "The courier arrives between 2 and 4 pm", "data": { "screen": "order", "id": "8412" } }

Two technical details people forget. Tokens change and die — when the service says a token is invalid, delete it, or your table fills up with dead addresses. And tapping a notification should open the right screen, not the home screen: that’s the whole reason the person tapped.

When to ask for permission

On iPhone the system prompt appears once. If the person taps “Don’t Allow”, the only way back is through the phone’s settings, and almost nobody goes there. Recent Android versions ask explicitly too.

So don’t ask on the first screen, before people understand what the app is. Ask when the value is obvious:

right after an order — “want to know when the courier leaves?”;
when they follow something — “notify you when it starts?”;
when they set a reminder themselves.

A good pattern is to show your own screen first, with an explanation and “Yes” and “Not now” buttons, and trigger the system prompt only after “Yes”. A “no” on your own screen burns nothing — you can ask again later. iOS also has a quiet option: notifications arrive silently in the notification centre, and the person decides whether to keep them.

What to send

The best notifications are ones people are already waiting for:

status changes on something they did: an order, a payment, a reply to a request;
messages from other people;
reminders they set themselves;
events they explicitly subscribed to.

Marketing pushes are possible, with limits: no more often than you’d want to receive them, during the day in the user’s time zone, and about something they might actually care about.

What not to send

“We miss you!” and anything else whose only purpose is an app open.
Sensitive content on the lock screen: login codes, amounts, health details. Anyone nearby can read the lock screen.
The same message on three channels at once — push, email and SMS.
Notifications at night because the server runs on its own time zone.

Let people pick types: separate toggles for orders, messages and news in the app’s settings. Android has notification channels for exactly this — someone can mute “Promotions” and keep “Orders”. Without that choice, they’ll mute everything.

How to measure

Count more than taps:

opt-in rate — how many said yes, and on which screen you asked;
delivery — how many sent messages actually arrived and how many hit dead tokens;
opens, per notification type;
opt-outs — which type makes people disable notifications or delete the app;
the target action — did the person come back and do the thing the notification was for.

The most honest way to tell whether a campaign works is to keep a small holdout group that doesn’t get it and compare retention. A high open rate with rising opt-outs is a bad result, not a good one.

In short

A push is delivered by the platform service (APNs or FCM) using a device token your server stores.
Ask for permission when the value is obvious, not on the first screen.
Send what people are waiting for; marketing pushes rarely, in daytime and to the point.
Keep sensitive content off the lock screen and let people choose notification types.
Measure returns and opt-outs, not just opens — ideally against a holdout group.

SUBXCAT can set up notifications end to end, from tokens to sending rules, so they bring people back instead of annoying them.