Push Notification

For a long time the only way to reach someone who had left the product was email. Email marketing is cheap and gives you room to write, but it loses the race inside an inbox. When Pagedeck sent a weekly summary, one or two people in ten opened it, and those one or two opened it two days later.

Having the app installed didn't change much. An app has to be opened before anything in it can be seen, and the only place to announce that a reason to open it had appeared was inside the app itself. Someone comments on your document and nobody knows until the next time they open it. A comment read three days later has already passed the moment when a reply mattered.

A push notification appears without the app being opened. One line on a lock screen registers within seconds. That strength is also the weakness. Exactly because it lands in front of someone, annoying them leads them to switch notifications off — and once they're off, there is no way to turn them back on from inside the app.

A delivery service sits between the sender and the device. There are six steps.

1. Get permission. The operating system asks whether notifications are allowed, and nothing proceeds unless the person agrees. Ask right after installation and a lot of people decline while they still have no idea what the notifications are for. Ask at the moment notifications become useful — the first time someone shares a document, for instance.
2. Store a value that identifies the device. Each installation receives one, and your server sends to that value rather than to a person. Uninstalling invalidates it, so failed values get cleaned out; a list that still holds tokens from deleted apps inflates every delivery number you look at.
3. Hand it to the delivery service. Your server can't put anything on a device itself. It passes the message to the service run by the company that makes the operating system, and that service sends it to the device.
4. The device displays it. What matters here is that arrival isn't guaranteed. A device that is switched off or in a power-saving state receives the message late or not at all.
5. Write the message. You need a title, one line of body text, and a destination for the tap. Without a destination the tap lands on the app's home screen and the person has to go find what they just read about. Most of them close the app right there instead.
6. Measure and adjust. Look at how many were sent, how many were actually displayed, what share were tapped, and what share of people turned notifications off. That last number outweighs the first three. A low tap rate can be fixed next time; someone who switched notifications off is gone from the channel permanently.

Timing and frequency are part of the design too. Nothing goes out at night, and a daily ceiling gets set in advance. Promotional content carries extra obligations — it has to be marked as promotional, and night-time delivery needs separate consent — so a channel that doesn't separate informational from promotional messages collects a compliance problem and a wave of opt-outs together.

The best fit is a notification attached to something the user did. That's the trigger message shape: the message goes out at the moment a defined event occurs. A comment on your document, a mention of your name, a failed payment. These read as information rather than advertising, and the reason to tap is already inside the notification.

The second fit is pulling back people who stopped coming. Someone who hasn't opened the app in two weeks gets told what piled up while they were away. The reason to send, though, has to come from their side. "We shipped a new feature" is the company's reason; "three documents you were invited to are waiting" is theirs. Teams that send only the second kind and teams that also send the first see very different opt-out rates.

Where it doesn't fit is equally clear. A single message broadcast to everyone is the most expensive choice available in this channel. In email that kind of send ends with a delete; in push it ends with notifications being switched off. One broadcast can cost you every notification you would ever have sent that person.

Deciding what gets announced and when, across the whole product, belongs to notification strategy. Decide it per channel and the same fact reaches someone by push and by email. Set the total any one person receives in a day first, then choose which channel carries each item.

"Does this go out as a push or as an email?"

Sorting what has to be known now from what can wait to be read.

"Push opt-outs hit 1.8 percent last week. Let's cut the sends."

More people switched notifications off, so frequency is the first thing to change.

"We never set a destination for the tap. Right now it drops onto the home screen."

Tapping the notification doesn't take anyone to what it was about.

Pagedeck splits push into two kinds: something happened in your documents, and news about the product. Settings let people switch each kind off separately.

Ravi's first proposal was to keep them as one. Settings stay simpler and product news reaches more people that way. Mia's objection was that combining them means anyone tired of the news switches off the document notifications too. Three months after splitting them, 14 percent had turned news off while 2 percent had turned document notifications off. Combined, that 14 percent would have disappeared from the document notifications as well.

Because it gets read, the assumption is that sending more is better. It genuinely does land more visibly than email, so the reasoning is easy to follow. But the cost in this channel isn't the cost of sending, it's the opt-out. With email, one unopened message doesn't stop the next one, and an opt-in can be collected again; with push, there's no way to tell someone who turned notifications off that anything is waiting. A team that sends three a day for two months and keeps its tap rate can find half its addressable audience gone six months later.

The other mistake is assuming a sent message is a delivered message. The send log records success, which makes the assumption natural. In practice it reaches nobody who declined permission, deleted the app, or has a device asleep. A successful send means the delivery service accepted it, not that a person saw it — which is why anything that truly has to arrive goes out over a second channel as well.