Skip to content
Dashboard

Click Handling & Redirect Flow

When a user opens a Detour link, the platform determines which app the link belongs to, records the click, and redirects the user. This page describes that flow and what you can configure.


  1. The user opens a Detour link in a browser.

    The link has the form https://<host>/<hash>/....

  2. Detour records the click.

    Either Detour collects the device fingerprint right away, or the user sees the iOS copy-link page and decides whether to copy the link to the clipboard. You choose which one in the iOS configuration in the dashboard.

  3. If App Preview is on, the user sees the preview page.

    The user taps to continue instead of being redirected right away.

  4. Detour redirects the user.

    Mobile users go to the App Store or Google Play. Desktop users go to the fallback URL.

  5. The user installs and opens the app.

    On first open, the SDK calls the match endpoint. If the click is matched, the SDK receives the link data.

You can replace each page in this flow with your own HTML. See Custom HTML Redirects.

Detour recognizes deferred links on platform hosts such as *.godetour.link, as well as on any configured custom domain. It looks up the app configuration attached to the link and redirects the user according to device OS and runtime context.

Only the base segment, the platform-generated hash, is canonical for that lookup. Anything you append to it is free-form:

  • extra path segments
  • URL search parameters

Neither affects deferred-link resolution, and both are delivered to your app in the returned link data. One app can therefore serve many campaign and content routes under a single base hash.

Most search parameters on a link are free-form and are passed to your app. A few names are read by the platform itself:

ParameterRead byEffect
ppidthe iOS store redirectSends the visitor to a specific App Store custom product page instead of the default one.
dtbSmart BannersIdentifies which banner a tap came from, for banner statistics.

Append ?ppid=<product-page-id> to a link and iOS installs from it open that custom product page, with different screenshots and promotional text per campaign, without a separate app or a separate link base:

https://acme-corp.godetour.link/x9y8z7/summer?ppid=1a2b3c4d-5e6f-7890-abcd-ef1234567890

The id is the UUID App Store Connect assigns to the product page. Constraints:

  • iOS only. Play Store custom store listings are selected by a different mechanism, so the Android URL never carries it.
  • A malformed id is dropped, not passed through. The App Store would silently serve the default page for an invalid id, which looks like a working campaign showing the wrong screenshots.
  • It is an ordinary query parameter, so it also appears in the per-parameter click breakdown in Analytics.

Detour includes safeguards against false attribution and redirect loops:

  • Automated and low-quality traffic is filtered out from attribution.
  • Repeated redirect attempts are guarded to avoid redirect loops.
  • If the redirect target cannot be resolved, the user sees a fallback failure view.

After a store redirect, Detour detects the visitor returning to the page, which happens when the store was dismissed, the app was not installed, or the browser restored the page from its back/forward cache. Instead of leaving the visitor on a redirect page that does nothing, Detour sends them to the web destination.

Instagram, Threads, Facebook and TikTok in-app browsers on iOS stopped loading App Store URLs, so a link that redirects to the store stops there. The Meta browsers end on a blank page with no error. TikTok shows an error toast.

For those browsers, and only for App Store destinations, Detour changes what it does:

  • Instagram, Threads and Facebook — a short hand-off screen opens the link in the system browser instead. If the hand-off does not go through, the visitor stays on the page with a button to continue manually.
  • TikTok — no hand-off works, so Detour does not attempt one. The page tells the visitor to open it in their own browser from the ••• menu.

For what this costs in attribution, see In-app browsers block the App Store.

Nothing else changes:

  • Safari, Chrome, desktop and every Android in-app browser keep the instant redirect.
  • Android is excluded deliberately. The Play Store URL carries the install referrer, which is the only deterministic attribution signal there, and a hand-off would drop it.

For host-specific behavior and /.well-known implications on custom domains, see Custom Domain.

An app has one desktop redirect URL, shared by all of its deferred links. The search parameters on the clicked link can still be forwarded to that URL. Pick a strategy in Link settings:

  • Pass all parameters — every search param on the deferred link is forwarded to the desktop fallback.
  • Pass specific parameters — only the params you name are passed.
  • Don’t pass parameters — the fallback URL is used as-is.

For matching details after first app open, see Matching. For platform-level setup context, see Dashboard Walkthrough.