Confirm your app is ready to receive deep links
Before setting anything up on the link side, your app itself needs to support receiving deep links — this is typically a small amount of configuration on iOS (Universal Links) and Android (App Links) that your development team sets up once. If you're not sure whether this is already done, check with whoever built the app before continuing.
Create the short link and enable deep linking
When creating a link in your dashboard, enable deep linking and select which app it should target. This is the setting that tells the link to attempt opening your app first, rather than just behaving like a normal web link.
Set the destination inside the app
Specify exactly what should open when the app launches from this link — a specific product page, a user profile, a piece of content — rather than just the app's default home screen. This is the whole point of deep linking: sending someone straight to what they clicked for.
Set the fallback for users without the app installed
Choose what happens if the app isn't installed — typically the appropriate app store listing (App Store or Google Play, detected automatically based on the visitor's device) or a web version of the same content, if one exists. This fallback is what makes deep linking safe to use broadly, since not every recipient will have the app.
Handle desktop clicks separately
Someone clicking your link from a desktop browser has no app to open at all, so set a sensible fallback for that case too — usually the web equivalent of the content, or a general landing page if no web version exists. Without this, desktop visitors can land somewhere confusing or broken.
Test on both iOS and Android, with the app installed
Click the link from a phone that has the app installed and confirm it opens directly to the correct content, not just the home screen. Test on both platforms separately, since iOS and Android handle deep linking through different underlying mechanisms and a working link on one doesn't guarantee the other works too.
Test the "not installed" fallback path
Test the same link from a device (or a fresh install / different account) without the app to confirm the fallback actually triggers correctly and lands on the right app store listing or web page. This path gets tested far less often than the "app is installed" path, and it's the one most likely to have a configuration mistake sitting undetected.
Roll it out across your marketing channels
Once tested, the same deep link can go anywhere you'd normally put a link — email, social posts, a QR code on packaging or signage — and it will behave correctly regardless of channel, since the app-installed detection happens at click time, not based on where the link was shared.
Monitor app-open vs. fallback rates
Your analytics should show how many clicks successfully opened the app versus how many hit the fallback path, which is a genuinely useful signal for how much of your audience already has the app installed. A high fallback rate on a channel aimed at existing customers might indicate a problem worth investigating rather than just a fact to note.
Update the destination later without creating new links
Because the link points to a redirect rather than a fixed destination, you can change what content it opens inside the app — or update the fallback — at any time without needing to create and redistribute a new link. This matters most for links already printed, embedded in an email that already went out, or saved somewhere you can't easily update.
Account for app updates that change internal navigation
If your app goes through a major update that restructures its internal navigation or content IDs, existing deep links can silently start pointing to the wrong place, or nowhere at all. Whenever a significant app update ships, it's worth re-testing a sample of your existing deep links rather than assuming they still resolve correctly, especially any that are printed or otherwise hard to update quickly.
Use deferred deep linking for install-then-open flows
If someone clicks your link without the app installed, goes through the app store to install it, and then opens the app for the first time, deferred deep linking preserves the original destination across that install gap so they still land on the right content rather than a generic home screen. This is worth setting up specifically if a meaningful share of your traffic comes from people who don't already have the app, since otherwise that context is simply lost the moment they leave for the app store.