Suppose you receive a letter in the mail saying you’ve won an all expenses paid trip to a newly opened tropical resort, but there’s a catch: you have to provide an honest review at the end of your stay. At first, you’re skeptical. But on a whim, you decide to check it out.
Next thing you know, you’re on a first-class flight landing at a Caribbean airport where you’ve been told a limo driver will be meeting you to take you the rest of the way to the resort. You’re ready to lie out on the beach and laugh and smile at your good fortune. But as you exit the gate, you notice there aren’t any drivers holding your name up. Your driver isn’t there. You call the resort to find that they were sent to the wrong airport.
You’re annoyed. You now have to look up directions, rent a car, drive to the resort and pay for the valet service. Sure, you end up reaching your final destination, but you can’t help feeling like the resort failed with their first impression. You’re left with a bad taste in your mouth which leaves you wondering: Will I ever come back?
Poor implementations of mobile deeplinking can leave you feeling much the same way as our contrived example above, leading to bad first impressions and ultimately a decline in user acquisition and retention. If you’ve ever clicked on a mobile link that took you to the App Store install page, only to take you to the app landing page after opening, you might be familiar with this pain point. Mobile deeplinking solutions continue to evolve. In this constantly changing ecosystem, how sure are you that you’re up-to-date on deeplinking strategy?
If your strategy is more than a few months old, it might be helpful to review the types of deeplinking solutions available in the market. You may find some useful functionality that you’ve been missing. But as a wise man once said, “you have to know the past to understand the present.” Let’s quickly review the history of deeplinks so we can get a better understanding of our current state.
Let’s start at the very beginning
In the beginning, there were web deeplinks
With web-based deeplinks, the functionality has remained relatively unchanged for a decade. First, you come up with a unique web-accessible URL for each piece of content you have; then you can share that URL anywhere and know it will work anywhere a browser is available. As the simplest of examples, this (http://hyfn.com/work/ufc-gym/) is a deeplink while this (http://hyfn.com) is not.
Then mobile apps came along
In 2008, when mobile apps first started showing up on iOS and Android, deeplinking was not a primary consideration. Over time, companies realized the same benefits available with web deeplinking would be useful in mobile as well.
But how could a deeplink exist on platforms where apps were not accessed via link? As it turns out, both Google and Apple provided some limited functionality within their respective platforms which would form the basis for legacy mobile deeplinks.
So we got legacy deeplinks
Legacy mobile deeplinks refers to the functionality Apple and Google provided in the earliest versions of their platforms to facilitate linking directly into an app. With both platforms, the primary use-case for this functionality was to allow other apps to call into your own. As such, features we’d expected from web deeplinks such as global uniqueness and availability were not considerations at the time. The specific implementations include:
iOS — Custom URL Schemes
iOS’s version of legacy links was in the form of custom URL schemes. Implementing a custom scheme for your app would allow for specially formatted URLs, similar to something like hyfn://home and hyfn://work/ufc-gym (to be defined by the app developer). These schemes would be registered on the user’s device at app install time, allowing other installed apps to reference and link into your app.
Android — Intent Filters
Android’s intent filters work similarly via a scheme declared within the app manifest.
But legacy deeplinks had some issues…
These approaches to mobile deeplinking worked great when their use was only required within the platform in question. However, attempting to integrate with web deeplinks or other platforms proved to be a problem for a few reasons.
The HTTP Scheme Issue
iOS custom URL schemes do not allow you to override the http scheme and therefore direct handling of web deeplinks as app deeplinks is not possible. Android intent filters do allow an app to respond to web based deeplinks; however, an application chooser dialog can be presented to the user when there are multiple apps installed that can resolve the deeplink. Opening a link to Facebook from your email could show a dialog asking if you’d like to open the link using your browser, the native Facebook app, or any third party app that registered an intent filter to accept “http://facebook.com” deeplinks. The downside here is the inability to control the user’s experience in deeplinking into your content, potentially creating confusing experience for the user.
The Uninstalled App Issue
Legacy deeplinks don’t work unless the user already has the app. Out of the box, this makes them rather useless for app discovery.
This requires extra workarounds on the part of the app developers, usually involving navigation to the web-based version of the deeplink (if one exists) or redirecting to the App Store to prompt the user to install the app first. Forcing a redirect to the App Store introduces another problem which our next iteration of deeplinks, deferred deeplinks, was developed to solve.
The first solution came in the form of deferred and contextual deeplinks
When using legacy deeplinks in such a case where a user does not already have the app installed, there is no way to redirect the user to the App Store and then continue with the load of the appropriate deeplink content once the app has been installed. Within advertising and analytics campaigns, legacy deeplinks can’t be used to measure conversions or attribution as the redirection to the App Store breaks the ability to pass along the context necessary to record the appropriate tracking event post install.
In order to solve this issue, one must retain the deeplink context state prior to the redirection being made and make sure to attribute it to the correct device when the install process completes. To do that requires fingerprinting the device and storing that information to a remote database prior to redirecting to the app store so that when the app is opened post-install, the app can do a lookup against the database to see if any deferred deeplinks were pending.
Implementation from scratch can be a rather involved process requiring additional logic to be defined within the mobile app and on web. If a mobile app doesn’t already have a web complement, creating one simply to provide deeplink support may not be an efficient use of resources. There are many services that have sprung up to provide support in this capacity. Third party solutions like branch.io, APPURL, TUNE, deeplink, and Tapstream have all built businesses around creating this functionality so that developers don’t have to, usually providing additional features that make the decision to use them even more appealing and calling the improved solutions contextual deeplinks.
If using a third party service isn’t an option or you simply would prefer to develop the logic yourself, URXblog has a good overview of the specifics that would need to be implemented. Google just announced Firebase Dynamic Links which provides yet another completion alternative with the third party providers mentioned above.
The latest improvements have come via Universal Web and Mobile Deeplinks
As mentioned above, iOS custom URL schemes and Android intent filters were intended primarily for inter-app communication and not for cross-platform deeplink support. As more companies move towards having a unified web and app presence, the need to have deeplinks that could work on web and apps seamlessly has grown.
Universal Links — iOS 9.0+
To better support this, iOS 9.0+ features Universal Links, which allows for associations to be defined between apps and web URL domains. On iOS 9.0+, if a user has installed an app associated with a standard web URL, then clicking a link to that URL will redirect directly to the app without opening Safari first. Since the URL is a standard web link, no additional implementation is required by the developer to ensure that the user is sent to the web version of the link when the app is not installed. Of course, if the intent is to send the user to the app store in this case, that logic would still need to be implemented on the web-side or via one of the services mentioned above.
App Linking — Android 6.0+
Similarly, in Android 6.0+, Google introduced their own functionality for associating apps to a specific web domain via app linking. This feature allows for an app to explicitly specify itself as the handler of the web deeplink, ensuring that no other apps can hijack the deeplink and removing the potential for confusing app selector dialogs.
So what can you do with each type of deeplink?
The primary use cases for legacy deeplinks on mobile are inter-app communication support and the ability to drive engagement to installed apps. The only remaining use case for legacy deeplinks would be when you only have a single mobile platform to support with zero cross-platform deeplinking requirements.
Aside from providing a cross-platform solution, the more advanced deeplink types mentioned above can also track app installs, growth, attribution, and perform more complicated flows such as personalized user onboarding.
You can increase organic traffic
Firebase app indexing (formerly Google app indexing) is used to promote search discovery from within Google Search.
You can run social ad campaigns
Each platform has its own provided methods for deeplinks to drive traffic to your app.
- Facebook’s documentation explains the process for setting up iOS and Android apps for deeplinking-based ad campaigns, including the use of their own cross-platform deeplink protocol app links (not to be confused with Google’s app linking mentioned above).
- Twitter’s offering to support social ad campaigns is in the form of app cards which also offers limited deeplinking into mobile apps similar to what you get from implementing legacy deeplinks. Branch.io has a more detailed post you can read about describing the pros and cons and their alternative solution if you’re interested.
- Pinterest’s app pins are even more limited: they can only promote app installs on iOS and only within the US. However, they also support Facebook’s App Links protocol, so a cross-platform solution can still be realized.
What’s next?
Every year, Google’s I/O and Apple’s WWDC bring announcements of new features coming down the pipeline. Google’s most recent I/O revealed an exciting new deeplinking approach called Instant Apps.
Android Instant Apps
Android Instant Apps aim to improve app searchability and discovery by providing a near-instantaneous ability to link into yet to be installed apps. In order to enable this functionality, developers will have to define a modular portion of the app codebase that will be loaded via Google Play Services at deeplink request time to present the linked content.
(via Google Search)
At this point, details are still vague and no official documentation has been released, but if you’re interested you can request early access as documentation becomes available here. Several questions come to mind on how this implementation might work: Will these Instant Apps also trigger a complete install of the full app after the user has completed their instant app interaction? Or will there be some way to encourage the user to get the full app?
Google’s FAQs on the matter address this question, but the answer is rather vague.
Can users choose to install the app permanently?
Developers can allow users to download the app from the Google Play Store. After download, the app remains on the phone after the user has left the experience.
Instant Apps functionality will be back-ported to Android 4.1, a version of Android that predates the ability to request permissions at runtime (Android 6.0). Does that mean that Instant Apps loaded on the fly will simply accept all permissions without user approval? Or would there be a reduced set of potential permissions developers can utilize in an instant app environment? Again, the FAQs have an answer, but fail to address how this will work on pre-6.0 devices.
How do permissions work in Android Instant Apps?
Android Instant Apps uses the runtime permissions model introduced in Android 6.0. If an app supports the permission model introduced in Android 6.0 (API level 23), it does not require any additional work to become an Instant App that runs on older devices.
The FAQs do provide this useful nugget of information regarding restrictions within Instant Apps not mentioned elsewhere:
Android Instant Apps restricts some features that might not match users’ expectations of an app that is not installed. For example, an Instant App can’t use background services, do background notifications, or access unique device identifiers.
It makes sense that background services would be excluded as the primary use case for Instant Apps is to get you quick access to specific features. However, this does seem to rule out links into apps such as media players and navigation apps that primarily depend on background services for constant updates, so something to consider as you decide if Instant Apps will work for your app.
From early indications, we can see how Instant Apps will be beneficial to all parties involved. App developers will be able to share their apps to a wider audience with a reduced barrier to entry. End users will be exposed to the best options available without having to search the web and App Stores separately, and Google will be able to monetize more mobile search ad traffic which previously would have not been attributable.
What do we suggest?
Here are our recommendations for the most common use cases we’ve experienced while implementing deeplink solutions.
If your app requires deeplinking into content already accessible via web:
- If you have an Android app targeting 4.1+ (and this is the future), why not give Instant Apps a shot?
- If you can target iOS 9+/Android 6.0+ and above, Universal Links and App Linking should be all you need for basic deeplinking support.
- If you want to support older OS versions or want extra features such as attribution tracking, use a deferred/contextual deeplink third party solution such as branch.io.
If your app requires deeplinking on mobile only:
- If you want deeplinks to survive an intermediary install via the App Store step or if you need to show a landing page if deeplink is accessed outside a mobile context, use a deferred/contextual deeplink third party solution such as branch.io.
- If you fully control the manner in which the mobile deeplinks will be used and can guarantee the app will always be installed when invoking a deeplink, you can stick to legacy deeplinks.
Determining the best deeplinking solution depends on a good understanding of deeplinks and your app’s needs. So now, go build, break, and fix fast. Happy deeplinking!
Keith Mayoral
VP of Mobile Technology at HYFN
