Onboarding That Matches the Ad
Updated 24 Oct 2026
Your growth team writes five creatives, each promising something different, because that is how paid acquisition works: you find out which promise lands by making several. Then every person who believed one of those five promises opens the app and gets the same first screen.
That gap is not a conversion-rate inefficiency. It is the app silently contradicting the thing that convinced someone to install it, during the thirty seconds when they are deciding whether they were fooled.
The Promise Is Made Before the App Opens
By the time a person reaches your first screen they have already read a headline, seen a screenshot, and decided what this app is for. They arrive with an expectation that is specific and that your product never agreed to. Whatever they do next is measured against it.
A single onboarding flow is a reasonable thing to have when there is one promise. The moment you run several store pages or several creatives, you have taken on several promises, and the generic flow is the one answer that is slightly wrong for all of them.
Acquisition buys attention with a specific promise. Onboarding is the first chance to keep it or break it — and a single flow cannot keep more than one.
Where the Promise Breaks
- The first screen answers a question they did not ask. They came for one job. A generic tour starts by explaining four, and the one they wanted is third.
- The vocabulary changes at the door. The ad said "meal plans". The app says "collections". Both are fine words; meeting the second one first costs the user a translation step.
- The proof is missing where it mattered. If the creative won on one screenshot, that screenshot is the thing to show first. A generic flow buries it.
All three have the same shape: the user is asked to do work that the ad already did. And all three are invisible in an aggregate funnel, because the aggregate averages the cohorts that were served well with the ones that were not. Split your onboarding completion by where people came from before you decide whether you have this problem.
Something Has to Know Where They Came From
This is the dependency that decides whether the idea is available to you at all. Amply does not do attribution. It reads attributes your app has written and picks a flow accordingly, which means the entry point has to be known, named, and written down before the first session is evaluated.
Your attribution SDK, or the parameters on the store page that brought the install, supply the answer. Your app turns that into one attribute:
// Android (Kotlin). Write it before the first session is evaluated.
amply.setCustomProperties(mapOf(
"entry_point" to entryPoint // resolved from your attribution SDK
))Two practical consequences follow, and they are the reason to read this section before promising anything to the growth team. First, attribution is not instant on every install, and a flow chosen a second too late is the generic flow. Second, organic installs have no entry point at all, so the plan needs a flow for people who arrive with no answer — and that flow is the one most of your users will see.
The routing itself is a deeplink into a flow your app already contains, in the same way deeplinks drive feature discovery later in the life of an account. New flows still arrive in releases; the choice between existing ones does not.
How Many First Screens Are Worth Having
Not one per creative. Creatives are cheap and flows are not: each one is a surface to translate, test on real devices, and keep correct through every future redesign. Group them by the promise instead.
Most apps find that five creatives collapse into two or three distinct promises, plus the default. The test for whether two creatives need separate flows is whether the first thing you want the user to do is different. If the first action is the same and only the wording differs, change the wording.
Decide the retirement rule at the same time. Creatives are replaced monthly; a flow that no live creative points at is dead code that still has to be maintained, and nobody notices it for a year.
When One Flow Is the Right Answer
Plenty of products should not do this, and the honest signals are easy to check. If every source sells the same promise, routing adds maintenance and nothing else. If paid acquisition is a small share of your installs, the default flow is the product and that is where the effort belongs. If you cannot yet split onboarding completion by source, you have no way to tell whether a routed flow helped, and you would be shipping on taste.
When you do run it, measure each flow against the default one rather than against each other, and watch the step people abandon inside each flow. A segmented flow that does worse than the generic one is the most useful result this work produces: it means the creative and the product disagree about what the app is for, which is worth knowing long before onboarding is the problem you are solving.
The division of labour, plainly: your attribution tool answers where someone came from, your app writes that down and draws the screens, and Amply chooses which flow this session gets — and only ever between flows the installed version already has. For the configuration, entry-based onboarding routing, configured has the campaigns, the fallback and the engineering hand-off.