Push notification strategy

A useful push notification strategy starts with a reason to interrupt someone, then gives that person control over what arrives. Decide which events warrant a message, ask for permission when its value is clear, limit repeats, and measure useful responses alongside turn-offs. Permission to send is not a reason to send every update the app can detect.

Decide what deserves a push

For each proposed notification, record what changed, who needs to know, how soon the information loses value, and what the recipient can do. A booking change may call for a prompt alert. A routine account summary may work better inside the app or in a digest the person chooses. Validate those decisions with the app’s users.

Distinguish updates triggered by a person’s own actions from optional recommendations and promotions. Someone tracking a delivery may expect a status change; they have not necessarily asked for offers. Check that the message is accurate for its recipient, its destination is available, and its visible text does not reveal private details on a lock screen.

Protect notification-related information

When notification systems handle personal information, the Office of the Australian Information Commissioner’s guidance says entities covered by the Privacy Act 1988 must take reasonable steps to protect it from misuse, interference, loss and unauthorised access, modification or disclosure. The guidance also addresses destroying or de-identifying personal information when it is no longer needed, unless an exception applies.

The OAIC notes reasonable steps include technical and organisational measures for information held after 11 December 2024. Consider this alongside message content: notification text and the data used to select recipients should not expose information unnecessarily.

Privacy and data protection requirements under Australian law

Make permission a clear choice

Explain the kind of update at a relevant moment, such as when someone chooses to track a booking. Leave a usable path if they decline. For a standard iOS authorisation request, the system saves the first answer; calling the request again does not show the same prompt.

On Android 13 and later, non-exempt notifications require the POST_NOTIFICATIONS runtime permission. Apps targeting Android 13 or later can choose when to show its dialog; older target versions have less control.

Keep device permission separate from the app’s own preferences. A person may allow notifications on the device but want booking changes rather than recommendations. Provide clear category choices and account for settings they can change later.

On Android 13 and later, a newly installed app has notifications off by default until it requests permission and the user grants it. If the person chooses not to allow notifications, the app cannot send them unless an exemption applies; if they dismiss the dialog without choosing, the permission state does not change.

iOS vs Android: Notification permission handling

Account for platform controls

On Android 8.0 and later, every notification must belong to a channel. Create channels that reflect distinct message types or user choices, and give each a name people can understand in system settings. Users control which channels are visible or intrusive, so channel design is part of the notification strategy, not just an implementation detail.

Choose channel behaviour carefully: after a channel is created, its importance and other notification behaviours cannot be changed by the app. Users can change those settings themselves. This makes it important to avoid putting unrelated messages with different urgency or value into one channel.

Best practices for notification channel design on Android

Set delivery rules

Give each message type a trigger, eligible audience, suppression rule and expiry. Suppress a reminder after its task is complete. If several events describe one changing state, consider showing the latest state instead of sending stale intermediate updates.

Set an initial limit for deferrable messages, then review it by category and by the total number one person receives. A global cap can block a useful urgent update while allowing too many low-value messages. Schedule non-urgent updates for the recipient’s local time where it is known.

Check notification readiness before sending

Apple says apps that display alerts, play sounds or badge their icon must configure notification support before scheduling notifications. The configuration should be completed before the app finishes launching; if it happens later, do not schedule notifications until it is complete.

Measure value and attention cost

Define the action that would show each message helped, such as viewing a revised booking or completing a time-sensitive task. Review that action alongside attempts to send, opens and observable changes in notification preferences. An open shows interaction, not value.

Read provider reports using their own definitions. Investigate changes by message type, audience and app version before changing the whole program.

Interpret platform reports carefully

Firebase Cloud Messaging distinguishes several stages: a message marked as sent may have been queued for delivery or passed to another service, while received data is available only for Android devices with FCM SDK version 18.0.1 or later.

Its impressions metric is for Android notifications displayed while the app is in the background, and reported opens cover notifications received while the app was in the background.

Firebase says some report statistics may be delayed by up to 24 hours because analytics data is processed in batches; sent-message statistics may also be delayed by several hours. Avoid treating a recent reporting gap as evidence that a message failed, and compare like with like when reviewing performance across platforms.