What is deep linking?
Deep linking is the use of a URL to open a specific screen inside a mobile app or on a website, instead of always landing on a home page. If the app is missing, the same URL should still resolve to a store listing or a web page. Deeplink (deeplink.in) hosts and routes those links.
A link that names the screen
A normal website URL already deep links the web. The path /pricing opens pricing, not the homepage, because the server and the router agree on what that path means. Mobile deep linking applies the same idea to an installed app. The operating system has to decide whether a tap stays in the browser or hands the URL to an app that has proved it owns the domain.
Two older patterns still show up in apps. A custom scheme such as myapp://product/42 can open an installed app, but another app can register the same scheme, and a scheme does nothing useful in a desktop email client that does not know the app. HTTPS links avoid that ambiguity when the phone has verified the association between the domain and the app. That verification is what iOS calls Universal Links and Android calls App Links.
The destination is whatever the product treats as addressable: a product, a chat, a password reset, an offer, or a web fallback with the same path. Parameters on the URL can carry a campaign name or an item id. If those parameters are stripped before the app opens, the screen may still open while the measurement is lost. Keeping the original URL intact is part of making the link trustworthy.
What happens on a tap
A person taps the link in a browser, an email, a message, or a camera app that understands QR codes. The phone looks at the domain. If an app is installed and the domain association is valid, the app opens and receives the URL. The app, or a library it embeds, maps that URL onto a screen. If no app can claim the domain, the link loads as a normal web page or follows a redirect the link host configured.
That branch is why teams bother with a deep linking platform instead of only publishing a website. The website can be the fallback, the store can be the fallback, and the app can be the preferred target, all from one URL. Deeplink stores a path and a fallback URL on the link, and it serves the association files for the link domain so Android and iOS can verify the app.
Links created in this product are hosted on a subdomain of chottu.link, or on a custom domain after that domain is verified. The marketing site at www.deeplink.in is not the host that redirects campaign clicks. Campaign URLs use the link domain configured for the app.
When the app is not installed
A deep link that only works for people who already have the app fails the first session of a new user. The usual web fallback is a page on your site, or a redirect to the App Store or Google Play. Deferred deep linking adds another step: remember the URL that was clicked, and after the install, open that destination on first launch. Without that memory, the install succeeds and the campaign context does not.
Deeplink’s deferred path is there so the click can survive the store. The dashboard and API also record clicks and installs for the link and compute a click-to-install conversion rate. Location, platform, and device breakdowns are part of the analytics already shown in the product. That is measurement of the link, not a promise about revenue or retention.
Steps
- Decide the destination. Pick the in-app screen and the web fallback URL. If the screen needs an id, put it in the path or the query string.
- Create the link. In the Deeplink dashboard or REST API, save the path, the fallback URL, and any UTM parameters you want on the campaign.
- Configure the app. Add the Android package name and SHA-256 fingerprints, and the iOS bundle id and team id, so the association files match the binaries you ship.
- Share and check analytics. Use the link in the channel you care about. Confirm clicks, and installs when they occur, on that link in the dashboard.
Common URL behaviors
| Situation | What the person should get |
|---|---|
| App installed and domain verified | The app opens on the intended screen |
| App not installed | The store or the configured web fallback |
| Desktop browser | The web fallback, unless you have a desktop app that claims the domain |
| App installed after the click | The original destination, if deferred deep linking is in place |
Example
A link hosted at https://your-app.chottu.link/product/42, or on a verified custom domain with the same path, is one URL. The path identifies the product. The fallback URL is the web page you stored for people who do not open the app. Replace your-app with the subdomain configured for that app. This is a pattern from how Deeplink builds link hosts, not a live customer URL.
Frequently asked questions
Is a deep link the same as a website URL?
On the web, a URL that opens a specific page is already a deep link. On mobile, the same HTTPS URL can also open an app when the operating system has a verified association for that domain. A custom scheme can open an app too, but it does not behave like a normal link in email and on the desktop web.
Do I need a separate link for Android and iOS?
Not with Deeplink. One URL is stored for the campaign. The app record holds Android package details and iOS bundle details, and the link host serves the association files those platforms check. The web fallback is the same URL’s safety net when neither app opens.
Get started
Create a Deeplink account to make a link, set a web fallback, and review click and install analytics.
Create a Deeplink accountRead about Deeplink pricingOpen the Deeplink documentation