Three myths about push notifications

There is no clever trick in this one, just a handful of decisions worth making deliberately. A few things about push notifications that get repeated more often than they get checked.

The version of the app your customers are running is rarely the one you just shipped. Write the reasoning down alongside the decision, because the reasoning is what changes first.

“It only matters for big sites”

Permission is granted once and revoked forever. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.

“We can deal with it after launch”

Sometimes true, usually expensive. That sounds obvious written down. It is still the thing most often skipped.

“Our platform handles it”

Deep link into the exact screen the notification is about. The teams that handle this well are rarely the ones with the biggest budgets. The version that survives contact with a real deadline is the simple one.

In practice

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. Three things worth confirming about push notifications before you move on:

• Someone can say what the current setup is without going to look
• Deep link into the exact screen the notification is about — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.