

Show HN: Branch – Mobile links that pass data through install and open - maephet
http://www.branchmetrics.io/?hn=show

======
volaski
If an app is a social app (like in the animated gif demo), that would mean
that the app creator already has some server code. Creating a custom link
would be pretty easy in that case. I'm not sure if i understand the use case
here.

~~~
palakchokshi
The use case here is that a user can go from a link in an SMS, email, facebook
post, tweet, etc. to app store for install and once installed goes directly to
the content shared. Right now a link could take you to the app store to
install but once installed you would not be able to immediately see the
content that was shared with you since it's difficult to figure out which user
had installed the app and whether that user was the one that got the original
link. I am going to keep an eye on this for when I'm ready to launch my app...

Edit: Here's a link to the article that describes the use case in more detail
[http://techcrunch.com/2014/09/23/branch-metrics-
raises-3-mil...](http://techcrunch.com/2014/09/23/branch-metrics-
raises-3-million-from-nea-for-more-intelligent-deep-links-that-make-apps-work-
like-the-web/)

------
notduncansmith
Not to be confused with Branch, the social discussion platform:
[http://branch.com/](http://branch.com/)

------
hiroprot
How are you doing the tracking across the app store? Some kind of cookie in
Mobile Safari, or attributing based on time/IP address correlation?

~~~
maephet
Alex with Branch here. Let me try to explain how it works. Basically, we use
different technologies in different scenarios with the goal to deliver the
user to the app as fast as possible.

First off, the most basic case is where we know the user has the app
installed. In this case, we use the standard URI scheme based deep link which
opens the app up right away and passes the link data. We also handle the case
where they had uninstalled the app, by taking them to the app store.

If we have never seen a user before across our entire network of apps based on
our first party cookie, we use a mechanism called fingerprinting. It's
commonly used for mobile app install attribution to tell a marketer how many
installs were generated from a particular advertisement shown in another app
or on a mobile site. Basically, we collect as much information as we can in
the browser (time, OS, screen size, IP, etc) before redirecting them to the
app store. When the user opens up the app, we generate that same set of
information inside the app and send it back to our service to match up with a
pending browser fingerprint. In the case of a match, we know that new user
came from a particular link and pass in all the data associated with the link.
This can happen across install and open. If we have seen the user before, we
just match up our cookie to the unique device ID once the user shows up.

The service also comes bundled with a free text-me-the app service which helps
pass the link data from a desktop click to the phone and eventually the app.

It's everything that we've always wanted as a linking service for our own
apps, plus all the accompanying analytics to measure the performance of your
various features. Try it out as it's free. We'd also love recommendations or
feedback on how we display the data on our dashboard.

Best, Alex

~~~
rpicard
What happens when someone's fingerprint matches up with another? Do they get
access to data that they shouldn't have access to?

~~~
maephet
Unfortunately, there is a very low probability of the mismatch until we have
effectively seen every device. As our linking service expands, that percentage
gets lower and lower. In our experience, the user experience and analytics
insight benefit far outweighs the consequence of a mismatch because they are
so rare. We encourage our developers not to bundle sensitive data into the
links if they use this base case.

If a developer does want 100% match, we have a separate option that can be
used with a slightly degraded user experience which pops the browser open
really quickly to check the cookie, then returning to the app with the URI
scheme.

~~~
jeremyflores
FWIW, Apple has frowned upon the browser cookie check approach and they might
reject a submission using it: [http://techcrunch.com/2013/02/25/apple-
rejecting-apps-using-...](http://techcrunch.com/2013/02/25/apple-rejecting-
apps-using-cookie-tracking-methods-signaling-push-to-its-own-ad-identifier-
technology-is-now-underway/)

Do you guys have any estimates as to what the rate of error might be for the
fingerprint approach?

Excited to see where you guys are going with this product!

~~~
maephet
Ah interesting. We wouldn't be using it in every scenario, basically only
scenarios where we believe there to be a match and want 100% confirmation.

Thanks for sharing!

