How we tried to fix the mobile app ecosystem by building links that actually work
Building deep links that let you turn your app inside out
One thing that makes the web great is that every link takes you to the content it was meant to — a scandalous news article link or sharing a cool jacket with your friend takes you straight to the content you were meant to see. So why wouldn’t links to an app work the same way? We set to enable you to do just that — by enabling you to create links to every piece of content in your app you can effectively turn your app completley inside out.
After struggling with this issue over and over again as app developers, we built Branch earlier this year and made it our mission to build deep links that always work, taking a new user to the content or experience they expect even if they don’t already have an app installed when they click.
Why making apps behave like the web is important
Let’s take a look at some examples of how the mobile ecosystem works today, and how our links can allow it to behave more like the web.
1. Inviting a friend to get a cool app and give them a coupon
Without deferred deep links: They download the app, but the app store acts as a black box, so once they are in the app there is no way for the app developer to know where the referral came from. The only way to bypass this is through the use of coupon codes, which is what companies like Uber are doing. But even then the friend needs to remember what the code is and type it in.
With deferred deep links: The friend gets the code automatically applied when they installed the app just as they would on the web and get a personal message from the friend.
2. Sharing an awesome article with a friend
Without deferred deep links: They download the app, but they don’t get directed to the specific content like they would on the web. They have to go back and click on the link again after the app is installed or search in the app for the content.
With deferred deep links: The friend is taken straight to the content you shared whether they have the app already installed or not.
3. Ads for content within an app
Without deferred deep links: This is not possible right now. App install ads take users directly to install the app and every new user gets the same experience after install.
With deferred deep links: The ad can actually be customized to point to content within the app. So an ad for a cute dress in an eCommerce app, takes a user straight to that dress after install.
How we made links to and from apps behave like they would on the web
1. Creating the deferred deep links
When we were designing our links, we wanted to make the process as flexible as possible. While all links have the same structure and can have data bundled with them, they can be created in a few different ways:
- In our mobile SDKs: every time a user clicks to share or invite another user, a new link is generated for that action. Take, for example, when someone wants to share specific content from the app. They click “Share” and we generate a link unique to that exact sharing scenario and content. This way, a developer can customize the post-install experience for the user to the exact context of the share (whether it’s the destination url, a personalized welcome from the referrer, or other customizations).
- Web SDK: similarly, you can generate dynamic links on your web page that can pass data through the install of your mobile app. A good use case for this capability is to build a cross-platform referral program.
- HTTP API: a common use case is to batch-create links customized to each of your users for a specific campaign. For example, if you have 200,000 users and want to send them each a unique install link, you can use our API to create 200,000 unique links.
- Dashboard: you can manually create custom marketing links that can be tracked and attributed to any channel.
Additionally, we wanted to make sure our developers choose what the links looks like, so we came up with two ways of customizing our white-labeled links:
- Using a custom domain name (contact us for details on setting this up)
- Customizing the URL slug, e.g. http://bnc.lt/fall2014discount
2. Bundling data with the link
In order for a link to work the same way it would work on the web, the deep link address must be available after install every time — regardless of whether the user already has the app already or not before clicking on the link. The problem with most deep linking solutions that simply use the URI scheme is that the deep link and the data bundled with the link are not available after install. We wanted to make this process better by actually enabling our links to pass data through install, including things like:
- the content you want the user taken to
- referring user IDs
- channel
- the location in the app where the link was shared
- amount of credits you want to award them because they came from that link
Just like a web link, we do not limit the amount of data that can be stored in the link. We also don’t show the info in the link — instead we store it all securely and anonymously on our servers and make it available to you right after a user has installed.
3. Click behavior on desktop
Our smart links detect the platform a user clicks from and takes them to the appropriate content. You don’t need separate links for iOS, Android and Desktop anymore. You just tell us your app store and web URLs for each scenario, and we make the routing happen, ensuring that your users convert at the highest possible rate.
When a user clicks on a desktop, we (by default) present them with a page allowing them to resend themselves the link via SMS. If you have a web version of the app content your users are trying to share, we can take them to that content as well.
If you want your users to be taken to the mobile content but also to retain the option of sending themselves the link they clicked via SMS, you can use our universal app banner on your web page that shows an app banner with an SMS input. Alternatively, you can aslo use a more advanced Web SDK JavaScript with your own HTML widget. If the user was routed to that Web SDK-enabled site from one of our links, we remember that referring link data and continue the link flow.
When a user clicks a Branch link on a mobile device, there are three places they can be redirected to: (i) deeplink into the app, (ii) deeplink into the app store (retaining the data post-install), or (iii) a custom/web destination.
4. Click behavior on mobile
The best user experience is possible when the user can be deeplinked straight into the app. However, because this is not always possible, we built our links to make sure that the link data is still available under each edge scenario.
5. Getting the parameters after install or open
This is the most important step that makes our links behave more like web links — the ability to bundle data from the link and retrieve it once a user has opened the web app.
Once the user has installed or opened your app, the Branch SDK will retrieve the data dictionary associated with the link the user came from. You can use these parameters to route the user to the appropriate place within the app or to provide other analytics or messaging.
Below is the whole diagram of how our links work, from start to finish. For every possible scenario, we make sure that you ultimately get the data you bundled with the link right when the app is opened. This ensures you take the user to the right spot in the app 100% of the time, allowing your app to function more like the web.
If you are looking for a technical guide on implementing our Branch links, you can find that in our documentation.
_______________
Mada is a co-founder of Branch Metrics, a full service, deeplinking solution for mobile apps. Branch links have the power to deeplink through app install and open, allowing the app developer to deliver a personalized post-install experience.
