Mobile deep linking

In the context of mobile apps, deep linking consists of using a uniform resource identifier (URI) that links to a specific location within a mobile app rather than simply launching the app. Deferred deep linking allows users to deep link to content even if the app is not already installed. Depending on the mobile device platform, the URI required to trigger the app may be different.

Deep linking and mobile operating systems

Unlike the Web, where the underlying technology of HTTP and URLs allow for deep linking by default, enabling deep linking on mobile apps requires these apps be configured to properly handle a uniform resource identifier (URI). Just like a URL is an address for a website, a URI is the address for an app on a mobile device. Examples of URIs that launch a mobile app:

  • twitter:// is the iOS URI to launch Twitter’s mobile app
  • YouTube:// is the iOS URI to launch YouTube’s mobile app

The format of the URI used to trigger or deep link an app is often different depending on the mobile operating system. Android devices work through intents,[1] BlackBerry 10 devices work through BB10's invocation framework,[2] Firefox OS devices work through Web Activities,[3] iOS devices work through the openUrl application method,[4] and Windows Phone 8 devices work through the UriMapper class.[5]

  • fb://profile/33138223345 is an example of a mobile deep link URI. The URI contains all the information needed to launch directly into a particular location within an app, in this case the profile with id '33138223345', i.e., the Wikipedia page, within the Facebook app, instead of simply the info for launching the Facebook app fb://. Wikipedia doesn’t allow such links so if we try to add it to this page, we instead see just the raw, uninterpreted wiki source code, as if this writing, for example [fb://profiled/33138223345 link with fb://profiled/33138223345 as its target], but it’s possible this will have changed by the time you, dear reader, read this. So instead of seeing raw, uninterpreted wiki source code you may see a working link.
  • eBay's apps demonstrate the use of different schemes by platform. eBay://launch?itm=360703170135 is the URI of a deep link into eBay’s iOS app while eBay://item/view?id=360703170135 is the URI of a deep link into eBay’s Android app.

Complexity of mobile deep linking and the need for a streamlined solution

The greatest benefit of mobile deep linking is the ability for marketers and app developers to bring users directly into the specific location within their app with a dedicated link. Just as deep links made the web more usable,[6] mobile deep links do the same for mobile apps.[7]

Unlike deep links on the web, where the link format is standardized based on HTTP guidelines, mobile deep links do not follow a consistent format. This causes confusion in development because different sets of links are required to access the same app on a different mobile operating system.

Passing search data via deep linking

Google allows app developers who have both iOS and Android apps to surface in-app content via mobile Google searches. Developers will need to submit their app and deep linking apps on both iOS and Android to be indexed by Google.[8] Alternatively, developers can use Google's short links to deep link mobile app users if the app is installed and direct others to the webpage.[9]

One example of a better user experience made possible because of deep link and data passing through install solution is one in which search information is passed into an app to bring the user to the exact information that drove them to the app. Compared to a common web link, this implementation may reduce the number of steps required. For example, to search for hotels in Boston, a user currently needs to:[10]

  1. Perform a Google search for a term
  2. See that a company has relevant content in its app
  3. Manually switch from the browser to the app (download the app first if required)
  4. Perform the search again in the app

That can be shortened to:

  1. Search on Google
  2. Select the in-app search result to view in-app (if app is installed)
gollark: Mine uses a horrific JS script
gollark: https://github.com/osmarks/website
gollark: osmarks.tk's main content is actually just statically compiled.
gollark: Just use Node.js with CGI!!!
gollark: I should really consider switching to CGI scripts for some of my website's backend; they're an outdated paradigm but actually quite a bit nicer to work with than the current way the `random-stuff` API works.

References
  1. "Android Intents Filters".
  2. "BlackBerry 10 Invocation Framework".
  3. "FireFox OS Web Activities".
  4. "iOS openURL Application Method".
  5. "Windows Phone UriMapper".
  6. Nielsen, Michelle (Mar 3, 2002). "Deep Linking is Good Linking". Nielsen Norman Group. Retrieved Aug 14, 2013.
  7. "Deep Linking Basics: Explaining Key Concepts". AppsFlyer. Retrieved 2019-06-02.
  8. "Surfacing content from iOS apps in Google Search". Googledevelopers.blogspot.com. 2015-05-27. Retrieved 2019-06-02.
  9. "Google Developers Blog: App deep linking with goo.gl". Googledevelopers.blogspot.com. 2015-05-27. Retrieved 2019-06-02.
  10. Kokalitcheva, Kia (Jan 7, 2015). "Yozio lets app makers spot where new users are coming from and personalize the download experience". VentureBeat.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.