Deep linking has never been more fundamental and relevant to digital transformation. As a well established technology, deep linking has been proven to benefit user engagement, retention, marketing and data reporting. New deep linking technologies have emerged and major tech players like Apple, Google and Uber are giving extensive attention to the role deep links play across their mobile app ecosystem. In fact, deep linking is even being used by research institutes in Europe to build omnichannel COVID 19 tracing apps.
However, many modern digital teams have not yet capitalised on deep link technology. Businesses still encounter missed opportunities in transitioning web users to their mobile app. A recent study by URX showed that among the top 200 mobile apps on an app store, only 22 percent utilised deep linking technology.
For a lot of businesses and developers, the benefits of deep links are not obvious. Additionally, a backlog prioritisation following a ‘big output for a small input’ approach usually means that deep link implementation doesn’t rank very high on the product roadmap. But…are deep links really that complicated to add to your digital ecosystem? We need a unintimidating, best practice view of what deep link adoption looks like; how it implicates a user’s journey in a digital landscape and a clear set of recommended implementation guidelines for achieving a good user experience.
What is deep linking?
Chances are you’ve already heard about deep linking, so let’s just summarise: a deep link is a behaviour applied to certain links that is used to route users to a specific part of a website or content in an app. It can also be used to connect web journeys to in-app journeys. Why does deep linking matter? Studies have shown that leveraging deep links to effectively drive users to the optimal place leads to a better user experience across different channels.
Deep linking assists a user in achieving their goals.
Deep link technology has evolved to support mobile app ecosystems through platforms such as Branch. Let’s take a look at two new types of deep links:
- Deferred deep link: These route users to specific app content, even if the app is not installed when the link is opened. Deferred deep linking allows information to pass through the app store so that after the app has been installed, the user is automatically sent to a specific screen or location within an app instead of the app’s default home page.
- Contextual deep link: These function like deferred links, except they also record information about the user to provide a targeted experience after the app install. This is possible by passing almost an unlimited amount of custom data: where the link was clicked, where the user wants to go, who originally shared the link, etc. With this contextual data, features can be built off of these links; we can customise welcome screens, create unique onboarding journeys, auto apply promo codes, and enable data gathering on how campaigns and channels are performing. Powerful stuff!
What happens if the destination app is not installed when the user clicks on a deeplink?
This is a common deep linking question. Deep links can and should function regardless if the destination app is installed on the mobile device or not.
When a deep link is accessed from a mobile app or mobile website, the system should first detect if the designated app is installed.
If the app detected as already installed on the system, (and the journey can be fully completed in the app itself) the user should always be brought directly to the installed app when clicking a deep link:
If the app is detected as not installed on the mobile device, the user should be able continue their journey in the mobile website or download and switch to the app anytime they wish using a smart app banner:
Take the smart app banner implementation from Close5 for example:
Close5’s mobile website uses iOS’ smart app banner to link content to their app. While the user is using their website, they are able to click the banner to download the app. After visiting the app store and installing the Close5 app, they are deep linked to the same content, directly in the app.
It’s a win-win: the user can continue their journey directly in the app, taking advantage of convenient device-only features. Additionally, Close5 has boosted their app discovery and gained a new user.
Best UX practices
There are several guidelines to help you integrate deep links into your digital product.
How should we implement deep links?
- Deep links should apply across websites and apps, on iOS/Android. (I’ll jump into these different scenario details later)
- Deep links should be implemented with data analytic and reporting functionality to capture as much usage data as possible. Trust me — data analytics is a super important when it comes to improving UX.
- Deep links should always retain their link context and pass the link data regardless of whether an app is installed, or the user is logged in to the app or not. If the app needs to be installed, we should always seamlessly guide a user to resume the context of their deep linked journey after installing or logging in the app, directly in the app. The user should not be expected to go back to the deep link origin or manually navigate to the originally designated page after an app install or logging in. In simple terms: the context of a deep link should not be lost through the app install or log in.
- Consider tailoring an app onboarding process with your deep links.
When should we direct a user to our app vs. our website?
- In general, app usage should always be encouraged if the end user is on a mobile device and an app is available (the assumption here is that the journey can be completed in-app). Apps are usually tailored to a better mobile experience than websites.
- If the user is accessing a deep link on a desktop PC, they should never be directed to switch to mobile app channel; they should continue the journey on their desktop PC.
- On a mobile device, don’t mandate the user to download an app if the web journey they are currently on can be fully completed via the mobile website. Instead:
- Use a smart app banner (like Close5 does) to make users aware of your app, and give them the option to use the app
- Only use a smart app banner to notify the user of the app if they are viewing the website from a mobile browser
- Allow the bar to be dismissed
- System should remember if the bar has been dismissed and don’t re-ask
User Journeys
Let’s get into the scenarios of how a deep link functions in a user journey. Before we start, it’s important that I point out some assumptions:
- If the app is installed, being logged into a website doesn’t automatically log the user into the app.
- It is not a requirement for the user to switch from website to app in order to complete the target journey; it can be completed fully either on the website or in app.
Deep link sources
Deep links can originate from a:
- default app (example: an email viewed in iphone’s default native mail app)
- non-default app (example: an email viewed in the Gmail app, installed on iOS device)
- mobile or desktop website (example: link viewed on Hotmail.com, Booking.com)
- smart app banner
We are not considering the generic ‘download the app’ links often found on the footer area, although these could also certainly be setup as deep links:
Deep link destinations
Deep links can lead to a designated web or app page that is accessible pre-login/public facing (ie: blog) or post-login/personal (ie: account dashboard).
From now on, let’s refer to a deep link destination simply as ‘X’.
Deep link use cases
If we consider the various combinations of deep link sources and destinations mentioned above, we can imagine the possible high level scenarios:
Epic #1: Using the Gmail app on their iPhone, user views an EDM. They click the EDM campaign deep link and are brought directly to a specific campaign screen in already installed app X.
Deep link source: Default/non-default mobile app
Deep link destination: App X
Epic #2: Using the Chrome browser on their iPhone, user logs into X website to place an order. They click the smart app banner and are redirected to install the X app. Once app is installed, user is brought to their place an order screen, in the app.
Deep link source: Website in a mobile web browser app
Deep link destination: App X
Epic #3: Using Chrome browser on their iPhone, user logs into X website to place an order. They close the smart app banner and continue their purchase journey in website X.
Deep link source: Website in a mobile web browser app
Deep link destination: Website in a mobile web browser app
Epic #4: Using Internet Explorer on their PC, user views email notification of unclaimed rewards available to them. They click the deep link in the email and are brought to their unclaimed rewards page, in their default desktop browser.
Deep link source: Website in a desktop web browser
Deep link destination: Website in a desktop web browser
OK. We have four example scenarios. But what happens to these deep linking scenarios when we add factors like if the app is installed or if the user is not logged into the app?
Well, let’s start by further simplifying the user journeys into just 3 categories, according to the deep link source:
- App
- Mobile web browser
- Desktop web browser
1. App
(User clicks deep link in default/non-default mobile app)
Scenario 1.1 (Mobile app ➤ Mobile app X):
Designated app is installed and user is already logged into the app
Designated page is either pre-login or post-login.
or
Scenario 1.2 (Mobile app ➤ Mobile app X):
Designated app is installed and user is not logged into the app
Designated page is pre-login.
Scenario 1.3 (Mobile app ➤ Mobile app X):
Designated app is installed and user is not logged into the app
Designated page is post-login.
Scenario 1.4 (Mobile app ➤ Mobile website X):
Designated app is not installed.
Designated page is post-login.
2. Mobile web browser
(User clicks deep link in mobile web browser)
Scenario 2.1 (Mobile website ➤ Mobile website X):
Designated app is not installed.
Designated page is either pre-login or post-login.
Scenario 2.2 (Mobile website ➤ Mobile app X):
Designated app is not installed.
Designated page is either pre-login or post-login.
3. Desktop web browser
(User clicks deep link in a desktop web browser)
Scenario 3.1 (Desktop website ➤ Desktop website X):
User is already logged into desktop website X.
Designated page is either pre-login or post-login.
Scenario 3.2 (Desktop website ➤ Desktop website X):
User is not logged into desktop website X.
Designated page is either pre-login or post-login.
Most deep linking UX implementations can be covered by one of the above scenarios.
What will your digital product flows look like with added deep link functionality? I hope that these flows help identify innovative ways of using deep linking to delight users and drive optimal routing across your digital ecosystem.
Interested in more deep link information? I’d recommend taking a look at Android’s or iOS’ official deep linking documentation as well as 3rd party deep linking solutions such as Branch.io.
