Before you invest in push notifications
The gap between knowing this and actually doing it is where most teams lose ground. Before you spend anything on push notifications, it is worth confirming a few things are already true.
The version of the app your customers are running is rarely the one you just shipped. Budget a little time for it every quarter and it never becomes a project of its own.
Prerequisites
- You can describe the outcome you want in one sentence
- Someone owns it after the work is done
- Permission is granted once and revoked forever
- You have a way to tell whether it worked
Where it usually goes wrong
Notify about things people asked for, not things you want to say. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
Deep link into the exact screen the notification is about. Small and consistent beats large and occasional here. Write the reasoning down alongside the decision, because the reasoning is what changes first.
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
- Notify about things people asked for, not things you want to say — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If any of that sounds like a description of your current setup, it is fixable.