What a Fallback URL Is
Every deep link has a preferred destination: a specific screen inside your app. A fallback URL is where the link goes when that destination is not available. The user might not have the app, might be on a laptop, or might be inside an in-app browser that refuses to hand off to the app. Without a fallback, those users hit an error page or a blank screen. With one, they reach a store listing or a useful web page.
Fallbacks are easy to overlook because they rarely appear in testing. The person building the campaign has the app installed and taps links on their own phone. The real audience includes people on other platforms, older OS versions and unusual browsers, and the fallback is what they see.
How Fallbacks Work on Each Platform
On iOS, a Universal Link is a normal HTTPS URL. If the app is installed and the domain is verified, iOS opens the app. If not, Safari loads the URL. That web response is your fallback: it can render the content, redirect to the App Store, or show a page with an install button.
Android App Links behave the same way. When the app is installed and verified, Android opens it. Otherwise the browser loads the URL and your server decides what happens next.
Custom URL schemes have no fallback at all. If myapp:// is not registered on the device, the tap fails. Older setups worked around this with JavaScript that tried the scheme and then redirected after a timeout, but browsers have made that unreliable, which is one reason schemes are no longer used for campaign links.
Desktop is a separate case. A desktop browser cannot install a mobile app, so desktop traffic should land on a web page. If that page exists only to send people to the app, a QR code that hands the link to a phone is a useful addition.
Choosing the Right Fallback
The right fallback depends on what the campaign is trying to do. For install campaigns, the store listing is the natural fallback, paired with deferred deep linking so the user still reaches the promised content after installing. For re-engagement campaigns aimed at existing users, a web version of the content avoids sending someone who deleted the app straight back to the store. For content that lives on both web and app, such as articles, listings or profiles, the web page is often the better experience.
Platform matters too. Set an App Store fallback for iOS, a Google Play fallback for Android, and a web fallback for everything else. If your app is available in only some countries, route users elsewhere to a web page instead of a store page that shows "not available in your region."
Keep fallbacks updated. A store URL with a changed app ID, a deleted landing page or an expired promotion page turns a working link into a dead end.
Fallbacks and Attribution
A fallback is not the end of the measurement story. When a user falls back to the store and installs, you still want to credit that install to the campaign. That only works if the link recorded the click before redirecting. Attribution links do this: they log the tap with campaign and platform details, choose the destination, and then match the eventual install back to the click.
If your fallback is a web page, measure what happens there as well. Tagging the fallback page with UTM parameters, or using a web SDK, shows how many users arrived through the fallback and whether they later installed the app.
Fallbacks in Linkrunner Links
Linkrunner links route users by platform and install state, with per-platform store and web destinations and redirection rules for cases such as specific countries or devices. Links opened inside social in-app browsers can pass through an intermediary page that helps users get out to the app or store instead of getting stuck in a webview. See deep linking and social-to-app links for how routing and fallbacks are configured.
Testing Your Fallbacks
Build a small test matrix: iOS with and without the app, Android with and without the app, desktop, and at least one in-app browser such as Instagram or TikTok. Tap each campaign link in every cell and confirm where it lands. Repeat after changing domains, store listings or app versions. A five-minute check before launch saves days of lost installs.