Steps
In order to properly deep link through the App Stores, we use a technique called fingerprint matching. This is where we grab a fingerprint snapshot of a user in the browser before redirecting them to the appropriate app store. When that user installs the app, we send a new fingerprint snapshot from our native library to be matched to the browser fingerprint. We are often asked about the accuracy of this technique, so we’ve written this section to help –
- “How accurate is Branch?”
- “Can I trust Branch enough to base rewards on it?”
- “Do you ever mess up?”
And most importantly…
- “What control do I have over Branch’s matching algorithms?”
The following addresses all of these questions.
How does Branch matching work?
There are three mechanisms by which we pass data through to the app and attribute app sessions back to the source:
1) Direct deep linking
If the app is currently installed on the phone, and you’ve configured your Branch links with your app’s URI scheme (myapp://), we will open the app immediately and pass a click identifier through to our native library. This click identifier is then sent to the Branch servers to retrieve the dictionary of data associated with the link.
For example, we’d call myapp://open?link_click_id=123456 to open the app immediately. The Branch native library parses out link_click_id: 123456 and passes it back to the Branch API to retrieve the link associated with that link click.
2) 100% match browser-app profile hit
Because we set a first party browser cookie on the bnc.lt (Branchlet) domain for any app that uses a Branch link which is deterministically matched up to the hardware id or IDFA retrieved via our native library on every link click, we can use this historical data to guarantee 100% accuracy on repeat users. So, when a user clicks a Branch link for your app, and we’ve seen them click a link for another app on our network, we’ve already matched them up to a corresponding app identifier. This means that when they install the app, we know with 100% certainty that they just came from that link click.
The fact that we have such a global network of apps with hundreds of millions of users clicking links, means that when you join the platform, you can benefit from the crowd-sourced accuracy gained through all our apps contributing the browser-app profiles.
3) Browser to app fingerprint match
Branch collects information about devices both when a user is in the browser – via a click on a Branch link – and then after they open the app. This information includes IP Address, OS, OS version, device model, screen size and other parameters. This is the user’s digital fingerprint and can be obtained in the browser and in the app.
We match the unqiue fingerprint collected in the app to the unique fingerprint collected in the browser to determine where user originated from if the prior two mechanisms were not used.
Believe us, this very, very accurate.
The nuances and edge cases
It’s technically possible that users can click the link at the same time and have identical fingerprints. Same IP address, identical devices, identical software versions and never before seen by Branch. It’s very rare out in the wild. For this reason, if someone clicks a link but doesn’t open the app, we “expire” their browser-based digital fingerprint after two hours by default. However, this duration is completely tunable by you.
A note about potential mismatch: This is an extremely rare case. So much so that the benefit to you from analytics perspective and the user from a personalization and delight perspective greatly outweigh the rareity of a mismatch. We only make you aware if it in order to design your new user experiences to be tolerant.
Match Type
If you are super concerned that users may potentially have the same fingerprint, you can choose to have us not match users if two identical fingerprints are outstanding. On the Dashboard’s Link Settings page, under advanced options, you should set Match Type.
This means that if two users with the same fingerprint, on the same wifi, were to click the link, we would blacklist that digital fingerprint for the expiration duration. Therefore, when they open up the app, no match would be made.
Duration
You can also modify the 2 hour default expiration for browser-based digital fingerprints. This can be set for individual links. Look for any methods with the “duration” parameter. This duration should be set in seconds. Two hours = 7200 seconds.
On iOS
One of the many methods in the iOS SDK:
- (void)getShortURLWithParams:(NSDictionary *)params
andTags:(NSArray *)tags
andChannel:(NSString *)channel
andFeature:(NSString *)feature
andStage:(NSString *)stage
andMatchDuration:(NSUInteger)duration
andCallback:(callbackWithUrl)callback;
On Android
One of the many methods in the Android SDK:
public void getShortUrl(String channel, String feature, String stage, JSONObject params, int duration, BranchLinkCreateListener callback)
Via the API
Any time you request a link via the API, you can insert a ‘duration’ parameter with the integer value of the fingerprint expiration time you’d like for that link.
On the Dashboard
Lastly, you can specify the default timeout duration for all of your links on the Dashboard’s Link Settings, under the Advanced Settings section.