Personalisation can make a push notification feel helpful or make it feel like surveillance. The difference is rarely the presence of data alone. It is whether the message is expected, proportionate, transparent and easy to control.
For developers and product teams, the challenge is to turn available signals into useful decisions without exposing sensitive information or creating the impression that the product knows too much. This requires more than inserting a user’s name into a template. It means designing a clear relationship between consent, data collection, audience selection, message content, timing and user control.
This guide explains practical ways to personalise push notifications while protecting trust.
Start with user benefit, not available data
A common mistake is to begin with the question, “What data can we use?” A better starting point is, “What useful action or information can we provide?”
Personalisation is justified when it helps a recipient understand or complete something relevant to them. Examples include:
- A reminder about an item the user deliberately saved
- A status update about an action they initiated
- A notification about a subscribed topic or chosen category
- A message adjusted to the user’s language or time zone
- A prompt based on a preference the user explicitly selected
Avoid personalising simply because a signal exists. Browsing history, approximate location, purchase history and inferred interests may all be technically available, but that does not automatically make them appropriate notification inputs.
A useful test is whether the recipient would reasonably expect the product to use the signal in this context. If the answer is uncertain, use a less specific message, ask for permission, or leave the signal out.
Make consent meaningful
Permission to send notifications is not blanket permission to use every piece of personal data for every message. Treat notification permission and personalisation permission as related but separate decisions.
Your onboarding and settings should explain:
- What types of notifications the user can receive
- Why each category may be useful
- Which preferences can be changed later
- Whether personalisation uses explicit choices, account activity or another source
- How to stop notifications entirely
Avoid bundling essential service updates with promotional or behavioural notifications. A user may need delivery or security alerts but not marketing messages. Separate categories allow people to make a more informed choice and reduce the risk of over-messaging.
Consent should also be reflected in system design. Store notification preferences in a form that can be checked before sending, rather than relying on a preference captured only in the interface. If a person opts out, the change should apply promptly across relevant devices and delivery paths.
Prefer explicit preferences over sensitive inference
The safest personalisation often comes from information the user knowingly provides. A selected interest, preferred delivery time or followed topic gives your team a clear reason for sending a message.
Inferred attributes require more caution. Do not assume that a user’s reading, browsing or purchase behaviour gives you permission to reveal sensitive conclusions in a lock-screen notification. Even an accurate inference can be uncomfortable when displayed out of context.
For example, a notification that names a medical condition, financial difficulty, relationship status or political interest may expose information to anyone who can see the device. The same concern applies to messages that reveal a purchase, appointment or account activity that the recipient may want to keep private.
When the underlying subject is sensitive, keep the notification generic and require the user to open the app for detail. Consider both the intended recipient and other people who may see the lock screen.
Use progressive disclosure in message content
A push notification has limited space and limited privacy. Put the minimum useful information in the notification, then provide additional context after the user opens the product.
Compare these approaches conceptually:
- Specific: “Your appointment about your condition is tomorrow at 10:00.”
- More discreet: “You have an appointment tomorrow at 10:00. Tap to view details.”
The appropriate wording depends on the product and the user’s settings, but the principle is consistent: do not place unnecessary sensitive detail in a channel that may be publicly visible.
Personalisation should make the message clearer, not more intimate than necessary. A name can be useful in some transactional contexts, but adding a name to every message can feel artificial. In many cases, a relevant object, task or preference is more useful than a greeting.
Keep targeting explainable
Before sending, your team should be able to answer three questions:
- Why is this person receiving the notification?
- Which data or preference selected them?
- How can they stop receiving similar messages?
This does not require exposing internal rules in every notification. It does require maintaining an understandable audience model and documenting it for support, product and engineering teams.
Server-side notification systems commonly support targets such as a device, user, tag, segment or all enabled devices. Each targeting method has different implications. A user target can be appropriate for account-level updates across devices. A device target may suit a device-specific action. A segment or tag can support a preference-based audience, but only if membership is accurate and current.
Be cautious with broad targets. “All enabled devices” should be reserved for genuinely universal, important messages. A message that is relevant to one segment can quickly become intrusive when sent to everyone.
Design frequency and timing controls
A relevant notification can still be annoying if it arrives too often or at the wrong time. Personalisation should include delivery policy, not just message wording.
Set limits by category and consider a quiet period or preferred delivery window. Transactional events may need immediate delivery, while recommendations, reminders and promotional messages can often wait. If users can select a preferred time, respect that preference unless there is a clear reason not to.
Frequency limits should account for multiple campaigns and product areas. A user does not experience separate teams; they experience one product. Use a shared record of recent sends, categories and suppression decisions where appropriate.
Also plan for bursts. A user may trigger several events in quick succession, or an upstream system may retry a request. Group related updates where possible, and ensure that a delivery retry does not become an accidental duplicate notification.
Build reliable delivery safeguards
Personalisation depends on correct identity and device state. A stale device token, duplicated identity or outdated segment membership can turn a well-designed message into a privacy and relevance problem.
For server-side sends, HoneyNotify uses POST /v1/notifications with a Bearer API key and an Idempotency-Key. A notification requires a title, body and target. Use idempotency when retrying requests so an uncertain network response does not lead to duplicate sends.
Client SDKs cover device registration, identity, token lifecycle, payload handling and lifecycle events across iOS, Android and Web Push. Integrate token refresh and identity changes as normal application events, not as an occasional maintenance task.
If you are migrating from another provider, imported OneSignal subscription IDs can remain as device IDs when matching provider tokens later register. However, token rotation or another provider environment can prevent matching. Treat migration as an identity reconciliation problem: monitor registration outcomes, handle unmatched devices, and avoid assuming that an imported identifier will always map to a future token.
Give users visible control
A trustworthy notification experience makes control easy to find. Provide settings that let people:
- Enable or disable categories
- Change frequency or delivery windows where supported
- Pause notifications temporarily
- Adjust privacy or lock-screen detail
- Review and remove relevant interests or subscriptions
- Unsubscribe from promotional messages without losing essential updates
Do not make the only control the operating system’s global permission switch. That switch is important, but category-level controls help users keep the notifications they value.
Respect the user’s action immediately and consistently. If an unsubscribe action is processed asynchronously, show the current state clearly and prevent new eligible sends while the change is being applied.
Measure usefulness without rewarding intrusion
Open rates alone are a weak success measure. A notification can attract a tap because it is urgent, confusing or overly personal. Combine engagement data with negative signals and longer-term outcomes.
Useful measures may include:
- Opt-out and permission withdrawal rates
- Notification dismissals or disabled categories
- Repeated opens versus one-off taps
- Completion of the intended task
- Complaints or support contacts
- Delivery failures and duplicate sends
- Retention after receiving a notification
Compare variants carefully. A more specific message may increase immediate engagement while reducing trust later. Establish privacy and frequency guardrails before testing copy, and stop experiments that create a clear increase in unwanted notifications.
Common mistakes
Using a name as a substitute for relevance
A name does not make an irrelevant message useful. First improve targeting, timing and content. Use names sparingly and only where they serve a clear purpose.
Revealing inferred or sensitive information
Do not expose a sensitive conclusion in a lock-screen message merely because your model predicts it. Use neutral copy and require an intentional open for details.
Treating permission as permanent consent
People’s expectations change. Revisit preferences, honour opt-outs and make category controls understandable.
Sending from disconnected systems
Separate teams can accidentally exceed a reasonable frequency when they do not share suppression and send history. Coordinate campaign rules and transactional messaging.
Ignoring identity and token changes
A notification can be correctly targeted in your database but delivered to the wrong device state or not delivered at all. Handle registration, token lifecycle and identity changes continuously.
A practical review checklist
Before launching a personalised notification, ask:
- What user benefit does this message provide?
- Did the recipient expect this type of notification?
- Is the targeting based on an explicit preference or a proportionate signal?
- Could someone else see sensitive information on the lock screen?
- Is the timing appropriate and within frequency limits?
- Can the recipient stop or change similar messages easily?
- What happens if identity, token or segment data is stale?
- How will we detect duplicate, unwanted or harmful sends?
Conclusion
Personalised push notifications work best when personalisation reduces effort rather than increasing intimacy. Use clear preferences, restrained content, explainable targeting, reliable identity handling and strong user controls. When a message might reveal more than the recipient expects, make it less specific and let the user choose whether to see the detail. Relevance earns attention; respect keeps it.