Chapter 3

Attribution & Deep Linking Tech

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 link:

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.

Attribution:

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 (example: window.location.href.split(“utm_campaign=”)[0]). App Attribution is much more complicated as the Apple App Store 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 tool used to attribute and measure users using a combination of link click, probabilistic modeling, SDK and people-based attribution services.

Matching:

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 - IE a developer’s biggest foe. SDK’s are 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. During the writing of this document, Attribution & 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 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. Example: Below are two examples. The first is an example of a callback from the Appsflyer SDK. The second is an example of the “callback” to the iOS app if you were to leverage Attribution & Deep Linking with AppsFlyer via mParticle. In both cases you can witness how the SDK is responding to the app with JSON, which can then be used for custom event triggers, and deep linking.

Types of deep links:

The proper way to think about “types” of deep links is rather 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:
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):

When a URL redirects through another URL or webpage for redirection or measurement purposes. This breaks Apple Universal Links, and complicates Attribution & Deep Linking for email, and paid channels.

Android App Link:

Android App Links are the analog to 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.

About the Authors

Karen Cohen

Karen is WW Product Marketing Manager at AppsFlyer. She's a “full stack marketer” with over 10 years experience in online/offline and product marketing. Previous stops include numerous startups and Hewlett Packard, where Karen has built and led global innovation programs and product marketing teams.