2019 Update: HasOffers has rebranded to TUNE! TUNE is the same great technology behind HasOffers, now enhanced with new tools and features for performance advertisers and affiliate networks. Check out our new platform features page, sign up for a free trial, or read the rebrand announcement.
I downloaded several apps to my new iPad over the weekend and saw something I’d never encountered before when I opened the Hotels.com app. It was so weird I deleted the app and reinstalled it just to see if it was an accident. It was definitely not an accident, but it doesn’t make sense.
Instead of simply launching me into the app, after tapping on the icon, I briefly saw the app screen, got kicked out of the app into Safari, and once Safari finished loading a blank page, I went back to the app. Later, when I went back to Mobile Safari, the blank page was still there. Somewhere along the way, the UX guys at Hotels.com must have been duct-taped in a closet while someone forced this lousy experience on me and millions of other app users.
If you haven’t seen what I’m talking about, watch this video, it should give you a pretty good idea.
Why would a newly installed app launch Mobile Safari?
I happen to have access to some really smart people at HasOffers, so this is exactly what I asked. The technical reasons behind seeing this user experience are rooted in attempting to apply desktop cookie tracking within the limitations imposed on iOS developers. In industry parlance, this is known as “the switch”.
Here’s what happens. Let’s say I download an app from the iTunes App Store which employs “the switch” for tracking purposes. Once the app is installed on my iOS device, I click on the app icon to open it. The app opens and kicks me over to Mobile Safari where Mobile Safari will look for cookie data that gets compared to an event ID. This is followed by either a URL GET to send data to an external tracking engine or an HTTP POST to log the tracking information.
Since I had an organic install, there won’t be a cookie, but that doesn’t matter. Once the cookie state is verified, I’m returned to the application where I can do what I wanted to in the first place, which is use the app.
A Better Way to Track App Installs
Besides cookie tracking, a number of ad networks and publishers utilize Device ID or Mac Address to uniquely identify an app install. When a user clicks an ad, either of these unique identifiers can be collected. An ID can be logged for later comparison against installed applications. Apple has already warned they are eliminating access to Device ID, which means tracking solutions will probably lose Mac Address tracking in the near future as well.
While Device ID and Mac Address tracking solve the user experience problem I’m complaining about, you can’t collect either of them from the mobile web. As a result, mobile app marketers are turning to a broader “fingerprint” tracking solution, like the one we use in Mobile App Tracking, to correlate many pieces of anonymous information from a single device.
Creating this user fingerprint on the mobile web is very different than the process used in tracking transactions that originate from a desktop computer. Not only is the information collected different, but the sandbox restrictions in iOS create unique challenges in matching the data when it gets pulled through the mobile app on install.
Here again, the interruptive user experience created by passing data through Mobile Safari is eliminated.
App Tracking is Necessary
App developers need the ability to track installs. Mobile app tracking allows developers to accurately measure advertising spending. It allows for calculation of cost per install. And it also allows app developers to get important metrics that help improve the in-app experience. That’s the key – tracking needs to support app developers in creating a better experience, not interrupt it.
How do you feel about “the switch”? Would you uninstall an app that launched your browser and left some random tracking URL open in your browser?
Author
Becky is the Senior Content Marketing Manager at TUNE. Before TUNE, she led a variety of marketing and communications projects at San Francisco startups. Becky received her bachelor's degree in English from Wake Forest University. After living nearly a decade in San Francisco and Seattle, she has returned to her home of Charleston, SC, where you can find her enjoying the sun and salt water with her family.
Hello,
How can you prove mobile fingerprinting is reliable? Is there some public research about it?
On mobile Safari, iPhone from Bob is pretty similar to iPhone from Alice…
Thanks
My
opinion on fingerprinting is that it is inaccurate. Here’s
why…
It relies on matching device characteristics between a click and an action
using things like IP address and the device / browser characteristics contained
in the header. Now, if you have a fairly static IP address per device and
a good diversity of device characteristics then maybe you are onto something.
But fact is that in mobile the IP address is highly dynamic, sometimes skipping
IP from page to page viewed. And in some OS – particularly iOS –
the quantity of differing device types is < 50. As a result it is
prone to false matching. Either false positives or false negatives
depending on how tightly you specify your matching algorithms.
Lets be generous and say it's 80% accurate. As we progress more
complex analysis e.g. multi click attribution and in-app action attribution,
then this error compounds. 0.8 * 0.8 * 0.8 = .51. So after only 3
decisions you are in 50/50 territory. Best use a coin eh!
It’s pretty lame that you commented anonymously Ad-x. Your calculations are pretty interesting, but where did you come up with the 80% again? Also, you seem to be missing some crucial elements. We’ll let you figure those out on your own.
For everyone else, this is the verbatim defense Ad-x sends their clients when they complain about the “switch” or safari redirect that occurs from their cookie tracking methods.
Come on, I’ve seen your own Jake Ludington post
your product plugs anonymously as well. And as for your claim that your tracking is superior to
cookie based tracking – I would rather see you guys provide some hard data
instead of trashing your competitors. Just because there is one bad example
(and I agree that the example in your video is quite bad…) that does not mean
that cookie based tracking bad across the board. This is like saying that all
mobile games suck just because you did not like the first game you ever played.
Hi Gordan,
I’ll let Jake respond to the first accusation. I am wondering how you knew it was him if it was anonymous though…
As for “trashing competitors.” I have never trashed a competitor. In fact, the first time I mentioned anything close to a competitor was in this comment thread above, and I still did not trash on you or your technology. To be honest I still don’t know that much about you. So that is flat out wrong. I would like to remind you that you’re the one trashing a competitor on their own corporate blog.
As for cookie tracking for iOS, I don’t quite understand your analogy to mobile games. I guess we’ll have to agree to disagree on that one until we’re ready to more publicly start releasing data.
GordonB,
I
So.. you want a medal for that or what?
does webkitui not work to accomplish the same thing?
No, cookie spaces are disconnected
[…] HTML5 cookies. An alternative approach is to pass a user through the Mobile Safari browser both after she clicks on an ad and after she launches an app for the first time. Although this approach is technically feasible and allows a user to clear cookies and opt-out of tracking, it offers a poor user experience as some have observed. […]
Lol, now that is hilarious, a regular flame war among the corporate elite on a public blog! I do think it’s kinda cheesy that Ad-X did it anonymously, get a clue guys and put your goods out there if that’s what you want to do. Only makes it seem like you have something to hide.
At any rate, their point is a good one Peter/Jake…can you address their accusation more specifically without letting go of your secret sauce?
ha, thanks tboy.
Regarding the accusation that device fingerprinting is like flipping a coin: We currently have a 94% accuracy rate on our platform for iOS. I’m not sure where he’s getting the “let’s be generous and say it’s 80% accurate.” On top of that, you have to take into account that the purpose of browser fingerprinting is not to follow the user for their lifetime, but just between the click and the install. Once the install occurs and we’ve credited that user to an advertisement, we move forward tracking the engagement of that user with an in-app ID.
I find it interesting that while he’s talking about the accuracy of fingerprinting you’re talking about the uniqueness of fingerprinting. Your own documentation states that “device fingerprints are currently 94% unique.” That’s great, except that doesn’t mean that it ever matches anything. One problem with mobile is that IP addresses change randomly and since it’s the only way, in the device headers, to even begin to narrow the user down it is normally always used as the key identifier in any fingerprinting technology. Unfortunately, while it may produce 94% uniqueness, its match percentage may be quite small as the IP may change between the time the ad is viewed and the app is first used. Remember, just because they downloaded the app right away doesn’t mean it was used right away. You can’t begin to match the app until it opens, giving time for the user’s IP to change. Also, many apps are large enough they require the download to be via Wifi, but if the ad is served via a cellular network the IP has changed again. In either case, your user will now have two very unique, but very different fingerprints. The real question I think people should ask is not how accurate fingerprinting is, but what is its match percentage.
Thanks for the response hkb261. Mind telling us who you are so that we know who we’re talking to?
Regarding your “uniqueness” vs “matching” comment:
Actually, the 94% is measured against traffic that also carried UDID or MAC Address, allowing us to measure the accuracy of the matching of one user’s click to the same user’s install. This test has been conducted across a large sample and varied verticals and has now been tested by several of our customers as well, providing the same favorable results. The cases you mentioned above are certainly possibilities for margin of error, and factors that must be considered by our clients as the choose the combination tracking methods and identifiers they will utilize (fingerprint, MAC, ODIN, OpenUDID, TPID, etc.)
Bringing this back to the original thought behind the article, do we have some cookie tracking accuracy numbers in comparison to UDID or MAC Address matching? It would also be very interesting to run a test comparing conversion rates.
You wrote “Actually, the 94% is measured against traffic that also carried UDID or MAC Address, allowing us to measure the accuracy of the matching of one user’s click to the same user’s install.”
You mean between two apps and not between a mobile website within a browser and an app then ?
That is correct Julien. We’re working on accuracy testing for device fingerprint from the mobile web using cookies and other technologies from some of our partners. We certainly have many customers relying on a device fingerprint for web to app tracking currently.
@PeterRyanHamilton:disqus I’m just curious and want to make sure I understood you correct; you’re saying that device fingerprinting works between apps but not mobile-web and app? As I understand from the video, the hotels.com app basically links a mobile-web session/cookie with an app install. So far I haven’t seen anybody be able to do that. And sorry for re-opening an old thread but I was searching around for ways to link app and mobile-web sessions and this was very interesting to read/see.
No worries Andrew. Thanks for posting. Most advertisers and networks doing app to app promotion use alternate identifiers that are available to iOS developers, the most recent being Apple’s ID. In this scenario, the device fingerprint acts as a fall back when other identifiers are not present.
Most of our clients utilize device fingerprint on web to app promotion with a standard lookback period of 24 hours to assume high statistical probability, and this relevance has proven to be very accurate for the purpose of their campaigns. Cookie tracking is also an option for tracking web to app, but not usually an option our clients choose due to the poor user experience. It just isn’t worth the sacrifice.
That’s interesting, can you share more info on how the fingerprinting works between web and in-app?
I wish there was a way around the switch that was as reliable and as simple to implement… Like there is on Android. Until there is, I feel like the best we can do is give a reason for the switch. Like an intro video or an element in the flow that “makes sense” rather than just an epileptic app parade.
Hi, I have a question on cookie tracking. As a mobile inventory supplier, we see more and more publishers utilising WebView to render pages which follow a clicks, as opposed to transferring focus out of an application to the devices default browser such as Safari. (Publishers do not wish to lose attention of their apps users)
In such a scenario an attempt to set a cookie will be carried out within the applications WebView, then following a download the cookie tracking solution will attempt to read the cookie from the default browser.
As far as I am aware, the cookie store between a WebView and a default browser is separate. In such a case how is it possible to attribute an install to the originating click?
You are correct. Webview and Safari are separate and cannot share cookie information.
So… how do we do app install tracking? Is the solution with Has Offers? I’m confused… I have some developers and I have a user base of instructors that I want to pay recurring monthly commissions to for referring new users to us. But I need this to integrate with a beta platform that we are creating… basically we roll out in new cities based on priority of user base (potential subscribers) and amount they are willing to spend to bring us there. So when that happens, we need to message all the users in queue who have entered referral codes given to them by the instructors, and then we need to pay those instructors a recurring amount every month once we get our subscribers.
I love your blog
I have read this article and enjoyed it