# Segment scenarios, not just your user base

- **Canonical URL:** https://playbook.affpartners.io/en/practices/push-segments/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/push-segments/index.md
- **Module:** Push notifications
- **Time:** 90 minutes for the first segments

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.

## Outcome

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

## 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

- **Events:** The date of the last useful action, journey start and completion, a confirmed interest, and notification permission.
- **Segment builder:** A communication system that shows group size and lets you set entry, exit, and mutual-exclusion rules.
- **Test profiles:** At least one profile per segment, plus one for the overlap, to check the rules before launch.

## Terms in plain language

- **Push notification — A short app message shown outside the app:** Definition: It appears on the device and can return a user to one specific useful action. It is sent only when the user has granted notification permission. Example: A message about a new item in a saved topic opens that item through a deep link.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.

## 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.

## 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**
  - **Source:** Use journey completion, how recent the last useful action is, saved interests, and results already viewed.
  - **If access is unavailable:** Without full analytics, start with one reliable server-side status and the last activity date.
- **Size and overlaps**
  - **Source:** Before launch, check the number of users in each group and how many fall into two scenarios at once.
  - **If access is unavailable:** Export the IDs of three simple groups into a table and look for duplicates.
- **Language and availability**
  - **Source:** Check language and country only when the scenario really differs, plus the permission for the channel.
  - **If access is unavailable:** If localization is not ready, limit the launch to one supported audience instead of auto-translating.

## Build the first segments

1. **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.
   - **Example:** Started verification in the last 24 hours and has not finished it yet.
2. **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.
   - **Example:** An unfinished journey, an active user with a saved interest, and a long-inactive user with a new relevant reason.
3. **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.
   - **Example:** The completion event removes the user from the reminder immediately.
4. **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.
   - **Example:** The new user continues the journey, the active one opens new material, the inactive one sees only a real change.
5. **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.
   - **Example:** 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.

## 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.

## Safety and constraints: 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.

## Key rule

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

---

- [HTML version](https://playbook.affpartners.io/en/practices/push-segments/index.html)
- [All practices](https://playbook.affpartners.io/en/)