6 ms·

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?

jeremyflores 12y ago
I'm really curious about this as well. Last I checked, Safari is sandboxed w.r.t. session data, and something like time/IP seems really difficult to use reliably, e.g. if the user is interrupted and waits a while before installing the app. Or they could instantly install the app and wait a week before remembering to open it. I'd love to use this service, but is the tracking guaranteed?
chandraonline 12y ago
My guess would be some sort of fingerprinting in the browser like this: https://github.com/Valve/fingerprintjs https://github.com/Valve/fingerprintjs
- jonahx 12y ago
  are you saying that the app opens up a webview in the default browser, computes the fingerprint, then sends that info back to the server, which compares it to recent link clicks, possibly also taking into account other info like ip?
  - chandraonline 12y ago
    Yes. That is what I am guessing. If the app is opened close to the user's click, it might be fairly reliable. I think hasOffers and few of the other tracking companies do this. But I am sure branch has figured out a better way to fingerprint.
    - jonahx 12y ago
      I thought the IDFA could be used to do tracking like this, or am I misunderstanding something? http://www.adexchanger.com/mobile/apple-throws-a-bone-to-app-marketers-blesses-idfa-for-attribution/ http://www.adexchanger.com/mobile/apple-throws-a-bone-to-app...
      - maephet 12y ago
        The IDFA has been blessed for this. All of our partners have been submitting their apps with that option checked without issue.
- pbreit 12y ago
  Except: "browser fingerprinting is not good with mobile browsers"
maephet 12y ago
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 12y ago
  What happens when someone's fingerprint matches up with another? Do they get access to data that they shouldn't have access to?
  - maephet 12y ago
    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 12y ago

I'm really curious about this as well. Last I checked, Safari is sandboxed w.r.t. session data, and something like time/IP seems really difficult to use reliably, e.g. if the user is interrupted and waits a while before installing the app. Or they could instantly install the app and wait a week before remembering to open it. I'd love to use this service, but is the tracking guaranteed?

chandraonline 12y ago

My guess would be some sort of fingerprinting in the browser like this: https://github.com/Valve/fingerprintjs https://github.com/Valve/fingerprintjs

jonahx 12y ago
are you saying that the app opens up a webview in the default browser, computes the fingerprint, then sends that info back to the server, which compares it to recent link clicks, possibly also taking into account other info like ip?
- chandraonline 12y ago
  Yes. That is what I am guessing. If the app is opened close to the user's click, it might be fairly reliable. I think hasOffers and few of the other tracking companies do this. But I am sure branch has figured out a better way to fingerprint.
  - jonahx 12y ago
    I thought the IDFA could be used to do tracking like this, or am I misunderstanding something? http://www.adexchanger.com/mobile/apple-throws-a-bone-to-app-marketers-blesses-idfa-for-attribution/ http://www.adexchanger.com/mobile/apple-throws-a-bone-to-app...
    - maephet 12y ago
      The IDFA has been blessed for this. All of our partners have been submitting their apps with that option checked without issue.
pbreit 12y ago
Except: "browser fingerprinting is not good with mobile browsers"

maephet 12y ago

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 12y ago
What happens when someone's fingerprint matches up with another? Do they get access to data that they shouldn't have access to?
- maephet 12y ago
  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.