Personalized app onboarding means acting on what users tell you, not just collecting it. Most onboarding flows ask about goals, experience level, or use case, then show every user the same screens anyway. The gap between asking and acting is where personalization lives. There are three levels: reflect answers back in your copy, branch the flow so different users see different paths, and target entire flows at segments defined by attributes and events. Each level takes more setup and pays off differently. Here is how to build all three.
Why asking without acting backfires
Users notice when a question goes nowhere. If screen two asks 'What brings you here?' and screen three is identical for everyone, the question was a survey for your team, not a service to the user. That is worse than not asking at all: you spent taps and attention, and you signaled that the answers do not matter.
The fix is a simple rule: never ask a question whose answer changes nothing the user can see. Every question in your onboarding flow should alter the copy, alter the path, or alter what the user is shown later. If it does none of those, cut it or move it to an in-app survey after activation. The rest of this post maps the three ways an answer can change the experience, from cheapest to most structural, with the concrete mechanics behind each one.
Level 1: reflect answers back in your copy
The cheapest personalization is reflecting what you already know into your copy. In Setgreet this is done with Variable Bindings: write {{user.firstName}} or {{user.goal}} into any string property of a screen, including text, button labels, and image URLs, and mix bindings with static text freely. The user. prefix pulls attributes set through the SDK's identifyUser call; the event. prefix reads properties of the event that triggered the flow. Dot notation reaches nested paths, and pipe modifiers format values: dates, currency, uppercase, and more, with currency and numbers formatted for the user's locale.
Two details matter in practice. First, resolution happens on the server when the flow is fetched, so the device receives finished text and a raw {{...}} token never reaches the screen. Second, set a fallback value on every visible binding. A missing attribute resolves to the fallback if you set one, and to an empty string if you did not, so 'Welcome back, {{user.firstName}}' renders as 'Welcome back, ' for a user you have not identified yet. Write copy that still reads well when the fallback shows. The personalization docs cover the full syntax.
Level 2: branch the flow on answers
Reflected copy is nice; a different path is persuasive. Level 2 branches the flow on the answer itself. In Setgreet's flow builder, a Branch node maps each option value of a question to a different sequence of screens: a fitness app can ask 'What is your goal?' on a RadioGroup and route strength, weight loss, and mobility users to different feature tours. Branching works with the branchable components: RadioGroup, NPS, Rating, Dropdown, Checkbox, and Button.
The compounding trick is Save to Attribute. Enable it on a Branch node and the response is persisted as a user attribute, so the answer outlives this flow: future flows can bind it into copy, trigger on it, and build segments from it. One honest caveat: an answer captured mid-flow is not automatically available to later screens of the same flow, so treat Save to Attribute as an investment in every flow after this one, not as a way to echo the answer two screens later.
Level 3: target entire flows at segments
Levels 1 and 2 personalize inside one flow. Level 3 decides who gets a flow at all. Segments are reusable, app-scoped user groups built in the condition builder, and they evaluate dynamically: when a user's attributes change, their segment membership follows. Flow Triggers then combine segments and further conditions on user attributes and event properties with AND/OR logic, using operators like equals, contains, startsWith, and greaterThan across strings, numbers, booleans, and dates. When several flows match the same user, the highest-priority flow wins, so a general onboarding can sit underneath segment-specific flows without conflicts.
This is where answers you saved at Level 2 pay rent. A goal answer saved during onboarding becomes a segment you can target next month with a goal-specific announcement or a tailored upgrade prompt. And because flows publish to live apps without an App Store release, adding a segment-targeted flow is a dashboard change, not a build.
Only personalize what users can notice
Personalization has a cost: more paths to write, translate, and maintain. It only pays when the differences are visible to users. If your strength and mobility branches differ by one adjective, you bought complexity and shipped nothing anyone can perceive. Before you branch, name the thing each segment will see that the others will not. If you cannot, use a binding instead of a branch, or skip it entirely.
Monetization is a useful test case, because expectations genuinely differ by audience. Directional estimates from a July 2026 snapshot of PaywallPro's public Open Paywall Gallery dataset of 910 top iOS subscription apps suggest about 77% of Business apps lead their paywall with a trial, versus roughly 24% of Entertainment apps. If your app serves audiences that different, how you frame the offer is a visible, consequential difference worth branching on. Then verify: treat each personalized path as a hypothesis and A/B test it against the generic version before you scale the pattern.
Frequently asked questions
What happens if a user attribute is missing?
The binding resolves to its fallback value if you set one, and to an empty string if you did not. The raw {{user.firstName}} token is never shown, because bindings are resolved on the server before the screen reaches the device. The practical rule: give every user-visible binding a fallback, and write the sentence so it reads naturally when the fallback appears, for example 'Welcome, {{user.firstName}}' with a fallback of 'there'.
Can I personalize onboarding for anonymous users?
Partially. Anonymous users cannot carry custom attributes, so attribute-based bindings and segment targeting require an identified user via the SDK's identifyUser call. What still works is in-flow branching: an anonymous user can answer a question and be routed down the matching path in the same session. To unlock the other two levels, call identifyUser as early as your signup allows so later flows can bind and target on real attributes.
Do I need a separate flow for every segment?
No, and you usually should not start there. Begin with one flow that uses bindings for names and goals, add a Branch node where paths genuinely diverge, and reserve fully separate segment-targeted flows for cases where most of the content differs, like new users versus returning upgraders. Because the highest-priority flow wins when several match, you can keep a generic flow as the default and layer segment-specific flows above it as each one earns its maintenance cost.