July 29th, 2015
Do you know that feeling of being new in a job and not understanding a single buzzword, so you are secretly googling every term in order to beef up your lingo? That’s what I was expecting to do during my first few days at Branch … but fortunately, I have amazing colleagues who patiently explained all the terms and technical details to me. I learned a ton, and so can you – without asking Google for every single keyword.
In this post, I want to explain the most important terms in the deep linking world in plain English. And if you want to go even deeper (pun intended) I’ll provide you with some helpful links along the way.
We are all using deep links every day, although most of us would probably just call them ‘links’. Technically, a deep link is a hyperlink that instead of linking to a homepage (such as www.branch.io) is linking to a specific website (e.g. this blog article) or piece of content (an image, a video etc.). In other words, deep links go deeper than just to the home page because they contain all the information to direct you to a specific place. That’s easy. But when you hear someone reference “deep links” in 2015, they are probably referring to deep links for mobile apps. This gets trickier:
Whereas on the web (desktop or mobile) I can just send you a deep link to some piece of content I like, I couldn’t really do this in a mobile app. While websites have a standardized document structure, apps don’t. As a consequence, I would need to tell you what app to download and where to click to find exactly the content I saw. Until recently, the same was true for app developers who wanted to promote specific content in their app, such as a special offer. If they would post an ad highlighting this deal on the mobile web, clicking the ad would direct me to the welcome screen of the app – or worse – to the app store. From there I have to find the special offer myself. And even if it was a really good deal, how likely am I to spend time searching for it?
Fortunately, companies like Branch have solved this problem. Once developers have integrated a few specific lines of code, they can create links to the content in their apps and direct users to any place they want, even if they first have to install the app.
Here, deferred deep linking comes into play. With deferred deep linking, clicking on a link that points to content inside an app you haven’t installed will bring you to the download page inside the app store. After downloading and opening the app, you will automatically be routed to the piece of content you were expecting – no search required. How does that work? Theoretically, the app stores are a barrier for information and analytics. After installing an app, the store won’t share where a user originally comes from and what he is looking for. In order to still direct you to the right place, deep linking solutions use something called device or snapshot matching in order to connect a user before and after they enter the app store. Basically, once a user clicks on a deep link, a snapshot of the user is taken in the browser and classified as an “outstanding match.” After installing the app the user is (very) quickly matched with his original snapshot, and subsequently matched with the experience he was looking for.
Which brings us to contextual deep linking. With contextual deep linking, you can pass information through the app store, e.g. the referring information that is required for deferred deep linking. But this is only the beginning – contextual deep links can also transport information about who the user is, where he is coming from, which ad campaign he clicked, which friend has referred him or which promotion code he wants to apply to his order. With contextual deep linking, developers can give users the most personalized and targeted app experience possible, especially when they open the app for the first time (also known as onboarding). Beyond that, with contextual deep links marketers are able to analyze exactly which advertising campaigns and marketing channels are effective at converting, and which are not.
The great thing about using a mobile deep linking solution like Branch is that you don’t have to integrate any platform or device-specific standards, many of which are constantly changing. Let’s familiarize ourselves with a few of these standards and the platforms that implement them:
Apple recently announced that its newest version of the mobile operating system iOS 9 will feature their own version of deep links, called Universal Links. Once developers have connected the domain of their mobile website with their app, Safari will check whether a user has installed the respective app when clicking on a normal web link. If the app is currently installed, the linked content will be opened in the app, if the app is not installed, Safari will load the content in mobile web as a fallback. In a nutshell, it’s one (universal) link that will either open the app or the mobile site in the browser.
Google has announced a similar deep linking solution for its newest release of the Android operating system. The feature, called App Links, has the same logic as Apple’s universal links: once a website is associated with an app, clicking on a link will open the content in the app if it is installed and the mobile site if it is not installed. Until now, a popup window asks Android users which app should open the link (choices include the web browser among others). With the newest Android release this popup will be UX history.
Facebook has partnered with a few other web services and implemented an open standard that is also called App Links. While the goal is the same (opening links shared on Facebook in the native app if installed and with a webview fallback if not) the approach here is a little different. Instead of connecting websites and apps on Facebook, App Links work by adding some metadata to your website. When a user clicks on a link, the Facebook robot looks for whether this metadata is available at the destination. If that’s the case, it opens the content inside the respective app.
Finally, let’s talk about Twitter Cards, which are a form of attachment to your tweets. In addition to adding videos, images or links to your website, Twitter also offers a product called the App Card. This card displays the name of the promoted app, its icon, price, and rating along with a brief description directly below the tweet. A link takes the user to the respective app store to download the app, or if they have it already installed, they are deep linked to the specific content within the app. In order to use App Cards, you have to add a few tags to your website which Twitter will crawl once you post a related URL.
This was just a basic overview of how the big players utilize deep links to improve user experience and help drive app installs. With so many different solutions and individual integration requirements in place, it’s hard to keep your code up to speed. This is why companies like Branch Metrics are building solutions that combine all the deep linking standards out there, so you can stay top of things. It’s free and open source because there is a bigger goal here, and the last buzzword for today: app discoverability.
When you are looking for a new app that has some content or functionality you are interested in, you are completely dependent on the way the apps are presented, promoted, and organized in the app stores. You can search for names and keywords but don’t really know what is inside the ‘black box’ you download and often pay for right away. As of today, you can’t search for native mobile app content based on your own interests because they are not completely indexed and searchable. And here deep links can make a difference: Once the content of many apps is indexed, it is possible to build a discoverability solution that connects users with those apps that have the most relevant content for them. What a great vision!