Getting Users to the Right Screen, Not Just the Right App
Deep linking is the difference between an app that opens to its home screen no matter what and one that takes users precisely to the content they intended to reach — a specific product, a shared post, a particular conversation. Getting this right meaningfully affects conversion for anything involving sharing, marketing campaigns, or cross-platform referrals from email or web.
Custom URL Schemes: The Original, Limited Approach
Custom schemes like myapp://product/123 were the original mobile deep linking mechanism, but they have real, significant limitations: they don’t work at all if the app isn’t installed (no graceful fallback), they’re not clickable as plain text in most contexts, and different apps can technically claim the same scheme, creating ambiguity about which app should actually handle the link.
Universal Links and App Links: The Modern Standard
iOS’s Universal Links and Android’s App Links use ordinary HTTPS URLs that open your app when it’s installed, and gracefully fall back to your website when it isn’t — solving the custom scheme’s fallback problem elegantly. This requires hosting a verification file (an apple-app-site-association file for iOS, an assetlinks.json file for Android) on your domain, cryptographically proving your app is authorized to handle links for that specific domain, which prevents other apps from hijacking your links.
Handling the “App Not Installed” Case Gracefully
The real test of a deep linking implementation is what happens when the app isn’t installed. A well-designed system falls back to a mobile web page offering the same content (or a reasonable close equivalent) plus a prominent install prompt, ideally preserving the original intended destination so the user lands on the right content immediately after installing and opening the app for the first time — not back at a generic home screen after all that friction.
Deferred Deep Linking
Deferred deep linking solves a genuinely tricky problem: a user clicks a link, doesn’t have the app installed, goes to the app store, installs it, and opens it for the first time — and the app somehow still knows where they originally intended to go, despite that context seemingly being lost during the app store detour. This typically works through a combination of device fingerprinting and matching techniques, or a first-run association if the OS provides one, and is genuinely valuable for marketing campaigns that need to track and honor specific referral sources across the install gap.
Testing Deep Links Thoroughly
Deep links need testing across several genuinely distinct states: app not installed, app installed but not running, app running in the background, and app already running in the foreground — each can trigger subtly different code paths in your link handling logic, and a bug in any single path can silently break a meaningful share of your actual traffic without being obvious from casual testing in just one state.
Link Structure and Routing Design
Design your deep link URL structure to mirror your app’s actual navigation hierarchy in a predictable way — /products/123, /users/456/posts/789 — so that routing logic stays maintainable as your app grows. Avoid encoding excessive state directly into the URL itself; pass an ID and let the app fetch fresh, current data rather than trying to pass a full serialized state through URL parameters, which becomes fragile and hard to maintain as your data model evolves.
Analytics and Attribution
Deep links are a critical attribution touchpoint — knowing which specific marketing campaign, shared post, or referral source actually drove an app open and, ideally, a subsequent conversion is essential for measuring marketing effectiveness. Ensure your deep linking implementation preserves and passes through attribution parameters consistently, rather than losing them somewhere in the fallback or install flow where they’re most likely to silently disappear.
Practical Recommendations
- Use Universal Links / App Links over custom schemes for anything user-facing or shared externally — the graceful fallback alone is worth it.
- Design a genuinely good web fallback experience, not an afterthought placeholder page.
- Test across all app states explicitly — not installed, backgrounded, foregrounded — as separate, distinct test cases.
- Pass IDs through links and fetch fresh data, rather than encoding fragile serialized state directly in the URL.