Deep Link Button
For engineers routing paid users from the success page into a web or mobile product. You'll have a clear model of what the button puts on the URL and how to handle it downstream. You need a destination URL on your web domain, a universal link on your mobile app, or App Store / Play Store URLs.
What it does#
The Deep Link Button is a funnel component you drop on the success page. It builds a URL from a plain destination plus opt-in contextual values (app_user_id, email, fbp/fbc, Stripe customer ID, etc.) — and any funnel answers you choose to forward — then opens it via funnelRouter.openExternal() when tapped. The button does not use {{template}} interpolation in the destination URL — instead, you toggle which built-in parameters to include and they're auto-appended as query parameters.
The button supports two types: Regular Button (single CTA) and App Store Buttons (Apple + Google Play badges). Both share the same parameter-injection machinery; only the rendering differs.
generateOneLinkURL().Setup#
1. Add the component to your success page#
In the funnel builder, drag the Deep Link Button component from the component library (under Others) onto the page positioned after your paywall (the success page).

Click the placed component to open its configuration panel on the right side of the builder.

2. Set the Destination URL#
Paste your destination — a deeplink scheme, universal link, or web URL — into the Destination URL field. Use a plain URL with no template syntax; contextual values are added in the next step. If the URL is missing https://, the button adds it automatically on tap.
3. Toggle Built-in Parameters#
Toggle on the contextual values you want appended to the URL — App User ID, Email, Funnel ID, etc. See Built-in Parameters below for the full list and per-field source mapping. Each toggle has a configurable key name — rename it if your app expects something different (e.g. customerUid instead of app_user_id).
4. Map URL parameters from the landing page (optional)#
For ad-click identifiers and other params that arrive on the funnel landing page (gclid, fbclid, ttclid, custom ?ref=, etc.), use the URL Parameter Mapping section to forward them onto the destination. See URL Parameter Mapping below.
5. Forward user answers (optional)#
To append answers the visitor gave earlier in the funnel — single-select, multi-select, range, etc. — select them in the Forward Variables section. Each is added as a query parameter keyed by its variable name. See Forward Variables below.
6. Read params in your app or web product#
On the destination side, read the appended query parameters however your platform handles URL params — URLSearchParams in a web page, the deeplink/intent payload in a mobile app, or your deferred deeplink provider's SDK if the URL is a tracker. Use app_user_id as the join key for matching against your backend.
Built-in Parameters#
Every built-in parameter is disabled by default. Toggle the field on (and edit the key name if needed) to include it.
| Field | Default key | Source | Use case |
|---|---|---|---|
| Funnel ID | funnel_id | tracker.funnelId | Server-side funnel attribution |
| Organization ID | organization_id | tracker.organizationId | Multi-tenant routing |
| Campaign ID | af_c_id | tracker.campaignId | AppsFlyer-style campaign attribution |
| Experiment ID | experiment_id | tracker.experimentId | A/B test bucket carry-over |
email | Funnel email variable | Pre-fill signup, link to existing record | |
| App User ID | app_user_id | tracker.sessionId | Canonical user identity (see app_user_id) |
| Stripe Customer ID | stripe_customer_id | Funnel _stripeCustomerId variable | Auto-link a Stripe customer in your backend |
| Meta FBP Cookie | _fbp | tracker.pageSnapshot.fbp | Server-side Conversions API matching |
| Meta FBC Cookie | _fbc | tracker.pageSnapshot.fbc | Server-side click attribution |
Default key names follow common provider conventions (note af_c_id is AppsFlyer's campaign key) but every key is editable — rename it to match whatever your backend or attribution provider expects.
A value is only appended when (a) the field is enabled, (b) the key is non-empty, and (c) the underlying value resolves to something truthy. Missing values are silently skipped, never sent as empty strings.
URL Parameter Mapping#
For ad-click identifiers and other params that arrive on the funnel landing page (e.g. gclid, fbclid, ttclid, custom ?ref=), the URL Parameter Mapping section forwards them to the destination URL.
Each mapping uses the option Label as the source (the param name on the current page URL) and the Description as the target (the param name on the destination URL). Source and target can be the same string when you just want to pass the value through unchanged.
Example: source fbclid → target fbclid copies ?fbclid=AbC123 from https://yourfunnel.com/f/...?fbclid=AbC123 onto the destination URL when the user taps.
Mappings only run in live mode and only copy values that are present in window.location.search at the moment of the click. Built-in Parameters are appended to the URL before URL Parameter Mapping, so if both target the same key, the URL Parameter Mapping value wins.
Forward Variables#
Beyond the fixed Built-in Parameters, you can forward any answer the visitor gave earlier in the funnel. In the Forward Variables section, pick one or more funnel variables — question answers (e.g. relationship_length, interests) and any derived variables — and each is appended to the destination URL as a query parameter keyed by its variable name.
The value sent is the raw machine value, not the on-screen text:
| Question type | Appended value | Example |
|---|---|---|
| single-select / slider | the chosen option ID | relationship_length=2 |
| multi-select | option IDs, comma-joined in selection order | interests=3,2 |
| range | the from-to string | experience=18-35 |
| text / number / email | the value as entered | first_name=Alex |
So a button forwarding two answers produces a tail like ?relationship_length=2&interests=3,2.
Those IDs are stable and compact, but they aren't human-readable on their own. To turn interests=3,2 into ["Finance", "Wellness"] on the receiving end, see Decode answer values — it shows how to map IDs to meaning using the funnel's Variables Schema.
Forward Variables runs in live mode only, and empty answers are skipped rather than sent as blank.
App Store Buttons mode#
Switch Button Type to "App Store Buttons" to render Apple + Google Play badges instead of a single button. You then configure:
- App Store Link — the iTunes / App Store URL.
- Google Play Link — the Play Store URL.
- Dark Mode — black background + white type vs. white background + black type.
- Button Stack — vertical (default, mobile-friendly) or horizontal.
Both badges go through the same parameter-injection path, so a ?app_user_id=...&_fbp=... tail is appended to whichever store URL the user taps. This lets you reconcile the eventual install with the funnel session post-attribution if the store URL is actually a tracked redirect.
You can disable either button independently. If both are off, nothing renders.
Variables from earlier in the funnel#
The Built-in Parameters read the funnel email and _stripeCustomerId variables directly. To put any other funnel variable on the destination URL — question answers, derived variables, or payment-provider variables like _stripeCheckoutSessionId / _paddleCustomerId / _paddleTransactionId / _solidgateCustomerId — add it in the Forward Variables section, as long as it's declared in your funnel. For values that need custom shaping before they're sent, write a custom success-page component that calls useVariable(), or read them server-side from the payment provider's webhook keyed by app_user_id.
tracker.sessionId (which becomes app_user_id on the URL) can be undefined for up to ~200ms. The button only fires on click, so this is rarely an issue — but if you wire a custom component that auto-fires on mount, use the polling pattern from Custom registration component.