Opening in the App
App Routing hands the visitor off to the native app instead of the web version. Platform catalog, three click id states, and why Android coverage is wider than iOS.
When the destination leads into a mobile app — a bot in Telegram, a profile on Instagram, a track on Spotify — the visitor can be handed off to the app itself, not its web page. This matters most for traffic from Meta's in-app browsers: there, the web version opens inside someone else's WebView, where there are no push notifications and no install.
The feature is off until you explicitly turn it on for a specific split. Nothing changes for traffic you haven't touched.
App Routing does not replace cloaking, filters, or tracking links. It changes exactly one thing — where the last step leads.
Where this turns on
The control appears in the split editor only when the destination URL is recognized by domain. An unrecognized URL shows nothing — not an empty "choose an app" form, but nothing at all.
- Open the funnel → Tracking Links → the split with the destination URL.
- If the domain is recognized, the Open in <app> toggle appears.
- Choose what happens when the app isn't installed: web page or store page.
What the editor shows
Once enabled, you see four rows. Each comes from the catalog, none is guessed.
| Row | What it covers |
|---|---|
| Platform coverage | whether the app opens on Android, on iOS, or only on one of them |
| Click id fate | arrives / does not arrive / unknown |
| Certification | which "app-source × OS" pairs this has been verified on a live device |
| Fallback | what happens if the app isn't installed |
Three click id states
This isn't yes or no. There are three states, and two of them aren't "no."
| State | What it means |
|---|---|
| Arrives | the vendor has documented the mechanism by which the payload reaches the destination's backend |
| Does not arrive | the vendor either says so directly, or its full published API list contains no such path |
| Unknown | we found neither a mechanism nor proof of its absence |
"Does not arrive" is an answer, not a gap. Don't confuse it with "unknown": the former means conversions from this click will not link up automatically, and the decision is yours with eyes open.
Link forms that carry a click id
https://t.me/<bot>?start=<payload> payload in /start, up to 64 characters
https://m.me/<page>?ref=<payload> arrives in the page's webhook
https://ig.me/m/<user>?ref=<payload> same for InstagramBoth Meta forms are conditional, and the conditions differ. m.me requires the visitor to tap a button in the chat, and Meta itself doesn't guarantee delivery. ig.me additionally requires configured Icebreakers and a published account.
When the catalog knows a link form can carry a click id, the editor offers to insert it in one tap. The suggestion is scoped to the right link family: ?ref= is offered on ig.me/m/<user> and not offered on instagram.com/<user>, because there the parameter does nothing.
Why Android coverage is wider
Android needs only the package name: the saved https URL is handed to the app as-is. So the Android path covers the whole catalog at once.
iOS needs its own scheme and a URL transformation rule for the specific link type. Few such rules exist — and often not for lack of effort on our part: many vendors deliberately dropped custom schemes in favor of Universal Links. LINE deprecated line:// in its own documentation to protect against takeover attacks. Pinterest's help center states it doesn't publish templates to third parties. X officially doesn't support schemes.
For such apps, the correct answer is the absence of a rule, and the iOS path honestly degrades to the web page. The coverage row in the editor says this plainly.
A declared iOS scheme alone doesn't give you a route. You need a URL transformation rule for the specific link form — without it, every iOS visitor goes to the web page.
Direct Link settings
Direct Link's main settings offer a choice: try to open the app or always lead to the browser. The second option is resolved on the server — the runtime doesn't receive the route configuration at all.
There's no arbitrary app choice here, deliberately. The app is derived from the destination URL that lives on the split, and one Direct Link reaches several funnels with different destinations — there's no single correct answer there.
App catalog
The app list is platform-level, editable only by the super admin. Package names and URL schemes are facts about the platform, not workspace settings; arbitrary input here would be a hole straight through destination validation.
The catalog's unit is an app × link type pair, not an app. https://t.me/<bot>?start=<id> and https://t.me/<channel> are the same app and opposite answers to every question the system asks.
Limits worth knowing
- The app can hand the visitor back. The transition fires, the app receives the link — and decides on its own whether to send the person back to the web. A logged-out app does this regularly. This is outside our control.
- The catalog doesn't equal coverage. An entry in the catalog means the facts about the package and scheme are plausible, not that the transition has been verified on a device. The certification column is the only thing that proves that.
- The "store" fallback isn't available everywhere. If the app has no store page configured for the needed platform, the web page is used instead. The editor shows this before you save.