Push notifications are most useful when they reach people who have a clear reason to act. Segmentation is the process of selecting an audience using signals such as identity, device, behaviour, subscription state, or product context. Done well, it makes messages more relevant without forcing every user into a different campaign.

Done poorly, segmentation creates stale audiences, confusing delivery logic, privacy risks, and a notification experience that feels intrusive. The goal is not to create as many segments as possible. It is to define a small set of dependable audiences, connect each one to a legitimate use case, and keep membership accurate over time.

Start with the notification objective

Before choosing a segment, define what the notification is meant to achieve. A transactional alert, a product reminder, and a promotional message have different targeting requirements.

  • Transactional notifications should normally target the user or device associated with an event, such as a completed payment or a change to an order.
  • Behavioural notifications can target users who have taken, or not taken, a meaningful action within a defined period.
  • Content notifications can target users who have opted into a topic, followed an account, or belong to a relevant interest group.
  • Operational notifications may target a region, service tier, workspace, or affected installation.

The objective should determine both the audience and the message. Avoid beginning with a convenient technical property, such as a tag, and then searching for a reason to use it. That approach often produces segments that are easy to create but difficult to justify or maintain.

A useful test is to complete this sentence: “This notification is relevant to people who…” If the answer is vague, the segment probably needs a clearer definition.

Choose the right targeting level

Push systems commonly support several targeting levels. HoneyNotify targets may address a device, user, tag, segment, or all enabled devices. Each level has a different operational meaning.

Device targeting

Device targeting is appropriate when the event belongs to one installation or when a user may have separate delivery preferences by device. It can also be useful during token registration and troubleshooting.

The drawback is that device records change. Tokens can rotate, apps can be reinstalled, and a person may use several devices. Device-level targeting should not be your only representation of a person if the notification concerns their account or activity across devices.

User targeting

User targeting is usually a better fit for account-related events and preferences. It allows the delivery layer to address a person across their registered devices, provided your identity mapping and opt-in rules are correct.

Define what happens when a user has multiple devices, disabled notifications on one device, or signed out. The product decision should be explicit rather than left to an accidental property of the delivery implementation.

Tags and segments

Tags are useful for simple, reusable attributes, such as a selected topic, workspace, plan category, or language. A segment is more suitable for a named audience with a defined purpose, such as “users who saved a report but have not opened it this week”.

Use tags for relatively stable facts and segments for combinations of conditions or campaign audiences. If a tag is being added and removed through complicated workflows, it may actually be a segment or a database attribute that deserves stronger ownership and validation.

Targeting all enabled devices should be reserved for genuinely broad messages where every recipient has a reasonable expectation of relevance. It should not be used as a shortcut for missing audience logic.

Build segments from reliable signals

A segment is only as good as the data behind it. Prefer signals that are explicit, current, and connected to a product decision.

  • Identity: account ID, team membership, role, or authenticated state.
  • Preference: selected topics, notification categories, language, or communication consent.
  • Behaviour: a completed action, an abandoned workflow, or recent product activity.
  • Context: location, time zone, device type, app version, or service status where appropriate.
  • Lifecycle: newly registered, active, dormant, trial, subscribed, or recently reactivated.
  • Delivery state: enabled devices, invalid tokens, and the last known registration state.

Record the source and meaning of each signal. “Premium” may mean a current subscription, a historic purchase, or a manually assigned support status. Those interpretations produce different audiences and should not share an ambiguous field.

Time windows also need careful definition. “Active recently” should specify the event, duration, time zone, and whether repeated activity counts once or many times. Store timestamps in a consistent format and evaluate them against a defined business time zone where the message depends on local time.

Design a segment model that can be maintained

Create a short specification for every production segment. It should state:

  • The segment name and business purpose.
  • The exact inclusion and exclusion rules.
  • The source systems and fields used.
  • The owner responsible for reviewing it.
  • The refresh method and expected freshness.
  • The notification types allowed for the audience.
  • The exit condition, such as conversion, expiry, opt-out, or account closure.

Exclusions are as important as inclusions. A re-engagement audience may exclude users who have already completed the relevant action, opted out of that category, or received the same message recently. Without exclusions, repeated sends can damage trust even when the original targeting rule was sensible.

Prefer composable rules over a large collection of nearly identical segments. For example, maintain clear attributes for language, topic preference, and account state, then combine them when a campaign requires it. This reduces duplication and makes changes easier to review.

Keep identity and device data in sync

Segmentation often fails at the boundary between product data and notification infrastructure. A user may qualify in your database, but delivery still depends on a current device registration, a valid token, and an enabled notification state.

HoneyNotify client SDKs cover device registration, identity, token lifecycle, payload handling, and lifecycle events across iOS, Android, and Web Push. Use those lifecycle events to keep registration data current rather than treating the first token received as permanent.

If you migrate from another provider, validate identity and device matching before relying on imported records. Imported OneSignal subscription IDs can remain as device IDs when matching provider tokens later register, but token rotation or another provider environment can prevent matching. Plan for unmatched records, re-registration, and environment differences instead of assuming that an imported ID guarantees future delivery.

Your application should also define what happens when a user signs out, changes account, reinstalls the app, or uses multiple browsers. A stale association can send a private or account-specific notification to the wrong person. Identity transitions deserve the same attention as initial registration.

Send safely from the server

Audience selection should happen in a trusted server-side workflow. The server can verify permissions, apply suppression rules, render appropriate content, and record the reason for the send before calling the notification provider.

HoneyNotify server-side sends use POST /v1/notifications with a Bearer API key and an Idempotency-Key. A notification requires a title, body, and target. Use an idempotency key that represents the intended send operation so a retry does not unintentionally create a duplicate notification.

Keep targeting logic separate from message composition. First produce an auditable audience or target decision, then construct the notification payload. This makes it easier to test whether the right people were selected without confusing a targeting defect with a copy or payload defect.

Do not put secrets, private customer data, or unrestricted targeting controls in client-side code. If a client can freely choose a segment, it may be able to send messages beyond its intended authority.

Test segments before sending

Use a controlled validation process for every new or changed segment.

  • Inspect representative included records and ask why each qualifies.
  • Inspect near-misses that should be excluded.
  • Check users with multiple devices and recently changed identities.
  • Test empty, very small, and unexpectedly large audiences.
  • Verify opt-outs, quiet hours, regional rules, and frequency limits.
  • Send to an internal or test audience before production delivery.
  • Record the segment definition and estimated audience at send time.

For event-driven notifications, test duplicate events, delayed events, retries, and out-of-order updates. A segment or trigger that is correct in a clean test can behave differently when real systems deliver the same event more than once.

Measure more than delivery. Depending on the use case, review opt-out rates, notification opens, downstream actions, dismissals, and complaints. A high interaction rate does not automatically mean the audience is healthy if recipients are receiving too many messages or cannot control the category.

Common segmentation mistakes

Treating every user as a marketing audience

A person may have enabled push notifications for security or order updates without agreeing to unrelated promotions. Separate notification categories, preferences, and lawful communication requirements in your product design.

Using stale membership

A user who completed an action yesterday may no longer belong in a reminder segment. Refresh time-sensitive conditions and include an exit rule in the workflow.

Over-segmenting too early

Do not create a separate audience for every conceivable combination. Start with segments that support a clear product or operational decision, then add detail when evidence shows that a broad audience is unsuitable.

Ignoring the device lifecycle

Expired tokens, reinstalls, browser changes, and disabled permissions can make a technically valid audience undeliverable. Treat registration and token updates as ongoing processes.

Sending without idempotency or audit data

Retries and background jobs can duplicate messages. Record the operation, target decision, idempotency key, and outcome so incidents can be investigated.

Conclusion

Effective push segmentation combines a clear notification purpose, dependable audience signals, explicit exclusions, current identity data, and disciplined server-side delivery. Begin with a small number of understandable segments, document their rules, test edge cases, and review their performance and freshness. Relevance is not created by complex targeting alone; it comes from connecting the right message to a justified, current audience.