Practice 03.04 · Push notifications

Segment scenarios, not just your user base

A segment is useful only when it changes a decision: who to message, why now, what to say, or where to send them. Start with three behavioral groups, not dozens of demographic filters.

Practice outcomeA three-segment matrix with precise entry and exit rules, distinct value, message, route, and exclusions.

90 minutes for the first segments

In plain language

A segment is not a label but a rule for a different scenario

“New,” “active,” and “inactive” are too generic until actions and time windows are attached. A good segment is testable: started the journey within 24 hours, saved a topic within 30 days, completed the action and must no longer get the reminder.

What you will need

EventsThe date of the last useful action, journey start and completion, a confirmed interest, and notification permission.

Segment builderA communication system that shows group size and lets you set entry, exit, and mutual-exclusion rules.

Test profilesAt least one profile per segment, plus one for the overlap, to check the rules before launch.

Terms in plain language

When to use it

Mass pushes produce few useful actions, people get irrelevant messages, and the team cannot explain why a given user received one.

In plain language

Which data to use

Take only data that actually changes the message's value or route. Do not collect sensitive attributes without need.

Product behavior

Use journey completion, how recent the last useful action is, saved interests, and results already viewed.

Without full analytics, start with one reliable server-side status and the last activity date.

Size and overlaps

Before launch, check the number of users in each group and how many fall into two scenarios at once.

Export the IDs of three simple groups into a table and look for duplicates.

Language and availability

Check language and country only when the scenario really differs, plus the permission for the channel.

If localization is not ready, limit the launch to one supported audience instead of auto-translating.

Build the first segments

Start from behavior

Describe an action and a time window that show the user's current context. Avoid abstract labels like “loyal” or “dormant.”

Where to do it: In the communication system's segment conditions.
What the result looks like: Started verification in the last 24 hours and has not finished it yet.

Choose three different scenarios

Take groups whose return reason and screen actually differ. Do not split the base just to personalize the greeting.

Where to do it: In the first three rows of the matrix.
What the result looks like: An unfinished journey, an active user with a saved interest, and a long-inactive user with a new relevant reason.

Define entry and exit

The segment must refresh automatically. After completing the action or losing relevance, the user leaves before the next send.

Where to do it: In the recalculation rules before launch.
What the result looks like: The completion event removes the user from the reminder immediately.

Give each group its own route

The difference must go beyond the name. Set a distinct value, copy, and deep link into the right context.

Where to do it: On each scenario's card.
What the result looks like: The new user continues the journey, the active one opens new material, the inactive one sees only a real change.

Resolve the overlaps

Decide in advance which message survives when a user matches several rules. Check the overlap on a test profile.

Where to do it: In the priorities and mutual exclusions.
What the result looks like: A service status outranks a content reason; the second message is held for 24 hours.

Practical examples

Three groups — three different routes

The unfinished user continues the saved step, the active one opens new material for their interest, and the long-inactive one hears only about a real update.

The overlap is resolved before the send

The user matches both a service status and a content reason. The more important status survives; the second message is held for 24 hours.

The finished artifact

A matrix of three segments

If two rows lead to the same copy and screen, merge them — a separate segment is not needed.

Segment	Condition	Value and route	Exit / exclusion
New, journey unfinished	Started the journey <24 h ago, no completion event	Continue the step → saved screen	Exits after completion
Active with an interest	Saved a topic <30 days ago	New material → collection	Exclude those who already read it
Long inactive	No useful actions for 14 days	A real update only → the change screen	No messages without a new reason
Recently active	Useful action <12 h ago	No message needed	Excluded from return pushes
Overlap	Matches 2 scenarios	Keep the more useful one	One push, by priority

Start with three scenarios and one overlap rule. Add a new group only when its moment, value, or screen genuinely differs.

Do not build segments for their own sake

If a group does not change the moment, the value, or the route, it only complicates the work and multiplies rule errors.

Segment checklist

Anyone on the team should be able to explain from the data — not by guessing — why a specific user is in the segment.

Entry and exit conditions are described with events and time windows. The segment changes the moment, the value, the copy, or the destination screen. Group sizes are known and the source data is quality-checked. Language, channel availability, and only the necessary attributes are used. Overlapping segments have a priority and one final message.

How to know segmentation helps

Accuracy

Test and real profiles land in the expected group and leave it once the action is complete.

Value

The target action after the tap grows in the specific segment compared with the generic message.

Risks

Overlaps, repeat messages, opt-outs, and complaints inside individual groups do not grow.

Start with three segments and add a new one only when it truly needs a different scenario.