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)
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.
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/ )
Related
This is the first time I upload an app to apple app store. After weeks for reviewing, finally, I get my app listed on apple app store. But the problem is, now seems like my app app-store page is only viewable from iTunes. When I try to open it in a browser, it will shows "Connecting to the iTunes Store...". Why is it my app can't be the view from the browser? Why did another app can? How to fix it?
Short answer: It seems, you cannot fully predict the behavior of an app store link for a certain user. You being redirected doesn't mean other people will be redirected right away as well. Your app's country/language availability, users' app store region and language settings, the specificity of the app store link (which has optional components and alternative styles), and the browser cache all seem to have a say.
Added details: After experimenting with this a lot, it seems to me that the behavior of the link (or rather the response from the Apple server to requesting it) depends on the language/country version being requested, my own current country/language defined in iTunes/my app store account, plus some caching issues. So, whether a preview page is shown in the browser, or iTunes is attempted to be opened right away depends on several factors and doesn't always have the same result (for different users). In fact, two consecutive attempts to open the same URL can have different redirect behavior.
I noticed that a full app store link like https://itunes.apple.com/us/app/keynote/id361285480 more likely leads to the preview web page, if the app is available in the language/country referenced ("us" in the example) and there is no prior request cached in which I clicked through to the app in iTunes. If the app isn't available in the referenced location, or any other information is missing in the link for the Apple server to identify a particular language version on the preview website, or there is cached data that makes Apple confident enough to redirect you to iTunes directly (or it's Friday 13th and the moon is right behind the sun by pure chance...) then you may see a redirect instead.
For posting app store links in the likes of Facebook, Apple's app linker seems to produce URLs with the nicest preview snippets (and not: "Connecting to the iTunes store"), when putting in the right country. So, these generated URLs seem to be most complete/specific.
If your app is intended for a specific region, AppStore connect will still give you a URL with .../us/... in it. Changing it to the respective local region seems to fix the problem for me.
For an example,
given URL: https://apps.apple.com/us/app/yourcompany/id123456
If the app is for Norway region, change the URL to: https://apps.apple.com/no/app/yourcompany/id123456
We're trying to implement deferred deep linking in one of our iOS applications to encourage users to invite their friends to use the app, and reward users based on how many installs occur from their referral link. Basically similar to TapStream's product.
Consider this example:
So, UserA shares their link, “ourappURL.com/refer?id=userA”, on any
network they want. UserB clicks that link, which will take them to
Safari and then bounce them to the App Store page where UserB
downloads the app.
When UserB opens the app, the app checks which referral ID they came
in on (if any). In this example, the referral ID would be “userA” as
that’s the ID that was in the referral link. The app then sends this to
our servers and we award UserA with a referral credit.
I'm trying to break this issue down into its core parts. I believe the first part is getting the web page for the user's referral link to save the referral ID to the device somewhere that the app can access it. But I'm not sure this is possible because of the sandboxed nature of iOS.
I know this is fundamentally possible because many ad providers offer the ability to track installations from an ad campaign (see Mobile App Tracking for example).
We have also attempted to do this ourselves and I will try to break down the different steps here.
Going back to your example, you are correct about "remembering" the device identification, and all relevant data "id=userA". You are also correct about "sandboxed nature of iOS" which I presume it means a web page is not allowed to store information outside of the browser app (Safari) and apps (your app) are not able to access information stored by other apps (Safari).
Our solution to this is to store this device to data key-value pair in an environment that is both accessible by the browser as well as by your app, i.e. your backend server.
The next challenge, which remains to be the biggest challenge, is how to uniquely identify this device from the information collectable from the browser? Javascripts in browsers, unlike native apps, don't have access to IDFAs which could be used to uniquely identify a iOS device. To overcome this, one can imagine to use a combination of common information that is available both to the browser app as well to your native app, i.e. OS type, public IP, screen size, etc. etc. Please note, a composite key from these data fields does not guarantee uniqueness (imagine two iPhone 6 visiting this web page via the same router). Therefore, your backend server (assuming you are using it to store this key-value pair), will want to have a strategy on how to handle collisions on keys i.e. the second key deletes the first key, or you allow collision to exist by having a queue of values for a single key. This really depends on how you actual plan to use this technology.
The last step is to form this composite key on your app using the exact same fields you used earlier in the browser to perform a "lookup" on your backend server to retrieve the value previously stored.
Here is a summary of the steps:
User 1 invites User 2 by sending the following link to 2: example.com?inviter=1
User 2 visit Web Page P
P constructs and sends the following key-value pair to your server S iOS|55.55.55.55|750×1334 -> inviter_id=1
User 2 goes to the app store and downloads your App A
User 2 first launches A, A contacts S with the same key (assuming the IP hasn't changed).
S finds the value inviter_id=1 by using this key passed in and, let's say, reward User 1 five points for inviting 2.
Hope this help!
Edit 04/24:
Since Derrick mentioned it in the comments, I figure I would take this chance to finish our story here.
Going back to the beginning of my answer where I mentioned we've attempted to do this ourselves. We had a working prototype based on our current system architecture (which is not in anyway optimized, or meant to be optimized, for storing and analyzing deep link data like this), we ultimately decided not to allocate any additional engineering resource into this project.
Due to the heuristic nature of this matching process, we found this project needing debugging, tuning and optimizing constantly for a diminishing ROI. More importantly, we have found other companies which are more specialized and do a much better job than ourselves.
It has been probably 6 months since we stopped using our internal system and we haven't regretted making such decision.
During this processes, we've worked with a number of vendors, Appsflyer, Adjust, TapStream and we have ultimately ended up with Branch Metrics https://branch.io.
Whether you should DIY or work with another company again depends on your specific objective. We finally decided to stay with Branch, not only because the other vendors charged anywhere from $500 to thousands of dollars per month while Branch is completely free, but also the level of the support they have provided is simply unparalleled.
We've successfully used the clipboard (NSPasteboard) to achieve this: the web page that processes the redirect to the app store does a paste to the mobile device's clipboard before letting the user download the app. Once the app is installed, it uses NSPasteboard on first launch to check for an appropriately coded string. This string can contain the text of interest or, more securely, a token used to fetch interesting data from the backend. In Objective C:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;
The clipboard can be cleared once the app is done with it, to avoid repeating the same action.
There is a good solution here: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/
Basic workflow:
User selects domain link on web.
Link sets referral ID to cookie.
User redirected to app store.
On app launch, load referral page in SFSafariViewController.
Referral page checks for cookie and if it exists calls a deeplink into the app with the referral ID.
My answer from HERE
Apple no longer supports Deep Links. It is now called Universal Links and works a bit differently.
Source
Now that Apple no longer supports URI schemes for deep linking, developers must implement Universal Links in order to deep link properly on iOS. If you are already using URI schemes, check out our blog on transitioning to Universal Links.
From: HERE
And HERE is another article on Universal Links and what they are.
I should be able to track the click to install conversion, with tools like Flurry or Adjust (ie. user clicks on a generated link, and is redirected to my app on the iOS AppStore and I could see, the click and the install).
How does this work, from the technical side. I'am generating a link, where I can obviously track the click very easily, but how do I get the conversion, from click to install? I can redirect the user to the AppStore page, but I would need to provide a ID (or similar) which the AppStore will provide my app, that the respective SDK can track the actual install.
Could you provide me some insight, how this works? Through iTunes Affiliate?
Through Flurry it's really easy if you own the apps:
Flurry SDK must be installed on both the apps (let call them A and B).
On Flurry website goto Company Tab -> "Conversions" -> "Up-Selling" -> "Create New Up-Sell..."
Then add the conversion you are trying to measure for example from A to B (you can also measure B to A separately).
This would make Flurry start measuring this.
For now you cannot measure exactly how many is by your ad at app A or if the user got both apps separately it would still get into that count. The way to measure that is not so complex it's involves Flurry creating a unique ID for the device (they are probably using Advertising ID - IDFA or other unique identifier you can get from the iOS SDK) and if this ID appears on the other app it would count as up sell (if A is before B).
Doing all that on your own without Flurry is too much because you would need servers just for that task. If you are willing to do so just on server side save each user_id (IDFA or other similar) the APP_ID that connected to it (it is pretty easy to get the bundle_id so you could use it or get from the iTunes API the exact APP_ID), then you would have for each device which apps he has that you installed your SDK on. from there you could estimate your conversion rate. On top of that you could register each link press on your server and then have another estimation of clicks from the SDK itself or sending the user to your server with his IDFA (or similar) and APP_ID. To make statistic more valuable you can measure time from the click till the actual running of the advertised app etc.
For now Apple doesn't provide this service themselves. not through iTunes connect or through other systems I know.
Flurry can give you a URL that redirects to your app on the App Store, and they can tell you how many people install the app by using that URL. How do they do this?
I've found the answer on Quora, answered by the CTO of Flurry. They use various data points to tie a certain click to a certain user of the app. They claim to be about 90% accurate.
Data points they use include time of click vs time of install, device type, location of user, etc.
http://www.quora.com/Flurry/How-does-Flurry-user-acquisition-work-1
I setup a Mobile App using the developer's panel and added all the correct information as mentioned in the tutorial video on the Facebook SDK page.
It's a native iOS app so I supplied the bundle ID and the App Store ID. I've installed the SDK and Facebook is registering installs whenever I run it on my device.
However once I tried to use the "Promote" feature to setup install ads it keeps getting rejected by Facebook on the grounds that the URL is bad. The URL works fine as I've tested it multiple times. The URL is generated by Facebook itself using the App ID.
I've tried submitting it again after changing the creative, but I'm assuming I've been blacklisted since it immediately is disapproved.
What can I do?
Is your app limited to a certain region or country?
My ad was also disapproved and this is what I got:
"The destination URL of this ad violates our Ad Guidelines or could not be reviewed. Please check the URL you have submitted to ensure that it is free of any spelling errors and that it complies with our Advertising Guidelines. Please note that all sites must be viewable and functioning properly, regardless of the viewer's location. Additionally, sites are prohibited from linking to proprietary file types (.pdf, .doc, etc,) initiating automatic downloads, or trapping a user's browser in any way (e.g., pop-ups of any kind).
"
In my case the only logical explanation would be the availability of the app, as it is only available in one country. I link directly to the app store so that should not be a problem...
Sorry for my reply, i know it's not very helpful, but there is so little info on the web about it. I need to do detective work in order to understand what is happening.
I had the exact same thing. I think Facebook changed a ton of stuff in their ads dashboard. I created a new ad yesterday and it was finally approved. Try again.