This guide will walk you through the various mechanisms you can use to deep link through install. There are so many techniques, and they all have their time and place to deliver a compelling deep link that works in all scenarios. This post is meant to give you some insight into how the typical Branch link works when it comes to passing data through install. To learn more, keep reading or request Branch demo.
Branch links deliver best-in-class deep linking because we sweat over every little detail to drive the best possible performance, no matter where the link is clicked. Due to our scale, we’re able to achieve the highest match rate in the industry through a large collection of proprietary browser-device pairs. As a result, snapshotting is becoming more of a fallback mechanism than anything else.
What Are Deferred Deep Links?
One of the biggest problems with today’s deep links is that they only work if the app is currently installed. Tools like Branch are the only way to make deep links work when the app is not installed. Branch links handle this scenario by quickly falling back to an app store or webpage. By using deferred deep linking, you can route to the settings page after the app is installed if the user clicked the settings page. It carries through the user’s context through install. Users should see the page they clicked on, always.
Deferred deep linking is incredibly important because it delivers a continuous experience rather than defaulting to a generic onboarding flow. A deferred user has a personalized experience depending on their origin. This has shown to yield a dramatic impact on the overall conversion and retention of a user. For example, a survey across the thousands of apps using Branch as found delivering a deep linked first install experience will yield at least a 100% lift on both conversion to sign up as well as three-day retention.
So you’re probably thinking: if this is so great, why isn’t everyone doing it? Well, the answer is because it’s technically challenging. In the next few sections, you’ll get an understanding of how we do it.
Basic Device Snapshotting
The most basic, and simplistic form of deferred deep linking is with a technique called device fingerprinting. Fingerprinting itself has a bit of a negative connotation from the web era, where advertisers would attempt use bypass cookie blockades using fingerprint parameters to uniquely identify users. When it comes to mobile, things are much different and we believe the term ‘snapshot’ is a more representative term for what actually occurs.
Device snapshotting has two places where a snapshot is collected: on the server when a link is clicked and after the app is installed and opened. We refer to the link-based snapshot as the browser snapshot and the app-based snapshot as a device snapshot. A snapshot is a set of characteristics including timestamp, IP address, OS, OS version, device model, screen size and more.
After receiving the device snapshot from the app open, you must attempt to match it up to a corresponding and outstanding browser snapshot that was collected upon link click. If there’s a match, you can be very certain that the user originated from this click. If not, they must have opened the app directly.
For accuracy and practical reasons, Branch only keeps a browser snapshot outstanding for two hours after the click by default. Some refer to this as an `attribution window`, although the snapshotting attribution window is very different than an ad network attribution window. We use 120 minutes because we’ve found that on average, >99% of users who will open up the app after clicking a link will do it within the first 60 minutes.
Measuring Match Success Rate
We often hear people say, “this company said they have 95% accuracy of fingerprinting” or “the industry standard is 75%”. All of this is nonsense because matching is a boolean function. Either the set of parameters matches or it doesn’t. It’s very simple. You can’t measure success rate when you don’t have an additional verification factor.
Secondly, the match rate is very dependent on the use case and environment of the clicking users. Imagine these two completely different use cases. One app wants to send a single link to a crowd of people attending a conference who all happen to be connected to the conference’s public WiFi. Another app allows its users to send individual links to friends via SMS. The first one will have hundreds or thousands of people clicking links and opening the app around the same time on the same IP address. The second will have individual users, scattered around the globe, clicking links at different times with very different IP addresses. The second will naturally have a much more accurate match rate.
Don’t believe these nonsense numbers!
Advanced Snapshotting
There are a couple other techniques you can deploy to improve the accuracy of your snapshotting if you’re not satisfied with the basic mechanism. The simplest thing you can do is reduce the attribution window. Practically speaking, the longer the attribution window, the higher probability that you will see a different user open up the app with the same snapshot as a clicking user. The shorter the window, the more likely you’ll miss a clicking user who had a slow download or didn’t open the app immediately. Branch has seen apps decrease the window to five minutes for some links and increase it to 12 hours for others.
Another advanced technique you can use to improve reliability is one that we call the ‘unique match constraint’. The core premise is that you only ever allow a single, unique browser snapshot for a given attribution window. If you see more than two of the same set of snapshot parameters, you block that set of parameters from matching into the app. For example, if two users, with the same exact phone and operating system version, connected to the same WiFi were to click on a link, you would block that set of browser snapshot params for the remainder of the attribution window, preventing them from being matched to any device snapshots. In certain circumstances, this reduces the number of incorrect matches.
Memory-Based 100% Match Technique
One technique that can improve match accuracy is to give your snapshotting technique a memory. Branch does this by saving a record of all the historically matched browser and device snapshot pairs. For long-term identification of these snapshots, we set a first-party cookie in the browser and save the IDFA or GAID. In case you’re not familiar, the IDFA (iOS) and GAID (Android) are the same as a browser cookie, but unique to a device and accessible from any app on the user’s phone. We only save these pairs when we’re sure they match, which is when we directly deep link from the browser into the app.
Then, when a user clicks the link again, you can look up their cookie and see if there’s a corresponding device snapshot historical match. If there is, you can ignore all of other parameters and just compare cookie to IDFA/GAID. This will result in a 100% match through install.
For an individual company, this isn’t extremely helpful unless you’re resurrecting old users. However, for a centralized linking service like Branch, this becomes immensely valuable. It means that even if a user clicks on a link to your app for the first time, if they have previously been matched with a Branch link from any other app, they will have a 100% match rate on this link click for you app. With over half a billion snapshots to date on the Branch service, this becomes the primary mechanism for matching users through install and delivering the deferred deep link.
Facebook App Links and 100% Match API
With Facebook’s new push around the App Links protocol, they’ve built a couple mechanisms to support deep linking from app install ads and app invites. It’s a bit clunky and poorly documented, but it works well. Branch has incorporated this technique and will use it whenever available.
Technically, it will require you to ask the Facebook API if a user came from their platform every single time the app is installed. You need to POST to them the IDFA/GAID of the user who just installed via this endpoint. Facebook will return back either: 1. a 500 error indicating that the user did not come from them or 2. the App Links associated with the object that a user originated from. You can use the App Link data to determine which link the user clicked, and deep link through install with 100% accuracy.
iOS 9 Safari View Controller 100% Match
With iOS 9 comes a bundle of new toys to play with. The most relevant to matching is the new Safari View Controller which shares the same cookie space as the main Safari app. This means that you can finally, from within the app, verify if that user just originated from a click in Safari.
The one downside, that the post doesn’t describe, is that this technique is slow. The current implementation of Branch snapshot and cookie-IDFA pair matching can complete in 5-10 milliseconds, whereas we’ve found it takes in the hundreds of milliseconds for the SafariViewController to even load in memory. We’ve opted for performance over accuracy, since our cookie-IDFA pool has become so reliable as of late.
Google Play INSTALL_REFERRER Broadcast
Last but not least, Android also has a technique which can yield 100% accuracy for deferred deep linking. It’s an interchange that happens between the Google Play store and your app after it’s been installed. Basically, you just need to append a custom referrer query parameter to the end of the Google Play store URL when you send a user there, then Google Play will fire off a message, called a broadcast intent, to your app that will include a custom referrer parameter.
Here’s an example. You can redirect a user to ‘market://details?id=com.myapp&referrer=deferred_deeplink_stuff`. Then, if a user installed after clicking that link, you’d receive the ‘deferred_deeplink_stuff’ in the app.
Similar to the Safari View Controller, Google Play is very unreliable when it comes to delivering this message. We’ve seen it take a second or two before it’s delivered, meaning that the user experience can be a little shaky. Branch has opted to use it when it’s available but rely more on our snapshotting and cookie-GAID pool for performance reasons.
Conclusion: Performance Comes First
Deferred deep linking is the lowest hanging fruit of all product features. If you’re thinking about growth and user onboarding, it’s an essential tool. Hopefully this helped explain why a third-party company like Branch exists to deliver this service to you. It’s not something you’d want to build this yourself.