安装iOS应用后的深层链接（延迟的深层链接）

Question

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)

Answer 1

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.

Answer 2

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/ )