What a deep link is
An ordinary link points at a page on the web. A deep link points at a location inside an application: a specific profile, a specific product, a specific conversation.
Phones handle this by letting apps claim particular addresses. When a claimed address is opened, the operating system hands it to the app rather than to the browser. If the app is not installed, nothing is claimed and the browser gets it as normal.
That fallback is what makes it safe to use. The worst case is the behaviour you already had.
When it is worth the trouble
Deep linking pays off in proportion to how much better the app is than the mobile site.
- Social profiles, where the web version is logged out and the app version is not.
- Marketplaces and shops with their own app, where checkout in the app is already signed in.
- Anything requiring an account, where the browser will ask for a login the app already has.
- Maps and directions, where the app can start navigating and the web page cannot.
For a plain content page with no app behind it, there is nothing to deep link to and nothing to gain.
What it cannot do
It cannot install the app. If the person does not have it, they get the web version, which is exactly why the destination still has to work in a browser.
It cannot override a platform that has decided otherwise. Some apps open links in their own built in browser regardless, and there is no setting on your side that changes that.
And it cannot rescue a bad destination. If the app screen you are pointing at is confusing, arriving there faster does not help.
Doing it through a short link
Setting deep linking up per platform, per app and per link is tedious. Doing it once on a short link is not.
In Digily Link, deep linking is a setting on the link for supported destinations. The short address stays the same, and the behaviour on a phone changes.
The advantage of keeping it on the link rather than in the destination is that you can turn it off again. If it causes trouble on a particular platform, you change one setting rather than rebuilding anything.
Test it on real phones
This is one of the few areas where testing on a desktop tells you nothing at all.
- Test with the app installed and signed in, which is the case you are optimising for.
- Test with the app uninstalled, to confirm the web fallback is sensible.
- Test from inside another app's browser, because that is where a lot of taps come from.
- Test on both iOS and Android, since they claim addresses differently.
Four tests, ten minutes, and you find out whether the setting is doing anything before you put the link in front of an audience.
What you can still measure
The click is recorded before the handover, so your link statistics stay complete regardless of where the person ends up.
What happens after the handover belongs to the app, and you will not see it in the link report. If the outcome matters, measure it where the outcome happens.
That split is worth being clear about with anyone reading the numbers, because a deep linked campaign can look identical in click terms to one that sent everybody to a worse page.