Many publishers have developed mobile apps that deliver a better user experience than their mobile Web sites. Getting people to use your app instead of your mobile Web site can increase user engagement with your publication.
Using different deep linking techniques to link to content within your app is one way of increasing traffic to your mobile apps and establishing app reading habits with your users.
In an ideal world, there should be no difference between an “app link” and a “Web link.” Links should simply work no matter what device or platform you are using.
The device should know whether to open the link in an app or in a Web site depending on the user’s preference. It should be possible to link from one app to another app or from a Web site to an app without knowing if the user has the app installed.
There is currently no standardised way to do this, but there are a number of ways this can be implemented.
Google, Facebook, and Apple are among the many companies that have developed initiatives to improve deep linking and tackle some of these challenges. Here are some of the others: mobile deep linking, SPARQ, AppURL, mURL.cc, Appsfire, URX, Facebook App Links, Cellogic, Branch, and Tapstream.
What is deep linking?
In the context of mobile apps, deep linking consists of using a URL to link to specific content within an app.
For your app to respond to URL requests correctly, you need to implement something called a URL scheme. You can specify the URL scheme in your app and decide what content to display to the user once the link has been clicked on and the app opened.
For example, if you would like to view a specific Twitter profile within the Twitter app:
If you open the last link on a mobile that has the Twitter app installed, it should open the app on the Marvel Entertainment Twitter page.
On Android, deep link information is passed to your app as part of intent data. You can add an intent filter to your app, which defines how to access specific content inside your Android app.
One issue with deep linking to an app is the fact that you don't know if the app is installed on the user’s device. The deep link to the app will only work if the app is installed. This URL scheme is also not standardised, so you need to know the syntax for a particular app URL to be able to link to content within an app.
Here are 6 ways to deep link to content within your app:
- Smart app banner.
Apple first introduced the concept of smart app banners in iOS 6. Smart app banners provide a standardised method of promoting apps on Apple’s app store by displaying a banner at the top of Web sites loaded into Safari on iOS devices.
If the app is already installed on a user’s device, the banner intelligently changes its action, and tapping the banner will simply open the app. If the user doesn’t have your app installed on his device, tapping on the banner will take him to the app’s app store page.
Smart app banners are not displayed within Web views embedded into other apps such as the Facebook app. This means that any app that opens your Web site within a Web view inside an app will not display the smart app banner.
Other browsers have not adopted this standard, but there are ways to replicate the same look and behaviour on Android, through the use of a jQuery plug-in, for example. There is, however, no option to deep link from the Android plug-in; it simply gives the user the option of opening the app.
- App Links.
Wouldn’t it be nice if a Web URL posted to Facebook opened my app directly, instead of my Web site within the Facebook app? App Links, an open, cross-platform solution for app-to-app linking developed by Facebook, tries to solve this problem. It’s a way of mapping URLs to deep links.
It is a standard way of describing how to deep link to content within your app when the user only knows the Web URL to the content. It basically tells any app that displays a link to your Web site what the corresponding app link is for the same Web content.
You first have to add some meta tags to your Web site containing the URL scheme of your apps. An app that links to your Web site that follows the protocol will first check to see if the Web page has these meta tags. If it does, the app will link directly to the content in your app as obtained from the meta tags.
The Web page can optionally specify a fallback URL in a meta tag to simply open the original Web page if the app fails to open.
Facebook has additionally introduced its Index API, which allows developers to get deep links through Facebooks Graph API.
It’s also possible for the app being opened to link back to the referral app making the whole process seamless. App Links, however, only works from app to app. It doesn’t support linking from Web to app.
- Twitter cards.
Twitter cards allow users to promote their own app on their Twitter feed. If the user doesn’t have your app installed, a link to the appropriate app store will be displayed in the Twitter card. If the user has your app installed, you can deep link directly to the relevant content within the app.
You can enable cards for app installs by adding Twitter footer tags to the mark-up on your Web page.
- Linking from your Web site to your app.
To be able to link from a Web page on a mobile device to an app, it is beneficial to know whether the user has the app installed or not. A slight hack is to try to link to your app once your Web site has finished loading.
If the link doesn’t work, then the app isn’t installed on the device; you can then fallback to just opening the Web page. If the app is installed, the app is opened automatically when the user opens your Web site on a mobile device.
Another possibility is to give users the option to download the app the first time they open your Web site on a mobile device. If they click on the link, you can remember this option and choose to redirect the user to the app the next time they visit your Web site on a mobile device. Examples of this type of functionality can be seen on the LinkedIn app and the Pinterest app on an iPhone.
On Android, you can register your app to respond to the HTTP protocol and a particular domain using intents. When HTTP links are opened on the device either through a browser or through an app, the operating system checks to see if there is an app registered to handle this particular URL.
The user can decide whether to launch the browser or launch the app with the Web URL. Your app will need to determine what content to show based on the HTTP URL that opens the app.
- Google app indexing.
Google app indexing lets Google index apps just like Web sites, resulting in deep links to your Android app appearing in Google search results on mobile devices.
If users have the app installed, they will be sent directly to the relevant content within the app. If they don’t have the app installed, they will be directed to your app download page on the Google Play store.
- iOS 8 app extensions.
Extensions are a feature in the iOS8 update. iOS extensions are similar to Android intent filters; extensions, among other things, are an attempt at making third-party apps talk to each other.
There are a number of pre-set extension points that Apple allows you to manipulate. “Share” and “action” extensions are the most relevant for this discussion.
A share extension allows you to specify that your app can handle actions like posting of photos, links, or other files from different apps. So, for example, you could create an extension for posting a photo to your app from the photos app. This could be a way to receive image and video tips from your users. Your app is basically telling the operating system that it can receive photos.
Any app using the default share dialog will display your app as an option to share with.
At the moment there is no standardised way across all platforms to achieve app-to-app communication or Web-to-app communication. But with the right mix of the deep link techniques outlined above, you can funnel users into the right parts of your app and increase user engagement and traffic to your apps.