Mobile Deep Linking Part 2: Using a Hosted Deep Links Provider
When to use a hosted service vs. building everything yourself
Previously I wrote about how to implement iOS and Android Mobile Deep Linking yourself. You can tell from the length of that article that implementing deep linking can be time consuming and painful, especially when you hit annoying corner cases where things don’t work as expected.
But you don’t have to build it yourself. Hosted deep linking services are also popular. Lots of big companies like Pinterest, Jet and Skyscanner use hosted solutions. This time, let’s talk about when you might (or might not) want to use one of these hosted deep link providers and how they work as an alternative to building it yourself.
Important disclosure: I researched this topic for Branch. They liked part one and paid for my time to write this follow-up on using hosted deep linking solutions. They didn’t tell me what to write, but I just want to be clear that they sponsored this work.
What are Mobile App Deep Links again?
Normally when a mobile user clicks on a link to your company’s website, the website opens in their web browser — even if the user already has your mobile app installed.
With deep linking, you can make it so that your company’s mobile app opens up instead. You can also make sure that your app opens to the correct screen that corresponds with the link:
Since native apps tend to convert better and offer a richer experience than mobile websites, most of the time it makes sense to implement deep linking. It’s a great way to get users back into your app if they aren’t in the habit of launching the app themselves. Users can disable it if they don’t like it.
And even if your company is app-centric and doesn’t have much of a website, implementing mobile deep linking still makes sense since you can use it to build a web-based user acquisition funnel to drive app downloads.
Why would I want to use a hosted provider?
Both Apple’s iOS and Google’s Android provide their own standards for how to implement deep linking. Apple calls their version ‘Universal Links’ and Google calls theirs ‘App Links’, but they are roughly the same thing done in different ways.
But since Apple and Google already give you a way to set up deep linking yourself, why would you want to use a hosted service instead?
The first thing to consider is that deep linking is full of corner cases where things break in unexpected ways. Here are a handful of examples I’ve run into personally:
- Deep links don’t trigger on content within the Facebook and Twitter iOS apps. Those apps force your links to open in a web preview tab instead. If your company gets a lot of social media traffic, this is really annoying since none of that traffic will lead back into your app.
- Every time an iOS user upgrades your app, the user’s phone pings back to your website to check for a list of supported deep link urls. If you don’t carefully configure caching on your web server or CDN, you can knock your website off the internet by accidentally flooding yourself with traffic each time you release an app update.
- Furthermore, iOS only pings back for supported deep links right when the app is upgraded. If you push out a new version of your iOS app before you update your website with the same changes, any new deep links won’t work for your existing users until you publish an entirely new iOS app release (ugh). This makes coordinating iOS app releases in a big company feel like a space shuttle launch.
The list goes on. Someone on your team will have to become a deep linking expert to maintain everything and debug problems. If you don’t want to dedicate time to that, using a hosted provider avoids most of these headaches (with some caveats I’ll mention later).
The hosted providers also offer additional features on top of what Apple and Google provide. Some of these are features that you’d probably end up building yourself anyway:
1. Better on boarding with Deferred Deep Linking
Apple’s deep linking system doesn’t give you a way to remember which web page the user was on before they installed your app. That means you often end up with this broken on boarding experience:
- A user visits your website and sees a promo banner for your app.
- The user decides to download your app and clicks on the promo banner. Great!
- The user downloads the app, launches it and immediately lands…. on the home screen of the app — with no idea how to get back to the content they were just looking at before installation. :(
Maybe you’ve had that experience yourself when trying out a new app. It’s pretty annoying.
When you use an hosted provider’s SDK, the SDK can capture the user’s context before installation and pass that to your app so it can show the right screen to continue the user’s flow. This is called “Deferred Deep Linking” and it makes a huge difference in how slick your app feels to the user.
2. Providing a self-service UI for your marketing team
If your company has a separate marketing team, you’ll want to make sure any links they use in marketing or advertisements are deep links. But this means that the marketing team will come back to you over and over asking how to link to specific content in a way that will work as a deep link and be tracked correctly. This can suck up a lot of your time.
The hosted deep link providers all give you a web-based dashboard you use to compose new deep links and view traffic reports. You can just give your marketing team an account and not mess with it yourself. It’s a big time saver in my experience:
The hosted deep link provider SDKs also let you compose new deep links on-the-fly inside the app itself. You can use this to implement dynamic features like user-to-user link sharing or user-to-user referral tracking.
Which Deep Linking service to try?
There are several companies and start-ups that offer hosted deep linking services. The services I see developers use most often are Firebase Dynamic Links and Branch — probably because both offer free plans. I also know some folks who use adjust, but I won’t cover here since it doesn’t offer a free plan as far as I know.
Firebase Dynamic Links SDK
Firebase Dynamic Links SDK is an add-on to Google’s Firebase Mobile App Platform. The Firebase Mobile App Platform provides a collection of libraries and SDKs that apps can use to save time implementing common features like login, file storage, and analytics. Dynamic Links SDK is the specific module that handles deep linking.
Take a look at the whole Firebase suite of offerings:
Dynamic Links is way over on the right. In other words, Firebase tries to do everything and deep links is just one of those things.
Branch deep links SDK
Branch is a stand-alone SDK specifically for deep linking. It’s a single-purpose tool (though they also have add-on products for specialized use cases like sending high-volume emails with deep links).
How do they compare?
Integration
The amount of work required to integrate with either the Firebase Dynamic Links SDK or the Branch SDK is similar. And even if you use other Firebase modules in your app (like Store or Authentication), you can still use the Branch SDK for deep linking just as easily as using the Dynamic Links SDK.
Pricing and Business Models
Both services are free! There’s no subscription fee to use either of them. But any free service makes me curious about the business model behind it because you want to be sure the service will stick around.
Google’s core business is built on being able to track how users behave on the web. When users go into native apps, Google can’t normally track that traffic on iOS. My guess is that Google offers the Firebase Dynamic Links SDK for free as a way to collect more information on users linking into native apps.
Branch has a different strategy. They use the information collected from their free SDK to power their user matching feature that tells you which web user clicked through into your app:
When a user clicks a Branch link for your app, and we’ve seen them click a link for another app on our partner network, we’ve already matched them up to a corresponding device identifier. This means that when they install the app, we know with 100% certainty that they just came from that link click.
In other words, the more apps that include the Branch SDK, the better they can track when a specific user installs your app. So it’s advantageous for them to get as many different apps as possible using their SDK to build their user database. To actually make money to support the product, Branch offers additional paid products that build on the free feature set.
Custom domain support for Deep Link URLs
To make deep linking work, you need to permanently tie a website domain name to your app. Then any time the user clicks on links to that domain name, your app will get a chance to intercept those links and open itself.
However when you are using a third party deep linking service, you can’t use your your normal website domain name for deep links. You have to set up an alternate domain name to intercept the links.
Unfortunately Firebase is very limited in the domain names that you can use. With Firebase, all your deep link urls will look like https://<something>.app.goo.gl.
Here’s a real example:
To me, that’s a big problem. I don’t want to link my users to rpb3r.app.goo.gl instead of the my normal website domain (in this case, that should be https://www.npr.org). Unbranded urls like this have a negative affect on click-through rate. I know that I wouldn’t click on a link like that because I’d be suspicious it was a link to a scam website.
Branch’s solution still doesn’t let your use your main website domain name (though they say they are working on it), but it gives you a lot more flexibility with how you name your deep links:
- You can use https://your_name.app.link
- You can use a different subdomain on your site, like https://mobile.yoursite.com or https://go.yoursite.com.
- You can use a secondary root domain: https://your_other_domain.com
While I’d rather use my normal web site address, Branch supporting subdomains for deep links is workable. For the NPR example, that might be something like https://go.npr.org/ instead of https://rpb3r.app.goo.gl/.
Firebase currently only supporting “.app.goo.gl” links is a deal breaker for me. Hopefully they’ll expand their capabilities in the future.
Tracking, Attribution and Reporting
Both Firebase and Branch give you tools for attributing user actions to different channels (i.e. tracking how the user found you) and building reports from the data.
Here’s an example:
Without a tool like this, it can be hard to figure out which marketing channels are leading to new app installs.
One trick that you can only do with Branch is track which exact user just installed your app from a link on your website. Some companies use this feature to implement automatic login for known users the very first time they launch the app without ever asking for a password.
Customizable App Promo Banners
Both iOS and Android have a built-in way to show a promo banner on your website if the user hasn’t downloaded your app yet:
Unfortunately you don’t have much control over these default banners. They display only when Apple or Google decide to show them (with different rules on each platform) and you can’t change how they look.
Branch gives you a toolkit for building custom mobile promo banners. You can control when these banners show up, which users see them, and how they look:
Branch also provides tools for promoting you app to desktop users. You can display a promo webpage that lets users text themselves a link to download your app:
Firebase doesn’t currently have any customized app banner features.
Working around issues with Facebook, Twitter and other popular iOS apps that block deep links
The Twitter and Facebook iOS apps block deep links and force all links to open inside a web preview window. Because of this, if anyone posts a link to your content on those social networks, your deep links won’t fire and your app won’t open. This is frustrating if you depend on social media to drive traffic to your app.
Because so many companies depend on Twitter and Facebook traffic, both Firebase and Branch provide workarounds to allow users to still be able to open your app with an extra click.
With Firebase, the user will see a blank interstitial page that says “Open link in app?”:
If the user clicks “Open”, your app will open. If not, nothing happens.
It’s a confusing user experience and unfortunately you can’t customize how it looks or works.
Branch has a much more flexible version of this idea that they call Deepviews. It lets you create a custom interstitial pages that preview the actual content that the user will see inside the app while encouraging the user to click through.
You can even edit the content, style and layout of what the user sees in the preview page:
If you depend on social media traffic, having a good solution here will save you a lot of headaches. Hopefully Firebase will improve their solution over time.
When to implement Deep Linking yourself
Even if you like the idea of using a hosted deep links provider, there are some cases where you might still want to implement deep links by hand using Apple and Google’s tools.
For example, maybe you have a receipt email that you send to users after they purchase and the email has a link to view order status. If you’ve already sent millions of those emails, you can’t change the links in those emails you’ve already sent — so you can’t point those users to a new deep-link-enabled url.
In that case, it might make sense to implement deep linking yourself to support those older links. But it’s still worth considering using a hosted provider for newer links. You can use both together.
The second case is that you just might not be comfortable using a third party for deep linking for whatever reason. Some companies work in specialized industries where you aren’t allowed to share data with anyone else (i.e. heath care or security). In that case, you might be forced to build deep linking yourself.
Recommendations
If I am building a new app for a start-up, I’d opt to use a hosted deep linking provider. It’s easier than maintaining it yourself, especially if you have a small team and can’t dedicate a person to it.
On the other hand if I was implementing deep links for a large company that already had millions of users and a mobile website, I’d go with to a hybrid solution:
- Implement basic deep linking by hand (to support legacy flows, etc.)
- Use a hosted tool for new deep links. Then I’d give the marketing team access to the web-based dashboard so that they could create links and monitor them without needing to talk to the development team. It would also give me a way to run customized app promo banners easily.
Between Firebase Dynamic Links and Branch, I’d personally choose Branch. The biggest issue to me is that Firebase makes you use those tacky http://xyz.yoursite.app.goo.gl links instead of being able to use a custom domain. The other reason I’d use Branch is because they do a better job of handling how deep links work inside the Facebook and Twitter iOS apps.
Disclosure Again: Like I mentioned at the very beginning, Branch paid for my time to research and write this article. They didn’t tell me what to write and the opinions are my own, but I want to be totally transparent that they sponsored the time I took to write this.
