Entry-based onboarding routing

Route users into different onboarding flows based on the Custom Product Page or ad creative that brought them in — no release required.

Use this when you run multiple CPPs or ad creatives and each one promises a different first-run experience. Don't use this when every acquisition source leads to the same product promise; routing adds noise without payoff.

Goal

Ads sell one thing, the app opens into another. If CPP A promises "meal planning in 30 seconds" and CPP B promises "calorie tracking for athletes," the generic onboarding flow breaks the promise for both. This recipe splits onboarding by entry point so each cohort sees the flow that matches the creative they clicked.

Setup

In the dashboard

• Create one campaign per entry point. Name them after the CPP or creative ID: onboarding-cpp-meal-planner, onboarding-cpp-athlete, onboarding-default.

• Trigger: session start, first session only.

• In the conditions editor, gate each campaign on an attribute that identifies the source (for example, acquisition_source = "cpp_meal_planner").

• Action: show the matching onboarding deeplink (yourapp://onboarding/meal-planner, etc.).

• Make onboarding-default the fallback with the broadest audience — no source condition at all — so organic installs (with no acquisition_source value) match it while the narrower, source-gated campaigns match their own cohorts.

• Publish all three at once so first-session users always match exactly one.

In the app (engineering hand-off)

• On install, read the entry-point hint from the attribution SDK or the CPP query string and write it as a user attribute:

  amply.setCustomProperty(key: "acquisition_source", value: "cpp_meal_planner")

• Register a deeplink handler that maps yourapp://onboarding/<flow> to the corresponding in-app flow controller.

• Call setCustomProperty before the first session starts so the first campaign evaluation sees the right value.

How it runs

1. User taps an ad, lands on CPP A, installs the app.

2. App boots, SDK initializes, attribution library resolves the source, app writes acquisition_source = "cpp_meal_planner".

3. Session starts. Amply evaluates candidate campaigns. The narrower acquisition_source condition on onboarding-cpp-meal-planner matches this user; the broader onboarding-default would also match but is selected only when no narrower campaign does.

4. Amply fires the deeplink yourapp://onboarding/meal-planner. The app routes into the meal-planner flow.

5. User finishes onboarding. Subsequent sessions evaluate again — the campaign is first-session-only, so it does not fire again.

6. A user who installs organically matches no source and falls through to onboarding-default.

Metrics to watch

• Onboarding completion rate, split by acquisition_source. Expect the segmented flows to beat the generic one by 10-25%.

• Trial-start rate in the first 24 hours, again split by source.

• Drop-off step within each flow. If a segmented flow is worse than the default, the creative and the flow are misaligned.

• Deeplink resolve success rate. A sudden drop means the app is not handling one of the new URLs.

Related

• Creating a campaign — building the campaigns used here

• Targeting an audience — how the source condition is expressed

• Managing deeplinks — registering the onboarding routes

• User attributes — why acquisition_source belongs on the user, not the event

• Handling deeplinks — the deeplink listener on the SDK side

• AI-assisted integration — describe this campaign in plain language and have your AI assistant build it