Skip to content

Inbound query parameters are dropped when redirecting to the Universal Link / App Link #66

Description

@hdeyana

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions