8

How can you solve this scenario:

User is using Safari on iOS. They click a link on a website that says "View Profile on our app". The user does not have the app, they are taken to the app store to download the app. After they open the app, the app immediately loads the profile screen (instead of the main screen).

Currently in order for us to solve this problem, when the app is installed we immediately open Safari to grab the session cookie, if it matches the one on the server we load the right screen. However, Apple is now rejecting our app (and others) for loading Safari at startup.

What is a valid solution that won't get rejected by Apple?

(Also note that we were exploring IDFA - which would have worked - but Apple is rejecting apps that use IDFA if the app isn't using Ads)

Quentin
  • 3,971
  • 2
  • 26
  • 29
Spentak
  • 3,359
  • 3
  • 21
  • 31
  • 1
    I don't think you can without getting rejected, you will have to get the user to sign in or press the "View profile in our link app" again – Oliver Atkinson Oct 09 '14 at 19:03
  • It appears there is a way: http://blog.urx.com/urx-blog/2014/10/7/implementing-deferred-deep-linking – Spentak Oct 10 '14 at 16:03

2 Answers2

8

This is definitely possible without the IDFA.

Basically, create a URL endpoint on your server that will 302 to the App Store on GET. When a user clicks this link, collect IP Address, OS, OS version, device model, screen size and other parameters and store it as a browser fingerprint.

Then, after the user installs your app, send the same array of meta data to your server as a device fingerprint. Your server can then match this device fingerprint to the browser fingerprint. If there's a match, you can be very certain that the user originated from your link.

Just to give you an idea of numbers, we (at Branch) give this service away for free and now process hundreds of millions of these match queries per day. We've seen that if a user will install, 99% of them will do it within the first 60 minutes. Just empirically, we estimate that this mechanism, with a short window of 2 hours is very close to 100% accurate.

For an added benefit, if you collect IDFA, you can drop a cookie on the browser on redirect and then store the matched pair to the IDFA to create a semi-permanent alternative to the fingerprinting mechanism I mentioned above. If someone clicks your link again, and you've got a cookie stored in the browser, you'll know who they are when they send their IDFA back to your service on install because you've seen that story play out before.

Alex Austin
  • 1,142
  • 8
  • 11
  • This question is about iOS, though. Most of those parameters are not useful for fingerprinting iOS devices — the OS is a constant, very few OS versions will be seen at a time, device model implies screen size, *etc*. You're essentially just fingerprinting based on the IP and device model, which will sometimes fail, potentially in some very surprising, privacy-breaking ways… –  Nov 27 '15 at 19:08
  • Is this still relevant 5 years later? – FlavorScape Apr 02 '20 at 18:41
0

The best solution requires IDFA, which you are in fact allowed to collect for the purpose of deferred deep linking. The "Apple IDFA Scare" was a bit overblown in the media, and Apple revised its T&Cs to make it more clear. Apple also allows you to collect IDFA if you are an advertiser, for attributing installs, or for attributing post-install actions. In other words, you don't have serve ads in your own app in order to collect IDFAs.

Here's a link to the current Apple policy (https://developer.apple.com/news/?id=08282014a ), and this article from AdExchanger goes into a little more detail (http://www.adexchanger.com/mobile/apple-throws-a-bone-to-app-marketers-blesses-idfa-for-attribution/ )

jmilinovich
  • 1
  • 1
  • I have found that you can't use IDFA for deferred deep linking because mobile safari does not grant access to the device IDFA. Unless you know of a way? Meaning if you are on the mobile safari and click a link, the web host has no access to the IDFA. – Spentak Oct 10 '14 at 20:46
  • i would just have the app make a request to your API to get the user fingerprint and redirect url – FlavorScape Apr 02 '20 at 19:28