Problem
When a link has an iOS Universal Link / Android App Link set, the query parameters the visitor arrives with are dropped from the redirect.
Example: a link whose Universal Link and App Link are both https://app.example/content, shared as
https://go.linkforty.com/<template>/<code>?v=titanic-ep1
redirects to https://app.example/content. The v=titanic-ep1 is gone, so the installed app opens without knowing which content to show.
Why
In src/routes/redirect.ts the inbound query string goes through extractLinkParams(request.query) and is stored on the click row (link_params). Only a deferred install (SDK /api/sdk/v1/install) ever sees it again. The redirect destination comes from decorateWebDestination(), which appends only:
- the link's
utm_parameters
- the link's own
deep_link_parameters
lf_click (when append_click_id is on)
request.query never reaches the destination. This affects the Universal Link / App Link 302, the in-app-browser web_fallback_url hop (which exists to give the UL a second chance) and the desktop destination.
The result is inconsistent: a new user who installs gets v through deferred deep linking, but an existing user who already has the app (the Universal Link case) doesn't. extractLinkParams()'s own doc comment names this "base-path-plus-parameters pattern that AppsFlyer and Branch both support"; those services forward the parameters to the deep link as well.
The only workaround today is one link per content item with the value baked into deep_link_parameters, which doesn't scale for a catalog (one link per episode).
Proposal
In decorateWebDestination(), also merge the visitor's non-reserved query parameters (extractLinkParams(request.query), which already excludes utm_*, fp_* and lf_click and caps count and length) into http(s) destinations, fill-only:
- a key already on the destination URL, or set by the link's
deep_link_parameters, is never overridden. A public URL can't rewrite e.g. the id of a Play Store link.
- no inbound parameters means the destination is unchanged.
Happy to send a PR.
Problem
When a link has an iOS Universal Link / Android App Link set, the query parameters the visitor arrives with are dropped from the redirect.
Example: a link whose Universal Link and App Link are both
https://app.example/content, shared asredirects to
https://app.example/content. Thev=titanic-ep1is gone, so the installed app opens without knowing which content to show.Why
In
src/routes/redirect.tsthe inbound query string goes throughextractLinkParams(request.query)and is stored on the click row (link_params). Only a deferred install (SDK/api/sdk/v1/install) ever sees it again. The redirect destination comes fromdecorateWebDestination(), which appends only:utm_parametersdeep_link_parameterslf_click(whenappend_click_idis on)request.querynever reaches the destination. This affects the Universal Link / App Link 302, the in-app-browserweb_fallback_urlhop (which exists to give the UL a second chance) and the desktop destination.The result is inconsistent: a new user who installs gets
vthrough deferred deep linking, but an existing user who already has the app (the Universal Link case) doesn't.extractLinkParams()'s own doc comment names this "base-path-plus-parameters pattern that AppsFlyer and Branch both support"; those services forward the parameters to the deep link as well.The only workaround today is one link per content item with the value baked into
deep_link_parameters, which doesn't scale for a catalog (one link per episode).Proposal
In
decorateWebDestination(), also merge the visitor's non-reserved query parameters (extractLinkParams(request.query), which already excludesutm_*,fp_*andlf_clickand caps count and length) into http(s) destinations, fill-only:deep_link_parameters, is never overridden. A public URL can't rewrite e.g. theidof a Play Store link.Happy to send a PR.