The first screen keeps the ad's promise.
If the ad promised 20% off, the first screen shows 20% off. The link carries the promise through the install, and the app's onboarding branches on it.
- Who runs it
- Product, marketers
- Time to set up
- One app release
- Plan
- Free
The promise goes in the link.
The campaign link carries the promise in its data: the code, the feature to lead with, the onboarding variant. The campaign tag stays on the link so each variant's results go back to the ad that used it.
- One link per ad set or promise.
- No new app release for a new promise, once the variants exist.
Onboarding that starts where the ad left off.
A new user who tapped a sleep-tracking ad starts onboarding on sleep tracking, with the discount already applied. Nobody has to find the code again.
- Works on iPhone and Android, after a fresh install.
- Users without a promise get your default onboarding.
Sign-ups by promise, back to the ad.
Onboarding completion by variant, then activation by variant, from the events your app sends. A big gap between variants is the case for building more of them.
- Completion and sign-ups per variant.
- Which ads earned their own onboarding.
One-time setup, then it's all yours.
Your developer adds the LinkTrail SDK once and branches onboarding on the link's data. After that, new campaigns reuse the variants you already built.
LinkTrail.onLink(link => {
// link.customData = { promo: "WELCOME50", lead: "sleep-tracking" }
startOnboarding(link.customData.lead, link.customData.promo);
});The full walkthrough: Onboarding that knows where you came from: the first screen matches the ad's promise
Every campaign makes a specific promise — a discount, a feature, a use case — and the generic onboarding flow makes none of them. The person who tapped 'try the sleep tracker' gets the same four screens as the person who tapped 'split bills with friends'. Both learn what the app is. Neither gets what they came for.
What problem does this solve?
The first screen after install should match the ad. If the ad offered a code, the code should already be applied. If it promised a feature, onboarding should lead with that feature. That requires the app to know, at first open, what the user was promised — which is exactly what the payload carries across the install.
How do you set the links up?
The campaign link carries the promise in the payload: the promo code, the feature to lead with, the onboarding variant. The app reads it at first open and branches. The campaign tag stays on the link so the variant's performance attributes back to the campaign that used it.
{
"deepLinkPath": "/onboarding",
"customData": {"promo": "WELCOME50", "lead": "sleep-tracking", "cmp": "meta-sleep-q3"}
}What should branch on the payload?
| Payload says | Onboarding does |
|---|---|
| A promo code | Applies it silently and shows the discount already active on the first paywall |
| A feature | Leads with that feature's setup, and defers the rest |
| A referrer | Names the friend and skips the 'how did you hear about us' step |
| Nothing | The default flow, which is now only for genuinely organic installs |
Why not just show the code on a screen?
Because every step between the promise and the delivery loses people. A code the user has to type is a code some of them mistype and some of them never enter. Applying it from the payload means the discount is a fact by the time they see a price, not a task.
Which metric should you watch?
Onboarding completion by payload variant, then activation by variant. If the sleep-tracking lead-in completes at 70% and the default at 45%, that gap is the case for building more variants — and the campaign tag tells you which ads deserve one.
Which teams own contextual onboarding?
- Mobile product teams
- Growth marketers
Which LinkTrail features does contextual onboarding need?
- Deferred deep linking
- Per-link campaign and creative tagging
- Post-install events
Onboarding questions.
How does onboarding know what the ad promised?
The campaign link carries the promise in its payload — a promo code, the feature to lead with, or the onboarding variant. The app reads it at first open after install and branches, and the campaign tag attributes each variant's performance back to the ad.
What should onboarding change based on the payload?
A promo code is applied silently and shown on the first paywall; a feature leads onboarding; a referrer is named and the 'how did you hear about us' step is skipped. With no payload, the default flow runs for genuinely organic installs.
Why not just show the promo code on a screen?
Every step between the promise and its delivery loses people — some mistype the code and some never enter it. Applying it from the payload makes the discount a fact by the time they see a price.
If you're doing this, you'll probably want these.
Re-engagement ads
Retargeting ads that open the app on the offer they showed, with your imported ad spend set against the results of each campaign.
Launch day
Turn a waitlist into installs that land on the right first screen, not a generic welcome.
Flash sale
A 24-hour deal that opens on the deal, whether the person already has the app or has to install it first. Sales credited to the email, post or ad that sent them.
Make your first campaign link.
Free for your first 5,000 users. No card, no sales call.