Deeplink User to Review Your App on Playstore

Introduction

The land of attribution and deep linking today

Most people don't recollect nearly attribution and deep linking in the correct way today.

Legacy tools similar 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 fail the technical intricacies of attribution, API accessibility, partnership integrations, privacy, security, and robust technical support in both integration and tool usage.

Nearly infuriating, sales teams beyond the ecosystem misfile marketers past spinning tales near 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 paw in hand – you don't need two vendors to do the aforementioned affair.

World-grade attribution with all the major providers are table stakes. If you can't attribute your campaigns effectively across every known touchpoint, information technology doesn't matter whether you can have a user to a specific spot in the app.

Every bit 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 earth-class technical implementation, knowing that compelling UX starts and stops with proper tool setup and usage. In today's globe, compelling UX means treatment every OS, Os version, app version, browser and transition experience. There are millions of border cases which all contribute to the commonage experience.

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

Chapter one

Setting the stage: Attribution and deep linking

Allow's fix the stage for this playbook past showtime reminding ourselves of some fundamentals regarding attribution and deep linking.

What attribution is and why it exists

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

In lodge to "capture" their channel and other important data nearly a user's originating source, link the entrada that prompted them to download the app, you must use tertiary party vendors to attribute users.

This is attribution.

The vendors who supply such technology are attribution providers.

A vendor SDK is able to aspect a user by and large identifying the device on mobile web and then matching the user when they open up the app. For instance, when you click an AppsFlyer URL, the link redirects you briefly to a folio that takes a snapshot of your device.

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

There is no information passage through the app shop – except on Android, with the Play Store Receiver. So, the vendor'due south SDK within 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 fifty-fifty matter?

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

1. You cannot trust the paid media channels to accurately report your information. They accept an inherent conflict of interest in reporting accurate information to yous.
2. Yous need a single unbiased vendor to count data across sources and piping 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 charge per unit when they come up from a deep link compared to a regular attribution link.
5. Deep links take higher intent, which means a much college lift in acquirement. In fact, industry reports bear witness that deep linking provides a 148% lift in average revenue per user (ARPU).

Deep linking is an extension of attribution

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

This is simply not truthful.

Deep linking is the extension or usage of attribution information.

Allow's go through a basic example of how it works to illuminate the tech. In the caption previously, nosotros talked about how a user may click a link or an ad:

1. The attribution vendor and 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 "friction match" the user.

   They likewise tie this to an IDFA on iOS and and GAID on Android to persistently record the user. Matching tin can exist washed with a multifariousness of methods, such equally the ability to receive and lucifer the Google Play Shop Referrer, the iOS Safari View Controller Cookie, among other methods.

3. When the user has the app, the lucifer 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 (activeness 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 primal 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, and then the SDK provides a callback to the app that contains the link and other clan attribution metadata.

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

            { campaign: "CAMPAIGN_NAME", // "None" if non specified on the link media_source: "MEDIA_SOURCE", //"None" if non specified on the link cost_cents_USD : "0", is_first_launch: truthful, install_time: "2018-12-30 23:59:39.330", orig_cost: "0.0", af_click_lookback: "7d", click_time: "2018-12-xxx 23:59:09", cost_cents_USD: "0", af_status: "Not-organic" }          

Now, when you go this callback data, y'all can practice anything you desire – log a custom event, burn a message, log some activity, etc. But most importantly, y'all can await 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 showtime fourth dimension the app opens after a user installs to retrieve the attribution information, parse the link or defined path and road 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'due south talk about deterministic matching and probabilistic modeling.

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

This is grounded in technology such equally 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'south accept an case: 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 within the app tin can parse this value and lucifer the user instantly with 100% accurateness. This same system and methodology works for the technologies to a higher place, 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 just sometimes alien parameters.

While the chances of an verbal 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 exist well informed about the differences between attribution methodologies.

Now that we accept discussed these two different types of matching, let'southward talk nearly the event at pale: Sometimes vendors will merits to have a "higher match charge per unit" or discuss "people-based attribution methods" that claim they are able to improve aspect users beyond channels.

In that location is some amount of truth to this, only it'southward important to unpack the assumptions and understand why and how.

Now let's discuss "higher match rates"

Kickoff, college match rates are a function of how many devices and people accept been matched via a probabilistic model.

This in turn is a proxy of:

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

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

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

The second criteria for measuring accuracy is past far the nearly 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 friction match and attribute that user will inherently be better. If you use attribution links across paid media, email, smart imprint, referral, then you volition inherently exist recording people better beyond more touchpoints and therefore your ability to properly attribute them will be improve!

And third, how a company chooses to share or non 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 non share IDFA and GAIDs with other companies.

Instead, they create an bearding pool of matched Spider web Cookies and IDFA/GAIDs.

They leverage this information gear up 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 information technology 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 earlier.

In determination, don't believe the hype that some vendors accept "cracked the secret sauce"

When folks say that "legacy attribution systems tin 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, besides as how yous, 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 in that location are then many dissimilar names for the aforementioned matter.

Every bit of import, frequently marketers remember in terms of user experience, just the technical delivery mechanism of that experience is lost. And particularly relevant is even with the word "deep linking" – which marketers ofttimes interpret as driving somebody to a particular spot in the app, only as of the writing of this document – can exist 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 bulldoze the person to the right spot in the app in sure contexts.

With this in heed, permit's review some of the most common deep linking and attribution taxonomy. You lot can and should use this when speaking with your team and across members of product, applied science and marketing.

A Chrome Intent is an Android-but 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 spider 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 item location within an app, instead of just launching the app'south homepage offering a consistent, contextual experience from the promotion to the in-app landing page.

Attribution:

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

• Web attribution is solved past the utilize of web query parameters and javascript. A link is clicked, and the team could apply 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 non allow you lot to laissez passer query parameters through the download process. This means that every user on iOS is considered as a new user, unless you utilize a 3rd party attribution service.

3rd party attribution service:

A third political 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 Political party Attribution Service'southward SDK recognizes a set up of parameters and "matches" the user.

Technically speaking, the SDK sends over a asking to the server where the Attribution Service tries to wait for the same device that visited the web link. If information technology finds a positive friction match, it returns the entrada information (Attribution) as well as the link or other information elements associated with the spider 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.due east. a developer's biggest foe) is usually required in order to properly aspect a user, as the 3rd Party Attribution Service's SDK will collect and process the user information equally 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 accept to build the functionality using directly API calls.

In some cases, there are no public API calls and so choosing not to utilise an SDK ways limiting functionality and capabilities. In general, attribution and deep linking as a service has get a commoditized engineering effort and it is much better to leverage a 3rd party than to effort 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 infinite, at that place 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 fashion to think virtually "types" of deep links is every bit "mechanisms" of deep linking.

A deep link is whatever link that routes a user to the right identify in the app.

How this occurs, however, can vary greatly.

URI:

A Universal Resource Indicator for the app that is sent in the app'southward configuration.

This allows the app to be opened directly. "Routes" tin be configured much like pathnames tin be configured. Nearly apps accept URI Schemes and Routes.

Examples of URIs include:

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

The route is the part of the URI that comes after the base of operations 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 exist constitute here.

Apple tree Universal Link:

Apple Universal Links are a standard from Apple that is deployed on the iPhone operating organization (iOS), which allows a user to tap a link and be delivered immediately to the app (if information technology'south installed on their device). This is a system level route, equally 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 equally such, must have user intent. In technical terms this is manifested past Apple Universal Links not working when wrapped in other click measurement or routing services – including e-mail click recorders.

Apps and other in-app browsers, likewise tin 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 arrangement. They allow a user to tap a link and exist delivered immediately to the app (if it'south installed on their device).

This is a arrangement level route, equally opposed to a redirect through a URL or link service.

Chapter iii

A deep linking chronology

Things weren't always so circuitous.

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

In order to understand why things are so complex today, information technology'southward 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.

And so AppsFlyer pioneered the engineering science 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 cursory moment, the browser would know the operating organization (OS), it would have the platform configuration including the URI scheme and route, and and so Javascript would set up a timer and and then endeavor to fire the URI scheme and route
4. If the timer expired before the browser responded, so it was known that the user did not download the app, so the browser would redirect to the appropriate app store tied to that OS
5. Simply 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 likewise pass a clickId or linkId and then that it's SDK knew exactly where the user came from

This was a simple and articulate 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 nine.iii Apple introduced two things:

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

The quondam world was dead forever after iOS ix.iii was released.

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

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

Hither'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 Contour	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	North/A
Safari Address Bar	deep links to af_web_dp or af_ios_url fallback	North/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	Due north/A
Apple Business organisation 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.

Information technology's of import to be explicit when you talk most these concepts, else you risk disruptive or confounding dissimilar technologies which operate very differently.

Apple Universal Links

Apple Universal Links are a standard from Apple that is deployed on the iPhone operating arrangement (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 fabricated to Apple and the Os opens the app immediately without ever opening the browser or loading the URL.

How Universal Links work:

Universal Links take 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 pocket-size lawmaking change in the Entitlements > Associated Domains file of the iOS app.

Information technology's of import now to distinguish an essential point – Universal Links are non a "set of links" but rather a organization that is setup on links that your domain uses.

Universal Links can be enabled on your ain 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/Assistant-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 appropriately.

In both cases, information technology is causeless that the developer will take some type of parsing and routing on each link. In the above case the developer might parse everything after the domain. In the bottom instance, the programmer will handle the af_dp value explicitly.

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

As a terminal note, it is important to indicate out that almost every visitor'southward AASA is hosted at their main domain followed by "/apple-app-site-clan" and therefore you can easily find the AASA file for whatsoever company.

Android App Links

Android App Links is the equivalent linking arrangement that is setup on Android.Apple Universal Links & Android App Links are essentially web URL which are intended to straight 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, simply take the user to the exact content in the app if they practise.

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 organization volition 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

Treatment 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.

Instance ane: Handling standard attribution and routing

In this instance, information technology 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 department of this guide which elaborately lay out exactly the procedure 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 yous have setup your SDK and now you're trying to empathize 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 fourth dimension of click or install.

Since the conversion data is reliant on the attribution link, information technology ways 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 information 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.

Instance in action

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

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

1. ▿ 0 : ii elements
2. – key : click_time
3. – value : 2018-08-fourteen 02:37:xxx.798
4. ▿ i : 2 elements
5. – key : orig_cost
6. – value : 0.0
7. ▿ 2 : 2 elements
8. – primal : cost_cents_USD
9. – value : 0
10. ▿ 3 : two elements
11. – key : is_first_launch
12. – value : 0
13. ▿ iv : 2 elements
14. – fundamental : entrada
15. – value : Test
16. ▿ five : ii elements
17. – primal : 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 : ii elements
26. – key : media_source
27. – value : Email
28. ▿ 9 : 2 elements
29. – central : install_time
30. – value : 2018-08-xiv 02:38:40.012
31. ▿ 10 : two elements
32. – key : af_status

A few things should stand out immediately and information technology should be clear that you can use this central value structure in the callback of this function to parse data and apply it to road 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 tin can be used to determine whether this is the kickoff time the user launched the app afterward install, or whether the user already opened the app in the by.

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 beneath menses diagram outlines exactly how you could employ these two dissimilar functions in combination to receive install data when an install occurs, and to receive open information when information technology does not. From in that location, you could parse the different keys that you'd like to utilise 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 ii distinct methods as illustrated past this chart. Others might accept more or less.

The process past which you parse information from the callback and route the user, even so, should non change!

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

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

The key to this use instance is to outset, make sure you sympathize the response keys from each vendor, then to brand sure you prioritize who to handle from a deep linking perspective.

Last, only not least, we'll examine how you can log this attribution callback data to a custom upshot and then that you can trigger a push notification, pop upwardly promotion or other campaigns using your AppsFlyer information!

Example in action

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

This unmarried mParticle API wraps both of AppsFlyers callbacks – as well equally 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'south process, and will call your completion handler cake (iOS), or AttributionListener (Android), whenever there is a new conversion data bachelor.

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

1. (lldb) po linkInfo
2. ▿ 1 chemical element
3. ▿ 0 : two elements
4. ▿ key : AnyHashable("mParticle-AppsFlyer App Open Issue")
5. – value : "mParticle-AppsFlyer App Open up Consequence"
6. ▿ value : one 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 Effect")
13. – value : "mParticle-AppsFlyer Attribution Consequence"
14. ▿ value : 11 elements
15. ▿ 0 : 2 elements
16. – primal : click_time
17. – value : 2018-08-14 02:37:30.798
18. ▿ i : 2 elements
19. – key : orig_cost
20. – value : 0.0
21. ▿ 2 : 2 elements
22. – primal : cost_cents_USD
23. – value : 0
24. ▿ 3 : 2 elements
25. – key : is_first_launch
26. – value : 0
27. ▿ 4 : ii elements
28. – key : campaign
29. – value : Exam
30. ▿ 5 : two elements
31. – key : af_click_lookback
32. – value : 7d
33. ▿ half dozen : two elements
34. – key : af_dp
35. – value : jet://product/Carbona-Washing-Auto-Cleaner-three-Count/d1909b8fb76240d480df7c983452a913
36. ▿ 7 : 2 elements
37. – key : idfa
38. – value : 0000000-0000-0000-0000-00000000000
39. ▿ viii : two elements
40. – fundamental : media_source
41. – value : Email
42. ▿ 9 : 2 elements
43. – key : install_time
44. – value : 2018-08-14 02:38:40.012
45. ▿ ten : 2 elements
46. – cardinal : af_status

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

Just as in the example of handling the AppsFlyer SDK response directly, you should consider which one of these responses yous want to handle and how y'all 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? Nearly marketers prioritize the response from a paid-relevant, MMP qualified vendor like AppsFlyer.
2. Think to bank check both install and open responses from AppsFlyer.
3. If the response is "Organic" you might cull to check the other vendors, peculiarly if that vendor doesn't have a directly integration with AppsFlyer.

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

Below are samples of how to do this directly with AppsFlyer too 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 elementary as "Attribution" or "Attribution Data" and the eventValues should exist 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 *effect = [[MPEvent alloc] initWithName:@"Attribution Information"
                                         type:MPEventTypeTransaction];
event.info = @{@"key":@"value"};
[[MParticle sharedInstance] logEvent:consequence]

Andriod

Map<String, Cord> eventInfo = new HashMap<Cord, String>();
eventInfo.put("key", "value");
MPEvent result = new MPEvent.Builder("Attribution Information", EventType.Navigation)
   .info(eventInfo)
   .build();
MParticle.getInstance().logEvent(event);

Encounter farther documentation for iOS and Andriod.

Chapter 6

Advanced topics

Web-to-app strategy: Banners and links

Considering the driver of spider 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 touch on overall revenue? How do I compare my Spider web users to my app users?

Typically when teams that take widespread Mobile Spider web adoption and are worried well-nigh its impact on revenue, it's important to notation that App users catechumen to purchase universally at a much college 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 buy funnel. In improver to the overall ease of conversion on apps compared to mWeb.

Other factors play into why information technology'due south important to drive users to the app:

• Login

  When users are logged in on the app information technology 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 feel is easier and college quality to spider web. This is why users spend more time and convert more in apps compared to Mobile Spider web.

• Engagement

  In addition to having an easier and better experience in the app compared to Mobile Web, apps tin can leverage button notifications, bulletin middle, feeds and other native only elements to prompt users to purchase or pickup an abased cart. Email is the simply option bachelor for Mobile Web users to be prompted.

  This higher rate of activation can atomic number 82 to ameliorate 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 visitor's utilize of the same attribution system throughout your marketing stack – on web, in the app, on ads, and in emails – and then that people are more appropriately and intelligently attributed across touchpoints.

Every bit discussed, the more you measure out with a single attribution system, the better yous're going to be able to identify the sources of traffic and the richer quality agreement you'll develop of your users beyond platforms.

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

This is the central premise of People Based Attribution, and an argument for why you should stick with ane unmarried Attribution provider for all your needs.

What does a "bully" web-to-app strategy expect similar?

What does great web to app strategy even look like?

You're convinced at this point that you need a imprint, but how should you pattern it and what'due south the easiest way to power it?

There are a few options:

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

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

At that place are lots of reasons why this would be disadvantageous, only the crux beingness that it is an immense amount of work when in that location are easier options bachelor.

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

Option #2 is the optimal and easiest arroyo: use an out of the box Spider web SDK with its pattern and measurement solutions that are available as JS methods.

AppsFlyer provides some static code that is used to generate the imprint 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 imprint that floats on the top of the website and provides options in the settings variable that customize the championship, icon, call to action (CTA), as well as a long list of measurement parameter options that tin be customized and set at a static and dynamic level using Javascript.

The do good 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 example, AppsFlyer is creating the URL with the attribution settings and generating the link.

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

Regardless of your choice, i 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, simply they provide no customization.

If you're going to go to the problem 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 than sending users to the App Store.

Deep linked emails

Background

Ever since the advent of Apple Universal Links, countless marketers, production 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 complication is that there are so many different email clients that handle these mechanisms differently.

Even so, there is hope!

Deep linking with e-mail is non as complex as people make information technology out to be.

There is ane case that is hard to handle – iOS, when users have the app – only otherwise, zero really changes for the vendor, customer or user.

Yous tin can handle deep linking from email yourself, much like you handle routing from whatever other 3rd Party Attribution Service. Information technology just requires an understanding of Apple tree Universal Links/Android App Links, a willingness to utilise AppsFlyer or other vendor links in your URLs, and a willingness to change your client lawmaking to handle email links very specifically.

Why ESP deep links intermission

Let's speedily recap why emails frequently 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 existent case where deep linking behaves poorly is when the user has the app on iOS.

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

Every bit a final note, people oft 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 blazon of app and about Desktop experiences go to web even so, and then in that location is no modification needed.

Then, there you lot accept information technology – don't believe the hype from vendors who effort to sell you that deep linked electronic mail 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 well-nigh all cases based on the following assumptions:

1. You must fix deferred and regular deep linking. For AppsFlyer, this includes "OneLink".
2. You lot must set upwards Apple tree Universal Links and Android Apps Links with these individual vendors.

If you see both of these requirements, then using regular deep links in your emails works for iOS and Android when the user doesn't take 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 volition either open up the app immediately via a Chrome Intent or the ESP link will route to the attribution link which volition open up the app via a URI scheme. Yous could also replicate the exact same functionality on Android as on iOS using Android App Links.

How to run across upwardly deep links for ESPs

1. You will keep click recording turned on
2. You will setup Apple tree Universal Links and Android App Links on your ESP domain. Most ESPs now support this in their documentation.

   For instance, 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, and then the app volition 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. Y'all 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 == aught) {            NSLog(@"Unable to handle user activity: No URL provided");            return imitation;        }        NSURLSession *session = [NSURLSession sharedSession];        NSURLSessionDataTask *chore = [session dataTaskWithURL:encodedURL completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {            if (response == cypher || [response URL] == null) {                NSLog(@"Unable to handle URL: %@", encodedURL.absoluteString);                return;            }            // Now y'all take the resolved URL that you can            // apply to navigate somewhere in the app.            NSURL *resolvedURL = [response URL];            NSLog(@"Original URL: %@", resolvedURL.absoluteString);        }];        [task resume];    }    return Yeah; }          

Android

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

            - (BOOL)awarding:(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 imitation;        }        NSURLSession *session = [NSURLSession sharedSession];        NSURLSessionDataTask *chore = [session dataTaskWithURL:encodedURL completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {            if (response == naught || [response URL] == nothing) {                NSLog(@"Unable to handle URL: %@", encodedURL.absoluteString);                return;            }            // Now you have the resolved URL that you tin            // 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 bespeak. Because you volition become 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 electronic mail…

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

As you tin can come across, yous are not constrained to buying a deep linked e-mail product, or relying on a vendor in whatever mode you wa

Nosotros recommend you lot at least handle the example of your ain links and your preferred attribution and deep linking partner, but don't waste fourth dimension and money on product and services that pretend to simplify this well known technical arrangement.

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 e-mail service provider such as Sendgrid wraps up this link when the email goes out
• The email the finish 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, only doesn't have the app) so things work just fine. There's literally no divergence. It's just regular old link redirection.

Email redirect cases

When a user on iOS ix.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 beneath you tin can encounter three dissever cases:

1. This is the flow of what has already been described every bit deferred deep linking.

   Without whatever blazon of 3rd party redirection on your email links, you lot tin can use AppsFlyer links out of box to direct users to web or the app shop. Subsequently install they may be deep linked to the right identify in the app without any boosted client side handling.

2. In this case, it'southward assumed that 3rd party click recording is enabled with your email service provider.

   If you lot're using AppsFlyer or your own domain URLs, a simple piece of client side code can assist you unwrap the underlying URL and route the user to the appropriate identify 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 lot'll demand to unwrap the ESP URL and resolve. If they do not accept the app, AppsFlyer or your own domain URL tin can take them to the appropriate spot in the App Store or on Mobile Spider web.

3. If you're in need of a unproblematic solution, you can use AppsFlyer only to intelligently directly 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 apply the code snippet referenced in a higher place to retrieve the underlying URL.

If the underlying URL is an AppsFlyer link or one of your ain links where the query params are listed out, then no further async calls are required. Merely 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 demand to subsequently make an async request to AppsFlyer to recall 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 some other roundtrip call.

If it'southward any other type of URL you can handle it similarly.

Current bug with Apple Universal Links

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

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

Issue 1: No recording or attribution

Considering Apple Universal Links are non a redirect, but rather a system practical to links to open the app, it is very difficult to constitute true click recording.

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

In that location'southward 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 take 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 brusque, whenever you need to record users who click on links, y'all should employ a third 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 matter.

When a marketer runs an ad or sends an electronic mail, often the service they are using volition have the link they are using and "wrap it" or send information technology through a redirect so that the system they are using tin count a click. It does this past redirecting to their website before sending the user to the last 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 spider web fallback instead of to the app.

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

In both cases, other 3rd political party tools may wrap URLs you are using that would otherwise bear 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.

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

Most customers merely choose to ignore this, every bit information technology is only displayed in a few cases, while a click on Apple Universal Links would normally accept the user to your app and non your website.

Issue four: Full general performance instability

Starting with iOS eleven, many apps have noticed that Universal Links practice non always perform the aforementioned way.

iOS leverages the domain information from the Apple App Site Association (AASA) file y'all've established in order to open up 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 eleven.ii, 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 too known to be hard to debug with many implementation steps to install.

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

Bold you've setup Universal Links on your regular URLs, or on the URLs you employ for your attribution provider, you can exam this and perchance get Universal Links to work over again by doing the following:

1. Logout of app
2. Delete app
3. Install the app from the app shop or examination/QA site
4. Restart the device (turn off and so on again) – on iOS 11 this can oft fix strange entitlement problems where the behavior of the link is not correct when clicked
5. Create or discover a link you are trying to exam
6. Paste the link in Notes, iMessage or in an electronic mail using the Apple Postal service Client
   • Do not use Slack, Facebook or any other app to click the link
   • Practice not paste the link into Safari – this will not piece of 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 seven

Testing & QA

Whether it's attribution or deep linking, or both, it is vital to your product and marketing teams to take 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 yous testing?
• Are your query parameters authentic?
• 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, package identifier and path that is associated with your test or prod app?

These are only some of the questions you must ask when QA'ing link.

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

Process philosophy

• Define a clear test process and goal.
• Explicitly state every component of the procedure – leave goose egg to assumption or speculation (the above questions are the types of questions yous 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 past iOS, Android, Web X User State (IE Has or Doesn't have the app). This should create a clear matrix so you lot tin can test all expected outcomes. Inside 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 certificate.
• Ever write down every required component of the documented QA process – declining to certificate is failure to QA properly.

Simulating fresh installs – iOS

In lodge to simulate a fresh install on iOS practise the post-obit in this society:

1. Logout of the app.
2. Delete the app.
3. Clear your IDFA: Settings > Privacy > Advertising > Reset Advertizing Identifier…
4. Clear your Cookies: Settings > Safari > Clear History & Website Information
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 yous are testing the production app.
8. Load test/QA version of the app on your device if applicable.
9. Open up 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

Think that a URI is a Universal Resource Indicator. Information technology is a URL or link that points to an app. In technical terms, this means that you cannot admission a URI unless you have the app.

On iOS, the easiest style to fire a URI scheme and or route, is to type it into Safari and hit "become."

If you have the app, it volition open up immediately. If the URI and Route exists and is handled past the app, it should take you lot to the appropriate spot in the app.

If you do non have the app, you volition see an mistake like this:

Testing directly URIs

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

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

Here's the procedure:

1. Logout of app
2. Delete the app
3. Install and open the test or QA app in utilise
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, information technology is often easiest to wrap the URI in an href element and host or put in an electronic mail 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 third Party Attribution Service – the procedure is very similar:

1. Logout of app
2. Delete the app
3. Install and open the exam or QA app in utilise
4. Open up 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, non only because there are and so many rules that could disable them, but too because there are known issues – one of which is non resolved and is a known issues with Apple.

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

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

Exam Process:

1. Become visual confirmation that the Universal Link domain is in the QA app Entitlements > Associated Domains.
2. Navigate to the domain/apple tree-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 then on – this resets the device'due south 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 awarding.
7. Tap the link and note the post-obit:
   1. You cannot utilise 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 non work in either of these situations.
8. The app should open immediately without a redirect through the browser.

Share

andrecomir1964.blogspot.com

Source: https://www.appsflyer.com/resources/guides/deep-linking-for-developers/

Bagikan Artikel ini