Sending push notifications

It's instant. Announcing a live broadcast that's starting, an episode that just went up, a piece of news that won't keep until tomorrow: delivery is immediate, and so is reading. No other channel holds that timing.

It's built for mobile. A notification that isn't opened right away doesn't disappear: it stays in the notification center and on the icon's badge. It waits on the home screen, next to the app.

Nobody stands in the way. On a social network, an algorithm decides who sees your post. In an inbox, a filter decides whether your message arrives. A notification leaves your back office and lands on the device, with no referee in between. That's precisely what you're buying by having an app rather than a page.

This guide treats push as an audience tool. Two neighboring uses are covered elsewhere, because they belong to a different job.

Notifications sent automatically at each stage of an order, from confirmation to delivery, are described in "Managing your orders". A shop's promotional campaigns, from discount codes to new collections, are in "Boosting your sales".

They all go by the same name in everyday conversation, but they don't share a trigger or a scope. The table below is the plan of this guide.

One point of vocabulary with practical consequences: the location notification is not a push. Nothing leaves our servers. The zone and the beacon are embedded in the application, and it's the device that decides to display the message when the condition is met. The chapter devoted to it draws two limits from that.

This is the basic move, and the screen is the same for everyone.

One field, 256 characters, and no separate title: the title shown on the device is your app's name. So write a sentence that stands on its own, without counting on a headline above it.

The preview on the right shows the iOS rendering and the Android rendering as you type. Use it, the two systems don't cut in the same place.

A notification that opens the app on its home page forces the reader to go looking for what you've just announced. The Select an action picker avoids that misstep: you choose to open the application, a specific section, or an external link.

One caveat before you rely on it: a section only appears in the list once it has been published. If you've just created it, check first that no update is pending on your publication page.

The same screen does both. Now goes out on click; On a specific date opens a calendar and a time.

The option worth knowing is the local time checkbox. Ticked, your notification scheduled for 8am goes out at 8am for each person, not at 8am your time. That's the difference between a good-morning message and a 3am wake-up call for your readers on the other side of the world.

Two settings that look secondary, but they decide how intrusive you are. You pick a sound from a list, or no sound at all. You switch the badge on or off, that small red counter on the app icon.

A custom sound on every notification gives yours the same status as a phone call. Save it for what deserves it.

Below the message, the Recipients block starts with the platforms: iOS, Android, Progressive Web App. Then comes the choice that matters, All or Target.

The counter at the bottom of the page recalculates the number of recipients on every change, broken down by platform. Look at it before you send: it's the only place that tells you whether your targeting makes sense or whether it has emptied your audience.

Three people-based criteria, and the third is the most interesting.

Your user groups, the ones you've built in your community space, are offered as they are. They require the Authentication extension, described in "Building a community with your app".

The number of app openings over the last thirty days gives you behavioral targeting with nothing to prepare: people who have never opened it, one to five times, five to ten, fifteen to thirty. That's what lets you write a win-back message to those who are drifting away, and leave the daily regulars in peace.

Two special cases complete the list: people who don't have the latest update of the app, and people who have never received a notification. You can also filter on the phone's language, which cleanly settles the case of an audience spread over two countries.

You restrict the send to iOS smartphones, to Android smartphones, or to certain OS versions. This filter mainly serves one case: not announcing a feature to people whose device can't run it yet.

A map, a point, a radius. The notification only goes out to users inside the circle you've drawn.

Not to be confused with the next chapter: here it's you who decides when to send, and position acts as a filter. In a location notification, it's the user's movement that triggers the message.

Progressive Web App users have their own targeting block, and it's shorter: your groups, the number of openings over thirty days, the browser language, the device and the browser. No geolocation, no OS version.

That isn't an oversight, it's what a browser is willing to say about a visitor. Plan for it if your audience is mostly on PWA.

Writing a notification after every article means doing the same job twice, and forgetting it every other day. The automatic push takes it over: you designate a section, and every post triggers a notification carrying the content's title.

Creating a rule opens the same form as a manual send, except that the message is replaced by a choice of section. You can go one notch down and only trigger on a category: the whole Articles section, or only the Concerts category.

A prefix field lets you add a mention in front of the title, along the lines of "New episode". It's the only place where you write any text, since the rest comes from the published content.

Publishing at 11pm doesn't mean waking your readers at 11pm. The Send this message picker offers three regimes: any time, during a time range you define day by day, or during a period bounded by two dates.

The second option is the one that protects your audience, and it's also the one people forget to set. A rule running without a time range always ends up going out at the wrong moment. While you're there, check the time zone shown under the seven lines of the week: that's what decides what 9am means.

The automatic push is an extension, and it isn't available on the Standard plan. A Standard app sends notifications, but only by hand.

Your list of rules shows a toggle for each one, its settings, its statistics and its status. So a rule can be switched off without being deleted, which is the right move for a seasonal announcement.

A museum that explains a room when a visitor walks into it, a shop that flags its offer of the day when a customer walks past, a festival that welcomes people at the entrance: the location notification responds to the moment rather than to your calendar.

The Geoalert group only appears in your menu once the matching extensions are switched on.

The geofence is a circle on a map: an address, a radius in meters. You manage them in Notification › Geoalert › Geofences, as a list or on a map, and each one shows the number of notifications attached to it.

The iBeacon is a Bluetooth beacon placed in a location. It serves where GPS isn't enough: inside a building, in a lobby, in front of a specific aisle. You enter its unique identifier in Notification › Geoalert › iBeacons.

Three possible moments: when the user enters the zone, when they leave it, or after a stay of a length you set.

Then comes the setting that prevents harassment, and it deserves a pause: you decide how long before the same person can receive the message again. On every new entry into the zone, or after 12 hours, 24 hours, two days, two weeks, up to a year. A passing-trade shop wants daily; a museum doesn't want to repeat the same explanation in every room.

As with the automatic push, a time range limits the hours it can be displayed.

Native apps only. The recipient counter only mentions iOS and Android: your PWA doesn't receive location notifications. That's the direct consequence of what makes them interesting in the first place, the fact that position monitoring happens inside the installed application.

A beacon is placed before compiling. Your iBeacons' identifier travels inside the app's binary. Changing it therefore means recompiling the application and submitting it to the stores again, which the back office flags on screen. A geofence, on the other hand, can be changed without republishing.

A third caveat, rarer but brutal: switching on Apps for Kids mode automatically disables geofences and iBeacons, along with chat. An app for children doesn't geolocate its users.

A notification only reaches people who have installed your app and accepted notifications. SMS talks to a phone number, which makes it the only channel left once the app has been uninstalled.

A 140-character message, a button, a recipient counter. No targeting, no scheduling: what you write goes out as it is to the people who gave you their number.

That consent is prepared in the Settings tab of the same screen. There you write the dialog box that asks for the number inside the app, its two buttons, its success and error messages, the default country code, and the welcome SMS sent on sign-up. A carefully written request is the difference between a list of numbers and an empty one.

SMS is an extension, and its listing shows the price that applies to your app. It includes 500 SMS a month, renewed on a fixed date, and the screen shows the remaining balance along with the next renewal date. Beyond that, extra credits are bought from the same page.

At 140 characters and with a real cost per send, SMS isn't a publishing channel. Keep it for what justifies interrupting someone: a cancellation, a change of time, a piece of information your audience would hold against you for not sending.

They're recalled at the top of every notification screen, and they explain most cases of "I didn't get anything".

Your PWA must be published and its push certificates set up, in Publish › PWA › Push Certificates. Your iOS and Android apps must be published on the stores. And the preview application doesn't receive notifications: testing a send from the test app proves nothing, either way.

The number of notifications you can send each month depends on your plan.

One point to read the right way round: the quota counts notifications sent, not messages written. A notification addressed to 5,000 people uses up 5,000. That's one more reason to target.

The first lock isn't yours: the operating system asks permission to send notifications, and the user can refuse it or withdraw it at any time.

The second one you can open. If your app has a member area, Settings › Profile settings lets you show the history of received notifications in the profile, and allow your users to subscribe to or unsubscribe from your scheduled notifications. This option requires the Authentication extension.

It's worth switching on, even though the idea of letting subscribers go is unpleasant. Between a reader who unsubscribes from your alerts and a reader who uninstalls the app, the first one is still reachable.