The segments that matter for a mobile app are the ones that change what a user sees: new vs returning, free vs trial vs paid, activated vs not, feature-discovered vs not, and lapsed. A segment used only as a dashboard filter is trivia. A segment used as a targeting rule decides which onboarding flow runs, which offer appears, and which message gets suppressed. That is the operating rule for this whole topic: every segment you build must have at least one experience consequence, or it is not worth maintaining.
Why dashboard filters are not segmentation
Every analytics tool lets you slice a chart by user properties. That is filtering, and it is useful for diagnosis: it tells you that trial users churn more, or that Android users skip a setup step. But a filter never changes anyone's experience. The user who was about to churn sees exactly the same app whether or not you noticed them in a chart.
A segment becomes powerful the moment it is attached to a consequence. Show this flow to this group. Suppress that message for that group. Change the offer for this group. So apply one test before building anything: name the flow shown, the message suppressed, or the offer changed. If you cannot name a consequence, you do not need the segment.
Which segments actually matter for a mobile app?
These five cover most experience decisions a mobile app has to make. Each is defined by data you either already have or can start collecting this week.
New vs returning
The most basic split, and still the most commonly botched. New users need a full onboarding flow: a permission ask with context, a setup step, a fast first win. Returning users need none of that, and showing it again teaches people to skip everything you present. Data needed: a first-seen timestamp or session count, both simple user attributes. Consequence: onboarding targets new users only, and returning users see a what's new screen after a major release, or nothing at all.
Free vs trial vs paid
Subscription state should drive more targeting than any other attribute. Paid users should never see an upgrade prompt: it is noise at best and insulting at worst. Trial users are racing a clock. RevenueCat's State of Subscription Apps 2026, based on over 115,000 apps, found that 55% of 3-day trial cancellations happen on Day 0, so trial targeting should push users to value immediately, not on day two. Data needed: a plan attribute synced from your billing system. Consequence: upgrade prompts target free users only, trial users get a first-day path to the core feature, and paid users get quiet.
Activated vs not
Activation is the moment a user first gets real value: the first workout logged, the first invoice sent, the first project shared. Users who have not reached it are one distraction away from deleting the app. Data needed: one activation event, tracked at the moment it happens. Consequence: non-activated users get a flow that removes whatever stands between them and that moment. Activated users never see it.
Feature-discovered vs not
Feature announcements usually broadcast to everyone, which means people already using the feature get interrupted and people who ignored it once ignore it again. Data needed: a usage event for each feature you care about. Consequence: the announcement targets only users who have never fired that event, and it stops appearing for a user the moment they do.
Lapsed
A user who has not opened your app in two weeks is a different audience from one who opened it yesterday, and what counts as lapsed depends on your category's natural usage rhythm. Our retention benchmarks post covers how to pick that threshold. Data needed: a last-active timestamp updated each session. Consequence: when a lapsed user returns, they get a welcome-back flow or a win-back offer instead of a home screen that assumes daily context.
What data does each segment need?
Every segment above reduces to one of two data shapes. User attributes are facts about who the user is: plan, signup date, role, goal. In the Setgreet SDK you set them with identifyUser, which merges new attributes into what is already stored, so you can add facts over time without resending everything. Events are facts about what the user did: workout_completed, invoice_sent, feature_opened, sent with trackEvent. New vs returning and free vs trial vs paid are attribute segments. Activated, feature-discovered, and lapsed are behavioral, built on events.
Two catches. First, anonymous users cannot carry custom attributes, so call identifyUser as early as your auth flow allows. Second, some attributes live in no system you own: the user's goal, their role, why they downloaded the app. Ask for those in the app. A well-placed in-app survey question with the answer saved back as an attribute turns a one-time response into a permanent targeting input. In Setgreet, Save to Attribute on a Branch node does exactly that: the response becomes a user attribute you can use in segments, triggers, and variable bindings from then on.
How do you turn a segment into a targeting rule?
This is where the operating rule becomes mechanical instead of aspirational. In Setgreet, segments are reusable, app-scoped groups built in the condition builder from user attributes and event conditions. They evaluate dynamically: a user who upgrades leaves the free segment on their own, with no list to maintain. You reference a segment directly in a flow trigger and combine it with other conditions or segments using AND/OR grouping, so "lapsed AND free" is one rule, not a spreadsheet export.
When several flows match the same user, the highest-priority flow wins, so overlaps resolve predictably instead of stacking three prompts on one session. Inside the flow, variable bindings reuse the same attributes to personalize copy, so the segment that decides who sees a screen also shapes what the screen says. And because flows publish to your live app without an App Store release, changing who sees what is an edit, not a release cycle.
Frequently asked questions
How many segments does a mobile app actually need?
Fewer than you think. The five here, new vs returning, free vs trial vs paid, activated, feature-discovered, and lapsed, cover most experience decisions. The constraint is not tooling, it is consequences: every segment needs at least one flow, message, or offer wired to it, and each of those needs upkeep. Start with lifecycle and monetization segments, and add feature-level ones only when a specific announcement or prompt needs an audience.
What is the difference between a segment and a trigger condition?
A trigger condition lives on one flow. A segment is a named, reusable group you can reference from many flows. If a rule appears once, write it as a trigger condition and move on. The moment two flows need the same audience, promote it to a segment so the definition lives in one place, and every flow referencing it follows automatically when the definition changes.
Can you segment anonymous users?
Partially. Events are tracked against an anonymous ID before sign-in, so event-triggered flows can reach users who have not identified yet. Custom attributes require an identified user, so attribute segments like free vs paid only apply after identification. The practical rule: identify users as early as possible, and lean on event-based segments for anything that must work before sign-up.