Tap a link to a specific product on a retailer's site from a text message, and if that retailer's app is installed, the app opens directly to that product page instead of its home screen. That handoff, from a URL to an exact spot inside an app, is what a deep link does, and how reliably it works depends entirely on which of three different mechanisms is behind it.
The three kinds of deep link
People use "deep link" as a catch-all term, but the three real implementations behave very differently, especially the moment the app is not already installed.
| Custom URI scheme | Universal link / app link | Deferred deep link | |
|---|---|---|---|
| What it looks like | myapp://product/482 | https://example.com/product/482 | A normal https link, paired with an attribution SDK |
| Ownership verified by the OS | No | Yes, via a file hosted on the domain | Same as universal link / app link |
| What happens if the app isn't installed | Fails silently or shows a system error, no fallback | Falls back to a normal web page in the browser | Sends the person to the app store, then routes them after install |
| Works if opened inside an in-app browser | Almost never, most in-app browsers block custom schemes | Inconsistent, many in-app browsers block the handoff too | Inconsistent, for the same reason |
| Needs a third-party SDK | No | No | Yes, typically (Branch, AppsFlyer, or similar) |
Deep link vs universal link, the actual difference
A "deep link" in the strict, original sense means a custom URI scheme, something like myapp://product/482. The app registers that scheme with the operating system when it's installed, and a tap on a link using it hands control straight to the app without a browser ever opening in between. The catch is that nothing verifies the app actually owns that scheme, and if the app is not installed, the link fails with either nothing happening or a system error, since there is no fallback destination built in.
A universal link (Apple's term) or app link (Android's term) fixes that specific failure. It's a normal https URL. The app proves ownership of the domain by hosting a small verification file, an apple-app-site-association file on iOS, a Digital Asset Links file on Android, that the OS checks before deciding whether to hand the tap to the app or let it load as a regular web page. Because it's a real URL first, it always has somewhere to go: the app if installed and verified, a normal browser tab if not. That fallback is the entire reason universal links and app links replaced raw custom schemes as the recommended default for anything customer-facing.
Deferred deep linking: routing someone who has to install first
Neither of the two above solves the hardest version of the problem: someone taps a link, doesn't have the app, gets sent to the app store, installs it, and opens it fresh. At that point the original link's context is gone. The app has no idea what the person originally wanted to see. A deferred deep link is the workaround: an attribution SDK bundled into the app records device and timing signals at the moment of the store visit, then matches them back up once the app opens for the first time, and routes the new user to the right screen retroactively. It's probabilistic matching, not a guarantee. It depends on a third-party SDK staying available and accurate.
That dependency is a real risk. Not a theoretical one. Google shut down Firebase Dynamic Links, one of the most widely used deferred deep linking services, in August 2025, after first deprecating it in 2024. Any app or guide still built around it needs to have already moved to a replacement, Branch and AppsFlyer are the two most common, or it has lost deferred deep linking entirely. It's a useful reminder that this category of tooling is a dependency on someone else's infrastructure, not a one-time setup.
Why a deep link can silently fail to fire
Three separate things have to line up for any deep link to actually open the app: the app has to be installed, the OS has to agree the link belongs to that app, and the tap has to reach the OS in a form it recognizes as a real link tap. That third condition is the one people miss. A link opened inside a platform's own in-app browser, the WebView Instagram or TikTok wraps around outbound links, often never reaches the OS's link-handling layer at all, because the host app deliberately renders the page itself rather than passing the tap along. From the app's own perspective this is desired behavior. It keeps the visitor inside it. From the deep link's perspective, it means a correctly built universal link can arrive at a page and just sit there as a normal web page, with no attempt made to open the destination app, unless the visitor first escapes to a real browser, the same failure mode covered in why links open in the wrong browser.
Where deep links fit into a link-in-bio setup
None of this is Raydar routing a click by device or location. Raydar does not run conditional redirects; a link either points somewhere or it does not. What it does handle is the in-app browser problem above: a Raydar link opened inside Instagram's or TikTok's built-in browser gets an escape step toward the visitor's actual default browser, which matters because that's the step a deep link, deferred or otherwise, generally needs before it has any chance of firing at all. For campaigns that also need to answer which post actually produced a given click, pairing that link with UTM parameters covers the analytics side that deep linking on its own does not.