Mobile Apps

All You Need to Know About Mobile Deep Link

When it comes to deep link, not many people know what it is. It’s the unsung hero of technology world. Yet people use it everyday without realizing its existence, or maybe don’t know it has a name. In this post, you will get some basic ideas about what deep link is and how it is applied on mobile.

What is deep link?

Deep linking is a methodology for launching a native mobile application via a link.

Deep link does exactly what it says: take users deep inside a website/application with a link. On desktop, deep linking is the use of a hyperlink that links to a specific content inside a website (e.g., “http://example.com/path/page”), rather than the website’s homepage (e.g., “http://example.com/”). On mobile, deep linking use a uniform resource identifier (URI) that links to a specific location within a mobile app instead of just launching the app. In this series, we only focus on mobile deep linking.

So you are browsing the Internet on your mobile. You search “Facebook” on Google and the first result points to Facebook’s home page. You tap on that link and instead of being redirected to Facebook’s home page, the Facebook app on your mobile opens. That’s basically how mobile deep linking works.

mobile deep link

Enabling deeplinking for a mobile application will allow you to invoke deeplinks that open an app and launch specific, defined screens within the app, such as the homepage, product pages, and shopping cart, much as you would on a website.
Deeplinking is especially useful for promotional efforts because it allows you and any third party to open the app when a link is clicked, rather than driving to a website or to your app’s listing on the iOS App Store or Google Play.

3 types of deep links

1. Traditional deep links

traditional deep link

Traditional deep links can route users to app content as long as the app is already installed when the link is opened. This means traditional deep links don’t work if the user doesn’t have the app, and will show either an error or a fallback page.

2. Deferred deep links

deferred deep link

Deferred deep links can route users to content even if the app is not installed when the link is opened. The link will first redirect to the App Store or Play Store to download the app, and then take the user to the specific “deferred” content immediately after first launch.

3. Contextual deep links

Contextual deep links have all the functionality of deferred deep links, plus much more. Contextual deep links store information about where a user wants to go, where the link was clicked, who originally shared the link, and an almost unlimited amount of custom data.

Contextual links add value for both app developers and users. App developers can build powerful features beyond just simple content linking, including personalized welcomes (where you see your friend’s recommendation in the app if they share an item with you) and referral programs. App users benefit because apps can provide better experiences and more relevant information.

URI Scheme

Custom URI schemes were the original form of deep linking for mobile apps. They are like creating a “private internet” for your app, with links that look like myapp://path/to/content. The advantage of custom URI schemes is they are easy to set up and most apps already have one. The disadvantage is a user’s device only knows about this “private internet” if the corresponding app is already installed, and there is no graceful fallback option by default.

The workaround approach to deep linking with URI schemes involves using a traditional http:// link to launch a web browser. This link contains a JavaScript redirect to a custom URI scheme, which is executed by the web browser to launch the app. If the redirect attempt fails because the app is not installed, the JavaScript then takes the user to the App Store or Play Store.

This is still the primary approach to deep linking on Android, but Apple began blocking this approach on iOS in 2015 with the release of Universal Links.

Apple iOS Universal Links

Apple introduced Universal Links in iOS 9 as a solution to the lack of graceful fallback functionality in custom URI scheme deep links. Universal Links are standard web links (http://mydomain.com) that point to both a web page and a piece of content inside an app. When a Universal Link is opened, iOS checks to see if any installed device is registered for that domain. If so, the app is launched immediately without ever loading the web page. If not, the web URL (which can be a simple redirect to the App Store) is loaded in Safari.

A study of the thousands of apps on the Branch platform found that Universal Links increased conversion to open by 40%.

Android Links

Google built App Links as the Android equivalent to iOS Universal Links, and they operate in a very similar way: a standard web link that points to both a web page and a piece of content inside an app. This results in a smoother user experience, but since custom URI schemes are still fully supported by every version of Android, App Links have seen very low adoption.

Facebook App Links

Facebook created App Links in 2014 as an open standard to solve the limitations of URI scheme deep links. App Links have two main components:

  1. A set of meta tags to add to the web page destination of a standard http:// link. These tags specify the custom URI scheme location of corresponding content inside the native app, and the behavior that should occur if the app is not installed.
  2. A routing engine for use inside apps that support opening links. This engine checks the destination URL for App Links tags before opening it, and then launches the corresponding app or executes the specified fallback behavior.

The App Links standard has a critical flaw: it requires work by both the origin and destination apps. While the meta tags component saw wide adoption, the only major implementations of the routing engine were in the core Facebook and Messenger apps.

Facebook now prefers to keep users inside its platform, and has removed the App Links routing engine from everywhere except the main Android app. Since Facebook also blocks iOS Universal Links, this leaves no reliable way to open third-party apps from Facebook or Messenger on iOS. Branch has implemented a solution to help work around these limitations.

Deeplink Structure

A deeplink functions much like a traditional hyperlink on a webpage. It is composed of separate elements that make up what is referred to as a Uniform Resource Identifier (URI). The URI contains all the information that, when invoked, launches a mobile application with a specific screen.

When thinking about deeplink structure, the best practice is to implement a URL with a unique scheme name and routing parameters (path and query strings) that represent custom actions to take in the app. Unless you have very specific needs, we recommend using a simple URL structure as shown in the example below:

mobiledeeplinkingprojectdemo://path?query_string

Where mobiledeeplinkingprojectdemo is the scheme name and path and query string are the routing parameters used to further route the user to a particular experience in the app.

For the scheme name:

  • When choosing a scheme name, it is essential to choose a name unique to your brand to avoid conflicting schemes across different applications
  • There is currently no central authority to manage conflicts with scheme names
  • The best practice is to have the scheme name reference your brand (e.g. mobiledeeplinkingprojectdemo). Another suggested pattern for scheme names is to use reverse domain name notation (e.g. org.mobiledeeplinking), but this is not widely followed

For the routing parameters (path and query string):

  • Routing parameters are optional, but are highly recommended. Routing parameters provide you with further control for routing the user to specific screens of the application or passing in additional parameters
  • The query string is optional, and might be used if you need to pass specific parameters, like a product ID
  • Third parties may append additional metadata to the routing parameters, so it’s important that your app can handle this use case (the iOS and Android libraries discussed in Part 2 account for this)
  • If the mobile app has a corresponding website, it is recommended that the routing parameters syntax for the mobile app match the URL structure on the website

Here are a few examples of deeplinks for popular apps on iOS:

DeveloperDeeplink – e.g.Purpose
Twittertwitter://timelineOpens the Twitter app and links to the user’s timeline
Facebookfb://profileOpens the Facebook app and links to the user’s profile
Yelpyelp://Opens the Yelp app (note: this example does not include any routing parameters)

Deeplink Implementation

Regardless of whether you choose to use the MobileDeepLinking library, implementing deeplinking requires you to:

  • Select the URI scheme you’ll be using, and declare it in the app’s manifest (discussed in more detail below). As discussed in Part 1, the scheme name must be unique to your app, otherwise conflicts with other apps may occur
  • Define the actions you want to launch by using a deeplink. Make sure these actions are in accordance with the URI syntax you chose. As mentioned in Part 1, the use of the URL syntax is highly recommended (e.g. schemename://path?query_string)

Once that’s done, you can start implementing the code that will handle the path and query string sections of the URL to launch the intended action.

It is recommended that you utilize the MobileDeepLinking libraries, but if you wish to implement mobile deeplinking directly, the high level process is as follows –

iOS

iOS apps are self-contained entities. There is only one point of entry in the app: the AppDelegate. When a deeplink to your app is initiated, it will call the AppDelegate with the deeplinking metadata.

It is important to maintain a consistent state in your app while providing the desired experience. A deeplink may be fired at any time in any app state, and it is your responsibility to keep the app in a stable state.

For example, this can mean allowing the user to return to the main screen of your app. To accomplish this, you must push the appropriate view controllers to send the user to the desired part of your app while still maintaining the correct view hierarchy.

When the app is opened, you can recover the URL that was used to launch it and process it according to your needs.

You can find reference documentation on the AppDelegate here.

Android

Android apps are composed of a set of Activities. Each of these Activities can be called by other apps if configured as such. Depending on how your app and deeplinks are structured, you can choose to use one central endpoint or many.

It is important to maintain a consistent state in your app while providing the desired experience. An Android Activity will launch on top of the current context and it is your responsibility to ensure the appropriate view hierarchy is maintained. Additionally, it is important to have the necessary data ready for the Activity when it is loaded for the user.

When the app is opened, you can recover the URL that was used to launch it and process it according to your needs.

You can find reference documentation on Android deeplinking here.

Use cases

1. Converting web users to app users

What if you’ve gone to the trouble of building a great mobile website in addition to a beautiful native app, but notice your conversion rate is better in the native app than on the web. In this case, converting mobile web users to download your app might give your business a boost. While moving them from one to the other can be challenging, deep linking makes it easy. With mobile deep linking, you can seamlessly transition users from your mobile website to the equivalent content within your app. And because the links survive the app install process, even new users can pick up where they left off on your mobile site without missing a beat.

mobile deep linking

2. Social, email, and SMS campaigns

Send promotional offers using links that work on any platform. Current and future users can redeem your offers whether they use iOS, Android, or a web browser, and whether or not they already have your app installed.

mobile deep link

3. User-to-user sharing

One of the most effective ways to get new users to install your app is by enabling your users to share content from your app with their friends. With mobile deep link, you can create a great user-to-user sharing experience: users who receive content recommendations from their friends can click a link and be taken directly to the shared content in your app, even if they have to go to the App Store or Google Play Store to install your app first.

deep link

4. Real-world app promotion

Use QR codes or bar codes that encode a deep link in your physical displays to promote your app at events and venues. Users can use their mobile phones camera to scan QR codes/bar codes and be redirected to the targeted content in your app, or be prompted to install your app first if they have not.

deep linking

The 4 use cases above are just some examples of how deep link can help your business, in a marketer’s point of view. There are certainly many other ways you can use mobile deep linking in your app to boost sales and engagement.

Conclusion

Deep links are simply a way to identify, address and transport users to specific content in apps. While convenient (and necessary), they’re not that revolutionary or exciting. The future value of deep links lies in how we use them — what’s buwilt on top of them, and the new consumer experiences they’ll enable.

This will include novel ways to discover deep links for apps that you have, discovering new apps through deep-linkable relevant content and services, and the transfer of more intelligence across the links themselves. Much like a hyperlink, it’s not the mechanism that will change the world, but the way we use them to connect the web together.