Introduction

Deep linking. You’ve heard the term. Perhaps you’ve heard that it improves user experience, resulting in a significant boost of conversions and revenues. And maybe you’ve been searching high and low for the ultimate guide that’ll teach you the basics quickly in simple, non-technical language.

Well, you’re in luck. We’ve put together an introductory primer you can read in 15-20 minutes. Here’s what’s inside:

• An introduction to the concepts of deep linking and deferred deep linking
• An explanation on how they work
• A discussion of the benefits of deep linking and how it drives ROX (return on experience) 
• An overview on Universal Links, App Links, and URI schemes
• Use cases galore covering different industries and business challenges
• Implementation considerations
  

Sounds good? So what are you waiting for? Have at it.

Chapter 1

What is deep linking?

In the context of mobile, deep linking describes the action of delivering users to specific in-app content from wherever they are.

What kind of specific content? Well, pretty much any in-app destination other than the app’s home screen, from a product page to checkout.

That covers the destination. What about the starting point? In other words, where would you place a “deep link” — i.e. the URL —- that begins the deep linking journey? 

That’s easy — any place your potential or existing users may be looking at: Instagram, Snap, an email or text message, chat inboxes, search engines, QR codes on billboards or a pizza box. Mobile users are nearly everywhere, and you should be too.

To help you wrap your head around deep linking, we like to compare mobile marketers to taxi drivers, admittedly a strange comparison at first glance. 

It goes like this: The job of a taxi driver and marketer is ultimately the same: driving customers from point A to point B. And while taxi drivers use a car for their job, marketers achieve this by using deep linking technology.

In a nutshell, deep linking is used to bring users from just about anywhere to nearly any digital destination. When it comes to mobile, it is most commonly used by marketers and product managers to drive app growth, engagement, and retention. 

How deep linking actually works

Now comes the interesting part. How can marketers and product managers make sure that the same link they’ve placed in a campaign triggers a smooth, seamless journey to specific content for any users — regardless of whether they have the app or not and irrespective of device (mobile or PC), operating system, browser, etc.?

That’s where the magic of deep linking happens.

Using a deep linking engine, marketers define the experience for users that will click on a link.

This can include things like where an app user should be redirected to, as well as different journeys for iOS, Android, and desktop users. 

At a very basic level, a deep linking engine allows marketers and product managers to provide two distinct types of journeys — one for app users and one for non-app users:

• If the user has the app — they are “deep linked” seamlessly to the content. 
• If they don’t have the app — a mechanism called “deferred deep linking” kicks in, where the user is brought to the right app store so that they download, install, and launch the app, after which the relevant in-app content will be displayed.

Crafting customized journeys for different users on the fly is what enables deep linking engines to create customer experiences that are contextual and personalized. Ultimately, these types of delightful journeys will generate a notable business impact, from boosting retention, to lifting conversions, and improving LTV.

Things you can do with a deep linking engine

Simple things
(1) Increase app engagement for existing users by sending an email with a link that sends users directly to a product page in your app.
(2) Drive app growth via a campaign with paid influencers who embed a link in their YouTube clip description. The links direct new iOS users to the App Store and new Android users to the Play Store, and then they are redirected to the contextual content in the app presented by the influencer in their clip.

More powerful things
(1) Drive app growth by setting up a web-to-app journey that begins with a mobile web banner that captures and reports the sources of incoming traffic, and then redirects users to the right app store, followed by the relevant in-app content.
(2) Increase app adoption by creating a campaign directing users to a mobile web landing page that displays multiple CTA buttons, each of which redirects users to different app stores and ultimately the app. (a la Coinbase’s Super Bowl commercial).

One final but very important factor to understand is the distinction between deep linking and deep linking engines. 

• Deep linking refers to the action of delivering users to specific in-app content from wherever they are 
• Deep linking engines allow brands to redirect users to different destinations (i.e., deep linking) including digital locations such as web landing pages and app stores.

Chapter 2

The benefits of deep linking

Now that you know a little bit more about deep linking, how it works, and some things you can do with it, let’s get back to basics and answer the question: Why do you need deep linking in the first place? 

App marketers and product managers use deep linking for a simple reason: 

Deep linking allows them to increase conversions by creating awesome, easily-created customer experiences that drive new and existing users to their app from any channel

By offering great customer experience (CX), marketers take more users to their desired destination — thereby widening the bottom of the funnel. Product managers, on the other hand, can better engage and retain their users. 

Great CX leads to business results, and the business impact resulting from investment in customer experience is known as return on experience (ROX).

We’ve been keeping close tabs on ROX for a while and have witnessed the dramatic uplift in click-to-install and share of paying users rates for customers that use deep linking. 

• Click-to-install (CTI) rates: While generic journeys –- which lack contextualization and personalization –- score just over 5% click-to-install (CTI) rates, deep linking-enabled experiences deliver up to 6X higher conversion rates.
  
  Take journeys beginning on a brand’s mobile website (web-to-app) and in the physical world (QR-to-app) as examples. They show remarkable 27% and 33% CTI rates across all verticals, respectively.

• Share of paying users: The smooth journey provided by deep linking into a specific app page also increases the share of paying users, which is the percentage of users that make a purchase after installing an app. 

For example, when food and drink brands use text messages to engage their users, an average of 14% of users make a purchase

Chapter 3

Deep linking, Universal Links, and App Links, oh my

Any basic primer on deep linking would be incomplete without a discussion around Universal Links, App Links, and URI schemes. This is going to be a brief introduction  but if you feel like deep diving into the topic — this dedicated blog and our Dev Hub can offer plenty of insights. 

Let’s start with Apple Universal Links and Android App Links. First of all, they’re not really links.

Universal Links (iOS) and App Links (Android) are very similar mechanisms that can be applied to any campaign link in order to send users directly into an app (provided they have it). 

Users sent to the app are then brought to the right in-app content (i.e., deep linked) based on the routing behavior defined in the deep linking solution. 

There are a number of clear benefits to using Universal Links and App Links:

1. Improve customer experience – Universal LInks and App Links open an app in a rapid, seamless way, presenting users with the most relevant in-app content without skipping a heartbeat, or having to launch the app, search for the correct content, and all that tiring stuff no one has time to do.
   
2. Boost app conversions – A welcome by-product of improved customer experience is a boost to conversion rates. The quicker and more smoothly a user is brought to the content they want to see, the more likely they are to convert.
   
3. Increase retention rates – The overall improved experience results in higher engagement and retention. It’s well known that it’s easier to re-engage with an existing user than to acquire a new one, which makes engagement maintenance imperative.
   
4. Provide a secure path for users to follow – Universal Links and App Links are designed by Apple and Google, respectively, to prevent hackers from hijacking unsuspecting users to fraudulent apps.

What about a URI scheme? That would be another mechanism that allows users to open an app that’s installed on a device. Because URIs are considered less secure than Universal Links and App Links, they’ve gradually become less popular. 

Chapter 4

Deferred deep linking: basics and benefits

At the beginning of this guide, we briefly introduced the concept of deferred deep linking. Since it’s part and parcel of any deep linking solution and has become an essential element of any mobile marketer’s UA toolbox, let’s dig in a little more.

Why is deferred deep linking so critical to building great mobile journeys? In the simplest terms, it’s a way to deliver app-less users to their in-app destination in the smoothest, quickest way possible. 

Here’s an example:

• Thanksgiving’s just around the corner, and I stumble across a great clip with an influencer sharing a recipe for a lovely holiday dinner. 
• The clip’s description includes a link that will allow me to buy the ingredients online at a nearby grocery retailer.
• Luckily, the marketer at the grocery brand has given the influencer in the clip a link created by a deep linking engine. 
• I’m redirected to the App Store, where I download the grocery store’s app. 
• After launching the app, I am deep-linked to the checkout page with all of the ingredients already populated in my shopping cart.

What would happen without deferred deep linking? That would depend on a few variables, such as how the grocery brand’s marketer set up the rerouting paths. 

The marketer would have to create different links for various scenarios and edge cases, and I would have to follow a tedious, multi-step process to get to the recipe:

• I’d see links in the description of the influencer’s clip to download the app in different app stores. 
• I’d head to the App Store to download and install the app.
• Then I’d head back to the clip to find another link to the in-app content (the checkout page).
  

In short, without deferred deep linking, it’s nearly impossible to provide a smooth, personal, and contextual path to the right place in the app, which would clearly undermine the ability to ramp up acquisition goals.

Deferred deep linking helps drive UA and return on experience (ROX)
Smooth, contextual CX results in delighted users, and up to sixfold boost in click-to-install we see with deferred deep linking users.

Chapter 5

Use cases: Deep linking & deferred deep linking

What do these flows or journeys actually look like and when should you use them? 

This section deep-dives into six use cases that address specific business challenges. Three of these use cases will cover deep linking, which is typically used in re-engagement and retention efforts, and three will cover deferred deep linking, which is usually associated with user acquisition campaigns.

Deep linking for re-engagement and retention

A. Cart abandonment (email marketing/eCommerce)

Cart abandonment is a huge problem for retailers. After browsing, shopping, and filling their cart, users can easily decide not to complete their purchase for one reason or another.  

A proven way to re-engage customers who have left their shopping cart full of goods is to proactively send them emails. 

Cart abandonment emails have high open and click-through rates, about 45% and 21%, respectively. More to the point, relevant, contextual emails can recover about 1% of potential lost revenue. (Sitecore) 

In the example below, a fashion retailer set up an automated process that sends emails to customers who have left goods in their carts. 

The marketer uses a deep linking solution to ensure that a user with the app is brought in a hassle-free way to the checkout page, which is already conveniently populated with the items that were left in the cart.

B. User acquisition (Friend referrals / Gaming)

Even in the digital age, word-of-mouth remains a powerful tactic for product and brand awareness. 

In fact, consumers are four times more likely to buy when referred by a friend, so it’s no surprise that many brands encourage existing users to invite their friends to share in the fun.

In the highly competitive gaming vertical, leveraging word-of-mouth serves a dual purpose: existing users keep playing the game and become more loyal, and referred friends join as new app users.

In this use case, a gaming app incentivized its users to invite friends to a head-to-head game via a very simple and quick process. 

The gamer sends a WhatsApp invite, the friend clicks on the link, downloads the game from the App Store, launches the app, and is magically brought to the waiting area in the app. Let the games begin. 

C. Average order value (Social media / Retail)

Average order value (AOV) is an eCommerce metric that measures the average total of each order over a defined period of time. This KPI is all about low-hanging fruit. Think about it: if a shopper is about to make a purchase, why not pique their interest with additional products they might need?

With the share of eCommerce revenue on mobile expected to jump from 64% in 2021 to 67% in 2024, it’s safe to say that the best channel for AOV uplift is mobile apps.

In the example below, a fashion brand shares an “outfit of the day” story on Instagram, which includes different products. Once shoppers swipe up, they are redirected to an AppsFlyer social landing page (to prevent Instagram from breaking the link).

By tapping on the “check it out now” CTA button, shoppers are taken to a pre-populated check-out page in the app, including all the products that appeared in the story. 
By providing a delightfully consistent social-to-app experience, shopping apps can achieve amazing re-engagement conversion rates (more than 10% in this case).

D. Traditional banking: Process abandonment (SMS / Banking)

When it comes to digital journeys, an acute pain point for finance companies is the dropoff rate of prospective customers filling out extensive insurance forms. In fact, about 75% of forms in the finance industry are abandoned mid-process. 

But what if there was a way for finserv companies to assist their customers by allowing them to take advantage of CX-superior apps?

This is what forward-thinking firms already do. How? 

They combine one or more of their owned media channels with deep linking to remind customers of the form they left behind, and bring them directly to the drop-off point. This way they can easily complete their desired action with minimal hassle involved.

In the below example, Int Bank has set up a process that engages form-abandoning customers, using a deep linking product that dynamically creates a unique, personalized URL for each of these customers. 

An SMS messaging platform receives the link and schedules a reminder SMS that includes a CTA to continue filling out the form. When clicking the link, the app opens in the right location so that customers can pick up where they left off.

Firms that build continuous and personalized bridges to their app — can fulfill two critical goals simultaneously. They can “rescue” forms from being abandoned by customers with high intent, all while delighting customers by helping them achieve the original goals they had set out to achieve. 

Deferred deep linking for app UA

A. Migration to app (QR code / Banking)

Migrating customers to the app can be challenging, especially when it comes to Gen X and older users who prefer to do their banking on desktop. 

One tactic that has worked well for moving users to app banking is placing QR codes at key trigger points throughout the journey.

Widely used and gaining popularity during the pandemic, QR codes can be leveraged as an app onramp, providing peace of mind and ease of use to customers. 

Banks can place QR codes on any page of their desktop site, in-branch signage, and marketing materials — to allow users to download the app using a simple scan.

In the example below, a bank displays a QR code on the homepage of its desktop website to encourage a user to scan it. 

The marketer uses their deep linking solution to ensure that customers are redirected smoothly to the right app store and then to the right in-app content once the app has been launched. 

B. Increase lifetime value (Mobile web / Media and entertainment)

Newspapers and magazines have been with us way before the rise of the internet and smartphones. This industry has had to adapt and readapt itself to keep up with these two disruptive revolutions, which was achievable by repeatedly changing both its business model and distribution strategy.  

Today’s readers are on mobile, and to increase LTV, media publishers need to migrate their readers from print and web to their mobile apps.

In the example below, a news app displays a web banner to users, inviting them to download the app while they are reading a specific article. 

Once users tap on the banner, the deep linking engine ensures that they are automatically taken to the relevant app store where they can download the app. After launching it, they are redirected to the same article — which they can keep reading with ease.  

With this contextual web-to-app experience, media publishers are achieving more than 30% click-to-install (CTI) conversion rates. 

A similar flow and CTI can be achieved through QR-to-app experiences by adding QR codes to printed newspapers and magazines.

C. In-store conversion (QR code / Traditional retail)

Let’s see how a traditional retailer can use QR codes to spur in-store sales and drive user acquisition. 

Below is an example of a clothing retailer using QR codes to drive in-store purchases. The retailer is looking to address a common hurdle faced by in-store customers: the need for more information about the product they’re interested in buying.  

At home, shoppers can search online for reviews and user-generated content to help with their decision making. But at a physical store, a lack of information can lead to a decision to forego the purchase.  

To provide instant access to the relevant information, the brand places dedicated QR codes next to each product and uses a deep linking engine to redirect users to reviews in the right channel (either web or app).  

App users are sent to the right in-app page showing the app ratings and reviews, while users without the app are redirected to the mobile reviews web page.  

To drive app adoption by the latter group of web users, the retailer displays a banner with a discount, incentivizing the shopper to download the app. 

This enables retailers to provide excellent shopping experiences, build trust with their customers, increase their in-store conversion, and boost their ROX.  

Users that scan QR codes typically have high intent. After all, the customer is shopping and wants to learn more about a product before making a purchase. It’s no wonder, then, that click-to-install rates for QR codes stands at an outstanding 33%. 

Chapter 6

Deep linking implementation

Implementing deep linking is relatively straightforward. A handful of deep linking providers offer SAAS products, and can walk you through the creation of deep links for mobile marketing campaigns. 

At the highest level, marketers and product managers use deep linking solutions to define the journeys they’d like their end-users to take once they click on the deep links they create:

• For non-app users:
  • Where should iOS or Android users be rerouted – an app store? A web landing page?
  • Should the users be redirected to a specific page in the app after installing the app, i.e., should deferred deep linking be used?
• For app users:
  • Where in the app should iOS users be routed?
  • Where in the app should Android users be routed?
  • Where should Android users be sent if you only have an iOS app?

Marketers and product managers can also use the power of deep linking engines to better understand campaign performance. For example, by measuring installs, revenues, share of paying users, and LTV, or for capturing the sources of users who have clicked the deep links.

What about developers? Do they have a role in deep linking implementation? The answer is: they typically do, given the fact that the app needs to open on the deep-linked page. A good deep linking solution provides ample guidance on the hand-offs between developers and marketers / product managers.

One last word on implementing deep linking. You should identify a provider that offers more than just that. Adding another solution to your marketing tech stack is typically less desirable than using a rich, robust mobile marketing platform that includes deep linking functionality in its core feature set.

Chapter 7

Key takeaways

• Deep linking is critical for mobile UA and engagement. Marketers and product managers use it to help them compete and achieve their UA and engagement goals.
  
• Deep linking effectively addresses key business challenges such as cart abandonment, web-to-app migration, in-store conversion, brand awareness, and more.
  
• The primary benefit of deep linking is driving return on experience (ROX), leading to significant business impact in the form of conversions and revenue.
  
• It’s best to work with a technology provider that offers deep linking as part of a robust mobile marketing platform that includes attribution, fraud prevention, and campaign measurement.

Introduction

Deep linking. You’ve heard the term. Perhaps you’ve heard that it improves user experience, resulting in a significant boost of conversions and revenues. And maybe you’ve been searching high and low for the ultimate guide that’ll teach you the basics quickly in simple, non-technical language.

Well, you’re in luck. We’ve put together an introductory primer you can read in 15-20 minutes. Here’s what’s inside:

• An introduction to the concepts of deep linking and deferred deep linking
• An explanation on how they work
• A discussion of the benefits of deep linking and how it drives ROX (return on experience) 
• An overview on Universal Links, App Links, and URI schemes
• Use cases galore covering different industries and business challenges
• Implementation considerations
  

Sounds good? So what are you waiting for? Have at it.

Chapter 1

1. What is deep linking?

In the context of mobile, deep linking describes the action of delivering users to specific in-app content from wherever they are.

What kind of specific content? Well, pretty much any in-app destination other than the app’s home screen, from a product page to checkout.

That covers the destination. What about the starting point? In other words, where would you place a “deep link” — i.e. the URL —- that begins the deep linking journey? 

That’s easy — any place your potential or existing users may be looking at: Instagram, Snap, an email or text message, chat inboxes, search engines, QR codes on billboards or a pizza box. Mobile users are nearly everywhere, and you should be too.

To help you wrap your head around deep linking, we like to compare mobile marketers to taxi drivers, admittedly a strange comparison at first glance. 

It goes like this: The job of a taxi driver and marketer is ultimately the same: driving customers from point A to point B. And while taxi drivers use a car for their job, marketers achieve this by using deep linking technology.

In a nutshell, deep linking is used to bring users from just about anywhere to nearly any digital destination. When it comes to mobile, it is most commonly used by marketers and product managers to drive app growth, engagement, and retention. 

How deep linking actually works

Now comes the interesting part. How can marketers and product managers make sure that the same link they’ve placed in a campaign triggers a smooth, seamless journey to specific content for any users — regardless of whether they have the app or not and irrespective of device (mobile or PC), operating system, browser, etc.?

That’s where the magic of deep linking happens.

Using a deep linking engine, marketers define the experience for users that will click on a link.

This can include things like where an app user should be redirected to, as well as different journeys for iOS, Android, and desktop users. 

At a very basic level, a deep linking engine allows marketers and product managers to provide two distinct types of journeys — one for app users and one for non-app users:

• If the user has the app — they are “deep linked” seamlessly to the content. 
• If they don’t have the app — a mechanism called “deferred deep linking” kicks in, where the user is brought to the right app store so that they download, install, and launch the app, after which the relevant in-app content will be displayed.

Crafting customized journeys for different users on the fly is what enables deep linking engines to create customer experiences that are contextual and personalized. Ultimately, these types of delightful journeys will generate a notable business impact, from boosting retention, to lifting conversions, and improving LTV.

Things you can do with a deep linking engine

Simple things
(1) Increase app engagement for existing users by sending an email with a link that sends users directly to a product page in your app.
(2) Drive app growth via a campaign with paid influencers who embed a link in their YouTube clip description. The links direct new iOS users to the App Store and new Android users to the Play Store, and then they are redirected to the contextual content in the app presented by the influencer in their clip.

More powerful things
(1) Drive app growth by setting up a web-to-app journey that begins with a mobile web banner that captures and reports the sources of incoming traffic, and then redirects users to the right app store, followed by the relevant in-app content.
(2) Increase app adoption by creating a campaign directing users to a mobile web landing page that displays multiple CTA buttons, each of which redirects users to different app stores and ultimately the app. (a la Coinbase’s Super Bowl commercial).

One final but very important factor to understand is the distinction between deep linking and deep linking engines. 

• Deep linking refers to the action of delivering users to specific in-app content from wherever they are 
• Deep linking engines allow brands to redirect users to different destinations (i.e., deep linking) including digital locations such as web landing pages and app stores.

Chapter 2

Great journeys lead to ROX – The benefits of deep linking

Now that you know a little bit more about deep linking, how it works, and some things you can do with it, let’s get back to basics and answer the question: Why do you need deep linking in the first place? 

App marketers and product managers use deep linking for a simple reason: 

Deep linking allows them to increase conversions by creating awesome, easily-created customer experiences that drive new and existing users to their app from any channel

By offering great customer experience (CX), marketers take more users to their desired destination — thereby widening the bottom of the funnel. Product managers, on the other hand, can better engage and retain their users. 

Great CX leads to business results, and the business impact resulting from investment in customer experience is known as return on experience (ROX).

We’ve been keeping close tabs on ROX for a while and have witnessed the dramatic uplift in click-to-install and share of paying users rates for customers that use deep linking. 

• Click-to-install (CTI) rates: While generic journeys –- which lack contextualization and personalization –- score just over 5% click-to-install (CTI) rates, deep linking-enabled experiences deliver up to 6X higher conversion rates.
  
  Take journeys beginning on a brand’s mobile website (web-to-app) and in the physical world (QR-to-app) as examples. They show remarkable 27% and 33% CTI rates across all verticals, respectively.

• Share of paying users: The smooth journey provided by deep linking into a specific app page also increases the share of paying users, which is the percentage of users that make a purchase after installing an app. 

For example, when food and drink brands use text messages to engage their users, an average of 14% of users make a purchase

Chapter 3

Deep linking, Universal Links, and App Links, oh my

Any basic primer on deep linking would be incomplete without a discussion around Universal Links, App Links, and URI schemes. This is going to be a brief introduction  but if you feel like deep diving into the topic — this dedicated blog and our Dev Hub can offer plenty of insights. 

Let’s start with Apple Universal Links and Android App Links. First of all, they’re not really links.

Universal Links (iOS) and App Links (Android) are very similar mechanisms that can be applied to any campaign link in order to send users directly into an app (provided they have it). 

Users sent to the app are then brought to the right in-app content (i.e., deep linked) based on the routing behavior defined in the deep linking solution. 

There are a number of clear benefits to using Universal Links and App Links:

1. Improve customer experience – Universal LInks and App Links open an app in a rapid, seamless way, presenting users with the most relevant in-app content without skipping a heartbeat, or having to launch the app, search for the correct content, and all that tiring stuff no one has time to do.
   
2. Boost app conversions – A welcome by-product of improved customer experience is a boost to conversion rates. The quicker and more smoothly a user is brought to the content they want to see, the more likely they are to convert.
   
3. Increase retention rates – The overall improved experience results in higher engagement and retention. It’s well known that it’s easier to re-engage with an existing user than to acquire a new one, which makes engagement maintenance imperative.
   
4. Provide a secure path for users to follow – Universal Links and App Links are designed by Apple and Google, respectively, to prevent hackers from hijacking unsuspecting users to fraudulent apps.

What about a URI scheme? That would be another mechanism that allows users to open an app that’s installed on a device. Because URIs are considered less secure than Universal Links and App Links, they’ve gradually become less popular. 

Chapter 4

Deferred deep linking basics and benefits

At the beginning of this guide, we briefly introduced the concept of deferred deep linking. Since it’s part and parcel of any deep linking solution and has become an essential element of any mobile marketer’s UA toolbox, let’s dig in a little more.

Why is deferred deep linking so critical to building great mobile journeys? In the simplest terms, it’s a way to deliver app-less users to their in-app destination in the smoothest, quickest way possible. 

Here’s an example:

• Thanksgiving’s just around the corner, and I stumble across a great clip with an influencer sharing a recipe for a lovely holiday dinner. 
• The clip’s description includes a link that will allow me to buy the ingredients online at a nearby grocery retailer.
• Luckily, the marketer at the grocery brand has given the influencer in the clip a link created by a deep linking engine. 
• I’m redirected to the App Store, where I download the grocery store’s app. 
• After launching the app, I am deep-linked to the checkout page with all of the ingredients already populated in my shopping cart.

What would happen without deferred deep linking? That would depend on a few variables, such as how the grocery brand’s marketer set up the rerouting paths. 

The marketer would have to create different links for various scenarios and edge cases, and I would have to follow a tedious, multi-step process to get to the recipe:

• I’d see links in the description of the influencer’s clip to download the app in different app stores. 
• I’d head to the App Store to download and install the app.
• Then I’d head back to the clip to find another link to the in-app content (the checkout page).
  

In short, without deferred deep linking, it’s nearly impossible to provide a smooth, personal, and contextual path to the right place in the app, which would clearly undermine the ability to ramp up acquisition goals.

Deferred deep linking helps drive UA and return on experience (ROX)
Smooth, contextual CX results in delighted users, and up to sixfold boost in click-to-install we see with deferred deep linking users.

Chapter 5

Use cases: Deep linking & deferred deep linking

What do these flows or journeys actually look like and when should you use them? 

This section deep-dives into six use cases that address specific business challenges. Three of these use cases will cover deep linking, which is typically used in re-engagement and retention efforts, and three will cover deferred deep linking, which is usually associated with user acquisition campaigns.

Deep linking for re-engagement and retention

A. Cart abandonment (email marketing/eCommerce)

Cart abandonment is a huge problem for retailers. After browsing, shopping, and filling their cart, users can easily decide not to complete their purchase for one reason or another.  

A proven way to re-engage customers who have left their shopping cart full of goods is to proactively send them emails. 

Cart abandonment emails have high open and click-through rates, about 45% and 21%, respectively. More to the point, relevant, contextual emails can recover about 1% of potential lost revenue. (Sitecore) 

In the example below, a fashion retailer set up an automated process that sends emails to customers who have left goods in their carts. 

The marketer uses a deep linking solution to ensure that a user with the app is brought in a hassle-free way to the checkout page, which is already conveniently populated with the items that were left in the cart.

B. User acquisition (Friend referrals / Gaming)

Even in the digital age, word-of-mouth remains a powerful tactic for product and brand awareness. 

In fact, consumers are four times more likely to buy when referred by a friend, so it’s no surprise that many brands encourage existing users to invite their friends to share in the fun.

In the highly competitive gaming vertical, leveraging word-of-mouth serves a dual purpose: existing users keep playing the game and become more loyal, and referred friends join as new app users.

In this use case, a gaming app incentivized its users to invite friends to a head-to-head game via a very simple and quick process. 

The gamer sends a WhatsApp invite, the friend clicks on the link, downloads the game from the App Store, launches the app, and is magically brought to the waiting area in the app. Let the games begin. 

C. Average order value (Social media / Retail)

Average order value (AOV) is an eCommerce metric that measures the average total of each order over a defined period of time. This KPI is all about low-hanging fruit. Think about it: if a shopper is about to make a purchase, why not pique their interest with additional products they might need?

With the share of eCommerce revenue on mobile expected to jump from 64% in 2021 to 67% in 2024, it’s safe to say that the best channel for AOV uplift is mobile apps.

In the example below, a fashion brand shares an “outfit of the day” story on Instagram, which includes different products. Once shoppers swipe up, they are redirected to an AppsFlyer social landing page (to prevent Instagram from breaking the link).

By tapping on the “check it out now” CTA button, shoppers are taken to a pre-populated check-out page in the app, including all the products that appeared in the story. 
By providing a delightfully consistent social-to-app experience, shopping apps can achieve amazing re-engagement conversion rates (more than 10% in this case).

D. Traditional banking: Process abandonment (SMS / Banking)

When it comes to digital journeys, an acute pain point for finance companies is the dropoff rate of prospective customers filling out extensive insurance forms. In fact, about 75% of forms in the finance industry are abandoned mid-process. 

But what if there was a way for finserv companies to assist their customers by allowing them to take advantage of CX-superior apps?

This is what forward-thinking firms already do. How? 

They combine one or more of their owned media channels with deep linking to remind customers of the form they left behind, and bring them directly to the drop-off point. This way they can easily complete their desired action with minimal hassle involved.

In the below example, Int Bank has set up a process that engages form-abandoning customers, using a deep linking product that dynamically creates a unique, personalized URL for each of these customers. 

An SMS messaging platform receives the link and schedules a reminder SMS that includes a CTA to continue filling out the form. When clicking the link, the app opens in the right location so that customers can pick up where they left off.

Firms that build continuous and personalized bridges to their app — can fulfill two critical goals simultaneously. They can “rescue” forms from being abandoned by customers with high intent, all while delighting customers by helping them achieve the original goals they had set out to achieve. 

Deferred deep linking for app UA

A. Migration to app (QR code / Banking)

Migrating customers to the app can be challenging, especially when it comes to Gen X and older users who prefer to do their banking on desktop. 

One tactic that has worked well for moving users to app banking is placing QR codes at key trigger points throughout the journey.

Widely used and gaining popularity during the pandemic, QR codes can be leveraged as an app onramp, providing peace of mind and ease of use to customers. 

Banks can place QR codes on any page of their desktop site, in-branch signage, and marketing materials — to allow users to download the app using a simple scan.

In the example below, a bank displays a QR code on the homepage of its desktop website to encourage a user to scan it. 

The marketer uses their deep linking solution to ensure that customers are redirected smoothly to the right app store and then to the right in-app content once the app has been launched. 

B. Increase lifetime value (Mobile web / Media and entertainment)

Newspapers and magazines have been with us way before the rise of the internet and smartphones. This industry has had to adapt and readapt itself to keep up with these two disruptive revolutions, which was achievable by repeatedly changing both its business model and distribution strategy.  

Today’s readers are on mobile, and to increase LTV, media publishers need to migrate their readers from print and web to their mobile apps.

In the example below, a news app displays a web banner to users, inviting them to download the app while they are reading a specific article. 

Once users tap on the banner, the deep linking engine ensures that they are automatically taken to the relevant app store where they can download the app. After launching it, they are redirected to the same article — which they can keep reading with ease.  

With this contextual web-to-app experience, media publishers are achieving more than 30% click-to-install (CTI) conversion rates. 

A similar flow and CTI can be achieved through QR-to-app experiences by adding QR codes to printed newspapers and magazines.

C. In-store conversion (QR code / Traditional retail)

Let’s see how a traditional retailer can use QR codes to spur in-store sales and drive user acquisition. 

Below is an example of a clothing retailer using QR codes to drive in-store purchases. The retailer is looking to address a common hurdle faced by in-store customers: the need for more information about the product they’re interested in buying.  

At home, shoppers can search online for reviews and user-generated content to help with their decision making. But at a physical store, a lack of information can lead to a decision to forego the purchase.  

To provide instant access to the relevant information, the brand places dedicated QR codes next to each product and uses a deep linking engine to redirect users to reviews in the right channel (either web or app).  

App users are sent to the right in-app page showing the app ratings and reviews, while users without the app are redirected to the mobile reviews web page.  

To drive app adoption by the latter group of web users, the retailer displays a banner with a discount, incentivizing the shopper to download the app. 

This enables retailers to provide excellent shopping experiences, build trust with their customers, increase their in-store conversion, and boost their ROX.  

Users that scan QR codes typically have high intent. After all, the customer is shopping and wants to learn more about a product before making a purchase. It’s no wonder, then, that click-to-install rates for QR codes stands at an outstanding 33%. 

Chapter 6

Deep linking implementation

Implementing deep linking is relatively straightforward. A handful of deep linking providers offer SAAS products, and can walk you through the creation of deep links for mobile marketing campaigns. 

At the highest level, marketers and product managers use deep linking solutions to define the journeys they’d like their end-users to take once they click on the deep links they create:

• For non-app users:
  • Where should iOS or Android users be rerouted – an app store? A web landing page?
  • Should the users be redirected to a specific page in the app after installing the app, i.e., should deferred deep linking be used?
• For app users:
  • Where in the app should iOS users be routed?
  • Where in the app should Android users be routed?
  • Where should Android users be sent if you only have an iOS app?

Marketers and product managers can also use the power of deep linking engines to better understand campaign performance. For example, by measuring installs, revenues, share of paying users, and LTV, or for capturing the sources of users who have clicked the deep links.

What about developers? Do they have a role in deep linking implementation? The answer is: they typically do, given the fact that the app needs to open on the deep-linked page. A good deep linking solution provides ample guidance on the hand-offs between developers and marketers / product managers.

One last word on implementing deep linking. You should identify a provider that offers more than just that. Adding another solution to your marketing tech stack is typically less desirable than using a rich, robust mobile marketing platform that includes deep linking functionality in its core feature set.

Chapter 7

Key takeaways

• Deep linking is critical for mobile UA and engagement. Marketers and product managers use it to help them compete and achieve their UA and engagement goals.
  
• Deep linking effectively addresses key business challenges such as cart abandonment, web-to-app migration, in-store conversion, brand awareness, and more.
  
• The primary benefit of deep linking is driving return on experience (ROX), leading to significant business impact in the form of conversions and revenue.
  
• It’s best to work with a technology provider that offers deep linking as part of a robust mobile marketing platform that includes attribution, fraud prevention, and campaign measurement.

Introduction

Deep links have a storied history as an essential element of attribution. In early 2015, the term and its associated technology barely made sense to even the most savvy technical marketer.

Today, it’s a ubiquitous element of every marketer’s jargon and attribution stack.

But while many recognize the overall importance of deep linking to the mobile user experience and high-performance paid marketing, few truly understand how things work and how deep linking can be leveraged to drive results.

This should come as no surprise since deep linking has become more complex and confusing with the advent of Apple Universal Links and Android App Links.

But it doesn’t have to be confusing; the goal of this guide to provide you with everything you need for understanding about deep linking, recognizing its value to your business, and learning how to employ it in your attribution strategy.

Chapter 1

What is deep linking?

The basics

What is a deep link?

Well, many people may not be familiar with the term, but they do know what links are.

You can’t understand deep links if you don’t understand links.

We use links for many things: to drive users to product pages, to execute paid campaigns on Facebook, to route users to an app store from web and email, and even to communicate important offers and deals in the app.

Links are used by apps, big and small, to drive users to the proper destination on the web and, of course, in the app.

So, then, what is a link?

A link is sometimes referred to as a URL or URI (Uniform Resource Locator / Identifier).

A link is merely an address, name, or reference to a file on “The internet”!

You can think of a link as a specific address on a specific street in a specific zip code.

When you type ‘https://www.walmart.com’, you’re working in the same mental model as if you are looking for an actual address in the physical world.

Where this analogy diverges is that a link, or URL, refers not to a house with an address, but to a file with a digital address.

This address is the URL.

Most URLs refer to a file on a computer or machine on a network that exists in the world. Just as we know addresses reference a house, office, or residence somewhere in the world, digital addresses – links – do the same thing with files and resources on the internet.

Links, or URLs, can refer to many types of resources, just as physical addresses can refer to many types of structures, like apartments, malls, offices, government buildings and more. URLs can be files (like an HTML page), databases, APIs, and much more.

A Link is a URL, and a URL is a URI

This is hopefully where the dots will start to connect.

In mobile, the term “URI” is flung around often, but most folks don’t know what this is or how it relates to everyday links.

In programming, a URI (Uniform Resource Identifier) is just a string of characters to identify the name of a resource on a network.

A URI is just another address in the world.

But the most common URI out there is the URL, a Uniform Resource Locator, which we have discussed at length.

URIs are not just limited to this so when you hear “URI scheme” or “URI” you should know that people are actually just talking about garden variety links, the same type you likely use in email campaigns, affiliate promotions, and on social media to promote products or your app.

Let’s put our knowledge into practice and look at a link:

Example Link
‘https://www.walmart.com’

This is a URL or “link”. It has two main components, separated by a colon.

Protocol Identifier (Scheme)
‘https’ – this is the protocol identifier or the scheme.

Resource Name
‘www.walmart.com’ – this entire string is called the “Resource Name.” It includes the subdomain, domain, and top level domain (in that order) combined into a single string. While not explicitly seen here, everything after the final slash “/” is called the “path” or “pathname”. If the URL is an address, then the pathname is the actual room in the house or building that the URL refers to!

If we think back to our physical address analogy, the scheme identifier most accurately embodies the mail carrier you use to send mail to the address. There’s UPS, Fedex, DHL, USPS and other options. Similarly, in the digital world, there are many types of schemes over which to send data, like accessing a website, downloading a file, or even sending digital mail. Other schemes include File Transfer Protocol (ftp), Gopher (gopher), File (file), and News (news).

HTTP stands for Hyper Text Transfer Protocol (HTTP), which is typically used to serve hypertext documents. The “S” in HTTPS is just the secure version of HTTP – it actually just stands for “Secure.” The HTTP and HTTPS protocols are typically used to send data between your browser and the website address you’re accessing.

Links as addresses

Here’s a comparison of a real life address to a digital address, and how the components of each are related.

As you can see, just like a physical address, a link has similar identifying features. Understanding how links are structured is the basis of understanding what deep links are and how they behave in a variety of situations.

What it’s Called	Real Life Address	Digital Address	What it’s Called
Complete Mailing Address	Facebook 1 Hacker Way, Suite 1 Menlo Park, CA 94025	https://www.facebook.com/zuck	Complete Digital Address (Link or URL)
Recipient Line	Facebook	facebook	Subdomain
Delivery Address	Menlo Park, CA 94025	www	Domain
Country	United States	.com	Top Level Domain
Carrier/Mail Delivery	UPS, Fedex, USPS	HTTP, FTP, fb://	Protocol Identifier or Scheme
Building & Office, Apartment, Suite etc.	1 Hacker Way Suite 1	zuck	Path

Here’s what to take away from the above table:

1. A link is just a digital address. An address is to a map as a link is to the internet.
2. A link is a URL. A URL is a type of URI. These things have fancy names, but at their core serve the same purpose and mean similar things.
3. A URL is made up of a “Scheme” and a “Resource Name.” The “Resource Name” has four important components:
   1. Subdomain
   2. Domain
   3. Top Level Domain
   4. Path
4. Deep links are very specific URLs, just like specific websites or physical addresses.

The mobile context: URI schemes=App PO boxes

Deep linking starts and ends with URLs, or URIs.

Just as we discussed before, a link and a URL are one and the same.

At a very high level a deep link is a link, or a special URL that routes to a specific spot, whether that’s on a website or in an app. These particular spots are deep links.

These might not be publicly visible to the world, but they exist as a real place to reference.

Key Point: The term “deep link” has come to mean the routes to specific spots on websites and to a native application via a link. A version of the term, called a “mobile deep link,” is a link that contains all the information needed to take a user directly into an app or a particular location within an app instead of just launching the app’s home page.

Deep links on the web are no different than deep links for apps – in both cases, links conceptually function the same.

The only difference is the way they look and behave. Most often people interchange the term URI or “URI Scheme” with a deep link. This is not only technically incorrect, but creates confusion.

The proper way to think about deep links is as follows:

• There are many types of deep links – including deep links that go to websites and to the app
• A deep link is just a link, which is a URL
• URLs can be deep links

Here is where things all come together: Remember the thing we talked about before, “schemes”?

An app can have its own special way of opening via a customized, registered scheme.

This is called the app’s “URI Scheme”. You can think of a “URI Scheme” like PO Boxes.

You can send mail to PO Boxes, but some differences and restrictions apply.

They don’t behave the same as regular mailing addresses. Each app has its own URI scheme that is registered to the app with the app stores and which is specially designed just to open that app.

Deep link?	Link examples	Description
No	https://nytimes.com	This is a link that goes to a “top level domain” page. This is not a deep link because it doesn’t go anywhere deeper within the domain.
Yes	https://www.hbe.io/about	This is a deep link because it goes to a place deeper within the website than just the main splash page.
Yes (Kind of)	nytimes://	This is the iOS URI Scheme to launch Times’ mobile app. People often interchange this with the term “deep link” which is incorrect. The correct thinking is that this URI Scheme can deep link a user into the app in certain contexts.
Yes	nytimes://ip/Trump-Korea-Tensions/172218418	This is a deep link. It is the iOS URI Scheme to launch the Times’ mobile app followed by the “route” to deep link a user to this particular item.

Key takeaways

• A URI Scheme is a way to directly open the app if it is installed on the device – this is the same as being able to send mail to a very specific Box if you have a PO Box number. The PO Box system is regulated by USPS, just like URI Schemes are regulated by the app engineers and the app stores.
• The term “deep links” is often incorrectly interchanged with an app’s URI Scheme. A URI Scheme with a specific path (`nytimes://ip/Trump-Korea-Tensions/172218418`) is a deep link.
• All of these are deep links:
  • https://www.facebook.com/zuck
  • fb://zuck
  • nytimes://ip/Trump-Korea-Tensions/172218418

Chapter 2

Making sense of Universal Links and App Links

Marketing and product teams are often confused by the concept of Apple Universal Links (iOS) and Android App Links (Android) and how they relate to deep linking.

What is not well-explained is the fact that these links are not really different “links” at all, but rather are behaviors or mechanisms applied to certain links that control how a user navigates to the app.

Similarly, the two different names refer to essentially the same concept, but are often interchanged, or confused with other routing mechanisms. It’s important to be explicit when you talk about these concepts, else you risk confusing or confounding different technologies which operate very differently.

Specifically, Apple Universal Links are a standard from Apple that is deployed on the iPhone operating system (iOS), which allows a user to tap a link and be delivered immediately to the app (if it’s installed on their device).

Apple Universal Links are neither new, different, or special links, nor are they link redirects.

They function as part of a complex system setup that changes the behavior of regular old links, turning them into app deep links in certain contexts. When the user taps the link, a roundtrip server call is made to Apple and the OS opens the app immediately without ever opening the browser or loading the URL. More about how this works below.

Android App Links is the equivalent linking system that is setup on Android.

How universal links and app links work

For the purpose of explanation, let’s talk about how these two systems work from the perspective of the Skyscanner app. Generically, an Apple Universal Link or Android App Link is any link that, when tapped, takes the user directly to the app.

Most marketers and product managers are accustomed to seeing redirects, where a link goes to a browser before ultimately sending the user to a final destination.

Apple Universal Links and Android App Links are not redirects – they are actually a special technology applied to links that sends users directly to the app.

When you download an app that has Universal Links or App Links enabled on its links, you are also downloading a special file. On iOS this is called the Apple App Site Association file. On Android it’s called the Assetlinks file.

Both of these files are hosted on the actual website of the links in question and both these files contain a type of map of where to send the user when they tap the link in the future. Coupled with these files is a small code change that allows the app to take the user to the right spot.

Try it out and see for yourself what the technology looks like.

Just visit the domain, followed by apple-app-site-association: https://www.skyscanner.co.il/apple-app-site-association

And just as normal skyscanner.com links can be Apple Universal Links, so too can skyscanner.com’s attribution links. Herein lies a nugget of important information: Android App Links and Apple Universal Links is a system that is applied to all types of links – including the links for a company’s website as well as the links they use in attribution and deep linking.

As mentioned before, third parties like AppsFlyer can also leverage the concept of Apple Universal Links and Android App Links on their customers’ behalf so that these attribution links take users to the app if they have it. The result is that users have a better experience across paid and non-paid channels.

The relationship between Universal Links, App Links and your attribution links can be confusing and is lost on even some of the most technical marketing teams.

The correct, technically accurate way to consider things is that your attribution and deep linking provider, such as OneLink, supports Apple Universal Links. It supports this Apple-developed mechanism that allows the app to open on iOS 9.3+.

In other words, Apple Universal Links is a standard that can be applied to any link, and the best attribution and deep linking vendors support this standard.

Known problems with Apple Universal Links

Apple Universal Links is a useful technology that is proven to offer a better UX for users who have the app.

However, these links have a few important limitations to be aware of else you and your product teams will be spending endless hours debugging issues that cannot be fixed. There are actually four core issues as of the writing of this document (iOS 11). They almost all only applicable to Apple Universal Links, not Android App Links.

Issue 1: No measurement or attribution

Because Apple Universal Links are not a redirect, but rather a system applied to links to open the app, it is very difficult to establish true click measurement.

Why? Because the app opens immediately from Apple Universal Links.

There’s no redirect through a webpage to count a click to a server. Instead, when the app opens, the URL that opens the app gets reported in via a well known Apple code snippet called ‘continueUserActivity’.

To count a click on the URL, a marketing team would have to setup a server and manually count the click from the app.

A much simpler and easier solution is to use an attribution and deep linking tool. These systems enable marketers to leverage Universal Links and automatically execute this type of measurement for you. In short, whenever you need to measure users who click on links, you should use a third party tool, such as OneLink.

Issue 2: No link wrapping allowed

This problem goes by many names – link wrapping, click measurement, link redirect – they all refer to the same thing.

When a marketer runs an ad or sends an email, often the service they are using will take the link they are using and “wrap it” or send it through a redirect so that the system they are using can count a click. It does this by redirecting to their website before sending the user to the final destination URL that the marketer input into the system.

Both Apple Universal Links and Android App Links cannot be wrapped in other URLs.

If you do this, the link will redirect users to the web fallback instead of to the app.

This mostly impacts marketers running paid ads with services like Double Click (where URLs get wrapped) and email marketers who have click measurement enabled with their email service provider (ESP).

In both cases, other third party tools may wrap URLs you are using that would otherwise behave as Universal Links. This breaks the functionality and defeats the purpose of using Universal Links. There are a variety of solutions to this, from turning off click measurement to employing a specialty consultant to help navigate the complexity.

Get the latest marketing news and expert insights delivered to your inbox

Issue 3: Phantom banner syndrome

For some reason, Apple may randomly inject a banner ad onto your site in Safari when Universal Links are implemented.

There is no way to control this, customize it, or measure it. It’s a strange feature that Apple introduced with Universal Links and has confused the market quite a bit.

Most customers just choose to ignore this, as it is only displayed in a few cases, while a click on Apple Universal Links would normally take the user to your app and not your website.

Issue 4: General performance instability

Starting with iOS 11, many app developers have noticed that Universal Links do not always perform the same way.

Assuming you’ve set up Universal Links on your regular URLs or on the URLs you use for your attribution provider, you can test this by doing the following:

1. Log out of app
2. Delete app
3. Install the app from the App Store or test/QA site
4. Restart the device (turn off and then on again) – on iOS 11 this can often fix strange entitlement issues where the behavior of the link is not correct when clicked
5. Create or find a link you are trying to test
6. Paste the link in Notes, iMessage or in an email using the Apple Mail Client
   • Do not use Slack, Facebook or any other app to click the link
   • Do not paste the link into Safari – this will not work correctly
7. Click the link
8. The app should open immediately, without a redirect through the browser, and route the user to the proper place in the app

The following illustration will make sense of it all:

Key takeaways

Both Apple Universal Links and Android App Links are fairly complex technical systems.

They do not describe special links, but rather refer to a unique and advanced system of routing users, leading to many pitfalls and issues to deal with.

The key takeaways about both these technologies are the following:

1. It’s a system applied to links that controls their behavior.
2. Both systems allow users with the app to click a link and be immediately routed to the app (without any redirects).
3. It makes regular web links into app deep links, but the technology can also be applied to third party vendor links, like offerings from attribution vendors such as AppsFlyer. In this case, your attribution links can open the app immediately, allowing for a better UX and higher performance when running retargeting and other types of re-engagement campaigns.
4. There are many known issues that even marketers must know how to properly test links in order to avoid confusion when running ads that deep link users into the app.

Chapter 3

Why deferred deep linking is a game changer

Why don’t regular links that open websites, also open apps?

You don’t have to do anything special to visit Mark Zuckerberg’s Facebook page (‘https://www.facebook.com/zuck’).

You just type his website address into the browser and the page loads. This is why you almost never hear the term “deep linking” in reference to websites, but rather in reference to native apps.

It’s because apps don’t behave like browsers.

They can’t receive mail in the same way that your house or office receives mail. They behave like PO Boxes. Apps have to be configured correctly and specifically for each app – or by comparison, they require their PO Box to be registered in order to be opened by a user directly via a URI scheme.

The technology that solves this problem is called deferred deep linking.

What is deferred deep linking?

It’s a concept invented by the deep linking industry in 2014. It refers to the process of deep linking a user after they install an app for the first time.

If a user can’t access the PO Box, they can install the app and access it after.

Deferred deep linking ensures that after they install, the user gets to the right spot in the app. Deep linking providers can defer or delay the deep linking process until after the app has been downloaded.

How deferred deep linking works

The attribution provider would create a special link or URL which:

1. Tries to open the PO Box (URI Scheme). If it works then the user goes right into the app
2. If the PO Box can’t be reached (URI Scheme doesn’t work) it means the user doesn’t have the app, so instead it delivers the user to the App Store or Website – you can think of this as the home or office address.
3. After the user installs the app, the attribution provider can send the mail to the PO Box (to the app) after the user opens from an install, allowing the user to continue their user experience.

Example deep link:

https://walmart.onelink.me/UIev?pid=Test&c=Test&af_dp=walmart%3A%2F%2Fip%2F33982751&af_web_dp=https%3A%2F%2Fwww.walmart.com%2Fip%2FIAMS-PROACTIVE-HEALTH-Adult-MiniChunks-Dry-Dog-Food-40-Pounds%2F33982751

In this case, the URL is an AppsFlyer link.

It behaves as a deep link because it tries to open Walmart’s URI Scheme, and if not, it falls back to the App Store.

• URI Scheme: walmart://
• Deep link path: af_dp

The importance of deferred deep linking

Previously, the only way to integrate deep linking was through heavy lifting across all mobile platforms a developer supports (App Store, Play Store, Windows etc.).

This was a huge barrier to entry for small developers hoping to create an easy way for all users to access their app.

Another big problem with deep linking is that it could not carry data through the app install process. Or, in other words, if the PO Box wasn’t setup then a user couldn’t get mail!

Without a URI scheme, there was no reliable way to deliver the user to the app, even when they didn’t have it installed. Deep links don’t provide context about the user unless they have the app already installed on their device.

Deep links provide a whole host of benefits related to this problem:

• Optimal Conversion: For e-commerce and other brands that sell products or services in their app, only deep links allow you to drive users straight to the point of sale, even after install
• Better User Experience: Users can go to the app store or app and get driven to a particular spot in the app after the install
• Personalization: Deep links allow user information to carry through the install process, which enables apps to deliver a custom welcome message or personalize the first experience in other ways

For technical minds, deep links and attribution vendors also provide a slew of benefits:

• Data reliability: All your data can be consolidated by device and user identity, making it easy for you to export data to a downstream source or visualize in a vendor dashboard
• Deferred deep linking: Better ads, better customer experience and improved conversion
• Efficiency: Save money by not spending on ad sources that are leading to high uninstall rates
• Analytics: Measure more metrics via an integration with a CDP like mParticle that ties all data sources together in a single spot

• This matters a lot when over 60% of users drop off less than 24 hours after download, you’ve just provided the user’s first experience migrating to the native app as an error message.

More importantly, according to AppsFlyer data:

• Deep linking users from your paid attribution sources drives a 31% retention to the app
• Users convert at a 2.5x higher rate when they come from a deep link compared to a regular attribution link
• Deep links have higher intent, which means a much higher lift in revenue. In fact, industry reports show that deep linking provides a 148% lift in average revenue per user (ARPU)
• Users who click on a deferred or regular deep link such as AppsFlyer’s OneLink are 2X more likely to spend money in your app and will spend 2.7X more dollars on average

Key takeaways

• Web links can’t open apps like URI schemes can
• Using an attribution or deep linking vendor provides many benefits:
  • Optimal Conversion
  • Better user experience
  • Personalization

Chapter 4

Use cases: How to leverage deep links to drive better performance

We have established that deep linking is a feature of Attribution which drives a better user experience across different channels, and creates better performance from these channels.

This is especially relevant in cases where the number of steps to conversion dictates performance success. Leveraging deep links to drive users to the optimal place in the app as quickly as possible, and with the right context, can unlock a higher performance across paid and non-paid channels.

But what does “leveraging deep links” look like?

This is another common issue in the industry.

Many vendors talk about the value of deep linking without showcasing specifics. To try to combat this problem, below, we will explore how typical customers leverage an attribution and deep linking service in order to drive better UX and performance from paid and organic channels.

How does an eCommerce app think about use cases?

Let’s explore:

• Running mobile app download campaigns with Google, Facebook, Pinterest, Snapchat, etc.
• Deep link users to specific products, even through the install process across all these channels
• Create single URLs that can drive and measure installs or opens for all marketing org efforts
• Analyze performance of “Download the App” banner at the top of mobile Web page and in emails
• Send a live feed of app downloads to ad partners to create a real-time blacklist (don’t show ads to customers who already have the app)
• Show customers a dynamic “Easy Reorder” ad featuring products they’ve purchased before with a link to download the app and opening the Easy Reorder page upon app launch

But use cases don’t stop there.

You can leverage an attribution and deep linking solution to power a variety of use cases, all of which have had noticeable growth impacts and can help serve a mobile marketing team.

Deep linking use cases

Social

This is one of the most common use cases for leveraging mobile links.

In this example, a marketer or mobile app would place a link to content in the app on a well-known social channel, such as Facebook, Google, Twitter, Instagram, or Snapchat.

With a universal routing and attribution system, this single URL would be able to intelligently route the user to the app store if the user did not have the app, or open the app via Universal Links & Android App Links if they did.

Beyond this, there are solutions that have a built in feature that scrapes “Open Graph” information from the URL.

This means that the attribution link will display a preview of the content, title and description when the link is posted in social media. Similarly, this option allows the link to be shortened, conserving space in posts and providing a level of trust in the link the user is clicking.

Email

Email is another great medium to leverage attribution and deep links.

Traditional email service providers (ESPs) do allow you to measure clicks on links, but they don’t always have the ability to route the user to the app store or app intelligently.

Also, Universal Links usually break if you wrap click analysis around them.

An email marketer can create deep link urls programmatically or manually and place them in the email for a better user experience.

SMS and referrals

Everyone knows that word of mouth referrals provides one of the strongest mechanisms to spread the app and create virality. Text message and SMS is the digital equivalent of this whereby friends can share great new apps with their friends.

Advanced deep linking technologies enable marketers to dynamically create short URLs in the app to share the app or a referral program.

This is how it works:

1. A user would share a link to the app from a piece of content or referral screen in the app.
2. At the moment when the user hits share, you can leverage the deep linking API to create a short link and stuff it with useful data that you want to tie to the user – such as promo codes, content strings, or even the referrer’s name and user ID.
3. When the user then shares it on SMS that data will all be wrapped up in a short link.
4. When the receiving user clicks the link, they get an optimal experience – going to the app store if they don’t have the app, and to the app if they do.
5. After downloading, your app developers will get all this rich data back in the app to help understand and invest in your best virality loops and referral channels.

QR codes

While some scoff at the use of QR codes, they serve as a major channel for many companies outside of the US.

With an attribution and deep linking provider can you create a url and instantly generate a QR code.

These codes, generated in the dashboard, can then be placed in emails, SMS, direct to consumer marketing and other mainstream channels.

With Android, QR codes can be instantly scanned and in iOS 11 there’s a built-in QR reader in the “Passes App.”

Get the latest marketing news and expert insights delivered to your inbox

Custom onboarding

An advanced version of SMS sharing and referrals allows you to use the data you share in links to provide a welcome screen or customized onboarding.

The concept is simple: when you create links for users in your regular marketing channels or even in SMS and referral links, you can include information like a “popup title” or “popup message”, and then display this information in the form of a welcome message.

Postmates uses a deep link to display welcome messages to users who come from paid and organic.

Example link:

https://postmates.onelink.me/5uYG?pid=facebook&af_click_lookback=7d&af_dp=postmates://root&promo_code=icecream&title=Welcome%20to%20Postmates!&message=Use%20OneLink%20for%20your%20custom%20onboarding&button_title=Let%27s%20Go

Web-to-app banners

Last, and certainly not least, one of the most well known use of deep links is to drive users dynamically from your mobile web site to your app.

Because most deep link provider URLs are easy to structure, many mobile teams develop their own banners or use one of the many templates AppsFlyer provides for free.

Your team can customize the banner however you’d like and then, an advanced deep link can power the urls and attribution behind the button.

In the below example, Moovit uses their own customized banner alongside AppsFlyer’s OneLink technology so that users can click and download or navigate to the app from moovitapp.com.

Regardless of whether the user has the app, an advanced deep link can direct them to the appropriate content, even after installing for the first time.

Chapter 5

Why combining attribution & deep linking is key to mobile success

While often misconstrued as separate technologies, attribution is what allows for deep linking.

It’s important to know this and why you should pick one vendor to do both.

Deep linking is a consequence of attribution

As we all know by now, a deep link is just another URL or link that has some special properties. How app developers use these special properties is what most people refer to as “deep linking.” When your app deep links a user, the app actually first attributes the user.

For example, when a user clicks an ad or link, the browser takes some identifying information about the device so it can properly “recognize” the user later. Then, the link redirects the user to the app store where they can install and open the app. At that moment in time when the user opens the app, all attribution and deep linking vendors are the exact same.

The user is matched with a Google Play Referrer (if on Android) or the same information gathered from before they installed the app – usually a combination of a device’s IP, Phone Size, Screen Size, OS, OS Version – and then the vendor, like OneLink, responds to the app with attribution data, such as the campaign the user came from, the media source and the URL.

Regardless of attribution mechanism, the attribution & deep linking vendor provides a “callback” or a server response telling the app where the person came from – what Facebook campaign, Google Ad, etc.

For example, if a user clicked and install from an ad, the app would receive something like this:

{ c:test
pid:snapchat
…
other data
…
referring_url: https://xxx.onelink.me/abc?c=..&pid=&af_dp=URISCHEME://PATHWAY

}

In this response to the app, the 3rd party can also tell the app which URL the user came from.

This is usually called the referral source, or the URL that referred the user to install; the app looks at this piece of data to route the user.

Deep linking is the process of using attribution data to route the user appropriately.

AppsFlyer does this with the URL af_dp value, which is sent in the attribution callback when the app opens and reports an install or open.

The key point here is that deep linking is just using the attribution data to route the user.

It’s super important to know this and is the basis of why you should never use two vendors for attribution and deep linking.

It’s all the exact same technology.

There’s no point in doing deep linking with one company and attribution with another when the technology is the same and you can get the exact benefits using one tool.

Benefits of using one tool for attribution and deep linking:

• Tool and SDK reduction – You don’t need two tools to do the same thing. This reduces size of the app, and helps marketing teams operate more efficiently since they don’t need to go back and forth between two different systems
• Reduces tech debt – it’s easier to maintain one SDK and its codebase versus two
• Deep link off of all your channels – you can use the tool you leverage for attribution to drive users to specific spots in the app
• Consistency in reporting – because all attribution and click data from deep links flows into one dashboard, it’s much easier to analyze data and pipe this information to a customer data platform such as mParticle
• Cost – one tool is cheaper than two!

Attribution and deep linking are central to the enterprise mobile growth stack

When we talk about the mobile growth stack today, we are really talking about 6 key components:

1. Attribution and deep linking
2. Media and ad networks
3. Marketing cloud
4. Marketing automation
5. App Store intelligence
6. Product analytics

Attribution with deep linking provides an important place in the growth stack. In fact, attribution and deep linking are one of the core pillars that growth teams can rely on to execute against KPIs. They are among the first components setup after the customer data platform because their utility and value can be proven almost immediately:

You can’t run good performance marketing without understanding the source of your growth and ensuring customers are getting a world class first impression of your app via deep linking.

This toolset is tightly connected to the customer data platform and serves as a two-way sync of data tied to device and customer data, allowing growth teams to understand how they are acquiring users as well as what actions they take downstream in the app.

All of these platforms provide mobile app attribution and measurement technology that is at the hub for a company’s mobile app download and re-engagement campaigns.

They enable measurement of the ROI of app download campaigns, provide a single source of truth for metrics such as Cost per Download and Cost per Consumables Customer Acquisition, and create a single system for deep linking across all channels.

Why is it important to invest in a tech stack?

The tech stack you build and maintain within your mobile marketing and product teams will define your success on mobile. That’s because each piece of the stack serves a specific purpose, and trying to get by without certain components will almost always catch up with you.

The best teams in mobile think not just about their short term needs – such as setting up solid attribution – but also how their needs will evolve and how they can tie tools together to serve future purposes.

It’s important to invest in multiple best-in-class tools that compliment one another in order to be efficient in mobile marketing. It’s also important to avoid duplicative features, to remove bad and old tech just as much as you add new technology, and to setup your stack right from the onset.

Growth stack best practices

If you know that a growth stack is important then understanding its ideal characteristics is important in your vetting & implementation process.

As you set out to design and implement a stack that includes attribution and deep linking, consider some of the following best practices from HBE Ventures, a US-based mobile growth consultancy firm:

• If Facebook is an important paid media channel, picking an attribution provider that is an MMP is a non-starter. Vendors without access to this program will provide a less accurate reporting from this channel
• In early 2014, deep linking was a complex and novel technical innovation. It is now a commodity – all the major players offer basic to advanced deep linking capabilities.
  • Optimize for deep linking providers that offer: Universal Link support, Android App Link support, short links, an API for their links and a single URL for all attribution on paid media.
• Focus on consolidating your stack. Fewer tools is better, especially in attribution & deep linking.
• Consider designing and implementing a concise campaign measurement nomenclature. A template is provided.
• Make sure you can easily sync data in and out of your attribution tool. Use a customer data platform and ensure that your attribution provider can receive downstream events and send your attribution data to the data platform for consolidating in a single visualization tool.

Key takeaways

• Deep linking is a feature of attribution – if your attribution provider offers deep linking, you do not need separate vendors for each use case
• The underlying technology powering attribution and deep linking is the same
• When vetting tools, you should first ensure that you pick a tool that meets your requirements for Attribution – this is the bottleneck. Most attribution tools also provide the ability to deep link. This should be a secondary consideration.
• There are quite a few benefits to consolidating attribution and deep linking under one roof. Marketers should take note to avoid complexity, waste, and confusion from using more than one
• Attribution and deep linking are at the very heart of the mobile growth stack
• The tech stack you build and maintain within your mobile marketing and product teams will define your success on mobile

Chapter 6

Deep linking glossary of terms

Term	Definition
Link	A link is merely an address, name or reference to a file on “The internet”! Links are URLs, they can refer to many different types of resources. URLs can be files (like an HTML page!), databases, APIs, and much more.
Deep Link	A deep link is a special URL that routes to a specific spot, whether that’s on a website or in an app. A “mobile deep link” then, is a link that contains all the information needed to take a user directly into an app or a particular location within an app instead of just launching the app’s home page.
URI Scheme	A URI Scheme is a way to directly open the app if it is installed on the device — this is the same as being able to send mail to a very specific Box if you have a PO Box number.
Deferred deep link	This is the process of deep linking a user after they install an app for the first time.
Query Parameters	Query parameters are everything in a URL followed by the question mark, and each query parameter is separated by an ampersand. For example in the URL: https://postmates.onelink.me/5uYG?pid=facebook&af_click_lookback=7d&af_dp=postmates://root&promo_code=icecream&title=Welcome%20to%20Postmates!&message=Use%20OneLink%20for%20your%20custom%20onboarding&button_title=Let%27s%20Go, the first query parameter is ?pid=facebook.
Subdomain	A subdomain is a subset of the higher domain. For example, in the URL www.facebook.com, facebook is the subdomain of the .com top level domain.
Domain	This is the website. Walmart.com is a domain. So is jet.com. The subdomain is the subset of the domain. These are all links.
Path or Pathname	The path of a URL is essentially the final destination of a URL, the “street address” of the building where the URL leads
Route	The route of the URL. This is the place in the app that you can take a user to with a deep link. Every attribution and deep linking company thinks about a route differently, but universally, it is known as the string that comes after the URI scheme of an app. For example, airbnb has the following URI scheme: airbnb:// Their route for a deep link is everything after this, such as airbnb://listing/123.
Apple Universal Link	Apple Universal Links are a standard from Apple that is deployed on the iPhone operating system (iOS), which allows a user to tap a link and be delivered immediately to the app (if it’s installed on their device).
Android App Link	Android App Links are deployed on the Android operating system, which allows a user to tap a link and be delivered immediately to the app (if it’s installed on their device).
Facebook App Link	Facebook App Links are a cross-platform standard that allows a user to tap a link and be delivered immediately to the app (if its installed on their device).
People-Based / Multi-Touch Attribution	This is attribution across multiple devices. For example, if someone is measured taking an action on mobile web and then performs an action in iOS app, their actions can be tied together by “People-Based / Multi-Touch Attribution.”

Introduction

The state of attribution and deep linking today

Most people don’t think about attribution and deep linking in the right way today.

Legacy tools like Kochava and Tune that have fallen behind on attribution, and have given the process and technical nuances a bad rap.

Newcomers only think about UX and neglect the technical intricacies of attribution, API accessibility, partnership integrations, privacy, security, and robust technical support in both integration and tool usage.

Most infuriating, sales teams across the ecosystem confuse marketers by spinning tales about how attribution and deep linking are related when it suits them, and not related when it doesn’t.

The reality is attribution and deep linking go hand in hand – you don’t need two vendors to do the same thing.

World-class attribution with all the major providers are table stakes. If you can’t attribute your campaigns effectively across every known touchpoint, it doesn’t matter whether you can take a user to a specific spot in the app.

As a technical product manager, marketer, or engineer, your focus should not be on ephemeral sales pitches, touting things like “optimized user flow” or “flawless user experiences.”

It should be on creating a world-class technical implementation, knowing that compelling UX starts and stops with proper tool setup and usage. In today’s world, compelling UX means handling every OS, OS version, app version, browser and transition experience. There are millions of edge cases which all contribute to the collective experience.

The purpose of this guide is to help a tech-savvy audience get it right when it comes to attribution and deep linking and to learn and leverage some of the most advanced topics surrounding the space.

Chapter 1

Setting the stage: Attribution and deep linking

Let’s set the stage for this playbook by first reminding ourselves of some fundamentals regarding attribution and deep linking.

What attribution is and why it exists

The app stores do not provide a reliable way to pass data about a user from the time they enter the app to the time they install and open.

In order to “capture” their channel and other important data about a user’s originating source, link the campaign that prompted them to download the app, you must use 3rd party vendors to attribute users.

This is attribution.

The vendors who supply such technology are attribution providers.

A vendor SDK is able to attribute a user generally identifying the device on mobile web and then matching the user when they open the app. For example, when you click an AppsFlyer URL, the link redirects you briefly to a page that takes a snapshot of your device.

It is then that the vendor points you to the appropriate app store to download the app.

There is no data passage through the app store – except on Android, with the Play Store Receiver. So, the vendor’s SDK inside the app is downloaded when the user installs. And when this user opens and launches the app, the SDK takes an analogous snapshot of the user and sends it to their system to “match” the user.

Why does attribution even matter?

There’s loads of reasons, but here are a few that should convince anyone that asks:

1. You cannot trust the paid media channels to accurately report your data. They have an inherent conflict of interest in reporting accurate data to you.
2. You need a single unbiased vendor to count data across sources and pipe this to the Data Aggregator.
3. Deep linking users from your paid attribution sources drives a 31% retention to the app.
4. Users convert at a 2.5x higher rate when they come from a deep link compared to a regular attribution link.
5. Deep links have higher intent, which means a much higher lift in revenue. In fact, industry reports show that deep linking provides a 148% lift in average revenue per user (ARPU).

Deep linking is an extension of attribution

A common misconception that exists in the market is that attribution and deep linking are somehow separate ideas or technologies.

This is simply not true.

Deep linking is the extension or usage of attribution data.

Let’s go through a basic example of how it works to illuminate the tech. In the explanation previously, we talked about how a user may click a link or an ad:

1. The attribution vendor then points the user to the appropriate app store to download the app.
   
   
2. When this user opens the app either after install or from the click, the attribution SDK takes an analogous snapshot of the user and sends it to their system to “match” the user.
   
   They also tie this to an IDFA on iOS and and GAID on Android to persistently record the user. Matching can be done with a variety of methods, such as the ability to receive and match the Google Play Store Referrer, the iOS Safari View Controller Cookie, among other methods.
   
   
3. When the user has the app, the match is deterministic in nature because the app opens immediately via deterministic flows, such as URI Schemes (my-app://), Universal Links, Android App Links, and Chrome Intents (activity registered and handled in the manifest).
   
   In these latter cases, the app is getting the link the user came from, and so a tool like AppsFlyer could append a deterministic key value pair query parameter set that could be seen in the click and immediately retrieved from the SDK upon app open.

At this moment in time, then the SDK provides a callback to the app that contains the link and other association attribution metadata.

Below is a sample of the AppsFlyer SDK callback provided on iOS.

{
campaign: “CAMPAIGN_NAME”, // “None” if not specified on the link
media_source: “MEDIA_SOURCE”, //”None” if not specified on the link
cost_cents_USD : “0”,
is_first_launch: true,
install_time: “2018-12-30 23:59:39.330”,
orig_cost: “0.0”,
af_click_lookback: “7d”,
click_time: “2018-12-30 23:59:09”,
cost_cents_USD: “0”,
af_status: “Non-organic”
}

Now, when you get this callback data, you can do anything you want – log a custom event, fire a message, log some activity, etc. But most importantly, you can look at the attribution data and take the user to a particular spot in your app. This is deep linking.

Deferred deep linking is just the process of using data the first time the app opens after a user installs to retrieve the attribution data, parse the link or defined path and route the user to that page in the app.

Debunking attribution myths

In the methodology described, an attribution partner provides attribution data based on matched devices and deterministic known devices between web and app.

First, let’s talk about deterministic matching and probabilistic modeling.

Deterministic matching is when a user can be attributed and deep linked with 100% accuracy.

This is grounded in technology such as URI scheme launches, Android chrome intents, Android play store receiver callbacks, Android App Links, iOS Universal Links.

In all these cases the app opens from a click and a deterministic indicator is supplied with the app open to ensure 100% accuracy.

Let’s take an example: spotify://track/123?click_id=known_user_ABCD123

In this case, when a link is clicked in a browser that supports URI scheme launches, such as Chrome on iOS, and the Android operating platform, the app will be launched from a redirect through an attribution link. What’s happening is that the attribution link redirecting the user from the browser to the app with javascript (think… window.location.href…).

This means the app will launch and an identifier for the upstream click can be supplied to the app. The SDK inside the app can parse this value and match the user instantly with 100% accuracy. This same system and methodology works for the technologies above, like Android App Links and Apple Universal Links.

This is deterministic matching and it’s 100% accurate.

Probabilistic modeling is where a user is matched from a click using statistical likelihood.

After the user installs and opens the app the SDK will receive a callback from the server indicating the source of attribution.

This method is considered probabilistic, because the attribution vendor is matching based on a set of highly predictable but sometimes conflicting parameters.

While the chances of an exact probabilistic mismatch are low, it still occurs in the real world and the reason why technical experts leveraging deep linking for UX flows that might contain highly personal information need to be well informed about the differences between attribution methodologies.

Now that we have discussed these two different types of matching, let’s talk about the issue at stake: Sometimes vendors will claim to have a “higher match rate” or discuss “people-based attribution methods” that claim they are able to better attribute users across channels.

There is some amount of truth to this, but it’s important to unpack the assumptions and understand why and how.

Now let’s discuss “higher match rates”

First, higher match rates are a function of how many devices and people have been matched via a probabilistic model.

This in turn is a proxy of:

1. The types of companies that use the attribution technology
2. How they use that technology
3. How anonymous attribution data is shared and leveraged

For example, AppsFlyer has more than 85,000 apps using the AppsFlyer SDK – the most of any attribution player in the space.

More importantly, however, is that AppsFlyer has brands with massive global reach using their SDK to create structured links across a variety of channels. Walmart, Alibaba, eBay, Epic Games (Fortnite), Microsoft (Minecraft), booking.com, Coca-Cola, Waze, and HBO are going to have more reach in terms of end users.

The second criteria for measuring accuracy is by far the most important.

Companies misconstrue terms like “people-based attribution is more efficient.”

What they really mean is that if you can capture a user from multiple touchpoints – across web and app – then your ability to match and attribute that user will inherently be better. If you use attribution links across paid media, email, smart banner, referral, then you will inherently be recording people better across more touchpoints and therefore your ability to properly attribute them will be better!

And third, how a company chooses to share or not share user data is important.

In 2018 we watched as GDPR became the new standard in Europe for controlling user marketing data. In the US, Facebook, Google and others had embarrassing testimonials before Congress as legislators and individuals became outraged at the way in which their private data was being used for nefarious purposes.

AppsFlyer, and most trustworthy attribution providers do not share IDFA and GAIDs with other companies.

Instead, they create an anonymous pool of matched Web Cookies and IDFA/GAIDs.

They leverage this data set internally to match users across all their apps – without sharing this data explicitly with companies. This sets limitations on how matching works and how efficient it can be. Not all companies follow these implicit rules and respect user privacy laws.

That’s why choosing an attribution provider that is part of OpenGDPR is more important in 2019 than ever before.

In conclusion, don’t believe the hype that some vendors have “cracked the secret sauce”

When folks say that “legacy attribution systems can’t connect the dots”, this is largely sales and marketing jujitsu, and is not grounded in real technology.

All good attribution providers use deterministic web cookie and device ID pairs (IDFA or GAID) to match users and their touchpoints.

What matters more is the reach of the attribution providers pool, as well as how you, as an individual choose to leverage or not leverage deep links.

Chapter 2

Attribution and deep linking tech and taxonomy

Taxonomy

The trouble with attribution and deep linking is that there are so many different names for the same thing.

Equally important, often marketers think in terms of user experience, but the technical delivery mechanism of that experience is lost. And especially relevant is even with the word “deep linking” – which marketers often interpret as driving somebody to a particular spot in the app, but as of the writing of this document – can be extremely nuanced.

Did they mean a URI scheme? An Apple Universal Link? A chrome intent? An Android App Link?

These are all deep links by definition, they all drive the person to the right spot in the app in certain contexts.

With this in mind, let’s review some of the most common deep linking and attribution taxonomy. You can and should use this when speaking with your team and across members of product, engineering and marketing.

A Chrome Intent is an Android-only deep linking mechanism that lets users launch the app from a webpage (documentation on how it works can be found here).

Deep linking and attribution, explained

Deep link:

A deep link is a link that takes a user to a specific spot on the website or the app.

All web URLs that go past the homepage are deep links.

A mobile deep link contains all the information needed to take a user directly to a particular location within an app, instead of just launching the app’s homepage offering a consistent, contextual experience from the promotion to the in-app landing page.

Attribution:

Attribution describes the process of identifying a set of user actions across screens and touch points, that contribute in desired outcome or event, and then identifying where that user came from – the source.

• Web attribution is solved by the use of web query parameters and javascript. A link is clicked, and the team could use javascript, grabbing and storing the URL parameters (for example: window.location.href.split(“utm_campaign=”)[0]).
• App attribution is much more complicated especially in the context of the Apple App Store as it does not allow you to pass query parameters through the download process. This means that every user on iOS is considered as a new user, unless you use a 3rd party attribution service.

3rd party attribution service:

A third party tool used to attribute and measure users using a combination of link click, probabilistic modeling, SDK, and people-based attribution services.

Matching:

Matching refers to when a user opens the app, the 3rd Party Attribution Service’s SDK recognizes a set of parameters and “matches” the user.

Technically speaking, the SDK sends over a request to the server where the Attribution Service tries to look for the same device that visited the web link. If it finds a positive match, it returns the campaign information (Attribution) as well as the link or other data elements associated with the web side click.

This information can be leveraged for deep linking.

For example, if a URL is provided in the callback, the developer can parse out the web URL, URI or other parameter used to route the user to a particular spot in the app.

SDK:

A Software Development Kit (i.e. a developer’s biggest foe) is usually required in order to properly attribute a user, as the 3rd Party Attribution Service’s SDK will collect and process the user information as well as receive the attribution data and make this presentable in a format that is easy to use (callback).

If you do not want to use an SDK, you would have to build the functionality using direct API calls.

In some cases, there are no public API calls and so choosing not to use an SDK means limiting functionality and capabilities. In general, attribution and deep linking as a service has become a commoditized engineering effort and it is much better to leverage a 3rd party than to try to build it yourself.

Callback:

A callback is a response that is returned and passed as an argument to other code.

In the attribution and deep linking space, there is a callback to the app – or response back the app – once the 3rd Party Attribution Service matches the user and returns the attribution and deep link data.

Types of deep links:

The proper way to think about “types” of deep links is as “mechanisms” of deep linking.

A deep link is any link that routes a user to the right place in the app.

How this occurs, however, can vary greatly.

URI:

A Universal Resource Indicator for the app that is sent in the app’s configuration.

This allows the app to be opened directly. “Routes” can be configured much like pathnames can be configured. Most apps have URI Schemes and Routes.

Examples of URIs include:

• airbnb://
• walmart://
• fb://

The route is the part of the URI that comes after the base scheme.

Chrome Intent:

A Chrome Intent is an Android-only deep linking mechanism that lets users launch the app from a webpage.

Documentation on how it works can be found here.

Apple Universal Link:

Apple Universal Links are a standard from Apple that is deployed on the iPhone operating system (iOS), which allows a user to tap a link and be delivered immediately to the app (if it’s installed on their device). This is a system level route, as opposed to a redirect through a URL or link measurement service.

User intent:

Apple defines “User Intent” into their standard by enforcing that users who click on Apple Universal Links, and therefore are routed as such, must have user intent. In technical terms this is manifested by Apple Universal Links not working when wrapped in other click measurement or routing services – including email click recorders.

Apps and other in-app browsers, also can choose to respect Universal Links or not, which influences intent.

Click measurement (click wrapping):

Click wrapping is when a URL is redirected through another URL (or webpage) measurement purposes. This breaks Apple Universal Links, and complicates attribution and deep linking for email and paid channels.

Android App Link:

Android App Links are Google’s version of Apple Universal Links and are deployed on the Android operating system. They allow a user to tap a link and be delivered immediately to the app (if it’s installed on their device).

This is a system level route, as opposed to a redirect through a URL or link service.

Chapter 3

A deep linking chronology

Things weren’t always so complex.

Before there were Apple Universal Links, and Android App Links, and Chrome Intents, there was just plain vanilla URI Schemes.

In order to understand why things are so complex today, it’s important to understand how attribution and deep linking first worked, and how that has evolved to today.

Original deep linking

Originally, there were just links and URI schemes.

Then AppsFlyer pioneered the technology to attribute and deep link users.

Here’s how it worked:

1. A user would click an attribution link (links that looked and worked much like they do today)
2. The user would be redirected to a page where javascript would load
3. In that brief moment, the browser would know the operating system (OS), it would have the platform configuration including the URI scheme and route, and so Javascript would set a timer and then try to fire the URI scheme and route
4. If the timer expired before the browser responded, then it was known that the user did not download the app, and so the browser would redirect to the appropriate app store tied to that OS
5. Just like with regular attribution, the user would install and open the app, passing on this information in the callback to the app
6. If the user has the app, then the URI would have opened the app immediately, and when the URI was opened, the Attribution provider would also pass a clickId or linkId so that it’s SDK knew exactly where the user came from

This was a simple and clear way to deep link and was leveraged by all the major 3rd Party attribution and deep link services.

So what’s changed?

Everything changed in 2015 when Apple introduced Apple Universal Links as part of iOS 9.3.

In iOS 9.3 Apple introduced two things:

1. The new standard for routing to apps, called Universal Links
2. A new Safari change that got rid of non-blocking javascript, and therefore eliminating the ability on iOS to route as described in the previous section – the timer and javascript routing mechanism no longer worked on iOS

The old world was dead forever after iOS 9.3 was released.

From this point in time, the ability to attribute and deep link only became more complex as operating systems and media vendors released their own standards including Chrome Intents, Android App Links, Facebook App Links, and more.

Today, deep linking is highly segmented and very much depends on the operating system, the mechanism being used, as well as the browser or app context.

Get the latest marketing news and expert insights delivered to your inbox

Here’s a look at the the expectations well-known deep linking contexts:

App	iOS	Android
Facebook Newsfeed	deep links to af_web_dp or af_ios_url fallback	deep links to app
Facebook Browser	deep links to app	deep links to app
Facebook Messenger	deep links to af_web_dp or af_ios_url fallback	deep links to app
Facebook Messenger browser	deep links to app	deep links to app
Instagram Profile	deep links to af_web_dp or af_ios_url fallback	deep links to app
Instagram Browser	deep links to app	deep links to app
Instagram Stories	deep links to af_web_dp or af_ios_url fallback	deep links to app
Twitter Feed	deep links to af_web_dp or af_ios_url fallback	deep links to app
Twitter Browser	deep links to app	deep links to app
Reddit	deep links to af_web_dp or af_ios_url fallback	deep links to af_web_dp or af_android_url fallback
Pinterest	deep links to af_web_dp or af_ios_url fallback	deep links to af_web_dp or af_android_url fallback
Pinterest Browser	deep links to app	deep links to app
Chrome Browser	deep links to app	deep links to app
Chrome Address Bar	deep links to af_web_dp or af_ios_url fallback	deep links to af_web_dp or af_android_url fallback.
Safari Browser	deep links to app	N/A
Safari Address Bar	deep links to af_web_dp or af_ios_url fallback	N/A
Firefox Browser	deep links to af_web_dp or af_ios_url fallback	deep links to app
Firefox Address Bar	deep links to af_web_dp or af_ios_url fallback	deep links to app
UC Browser	deep links to af_web_dp or af_ios_url fallback	deep links to app
Naver Browser	deep links to af_web_dp or af_ios_url fallback	deep links to app
Kakao Browser	deep links to af_web_dp or af_ios_url fallback	deep links to app
Opera Browser	deep links to app	deep links to app
Apple iMessage	deep links to app	N/A
Apple Business Chat	deep links to app	N/A
Slack	deep links to app	deep links to app
WeChat	deep links to af_web_dp or af_ios_url fallback	deep links to af_web_dp or af_android_url fallback
WhatsApp	deep links to app	deep links to app
Gmail	deep links to app	deep links to app

Chapter 4

Deep linking mechanisms deep dives

Apple Universal Links (iOS) and Android App Links (Android) are essentially the same concept, but are often interchanged, or confused with other routing mechanisms.

It’s important to be explicit when you talk about these concepts, else you risk confusing or confounding different technologies which operate very differently.

Apple Universal Links

Apple Universal Links are a standard from Apple that is deployed on the iPhone operating system (iOS), which allows a user to tap a link and be delivered immediately to the app if they already have downloaded it.

These type of links do not have redirects and it is a special system setup with some degree of technical complexity.

When the user taps the link, a roundtrip server call is made to Apple and the OS opens the app immediately without ever opening the browser or loading the URL.

How Universal Links work:

Universal Links have two key components:

1. AASA: Apple App Site Association file hosted on the domain of the links which will open the app immediately if the user has the app (documented here).
2. Associated Domains: A small code change in the Entitlements > Associated Domains file of the iOS app.

It’s important now to distinguish an essential point – Universal Links are not a “set of links” but rather a system that is setup on links that your domain uses.

Universal Links can be enabled on your own company domain URLs as well as 3rd Party attribution URLs.

Examples:

1. A walmart.com link, which has “Universal Links” enabled on them:  https://www.walmart.com/ip/Banana-Dog-Costume/172218418
2. An AppsFlyer OneLink, which has “Universal Links” enabled on them: https://walmart.onelink.me?… af_dp=walmart://ip/Banana-Dog-Costume/172218418

In the top case, the entire URL will come into the app via continue UserActivity, and you can then parse and route the user accordingly.

In both cases, it is assumed that the developer will have some type of parsing and routing on each link. In the above case the developer might parse everything after the domain. In the bottom case, the developer will handle the af_dp value explicitly.

This is at the core of handling static value deep links.

As a final note, it is important to point out that almost every company’s AASA is hosted at their main domain followed by “/apple-app-site-association” and therefore you can easily find the AASA file for any company.

Android App Links

Android App Links is the equivalent linking system that is setup on Android.Apple Universal Links & Android App Links are essentially web URL which are intended to direct users to the optimal location on web or the app. They were intended to take users to mobile web if the user doesn’t have the app, but take the user to the exact content in the app if they do.

On a mobile device, if the user follows a universal link and has our app installed, they may be directed to the app, otherwise the system will fallback and land the visitor on our mobile website (with a few exceptions – see below).

For a link to be truly universal, it requires that the linked feature is enabled on web, iOS and Android and for all apps to share the same resource path.

Chapter 5

Handling attribution and deep linking callbacks (with examples!)

The easiest way to put some of this knowledge into practice is to demonstrate how to handle attribution and deep linking using examples.

Case 1: Handling standard attribution and routing

In this example, it is assumed that you already have the SDK setup and are properly following all steps to successfully test a deep link.

If you are not able to, check out the Testing & QA section of this guide which elaborately lay out exactly the process to follow on how to QA deep links, as well as some of the common pitfalls.

We also provide succinct checklists to follow with your QA team.

In this case, assuming you have setup your SDK and now you’re trying to understand how to deep link the user. AppsFlyer provides two different functions for receiving install data in the apps:

• Android: onInstallConversionDataLoaded
• iOS: onConversionDataReceived

The returned conversion data from these functions consists of all the parameters on the original attribution link and some additional server parameters created at the time of click or install.

Since the conversion data is reliant on the attribution link, it means that different sources and attribution links may produce different conversion data parameters.

Additionally, there are 3 possible outcomes depending on the type of install:

1. Non-organic installs: Returns the original attribution data of the install (see the examples below).
2. Organic install (or re-install): Returns “organic install”
3. Re-attribution: Returns the re-attribution conversion details.

Example in action

Below is an example callback you might receive if you called onConversionDataReceived on iOS and received a proper callback.

The example is demonstrated with the shopping app, Jet, who uses AppsFlyer to deep link from paid ads.

1. ▿ 0 : 2 elements
2. – key : click_time
3. – value : 2018-08-14 02:37:30.798
4. ▿ 1 : 2 elements
5. – key : orig_cost
6. – value : 0.0
7. ▿ 2 : 2 elements
8. – key : cost_cents_USD
9. – value : 0
10. ▿ 3 : 2 elements
11. – key : is_first_launch
12. – value : 0
13. ▿ 4 : 2 elements
14. – key : campaign
15. – value : Test
16. ▿ 5 : 2 elements
17. – key : af_click_lookback
18. – value : 7d
19. ▿ 6 : 2 elements
20. – key : af_dp
21. – value : jet://product/Carbona-Washing-Machine-Cleaner-3-Count/d1909b8fb76240d480df7c983452a913
22. ▿ 7 : 2 elements
23. – key : idfa
24. – value : 00000-0000-0000-0000-0000000000000
25. ▿ 8 : 2 elements
26. – key : media_source
27. – value : Email
28. ▿ 9 : 2 elements
29. – key : install_time
30. – value : 2018-08-14 02:38:40.012
31. ▿ 10 : 2 elements
32. – key : af_status

A few things should stand out immediately and it should be clear that you can use this key value structure in the callback of this function to parse information and use it to route the user, and call custom events or experiences.

For example, the af_dp value, which stands for AppsFlyer deep link, can be leveraged to immediately route the user to this URI.

Similarly, the is_first_launch value can be used to determine whether this is the first time the user launched the app after install, or whether the user already opened the app in the past.

A unique aspect of AppsFlyer is that it has another method for both iOS and Android – onAppOpenAttribution to receive attribution data every time the app opens.

The below flow diagram outlines exactly how you could use these two different functions in combination to receive install data when an install occurs, and to receive open data when it does not. From there, you could parse the different keys that you’d like to use for deep linking such as af_dp, af_web_dp, af_ios_url, or af_android_url.

A full list of AppsFlyer link parameters that would be included in a URL can be found here.

This brings us to an important nuance: depending on the SDK and the 3rd Party Attribution Service, you may have different ways of receiving data.

AppsFlyer has two distinct methods as illustrated by this chart. Others might have more or less.

The process by which you parse data from the callback and route the user, however, should not change!

Case 2: AppsFlyer and more with a CDP (mParticle)

In the case below, we will examine how to handle multiple deep link responses via a Customer Data Platform – in this example, mParticle.

The key to this use case is to first, make sure you understand the response keys from each vendor, then to make sure you prioritize who to handle from a deep linking perspective.

Last, but not least, we’ll examine how you can log this attribution callback data to a custom event so that you can trigger a push notification, pop up promotion or other campaigns using your AppsFlyer data!

Example in action

This app has integrations with two other vendors that provide callbacks to the app. mParticle, a customer data platform that excels in web and mobile data handling, pipes all attribution and deep linking callback data to a single method.

This single mParticle API wraps both of AppsFlyers callbacks – as well as the callbacks of all other attribution providers –  while the respective AppsFlyer Kit exposes constants to inform you of which callback has been fired.

On both platforms, the iOS/Android kit will register a delegate/callback with the AppsFlyer SDK on initialization and for the lifetime of the app’s process, and will call your completion handler block (iOS), or AttributionListener (Android), whenever there is a new conversion data available.

The keys returned in these results will match the result of the AppsFlyer SDK, documented here: AppsFlyer Callback Response.

1. (lldb) po linkInfo
2. ▿ 1 element
3. ▿ 0 : 2 elements
4. ▿ key : AnyHashable(“mParticle-AppsFlyer App Open Result”)
5. – value : “mParticle-AppsFlyer App Open Result”
6. ▿ value : 1 element
7. ▿ 0 : 2 elements
8. – key : link
9. – value : https://jet.bttn.io/product/Carbona-Washing-Machine-Cleaner-3-Count/d1909b8fb76240d480df7c983452a913/?btn_ref=fakesrctoken-1111111111111111Shop
   (lldb) po linkInfo
10. ▿ 1 element
11. ▿ 0 : 2 elements
12. ▿ key : AnyHashable(“mParticle-AppsFlyer Attribution Result”)
13. – value : “mParticle-AppsFlyer Attribution Result”
14. ▿ value : 11 elements
15. ▿ 0 : 2 elements
16. – key : click_time
17. – value : 2018-08-14 02:37:30.798
18. ▿ 1 : 2 elements
19. – key : orig_cost
20. – value : 0.0
21. ▿ 2 : 2 elements
22. – key : cost_cents_USD
23. – value : 0
24. ▿ 3 : 2 elements
25. – key : is_first_launch
26. – value : 0
27. ▿ 4 : 2 elements
28. – key : campaign
29. – value : Test
30. ▿ 5 : 2 elements
31. – key : af_click_lookback
32. – value : 7d
33. ▿ 6 : 2 elements
34. – key : af_dp
35. – value : jet://product/Carbona-Washing-Machine-Cleaner-3-Count/d1909b8fb76240d480df7c983452a913
36. ▿ 7 : 2 elements
37. – key : idfa
38. – value : 0000000-0000-0000-0000-00000000000
39. ▿ 8 : 2 elements
40. – key : media_source
41. – value : Email
42. ▿ 9 : 2 elements
43. – key : install_time
44. – value : 2018-08-14 02:38:40.012
45. ▿ 10 : 2 elements
46. – key : af_status

In this case, we are receiving callback data from the single mParticle deep link API.

Just as in the case of handling the AppsFlyer SDK response directly, you should consider which one of these responses you want to handle and how you want to handle it.

Here is a framework for structuring your link logic:

1. If you are receiving callback data from multiple vendors, who takes precedence? Most marketers prioritize the response from a paid-relevant, MMP qualified vendor like AppsFlyer.
2. Remember to check both install and open responses from AppsFlyer.
3. If the response is “Organic” you might choose to check the other vendors, especially if that vendor doesn’t have a direct integration with AppsFlyer.

In addition to thinking through your attribution and deep linking logic, you should also log a custom event with the flattened keys and values from this client side attribution event.

Below are samples of how to do this directly with AppsFlyer as well as with a CDP like mParticle.

AppsFlyer

iOS – (void) trackEvent:(NSString )eventName withValues:(NSDictionary)values

The eventName could be as simple as “Attribution” or “Attribution Data” and the values should be all or some of the values from the callback response listed above.

Android – public static void trackEvent(Context context, String eventName, Map eventValues)

The eventName could be as simple as “Attribution” or “Attribution Data” and the eventValues should be all or some of the values from the callback response listed above.

See further documentation on this for both OS’s here.

mParticle

iOS

MPEvent *event = [[MPEvent alloc] initWithName:@”Attribution Data”
                                         type:MPEventTypeTransaction];
event.info = @{@”key”:@”value”};
[[MParticle sharedInstance] logEvent:event]

Andriod

Map<String, String> eventInfo = new HashMap<String, String>();
eventInfo.put(“key”, “value”);
MPEvent event = new MPEvent.Builder(“Attribution Data”, EventType.Navigation)
   .info(eventInfo)
   .build();
MParticle.getInstance().logEvent(event);

See further documentation for iOS and Andriod.

Chapter 6

Advanced topics

Web-to-app strategy: Banners and links

Considering the driver of web to app is an important and often neglected part of an engineer’s thoughts around attribution.

Typically organizations get spun up around analyzing and thoughtfully considering the following problem:

If we drive users from Mobile Web to the app will that negatively impact overall revenue? How do I compare my Web users to my app users?

Typically when teams that have widespread Mobile Web adoption and are worried about its impact on revenue, it’s important to note that App users convert to purchase universally at a much higher rate, with 3x higher conversion rates.

This is largely because apps can deliver a UX that is much higher quality and easier to navigate through the purchase funnel. In addition to the overall ease of conversion on apps compared to mWeb.

Other factors play into why it’s important to drive users to the app:

• Login
  
  When users are logged in on the app it makes it much easier for them to simply add something to their cart and checkout.
  
  Apps can retain login credentials for longer sessions, and the UX design of a native experience is easier and higher quality to web. This is why users spend more time and convert more in apps compared to Mobile Web.
  
  
• Engagement
  
  In addition to having an easier and better experience in the app compared to Mobile Web, apps can leverage push notifications, message center, feeds and other native only elements to prompt users to purchase or pickup an abandoned cart. Email is the only option available for Mobile Web users to be prompted.
  
  This higher rate of activation can lead to better results.

Outside of the business benefits of driving users to the app from Mobile Web, there is justification from an attribution and technology perspective that it is highly advantageous to have a cohesive web to app strategy.

This is because People-Based Attribution, which was earlier discussed, in part relies on your company’s use of the same attribution system throughout your marketing stack – on web, in the app, on ads, and in emails – so that people are more appropriately and intelligently attributed across touchpoints.

As discussed, the more you measure with a single attribution system, the better you’re going to be able to identify the sources of traffic and the richer quality understanding you’ll develop of your users across platforms.

If you record users across all your marketing touchpoints using the same attribution tooling, you’ll get better attribution results and richer/more accurate data related to your users sources.

This is the fundamental premise of People Based Attribution, and an argument for why you should stick with one single Attribution provider for all your needs.

What does a “great” web-to-app strategy look like?

What does great web to app strategy even look like?

You’re convinced at this point that you need a banner, but how should you design it and what’s the easiest way to power it?

There are a few options:

1. Custom design and custom measurement
2. Out-of-the-box design and measurement
3. A hybrid of the above

Option #1 is to design a banner and implement your own custom measurement not using an attribution tool at all.

There are lots of reasons why this would be disadvantageous, but the crux being that it is an immense amount of work when there are easier options available.

You maintain control at the expense of speed and flexibility. Here are some examples of fully custom banners that companies have made on their own:

Option #2 is the optimal and easiest approach: use an out of the box Web SDK with its design and measurement solutions that are available as JS methods.

AppsFlyer provides some static code that is used to generate the banner and some optional methods and parameters that can be used to customize the design and measurement.

The Web SDK has a method to create a banner that floats on the top of the website and provides options in the settings variable that customize the title, icon, call to action (CTA), as well as a long list of measurement parameter options that can be customized and set at a static and dynamic level using Javascript.

The benefit of this method is that the developer doesn’t need to worry about both designing the banner, ensuring it fits all browsers and device models and doesn’t have to worry about properly constructing and maintaining the attribution URL that floats under the button of the CTA.

In this case, AppsFlyer is creating the URL with the attribution settings and generating the link.

This is helpful as certain pages may have settings that vary dynamically, and so this out of both settings variable allows the developer to customize the experience and measure as the website changes.

Regardless of your choice, one thing is very certain – do not use the “out of box” meta tags provided by Apple and Android.

Not only do these provide limited to no measurement, which means no contribution to your overall Attribution model, but they provide no customization.

If you’re going to go to the trouble of installing some JS on your site, you might as well opt for a few extra minutes and install a banner that accomplishes more than sending users to the App Store.

Deep linked emails

Background

Ever since the advent of Apple Universal Links, countless marketers, product managers and engineers have lamented over emails that no longer deep link to the app.

This is partially due to the complexity of linking mechanisms that has been outlined in previous sections. Adding to the complexity is that there are so many different email clients that handle these mechanisms differently.

However, there is hope!

Deep linking with email is not as complex as people make it out to be.

There is one case that is hard to handle – iOS, when users have the app – but otherwise, nothing really changes for the vendor, client or user.

You can handle deep linking from email yourself, much like you handle routing from any other 3rd Party Attribution Service. It just requires an understanding of Apple Universal Links/Android App Links, a willingness to use AppsFlyer or other vendor links in your URLs, and a willingness to modify your client code to handle email links very specifically.

Why ESP deep links break

Let’s quickly recap why emails often don’t deep link users properly on newer operating systems:

• ESPs wrap links in click recording
• This breaks Apple Universal Links, and complicates Android
• ESPs don’t provide reliable routing to app or web based on a variety of circumstances like a tool such as OneLink provides

The only real case where deep linking behaves poorly is when the user has the app on iOS.

In this case, the ESP link that measures clicks “breaks” the universal link functionality. You have to develop a system to handle this. This explains what the  problem is when people say “email deep links” or “universal links” are broken for email.

As a final note, people often ask, “well, what about desktop links?!” Desktop links behave normally in all cases. The ESP link just wraps whatever redirects you want. Redirects on desktop never go to any type of app and most Desktop experiences go to web still, so there is no modification needed.

So, there you have it – don’t believe the hype from vendors who try to sell you that deep linked email requires an expensive product.

Using attribution links or deep links from AppsFlyer or other standard 3rd Party Attribution Services should work easily and without an additional cost in almost all cases based on the following assumptions:

1. You must set up deferred and regular deep linking. For AppsFlyer, this includes “OneLink”.
2. You must set up Apple Universal Links and Android Apps Links with these individual vendors.

If you meet both of these requirements, then using regular deep links in your emails works for iOS and Android when the user doesn’t have the app.

In these cases, the user can either go to mobile web or the app store depending on your preference.

If the user has the app on Android, these links will either open the app immediately via a Chrome Intent or the ESP link will route to the attribution link which will open the app via a URI scheme. You could also replicate the exact same functionality on Android as on iOS using Android App Links.

How to see up deep links for ESPs

1. You will keep click recording turned on
   
   
2. You will setup Apple Universal Links and Android App Links on your ESP domain. Most ESPs now support this in their documentation.
   
   For example, Sendgrid has very detailed instructions on how to enable this on their site: https://sendgrid.com/docs/ui/sending-email/universal-links/#setting-up-universal-links-using-cloudfront
   
   
3. Once Universal Links are enabled, then the app will open from the ESP click recording domain.
   
   You now need a way to retrieve the underlying URL that was put into the email HTML by the marketing team. You can use Sendgrid’s out of box URL Resolution code snippet:

iOS

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler {
   if (userActivity.activityType == NSUserActivityTypeBrowsingWeb) {
       NSURL *encodedURL = userActivity.webpageURL;
       if (encodedURL == nil) {
           NSLog(@"Unable to handle user activity: No URL provided");
           return false;
       }
       NSURLSession *session = [NSURLSession sharedSession];
       NSURLSessionDataTask *task = [session dataTaskWithURL:encodedURL completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
           if (response == nil || [response URL] == nil) {
               NSLog(@"Unable to handle URL: %@", encodedURL.absoluteString);
               return;
           }
           // Now you have the resolved URL that you can
           // use to navigate somewhere in the app.
           NSURL *resolvedURL = [response URL];
           NSLog(@"Original URL: %@", resolvedURL.absoluteString);
       }];
       [task resume];
   }
   return YES;
}

Android

If you have written your app for Android, you can use HttpURLConnection to resolve the URL by setting setInstanceFollowRedirects to false.

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler {
   if (userActivity.activityType == NSUserActivityTypeBrowsingWeb) {
       NSURL *encodedURL = userActivity.webpageURL;
       if (encodedURL == nil) {
           NSLog(@"Unable to handle user activity: No URL provided");
           return false;
       }
       NSURLSession *session = [NSURLSession sharedSession];
       NSURLSessionDataTask *task = [session dataTaskWithURL:encodedURL completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
           if (response == nil || [response URL] == nil) {
               NSLog(@"Unable to handle URL: %@", encodedURL.absoluteString);
               return;
           }
           // Now you have the resolved URL that you can
           // use to navigate somewhere in the app.
           NSURL *resolvedURL = [response URL];
           NSLog(@"Original URL: %@", resolvedURL.absoluteString);
       }];
       [task resume];
   }
   return YES;
}

Developers have lots of options at this point. Because you will get back the underlying URL, you could choose to deep link off of your own web URLs and your attribution URLs.

ESP Link clicked by user in email…

• Opens App via Apple Universal Links or Android App Link
• Resolve URL
• URL could be of a few varieties:
  • https://jet.com/product/123
  • https://jet.onelink.me/…af_dp=…af_web_dp=…
• Handle URL like you might handle these links already!

As you can see, you are not constrained to buying a deep linked email product, or relying on a vendor in any way you wa

We recommend you at least handle the case of your own links and your preferred attribution and deep linking partner, but don’t waste time and money on product and services that pretend to simplify this well known technical system.

How it works (flow diagram)

Email Creation

• Marketer inputs a URL into their email campaign (this could be a regular company domain URL or an AppsFlyer link)
• Your email service provider such as Sendgrid wraps up this link when the email goes out
• The email the end user sees shows this ESP URL – for example:
  • click.airbnbmail.com
  • shop.jet.com
  • click.go.wholefoods.com
  • Eml.flagship.postmates.com

When a user taps this link on iOS Chrome or Android (or iOS, Safari, but doesn’t have the app) then things work just fine. There’s literally no difference. It’s just regular old link redirection.

Email redirect cases

When a user on iOS 9.3+ who has the app taps the link, if they’ve setup Universal Links or Android App Links on their click recording domain, then the app will open immediately.

In the diagram below you can see three separate cases:

1. This is the flow of what has already been described as deferred deep linking.
   
   Without any type of 3rd party redirection on your email links, you can use AppsFlyer links out of box to direct users to web or the app store. After install they may be deep linked to the right place in the app without any additional client side handling.
   
   
2. In this case, it’s assumed that 3rd party click recording is enabled with your email service provider.
   
   If you’re using AppsFlyer or your own domain URLs, a simple piece of client side code can help you unwrap the underlying URL and route the user to the appropriate place in the app.
   
   By default, when the user has the app, they will open to the app immediately via Universal Links or Android App Links, whereby you’ll need to unwrap the ESP URL and resolve. If they do not have the app, AppsFlyer or your own domain URL can take them to the appropriate spot in the App Store or on Mobile Web.
   
   
3. If you’re in need of a simple solution, you can use AppsFlyer only to intelligently direct the user to the App when the user has it. AppsFlyer will fire a URI scheme from the browser if they know the user has the app.

Managing ESP Universal Links: Resolving URLs, handling clicks and routings

The app should employ the code snippet referenced above to retrieve the underlying URL.

If the underlying URL is an AppsFlyer link or one of your own links where the query params are listed out, then no further async calls are required. Just handle the link by parsing query params sending them to the app’s route handler.

Note: If the underlying URL is an AppsFlyer OneLink Short URL, then you would need to subsequently make an async request to AppsFlyer to retrieve the link metadata before being able to process is. For this reason, we usually recommend using long form URLs where the key values are visible in the URL to make routing easy and not require another roundtrip call.

If it’s any other type of URL you can handle it similarly.

Get the latest marketing news and expert insights delivered to your inbox

Current issues with Apple Universal Links

Apple Universal Links is a useful technology that is proven to offer a better UX for users who have the app.

However, these links have a few important limitations to be aware of, otherwise  you and your product teams will be spending endless hours debugging issues that cannot be fixed. There are actually four core issues as of the writing of this document. They almost all only applicable to Apple Universal Links (iOS 12), not Android App Links.

Issue 1: No recording or attribution

Because Apple Universal Links are not a redirect, but rather a system applied to links to open the app, it is very difficult to establish true click recording.

Why? Because the app opens immediately from Apple Universal Links.

There’s no redirect through a webpage to count a click to a server. Instead, when the app opens, the URL that opens the app gets reported in via a well known Apple code snippet called `continueUserActivity`.

To count a click on the URL, a marketing team would have to setup a server and manually count the click from the app.

A much simpler and easier solution is to use an attribution and deep linking tool, such as AppsFlyer.

These systems will have Universal Links on their actual domain, such as your_company_name.onelink.me and automatically execute this type of recording for you. In short, whenever you need to record users who click on links, you should use a 3rd party tool, like OneLink.

Issue 2: No link wrapping allowed

This problem goes by many names. Link wrapping, click recording, link redirect, they all refer to the same thing.

When a marketer runs an ad or sends an email, often the service they are using will take the link they are using and “wrap it” or send it through a redirect so that the system they are using can count a click. It does this by redirecting to their website before sending the user to the final destination URL that the marketer input into the system.

Both Apple Universal Links and Android App Links cannot be wrapped in other URLs.

If you do this, then the link will redirect users to the web fallback instead of to the app.

This mostly impacts marketers running paid ads with services like Double Click (where URLs get wrapped) and email marketers who have click recording enabled with their Email Service Provider (ESP).

In both cases, other 3rd party tools may wrap URLs you are using that would otherwise behave as Universal Links.

This breaks the functionality and defeats the purpose of using Universal Links. There are a variety of solutions to this, from turning off click recording to employing a specialty consultant to help navigate the complexity.

Issue 3: Phantom banner syndrome

For some reason, Apple could randomly inject a banner ad onto your site in Safari when Universal Links is implemented. There is no way to control this, customize it, or record it. It’s a strange feature that Apple introduced with Universal Links and has confused the market quite a bit.

Most customers just choose to ignore this, as it is only displayed in a few cases, while a click on Apple Universal Links would normally take the user to your app and not your website.

Issue 4: General performance instability

Starting with iOS 11, many apps have noticed that Universal Links do not always perform the same way. 

iOS leverages the domain information from the Apple App Site Association (AASA) file you’ve established in order to open apps with Apple Universal Links.

When a new user on iOS installs the app, the AASA file is downloaded into local storage on the user’s device, and is then parsed to configure the routing for Universal Links at the device level, allowing for a user to tap a link and route properly with a configured domain.

Unfortunately, on iOS 11.2, developers report that the AASA file no longer reliably downloads onto the device and into local storage after install, and therefore, since the file is not present, Universal Links don’t work. Generally, they are also known to be difficult to debug with many implementation steps to install.

There is a well known Apple bug regarding this issue that is being monitored which you can follow here:  http://www.openradar.me/radar?id=4999496467480576

Assuming you’ve setup Universal Links on your regular URLs, or on the URLs you use for your attribution provider, you can test this and possibly get Universal Links to work again by doing the following:

1. Logout of app
2. Delete app
3. Install the app from the app store or test/QA site
4. Restart the device (turn off and then on again) – on iOS 11 this can often fix strange entitlement issues where the behavior of the link is not correct when clicked
5. Create or find a link you are trying to test
6. Paste the link in Notes, iMessage or in an email using the Apple Mail Client
   • Do not use Slack, Facebook or any other app to click the link
   • Do not paste the link into Safari – this will not work correctly
7. Click the link
8. The app should open immediately, without a redirect through the browser, and route the user to the proper place in the app

Chapter 7

Testing & QA

Whether it’s attribution or deep linking, or both, it is vital to your product and marketing teams to have extremely well documented, well understood QA and troubleshooting guidelines.

Testing attribution and deep linking is very complex and full of technical nuances:

• What media source are you testing?
• Are your query parameters accurate?
• Is your link URI encoded?
• Does the link have the appropriate API and Redirect Parameters?
• Are you testing with Apple Search Ads turned on? Did you know this impacts callback latency?
• Are you testing deferred or regular deep linking?
• If regular deep linking, by what mechanism?
• Are you clicking the link on Slack? If not, from what app or browser?
• Are you using a test or production build?
• Are your links configured with an AASA?
• Is your AASA the correct format and includes the correct app prefix, bundle identifier and path that is associated with your test or prod app?

These are just some of the questions you must ask when QA’ing link.  

This guide outlines how to tackle these questions with both direct answers as well as a step by step process when testing links.

Process philosophy

• Define a clear test process and goal.
• Explicitly state every component of the process – leave nothing to assumption or speculation (the above questions are the types of questions you must ask) including: OS, OS version, QA app, app version, browser, links, how to click links, where to click links from, QA tester, vendor, owner, user experience.
• Define expected outcomes by iOS, Android, Web X User State (IE Has or Doesn’t have the app). This should create a clear matrix so you can test all expected outcomes. Within this table make sure to denote the mechanism by which deep linking occurs.
• Create a clear document that captures test cases – share and collaborate with team-members using the same document.
• Always write down every required component of the documented QA process – failing to document is failure to QA properly.

Simulating fresh installs – iOS

In order to simulate a fresh install on iOS do the following in this order:

1. Logout of the app.
2. Delete the app.
3. Clear your IDFA: Settings > Privacy > Advertising > Reset Advertising Identifier…
4. Clear your Cookies: Settings > Safari > Clear History & Website Data
5. Click on the attribution link – let it redirect you through to Safari landing page.
6. Click “Open App Store”.
7. Do not download the app from the app store unless you are testing the production app.
8. Load test/QA version of the app on your device if applicable.
9. Open the app.
10. Depending on your setup, you should see a fresh install and a deep link if you are leveraging the callback to route to the proper spot in the app.

Testing URIs

Recall that a URI is a Universal Resource Indicator. It is a URL or link that points to an app. In technical terms, this means that you cannot access a URI unless you have the app.

On iOS, the easiest way to fire a URI scheme and or route, is to type it into Safari and hit “go.”

If you have the app, it will open immediately. If the URI and Route exists and is handled by the app, it should take you to the appropriate spot in the app.

If you do not have the app, you will see an error like this:

Testing direct URIs

The below can be used to properly QA URI schemes and routes.

This should be part of every app’s standard QA process. You should maintain a known list of routes that are aligned on iOS and Android.

Here’s the process:

1. Logout of app
2. Delete the app
3. Install and open the test or QA app in use
4. Open the app
   1. On iOS, paste the URI into the browser on Safari
   2. On Android, put the link behind an <a href=””> element and click the button or link

On Android, it is often easiest to wrap the URI in an href element and host or put in an email or another type of medium. You cannot paste URIs into Chrome like you can with Safari.

For Attribution Link URIs – or URIs that are triggered by the 3rd Party Attribution Service – the process is very similar:

1. Logout of app
2. Delete the app
3. Install and open the test or QA app in use
4. Open the app
5. Paste the link into email, notes, or SMS
6. Click the link

Testing Universal Links

Apple Universal Links are possibly the hardest to test deep linking mechanism, not only because there are so many rules that could disable them, but also because there are known issues – one of which is not resolved and is a known bug with Apple.

Before reading below remember the following issues with Apple Universal Links:

• Check your AASA. Make sure it’s accurate and hosted properly
• Check your Entitlements File
• Make sure the domain is correct and listed in the Associated Domains
• Make sure you’ve filled in relevant information with your 3rd Party Attribution Service (with AppsFlyer, this UI can be found in the OneLink configuration menu)
• Make sure the link you are using has the appropriate domain, and pathname
• Make sure you’re not clicking the link from Slack or other non-supported apps or browsers (when in doubt, just use Notes or SMS app from Apple!)
• Do not wrap your Universal Link in any type of click recording

Test Process:

1. Get visual confirmation that the Universal Link domain is in the QA app Entitlements > Associated Domains.
2. Navigate to the domain/apple-app-site-association and validate that the file and the proper pathnames are present.
3. Delete all versions of the app from the device.
4. Power the device off and then on – this resets the device’s entitlement and AASA cache.
5. Install the test version of the app in question.
6. Using the NOTES app or iMessage, paste a link into the application.
7. Tap the link and note the following:
   1. You cannot use Slack, Outlook or other applications. Universal Links only work in some apps. Notes and iMessage are known, supported apps.
   2. Do not paste the link into the browser or use Chrome! Universal Links do not work in either of these situations.
8. The app should open immediately without a redirect through the browser.

Chapter 8

Appendix

Well known documentation and resources

• Deferred deep linking and install callback data: https://support.appsflyer.com/hc/en-us/articles/207032096-Deferred-Deep-Linking-Getting-the-Conversion-Data#Response-Keys
• Android URI schemes vs. Android App Links: https://support.appsflyer.com/hc/en-us/articles/115005314223-Deep-Linking-Users-with-Android-App-Links
• Android App Links (official documentation): https://developer.android.com/training/app-links/
• iOS – additional testing: https://support.appsflyer.com/hc/en-us/articles/115000262823-Additional-Testing-for-AppsFlyer-iOS-SDK
• AppsFlyer’s comprehensive set of link recording parameters: https://support.appsflyer.com/hc/en-us/articles/207447163-AppsFlyer-Tracking-Link-Structure-and-Parameters