Deeplinking: power up your integrated Marketing campaigns

profile picture

Justin Strategy Project Manager

4 Jan 2018  ·  9 min read

One of the main challenges in launching a modern digital marketing campaign is to reach your audience where they are – with minimal effort and maximum impact. We’d like to introduce you to the huge effect deeplinking with Firebase Dynamic Links can have on your digital campaigns.

Before actually diving into the inner workings of deeplinks, let’s first take a step back and explain their origin.

Think back to about ten years ago. Most people back then had just one go-to platform for consuming, consulting, and searching for content: their personal computer. Sure, innovators and early adopters were already using their first iPhones, but most companies still focused on providing content in one location: a desktop-first environment. And that one location could be easily accessed by one simple URL – one path for the user to follow.

Today, that desktop-first orientation has shifted dramatically. The contemporary online content consumer uses a multitude of platforms, and expects a good experience on all of them. This includes that based on the specific platform they are using, they want to be redirected to the most appropriate location to watch, listen or read certain content. So how can we best facilitate this?

Deeplinking: say whut now?

Enter: deeplinking. Deeplinking is the concept of not just linking to a webpage, but also linking to content within a native application. Each of today’s major operating systems tried to facilitate this kind of linking, albeit in different ways. Apple first introduced custom URL schemes, while Google coined the term Android App Links. However, a lot of issues propped up.

At first, you had to use a different link for apps on Android and iOS devices. That quickly became problematic, as companies wanted to communicate to all of their users with the same link at once. This issue was most prevalent in email campaigns. Companies don’t always know which operating systems their audience is using – so they could be sending an iOS link to an Android user, causing frustration. This issue, however, was solved when Apple switched to Universal Links.

But a persisting problem was that Apple and Google’s deeplinking mechanisms only worked brilliantly if you had the apps installed. But when you didn’t yet have the app, the links often didn’t redirect you to the equivalent web pages – or just did not work at all.

Enter: Firebase Dynamic Linking. Google describes its product best: “With Dynamic Links, your users get the best available experience for the platform they open your link on.” Google has provided an answer to the question: “Can we create one link to rule them all?”. With one Firebase deeplink, three very different use cases can be catered to and configured at will:

  1. If a user has your native app installed, the Dynamic Link will redirect them to the content in the application (regardless of the operating system).
  2. If a user does not have the app installed, the Dynamic Link will redirect him/her to the app store (and after the install, to the correct content. We’ll explain this further on, but this is called ‘deferred deeplinking’).
  3. If a user clicks the link in a desktop environment, they will be redirect to the equivalent content on your website.

How it works

To explain how deeplinking works, we will take an inside-out approach. First, we’ll explain how deeplinking in a native application works. Then, we will introduce how Google’s Firebase SDK can act as the ideal switchboard between the user and content they want to access.

The key question in explaining how (Firebase) deeplinking (and by extension) works is:

“How does the operating system know where in a native application the user needs to be redirected to?”

The internal navigation of a native product is (or can be) pretty similar to navigating on a website. In fact, when a user installs a native application, the operating system engages a mechanism that allows the app to register for a specific URI scheme. This URI scheme can be as extensive as you want to make it. You can create internal URLs for specific pieces of content or define it more top level, to navigate to the major sections in your app.

So you can see the main principle: if the internal path exists in your application, the operating system will be able to redirect you to it, if you have the app installed. But what if the user does not have the app installed? Do you want to redirect them to the equivalent content on your website? Or do you want to bring them to the app store and download your native application to increase user retention? Or what if you want the best of both worlds? If they’re on a mobile browser, redirect to the app store. If they’re consuming content on a website, redirect them to the appropriate location on the website. Sound good? No worries, Firebase can facilitate your every whim. In the Firebase console, the administrator can customize the behavior of a deeplink on each platform.

Here’s an example from one of our clients, VTM. During the winter break, VTM wants to offer their users exclusive online content. This time, VTM offered three seasons of binge-worthy content of the popular detective show Aspe. That content exists both on the website of VTM and in the application. To make sure that users could consume all that content in the best way possible, we created a dynamic link with Firebase.

In the console, we can set these properties:

  • If the user opens the link in the email from a mobile client and they have the VTM app installed, they will be redirected to the program detail page of Aspe in the VTM app.
  • If the user opens the link in the email from a mobile client and they don’t have the VTM app installed, they will be redirected to the app store. If they install the VTM app, they will be immediately redirected to the appropriate content in the app (deferred deeplinking).
  • If the user opens the link in the email from a desktop client, he/she will be redirected to the program detail page of Aspe on

A note on deferred deeplinking

Before diving into the pros and cons of using Firebase deeplinking, a quick note on deferred deeplinking. Remember we mentioned that today’s content consumer is very demanding. This means that removing hurdles between them and the content they want to consume is vital for acquiring and retaining as many users as possible. And that is exactly what deferred deeplinking does.

It’s an aspect of mobile deeplinking that keeps the deeplink active across installs. Let’s illustrate with the VTM example we just mentioned. Let’s say I clicked the link in the mail for Aspe on my mobile device, but I did not have the application installed. I am redirected to the relevant store and I start the install. After the install, the deeplink is still ‘active’ and I will consequently be brought to the content I was initially interested in.

Streamlining and reducing the amount of time between intent and consumption is critical and can be met with Firebase deeplinking.

The Pros of using Firebase Dynamic Linking

Catering to the users intent from acquisition to retention

Using these smart URLs, we can offer the users the best experience – whatever platform they are on. This experience can also be extended across installations, offering a smooth transition from awareness to acquisition and retention.

Converting mobile web users to native app users

Users that were using the mobile website to consume content, can easily be redirected to the native experience. This transition can become seamless by means of using Firebase Dynamic Links.

Drive conversion with email and social campaigns

“One link to rule them all” is essential for one-to-many campaigns. In the past, these one-to-many campaigns were perceived as very generic. Users were brought to one central location, with little regard for an optimal experience. By using Firebase Dynamic Links, we can reduce the effort we need to spend on creating multiple emails and increase the impact we have with our users. The ambition of “being where the user is” can be fulfilled with this technology, eventually resulting in conversion from aware user to dedicated content consumer.

The Cons of using Firebase Dynamic Linking

Although Firebase is a drastic improvement from the original deeplinking mechanisms the operating systems provided, there are still some quirks in the system. Two of them stand out:

Facebook and Google are no match made in heaven

Apart from email campaigns, social campaigns immediately spring to mind when contemplating the possibilities of using Firebase Deeplinking in your marketing campaigns. Although you can easily use it on Twitter and Linkedin, Facebook applications are an issue.

Facebook has its own mechanism for deeplinking. Up until two months ago, they even hosted the links on their own servers. So you had to create separate deeplinks to use in that specific social environment. This is a hassle of creating, documenting and monitoring two separate links (one for Facebook and one for everywhere else), but sure, you could make do. However, a couple of months ago Facebook deprecated the deeplink hosting feature. This means you now need an implementation in your native applications and on your website. And it still did not solve the issue of having two URLs to work with. So the notion of “one url to rule them all” does not ring true across all platforms.

Redirect issues on iOS

One key issue in implementing deeplinks throughout your campaigns is redirecting. What it boils down to is that a deeplink that is accessed after a redirect will not work on your iOS platforms. This is because Firebase Deeplinking still uses Universal Linking under the hood. In their own guidelines, Apple states that the user needs to be responsible for the interaction leading up to a deeplink. So if a server or any form of JavaScript triggers the deeplink, the operating system (on Apple devices) will not consider this interaction triggered by the user, and the deeplink will not work. This might sound like an edge case, but it’s very prevalent in certain campaign mail clients. These systems create emails with a number of links in them, and those links are very often redirects. This has a reason: it lets them perform their own tracking. However, it’s exactly that functionality that messes up the deeplinking functionality in an Apple environment.


Firebase Dynamic Linking offers a great solution to the needs of a user who is present on a variety of platforms. Brands can offer an optimal experience with minimal effort using this technology.

But although it’s clear that we’re fans of the application, we do feel that it’s still tricky to use this technology in a 360° communication campaign. Both in email campaigns and in social campaigns on Facebook, there’s still a few hiccups with dynamic linking. In both cases, these are not the result of faulty or unfinalised tech. They result from a platform-first thinking on behalf of these players (such as Facebook, Selligent etc.) as opposed to a user-centric approach championed by players such as Google.

It would be naive to state that Google does not have its own market interests in mind. Of course they do. But they have devised a product that has the potential of functioning as a one-stop-shop to cater to the multi-platform user. But although the dream of having “one link to rule them all” is within grasp, the final stretch might just prove to be the hardest – and it’s not entirely in the hands of Google/Firebase.